How to Set Up MCP-Powered Coding Agents in GitHub Copilot and Xcode

MCP-powered coding agents are finally crossing the line from interesting demos into practical daily tooling. Instead of stopping at inline suggestions or chat answers, coding agents can inspect your repo, plan work, use tools, make changes, run builds or tests, and hand you something concrete to review.

That matters right now because both GitHub and Apple have moved this model closer to normal developer workflow. On the GitHub side, coding agent can work from repository context and use MCP-backed tools. On the Xcode side, Xcode (with agentic coding support) adds agentic coding and can expose Xcode capabilities through the Model Context Protocol, which makes local Apple-platform workflows much more useful than plain copy-paste prompting.

In this tutorial, you will set up a small Swift package, enable coding agents in GitHub Copilot and Xcode, connect MCP-based tools, and run a real workflow: ask the agent to explain the codebase, fix a bug, add tests, and then validate the result before accepting it.

Before you start, make sure you can access GitHub Copilot, open a project in Xcode (with agentic coding support) or later, and authenticate with a supported coding product in Xcode. You do not need a massive codebase for this walkthrough. A tiny Swift package is enough to prove the workflow works end to end.

Step 1: Understand the Moving Parts

Before you flip on features, it helps to understand what each layer is doing. Most agent setup problems are really mental-model problems: the wrong tool is enabled, the agent has the wrong scope, or the developer expects autocomplete behavior from a system designed to complete tasks.

What Agent HQ is

In GitHub, coding agent is not just “Copilot chat, but stronger.” It runs as an autonomous task-oriented workflow tied to your repository and pull request process. Depending on your plan and setup, you can work from the repository’s Agents tab or the global agents page, choose a repository, start a task, and monitor the live session while the agent reads code, edits files, and prepares a pull request.

That is fundamentally different from autocomplete. Autocomplete predicts what comes next at the cursor. A coding agent evaluates a goal, breaks it into steps, navigates your codebase, and works toward an implementation you can review.

What Xcode agentic coding does

Xcode (with agentic coding support) adds a similar shift locally. Instead of only generating snippets, Xcode can work with an external coding agent that uses Xcode-provided capabilities to inspect your project, search Apple documentation, build, test, and iterate. That means your Xcode setup can become a real execution environment for agent work rather than just a text editor that sends prompts to a model.

Where MCP fits in

MCP is the glue between models and tools. A model alone can reason over text you send it, but MCP lets the agent use structured tools and external context in a standardized way. In practice, that means things like:

• repository and issue access
• build and test commands
• documentation lookup
• bug and exception context
• issue tracker or deployment data

On GitHub, MCP can expose tools from configured servers to coding agent. In Xcode, MCP is how external coding tools can access Xcode capabilities such as build, test, and documentation search.

A good working model is this:

• GitHub coding agent is ideal for background repo tasks that should end in a pull request.
• Xcode agentic coding is ideal for interactive local development, debugging, and Apple-platform context.
• MCP is what gives both of them access to more than plain text.

You should now understand why this setup is more powerful than autocomplete alone, and why GitHub plus Xcode plus MCP is a useful combination rather than three unrelated features.

Step 2: Enable Coding Agents in GitHub

This step gets GitHub Copilot coding agent working on a repository you control. The goal is to make sure the agent can see the repo, start a task, and operate in the right place before you add any extra MCP tools.

Create a tiny practice repository

If you do not already have a safe repo to test with, create a small Swift package. This gives you something Xcode can open and GitHub can operate on.

Create a new folder and initialize the package:

mkdir AgentPlayground
cd AgentPlayground
swift package init --type library
mkdir -p Sources/AgentPlayground
mkdir -p Tests/AgentPlaygroundTests

Replace Package.swift with:

// swift-tools-version: 6.0
import PackageDescription

let package = Package(
    name: "AgentPlayground",
    products: [
        .library(
            name: "AgentPlayground",
            targets: ["AgentPlayground"]
        )
    ],
    targets: [
        .target(
            name: "AgentPlayground"
        ),
        .testTarget(
            name: "AgentPlaygroundTests",
            dependencies: ["AgentPlayground"]
        )
    ]
)

Create Sources/AgentPlayground/TipCalculator.swift:

import Foundation

public enum TipCalculator {
    public static func total(amount: Double, tipPercent: Int) -> Double {
        let tip = amount * Double(tipPercent / 100)
        return amount + tip
    }
}

This file has an intentional bug: tipPercent / 100 performs integer division before conversion, so 15 / 100 becomes 0.

Commit the repo:

git init
git add .
git commit -m "Create AgentPlayground sample"

Push it to a new GitHub repository:

git branch -M main
git remote add origin git@github.com:YOUR-USER/agent-playground.git
git push -u origin main

Turn on GitHub Copilot coding agent access

GitHub Copilot coding agent availability depends on your plan and admin settings. As an individual subscriber, it may already be enabled. In Business or Enterprise environments, an administrator may need to enable it first and allow repository access.

At a high level, check these items:

1. Open GitHub Copilot settings.
2. Confirm coding agent is enabled for your account or organization.
3. Confirm your target repository is included in repository access.
4. Open the repository and look for the Agents tab or use the global agents page.

Start your first agent session

Open the repository in GitHub, then start a new task from the Agents tab or the global agents page. Choose your repository and base branch.

For your first task, use a read-only prompt that proves the agent can see the repo:

Explain the structure of this repository. Identify the package name,
the main target, and the file most likely responsible for tip
calculations. Do not make any changes yet.

A good response should mention:

• the AgentPlayground package
• the AgentPlayground target
• Sources/AgentPlayground/TipCalculator.swift

If your plan includes multiple agents or model choices, choose the default Copilot coding agent first. Do not optimize model selection before you confirm basic repository access works.

Verify the agent can see the codebase

The easiest verification is not whether the session starts. It is whether the agent can accurately describe files, targets, and likely edit locations without hallucinating.

You should now see a session that can name your package, identify TipCalculator.swift, and reference the repository structure correctly. If it cannot, stop here and fix repository access before moving on.

Step 3: Set Up Agentic Coding in Xcode

Now you will configure the local side of the workflow. The goal is to connect a supported coding product inside Xcode, enable Xcode’s MCP-backed tools, and confirm the agent can inspect your project context.

Open the same project in Xcode

From the repo root, open the Swift package in Xcode:

xed .

If xed is not available, open Xcode manually and select the Package.swift file or folder.

Enable coding intelligence and connect a supported agent

In Xcode, open:

Xcode > Settings > Intelligence

From there, enable the coding product you want to use. Xcode (with agentic coding support) supports direct setup flows for supported coding agents, and the coding assistant lets you choose which product to use in a conversation.

If the product requires authentication, sign in and finish setup before you continue.

Choose an agent in the coding assistant

Open the coding assistant in Xcode. In the coding assistant toolbar, start a new conversation and use the product picker to select the coding product you enabled.

Use this first prompt:

Inspect the open Swift package and explain where the business logic
lives, where tests should go, and which file you would change to fix
the tip calculation bug. Do not edit anything yet.

A good answer should identify:

• business logic in Sources/AgentPlayground/TipCalculator.swift
• tests in Tests/AgentPlaygroundTests
• the bug likely being related to percentage calculation

Confirm the agent has real project context

Now test whether Xcode is giving the agent useful context instead of just raw prompt text. Ask:

Before making changes, list the package target names and summarize the
current implementation of TipCalculator.total(amount:tipPercent:).

If the response matches the actual code, Xcode is successfully passing project context.

You should now have a working Xcode conversation that can see the open project, identify your Swift package structure, and reason about the bug location before editing code.

Step 4: Add MCP-Based Context and Tools

This is where the workflow becomes meaningfully “agentic” rather than just chat with file context. In this step, you will wire tool access into GitHub and enable Xcode’s MCP-based Xcode Tools so the agent can do more than edit source text.

Add a repository-level MCP configuration in GitHub

On GitHub, open your repository and navigate to:

Settings > Copilot > Coding agent

Find the MCP configuration area and add a minimal configuration. For a first setup, a read-only GitHub MCP configuration is a good starting point because it keeps the scope narrow.

Use this JSON:

{
  "mcpServers": {
    "github-mcp-server": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/readonly",
      "tools": ["*"],
      "headers": {
        "X-MCP-Toolsets": "repos,issues,pull_requests,actions,web_search"
      }
    }
  }
}

This configuration keeps the server in read-only mode and limits access to a subset of GitHub toolsets. It is not the tightest possible configuration, but it is a practical first step for learning and verification. Check GitHub’s current MCP documentation for the latest endpoint URLs and configuration options, as these may change.

Add secrets only if your MCP server needs them

Some MCP servers need API keys or tokens. In GitHub, create a repository environment named copilot and add secrets or variables prefixed with COPILOT_MCP_.

For example:

• COPILOT_MCP_SENTRY_AUTH_TOKEN
• COPILOT_MCP_GITHUB_PERSONAL_ACCESS_TOKEN

If your server needs extra dependencies at runtime, you may also need a copilot-setup-steps.yml workflow so the agent environment can install them before starting the server.

For this tutorial, you can skip that unless your MCP server requires custom setup.

Enable Xcode Tools for external agents

In Xcode, go back to:

Xcode > Settings > Intelligence

Under Model Context Protocol, turn Xcode Tools on.

That setting is what lets supported external agents use Xcode capabilities through MCP. In practice, that can include actions such as:

• building the project
• running tests
• reading diagnostics
• searching Apple documentation relevant to the code

Test MCP-backed tool access

Use a tool-oriented prompt in GitHub first:

Using the available tools, summarize the open issues and pull requests
for this repository, then explain whether there is already a tracked
bug related to tip calculation. Do not make changes.

Then use a tool-oriented prompt in Xcode:

Use Xcode tools to inspect the project, then tell me whether the
package builds cleanly right now and what would need to change to add
regression tests for TipCalculator.

A successful result will usually mention tool activity, project inspection, build/test context, or documentation lookup rather than returning a purely generic answer.

You should now have MCP-backed tools working in GitHub and Xcode: GitHub through repository MCP configuration, and Xcode through Xcode Tools exposed to the coding product.

Step 5: Run a Real Task

Now that the plumbing is in place, you can run an actual agent workflow. The safest first task is narrow, testable, and easy to review: fix a simple bug and add regression tests.

Ask the agent to explain architecture before changing code

Start with this prompt in either GitHub or Xcode:

Before editing anything, explain the architecture of this package in
5 bullet points. Then propose the smallest safe change needed to fix
the tip calculation bug and the tests you would add.

This is an underrated pattern. It forces the agent to demonstrate understanding before it starts changing files. If the explanation is wrong, you can correct it early instead of reviewing a broad, low-quality diff later.

Ask GitHub coding agent to fix the bug

Create an issue in GitHub with a tightly scoped description:

Title: Fix tip percentage calculation and add regression tests

Body:

The function `TipCalculator.total(amount:tipPercent:)` currently
calculates the tip incorrectly because the percentage math uses
integer division.

Please:
1. Fix the bug so `tipPercent = 15` on `amount = 100` returns `115.0`
2. Add focused regression tests for 0%, 15%, and 20%
3. Keep the change minimal
4. Do not add new dependencies

Assign the issue to Copilot coding agent, or start an agent task from the Agents tab with that same instruction.

A good GitHub agent run should:

• inspect TipCalculator.swift
• update the calculation
• create a test file
• open a pull request with a concise summary

Ask Xcode agentic coding to do the same locally

In Xcode, use this prompt:

Fix the bug in TipCalculator.total(amount:tipPercent:). Then add
XCTest regression tests for 0%, 15%, and 20%. Build or test the
package after your changes and summarize exactly what you changed.

If you want a smaller first pass, split it into two prompts:

1. Fix the bug only.
2. Add tests and run them.

That gives you tighter control and makes the diff easier to review.

What the fixed code should look like

A correct implementation in Sources/AgentPlayground/TipCalculator.swift should end up functionally equivalent to this:

import Foundation

public enum TipCalculator {
    public static func total(amount: Double, tipPercent: Int) -> Double {
        let tip = amount * (Double(tipPercent) / 100.0)
        return amount + tip
    }
}

And a focused test file at Tests/AgentPlaygroundTests/TipCalculatorTests.swift should look like this:

import XCTest
@testable import AgentPlayground

final class TipCalculatorTests: XCTestCase {
    func testZeroPercentTip() {
        XCTAssertEqual(TipCalculator.total(amount: 100.0, tipPercent: 0), 100.0, accuracy: 0.0001)
    }

    func testFifteenPercentTip() {
        XCTAssertEqual(TipCalculator.total(amount: 100.0, tipPercent: 15), 115.0, accuracy: 0.0001)
    }

    func testTwentyPercentTip() {
        XCTAssertEqual(TipCalculator.total(amount: 100.0, tipPercent: 20), 120.0, accuracy: 0.0001)
    }
}

You should now have either a GitHub pull request or a local Xcode change set that fixes the bug and adds regression tests.

Step 6: Review and Validate Outputs

This step is where most of the value is won or lost. A coding agent that can produce code is useful. A developer who can rapidly validate and shape that code is where the real productivity gain appears.

Review the diff before reading the summary

Agent summaries are helpful, but the diff is still the source of truth. Check:

• Did it only touch TipCalculator.swift and the test file?
• Did it avoid unrelated formatting churn?
• Did it change project settings or dependencies without being asked?
• Did it add tests that actually match the bug?

If the change set is broader than expected, ask for a narrower revision instead of hand-fixing everything yourself.

Run tests locally

From the repository root, run:

swift test

If you prefer to validate through Xcode’s toolchain directly, you can also build and test from the command line:

xcodebuild test \
  -scheme AgentPlayground \
  -destination 'platform=macOS'

For this sample package, swift test is the simplest confirmation.

Check for risky changes

If the agent changed anything outside the requested scope, review those files carefully. This is especially important if the run involved MCP tools, build/test automation, or third-party context sources.

Use this checklist:

• No new dependency was added without a reason
• No secret, token, or credential reference was introduced
• No project settings changed unexpectedly
• Tests cover the intended regression
• The implementation is the minimal reasonable fix

Iterate with targeted feedback

If the output is close but not mergeable, give precise instructions instead of starting over. For example:

Keep the calculation fix, but rewrite the tests to be more explicit
and avoid repeated literal values. Do not modify production code.

Or:

The bug fix is correct, but the diff is too broad. Revert unrelated
formatting changes and keep only the functional fix and regression tests.

You should now have a validated result: reviewed diff, passing tests, and a clear understanding of what the agent changed and why.

Step 7: Put Guardrails Around Usage

Once the workflow works, the next goal is not “use agents everywhere.” It is to make them predictably useful. Good guardrails turn agents into leverage. Bad or missing guardrails turn them into cleanup work.

Limit permissions and scope

In GitHub:

• keep repository access limited to the repos that actually need coding agent
• keep MCP servers narrow and read-only unless broader access is justified
• prefer allowlisted tools over wide-open * configurations in production
• avoid giving MCP servers unnecessary secrets

In Xcode:

• enable only the coding products you actually use
• keep tasks tightly scoped
• avoid letting the first prompt combine architecture changes, dependency changes, and bug fixes in one shot

Create a custom GitHub agent for narrow bug-fix work

A custom agent is a good way to enforce consistent behavior for repetitive work. Create .github/agents/bugfix-ios.agent.md:

---
name: bugfix-ios
description: Specialized agent for narrow Swift bug fixes and regression tests
tools: ['read', 'search', 'edit']
---

You are a Swift maintenance agent.

Rules:
- Focus only on the files required to fix the requested bug.
- Prefer the smallest safe change.
- Add or update regression tests when behavior changes.
- Do not add dependencies.
- Do not change package configuration or build settings unless explicitly asked.
- Explain your plan before making broad edits.
- If the task is ambiguous, choose the most conservative implementation and note assumptions in the summary.

This will not solve every quality issue, but it makes the default behavior more predictable.

Decide which tasks agents should and should not do

Good tasks for coding agents:

• focused bug fixes
• adding or tightening tests
• small refactors
• documentation updates
• repetitive mechanical changes
• generating a first draft of a feature with clear constraints

Bad first candidates:

• auth redesigns
• billing or money movement logic
• large schema migrations
• security-sensitive rewrites
• incident response changes
• ambiguous product work with no acceptance criteria

Keep humans in the review loop

The winning pattern is not “agent replaces developer.” It is “agent does the first pass, human owns acceptance.” That means:

• the human defines scope
• the agent executes
• the human reviews, tests, and merges

The best teams keep the merge decision human, even when the task itself is heavily automated.

You should now have both the technical setup and the operational guardrails needed to make MCP-powered coding agents useful without turning them loose on everything.

Common Setup Problems

Agent cannot access the project

Symptoms:

• The GitHub agent cannot start on the repo
• The Xcode agent gives generic answers and cannot identify files
• The repo is missing from the selection UI

Likely causes:

• GitHub coding agent is disabled for your plan, org, or repository
• Your repository is outside the allowed access list
• In Xcode, the coding product is not fully enabled or authenticated
• The wrong folder or project is open in Xcode

Fix:

1. In GitHub, confirm coding agent is enabled and the repository is allowed
2. In Xcode, reopen Xcode > Settings > Intelligence and verify the product setup
3. Reopen the actual project or package root, not a parent directory
4. Re-run a read-only prompt that asks the agent to name files before asking it to edit code

MCP tool is not recognized

Symptoms:

• GitHub accepts the config but the tool never appears in logs
• The agent behaves as if no tools are available
• Xcode agent cannot build, test, or search docs through Xcode tools

Likely causes:

• Invalid JSON in repository MCP settings
• Missing COPILOT_MCP_ secret or variable prefix
• The MCP server requires dependencies or setup not present in the agent environment
• Xcode Tools is not enabled under Model Context Protocol

Fix:

1. Re-check the JSON carefully for commas, quotes, and object nesting
2. Confirm secrets and variables use the COPILOT_MCP_ prefix
3. Review the session log for the Start MCP Servers step in GitHub
4. In Xcode, turn Xcode Tools on again and restart the conversation

Context is incomplete

Symptoms:

• The agent edits the wrong file
• It describes the architecture incorrectly
• It misses obvious tests or modules

Likely causes:

• Your prompt is too vague
• The repo structure is unclear
• The agent started editing before proving understanding
• There are not enough explicit constraints in the task

Fix:

Start with an architecture-first prompt like:

Before editing anything, summarize the package structure, identify the
exact files you plan to change, and explain why.

Then follow with the edit request only after the explanation is correct.

Generated changes are too broad

Symptoms:

• The agent reformats unrelated files
• It changes config, package, or build settings without being asked
• The pull request is much larger than the problem

Likely causes:

• The task was underspecified
• The agent was allowed too much freedom
• The instruction did not define what not to touch

Fix:

Use narrower prompts:

Fix only the bug in TipCalculator.total(amount:tipPercent:). Add
regression tests. Do not change dependencies, formatting outside
edited files, or package configuration.

If needed, create a custom agent with explicit scope rules and use that instead of the default agent.

Wrap-Up

You now have a working cross-tool setup for MCP-powered coding agents in GitHub Copilot and Xcode. You enabled GitHub coding agent, configured Xcode agentic coding, turned on MCP-backed tool access, ran a real bug-fix task, and validated the output with tests and diff review.

The next useful things to automate are small and repetitive: regression tests, documentation updates, narrow refactors, and issue-driven bug fixes. Once those are reliable, add custom agents and more specific MCP servers so the workflow becomes sharper rather than broader.

As a rule of thumb, use one agent for a tightly scoped task that should end in a single reviewed change. Use multiple agents or products when you want to compare approaches, separate exploratory local work from repository PR work, or specialize one agent for tests and another for implementation. The reason to do this now is simple: the GitHub and Xcode pieces have become close enough to real development flow that the time spent setting them up can finally pay back in everyday work instead of staying a novelty.