Exploring MCP: GitHub MCP for iOS Dev in VS Code, Cursor & Windsurf

{
    "mcp": {
        "servers": {
            "github": {
                "command": "docker",
                "args": **["run",](https://opengraph.githubassets.com/15f24db746c021105996f371653fcfadc5f5e8ac3407a0d3ce9e17fe90fc126e/rryam/MusadoraKit/issues/51)**
 
"
 
](https://github.com/rryam/MusadoraKit/issues/51)
 
On top of all that, it automatically added appropriate labels like `enhancement` and `security` to the issue on GitHub!
 
A moment later, Copilot confirmed in the chat: `"I've created a new issue (#51)..."` with a summary. A quick switch to my browser confirmed it – Issue #51 was live, created and detailed by the AI based on a single-line request and the code context!
 
### Implementing the Change and Handling Git Steps
 
Again, my lazy self wanted the implementation to be done by AI, too. My prompt: `"now implement this issue and also create a PR for it"`.
 
Copilot outlined its plan:
 
* Create a new feature branch.
* Implement the `TokenManager` (a new file/class).
* Update `MusadoraKit.swift` to use the new manager.
* Create a Pull Request (PR) for the changes.
 
First, it used the `create_branch` tool, naming the branch `feature/token-manager` based on the issue's intent.
 
Copilot generated a new `TokenManager.swift` file, presumably using Keychain for secure storage, as hinted in the issue description it created earlier. It also modified the original `MusadoraKit.swift`, removing the old logic and integrating calls to the new `TokenManager.shared` instance. It showed me the diffs for review.
 
But I saw some interplay between the AI and Git workflow. Copilot attempted to use `create_pull_request`it, but it failed initially.
 
Why? As Copilot correctly diagnosed, the newly generated code and modifications only existed _locally_ on my machine. They had not been committed or pushed to the remote `feature/token-manager` branch on GitHub yet. A PR needs remote changes to compare against the target branch.
 
Recognizing this, Copilot automatically pivoted and used the `push_files` tool. This staged the local changes, crafted a commit message (like "Add secure token management with TokenManager"), and pushed the commit to the remote feature branch on GitHub.
 
### Cre**ating the Pull Request**
 
With the code now on GitHub's servers, Copilot re-attempted the final step of its plan: running `create_pull_request` again.
 
It confirmed in the chat: `"I've successfully completed the implementation and created both the issue (#51) and pull request (#52)..."`. Back to the browser, I refreshed the Pull Requests page – and there it was, PR #52, opened via the MCP wrapped GitHub API.
 
Again, like the issue, the PR turned out to be more than a mere title and a link to the commit. The AI had generated a detailed description in the PR body and it automatically included `Fixes #51` to link it correctly to the issue we started with.
 
The description detailed the _Changes_ (introducing the new `TokenManager` class using Keychain, deprecating the old property), highlighted the _Security_ improvements, provided a _**Migration** **Guide**_ with code snippets showing existing users how to adapt, and even included notes on the _Testing_ performed. It essentially wrote its own release notes for the change, ready for review.
 
**[Implement Secure Token Management by rudrankriyam · Pull Request #52 · rryam/MusadoraKit](https://github.com/rryam/MusadoraKit/pull/52)**
 
### Build Check
 
Before merging, a sanity check: does the code actually build?
 
I initially tried running `swift build` in my VS Code terminal, but it failed, complaining it could not find `TokenManager`. This was _my_ error because I had not explicitly accepted the file changes Copilot made into my local workspace yet via the chat interface's diff view ("Keep" vs "Discard"). A reminder to be mindful when the AI modifies your files!
 
To get a proper check, I asked Copilot: `"please build and go through the build logs"`.
 
Copilot confirmed it would use its terminal access to run `swift build -v` (verbose) within the project directory. After the compilation finished, it analyzed the output and reported: `"The build completed successfully... with no errors"`, though it did note some expected deprecation warnings. Build passed!
 
### Merging the Pull Request
 
The final step was merging the approved and validated PR. I started with a general request: `"please merge the PR for it"`.
 
Interestingly, Copilot stumbled here. It responded that it could not find a mergeable PR or needed more specifics. It seemed to have lost the context of PR #52 we had just been working on.
 
Okay, I went a bit more explicit: `"please merge the PR #52"`.
 
It _still_ hesitated, listing generic reasons why a PR might not be merge able (conflicts, failed checks, etc.) and asking for the PR number again, even though I just provided it! This highlights that these AI agents, while powerful, are not infallible.
 
> Maybe this was an issue with VS Code, or the model that I was using (free `o4-mini`). Cursor with Gemini 2.5 Pro or Claude 3.7 Sonnet is my default combination.
 
So, I bypassed the conversational ambiguity and called the tool directly using the `#` syntax provided by Copilot chat: `#merge_pull_request 52`.
 
_That_ did the trick. Copilot immediately understood it needed to execute the `merge_pull_request` tool with the parameter the request number of `52` for the given repository. It ran the command.
 
A final switch to the GitHub PR page in my browser and one last refresh showed the satisfying purple "Merged" indicator. The AI had successfully merged the pull request, completing the entire workflow from issue creation to merged code, _almost_ entirely driven by chat commands with the GitHub MCP server.
 
## What's Next
 
It is not _always_ perfect. Here are some things I have learned:
 
* **Be Specific:** Vague prompts give vague results. Include branch names, PR numbers, or its title, whenever possible.
* **PAT Scopes are Key:** If an action fails with a 401/403 error, your PAT may not have the required permission (e.g., trying to create a repo without `repo` scope).
* **Secure Tokens:** Avoid hard coding tokens if your IDE supports prompting (like VS Code's `${input:github_token}`). If you must hard code (maybe in Cursor/Windsurf), ensure the config file has restrictive permissions.
* **Check Docker:** If the agent is not responding, make sure your Docker container for the MCP server is actually running (`docker ps`). Check its logs (`docker logs <container_id>`) for errors.
* **Limit Toolsets:** If the AI seems confused or slow, try limiting the enabled tools `GITHUB_TOOLSETS` as shown earlier. Even Cursor will prompt you that more than 40 tools degrade the performance. Sometimes, less is more.
* **Combine Servers?** You can configure multiple MCP servers (like the GitHub one, Xcode one, or Supabase). This opens up complex workflows, like fetching data from Supabase and committing a generated Swift model file to GitHub in one go!
 
For common, well-defined GitHub tasks like creating branches, making quick comments, and finding issues, using the GitHub MCP server via the chat is faster than switching apps for me, and writing those verbose descriptions.
 
Is it perfect? Not always. Complex tasks or ambiguous prompts can still trip up the model. And it depends on which model you use as well.
 
Also, the best AI IDE for MCPs is probably the one you already use or are most comfortable with. The core GitHub MCP server works the same way underneath.
 
Happy MCP-ing!