GitHub Copilot is moving beyond code completion and chat into agent-based development. In a JetBrains IDE, Copilot can work with project files, run development tools, and use Model Context Protocol (MCP) servers to access additional tools and services.

That flexibility is useful, but it also creates another question for developers:

Which MCP tools should Copilot be allowed to use, and which ones should require approval or remain disabled?

Copilot for JetBrains 1.18.0 adds more control over MCP usage. The release includes a setting to enable or disable the built-in GitHub MCP Server independently of manually configured MCP servers, along with persistent per-tool controls for MCP servers in agent sessions.

These controls are important because an MCP server is not simply another source of documentation. It can expose actions that allow an AI agent to interact with repositories, issues, pull requests, and other systems.

What Is MCP?

Model Context Protocol, commonly called MCP, is a protocol for connecting AI applications with external tools and data sources.

Instead of keeping an AI assistant isolated from the rest of the development environment, MCP provides a standardized way to expose capabilities to the model.

A simplified architecture looks like this:

JetBrains IDE
      |
      v
GitHub Copilot
      |
      v
MCP Client
      |
      +------------------+
      |                  |
      v                  v
MCP Server          MCP Server
      |                  |
      v                  v
GitHub Tools        Other Tools

An MCP server can expose multiple tools.

For example, the GitHub MCP Server can provide access to repository information, issues, pull requests, and other GitHub capabilities.

This means developers need to think about permissions at more than one level.

Why MCP Controls Matter

Consider a normal coding request:

Find the authentication bug
and explain what is wrong.

Copilot may only need project files.

Now consider:

Find the authentication bug,
create an issue describing it,
and update the related pull request.

The second request requires access beyond the local codebase.

The agent may need to use:

Repository
   |
   +---- Issues
   |
   +---- Pull Requests
   |
   +---- Repository Data

The ability to perform those operations is useful, but it also increases the permission surface.

This is why MCP controls matter.

What Changed in Copilot for JetBrains 1.18?

Copilot for JetBrains 1.18.0 introduced two notable MCP controls:

  1. A setting to enable or disable the built-in GitHub MCP Server.

  2. Persistent per-tool controls for MCP servers in Copilot agent sessions.

The built-in GitHub MCP Server remains enabled by default, but developers can control it separately from manually configured MCP servers.

The per-tool controls are particularly useful because developers do not always need every capability provided by an MCP server.

Instead of thinking:

MCP Server = Allow Everything

the workflow can become:

MCP Server
   |
   +---- Tool A -> Allow
   |
   +---- Tool B -> Ask
   |
   +---- Tool C -> Disable

That provides a more granular permission model.

Built-In GitHub MCP Server vs Custom MCP Servers

It is useful to distinguish between the built-in GitHub MCP Server and manually configured MCP servers.

MCP Configuration

Purpose

Control

Built-in GitHub MCP Server

GitHub-related capabilities

Can be enabled or disabled

Manually configured server

External or custom tools

Configured separately

Individual MCP tool

Specific operation exposed by a server

Can have persistent controls

Enterprise-managed server

Organization-approved capability

Controlled by administrators

The 1.18 JetBrains update specifically makes the built-in GitHub MCP Server setting independent from manually configured servers.

That separation is useful for developers who want GitHub's built-in capabilities without changing their other MCP configuration.

What Can the GitHub MCP Server Do?

The GitHub MCP Server allows Copilot to interact with GitHub features directly from the IDE.

GitHub documents examples such as:

  • Retrieving repository information

  • Listing pull requests

  • Creating issues

  • Working with other GitHub features exposed through the server

The exact capabilities depend on the available tools and the user's permissions for the corresponding GitHub features.

For example, a developer could ask:

List the open pull requests for this repository.

The MCP server can provide the relevant GitHub information through Copilot.

A more action-oriented request could be:

Create an issue describing the failing integration test.

That request can result in an external change rather than simply an informational response.

Read Operations and Write Operations

One of the easiest ways to understand MCP permissions is to separate read operations from write operations.

Read Operations

Examples include:

List repository information
Read issue details
List pull requests
Inspect repository metadata

These operations primarily retrieve information.

Write Operations

Examples include:

Create an issue
Modify an issue
Create or modify repository resources
Perform another external action

These operations can change external state.

The distinction is important because a developer may be comfortable allowing Copilot to inspect GitHub but may want confirmation before it changes anything.

Per-Tool Controls

A server can expose many tools.

For example:

GitHub MCP Server
    |
    +---- list_repository
    |
    +---- get_issue
    |
    +---- list_pull_requests
    |
    +---- create_issue
    |
    +---- update_issue

You may need only the first three for a particular development workflow.

Persistent per-tool controls let developers manage individual tools rather than treating the complete server as one permission unit. GitHub specifically identifies persistent per-tool controls as part of the JetBrains 1.18 update.

This is especially useful when an MCP server exposes both read and write capabilities.

A Practical Example

Suppose you are working on a Java application and ask:

Check whether there are existing GitHub issues
related to the NullPointerException in UserService.

Copilot may need to:

Search local project
       |
       v
Understand the error
       |
       v
Query GitHub
       |
       v
Read matching issues
       |
       v
Summarize findings

No issue needs to be created.

Now compare that with:

Create a GitHub issue for this confirmed bug.

The final operation changes external state.

A sensible workflow separates the two:

Investigate
    |
    v
Review findings
    |
    v
Decide whether an issue is required
    |
    v
Create issue

The MCP tool controls help establish that boundary.

Why Persistent Controls Are Useful

Without persistent controls, developers may repeatedly encounter the same approval decisions.

Imagine an agent repeatedly using the same repository-read operation:

Request -> Approve
Request -> Approve
Request -> Approve
Request -> Approve

For a trusted operation, this can become distracting.

A persistent control can reduce repeated interruptions.

However, persistence should be treated carefully.

A permission that is convenient for today's task may not be appropriate for a different task tomorrow.

Persistent Permission Is Not the Same as Permanent Trust

Developers should avoid thinking:

I approved this tool once,
so it is always safe.

Instead, think:

I am allowing this tool
within a particular development context.

This distinction becomes important when:

  • The repository changes

  • The MCP server changes

  • Tool capabilities are updated

  • The task becomes more sensitive

  • Organization policies change

Permission management should therefore be reviewed periodically.

MCP Controls and Agent Mode

MCP becomes particularly relevant when using Agent mode.

GitHub describes Agent mode as a workflow where Copilot can autonomously work toward a development task and use tools as necessary.

A normal chat request might be:

What does this method do?

An agent request could be:

Investigate this bug, check related GitHub issues,
and update the implementation if appropriate.

The second request can involve several tools.

A possible workflow is:

User Request
     |
     v
Agent
     |
     +---- Local project search
     |
     +---- Local file inspection
     |
     +---- GitHub MCP query
     |
     +---- Code modification
     |
     +---- Tests
     |
     v
Result

MCP controls therefore become part of the agent's overall permission model.

MCP Tools Can Affect External Systems

This is one of the most important differences between MCP and ordinary code completion.

A code suggestion normally stays inside the editor until the developer accepts it.

An MCP tool may interact with an external service.

For example:

AI
 |
 v
MCP Tool
 |
 v
GitHub API
 |
 v
Issue Created

The operation has crossed the boundary of the local development environment.

That makes access control particularly important.

MCP Tool Permissions vs GitHub Permissions

There are two separate permission layers to consider.

Copilot or MCP Permission

Can Copilot invoke the tool?

GitHub Permission

Does the authenticated user have permission to perform the underlying GitHub operation?

The second layer still matters.

GitHub notes that individual tools in the GitHub MCP Server inherit the access requirements of the corresponding GitHub features.

So allowing an MCP tool does not automatically give the user permissions they do not already have on GitHub.

A simplified model is:

Copilot Permission
       |
       v
MCP Tool Allowed?
       |
       v
GitHub Authentication
       |
       v
GitHub Authorization
       |
       v
Operation

All relevant layers must permit the action.

Enterprise MCP Governance

Individual developers are not always the only people responsible for MCP configuration.

Organizations and enterprises can manage MCP usage centrally.

GitHub provides MCP management features that allow administrators to control which MCP servers developers can use. Administrators can configure allowlists and, in supported environments, use a custom MCP registry.

This is important for organizations that need consistent security and compliance controls.

A company might decide:

Approved MCP Servers
    |
    +---- GitHub MCP Server
    +---- Internal Documentation Server
    +---- Approved Testing Server

while blocking unknown or unapproved servers.

Enterprise Allowlist and Denylist Controls

GitHub's enterprise-managed settings support centralized MCP server controls, including allowedMcpServers and deniedMcpServers for Copilot in JetBrains.

Conceptually:

Enterprise Policy
       |
       +---- Allow Server A
       |
       +---- Allow Server B
       |
       +---- Deny Server C

This prevents every developer from independently deciding which external AI tools can connect to the organization's development environment.

That is especially useful in larger teams.

Managed Settings Can Override Local Choices

Enterprise management can also affect permission behavior beyond MCP servers.

GitHub's enterprise-managed settings support controls for operations that can be allowed, denied, or require fresh approval.

GitHub also documents enterprise-managed sandbox policies for JetBrains that can control areas such as filesystem access, network access, proxy settings, developer-tool access, and other sandbox behavior. Managed restrictions take precedence over user settings.

This creates a hierarchy:

Enterprise Policy
       |
       v
IDE / Copilot Configuration
       |
       v
MCP Configuration
       |
       v
Individual Tool
       |
       v
Agent Action

A developer may therefore see a setting that is locked because it is controlled by the organization.

MCP Registries

An MCP registry provides a way to organize and discover MCP servers.

GitHub documents support for configuring an MCP registry in supported IDE environments. The registry can provide a customized list of servers available to developers.

This can be useful for organizations that want developers to discover approved integrations without manually configuring every server.

For example:

Company MCP Registry
       |
       +---- Documentation
       +---- GitHub
       +---- Testing
       +---- Internal APIs

The registry approach can make MCP adoption more manageable across a development team.

Toolsets and Fine-Grained Control

MCP servers can expose many capabilities.

GitHub's documentation also provides configuration options for toolsets and tools for the GitHub MCP Server, allowing more fine-grained control over which capabilities are available.

This matters because developers do not necessarily need every capability.

For example:

GitHub MCP
    |
    +---- Repository Read
    +---- Issues
    +---- Pull Requests
    +---- Actions
    +---- Other Capabilities

A development workflow might only need repository and issue information.

Restricting unnecessary capabilities reduces the number of operations an agent can perform.

A Practical Development Scenario

Imagine a team maintaining an ASP.NET Core application.

A developer asks:

Investigate why the payment API test is failing.
Check related GitHub issues and suggest a fix.

The agent may need:

Local Code
    |
    v
Test Failure
    |
    +----> GitHub MCP
    |          |
    |          v
    |     Existing Issues
    |
    v
Potential Fix

At this stage, read-only GitHub access may be enough.

Now the developer says:

Create an issue if this is a confirmed regression.

The agent now needs a write operation.

The workflow changes:

Investigate
   |
   v
Confirm Regression
   |
   v
Create Issue

A per-tool permission model makes this distinction easier to enforce.

Common Mistakes

Enabling Every MCP Server

More integrations do not automatically mean a better development workflow.

Each server increases the capabilities available to the agent.

Allowing Every Tool From a Trusted Server

A trusted server can still expose tools you do not need.

Confusing MCP Access With GitHub Authorization

Allowing a tool does not bypass GitHub's own permissions.

Forgetting External Side Effects

An MCP operation can modify resources outside the IDE.

Using Persistent Permissions Without Reviewing Scope

Persistent controls can remain useful after the original task is finished.

Ignoring Enterprise Policies

A local configuration may not override an organization-managed restriction.

Troubleshooting MCP Issues

When an MCP tool is unavailable, work through the configuration layers.

1. Check Whether MCP Is Enabled

Verify that MCP is available in the Copilot environment.

2. Check the Server

Confirm that the required MCP server is configured and available.

3. Check the Specific Tool

A server can be available while an individual tool is disabled or restricted.

4. Check Authentication

For GitHub operations, verify that the account has the required access.

5. Check Enterprise Policies

An organization may restrict available MCP servers.

6. Check the Requested Operation

A read operation may be permitted while a write operation requires additional approval.

7. Check the IDE and Copilot Version

MCP capabilities and controls can change between releases. GitHub recommends using current supported versions for the latest Copilot functionality.

Best Practices for Developers

Start With the Minimum Required Tools

If the task only needs repository search, do not enable unrelated external tools.

Separate Read and Write Operations

Treat information retrieval differently from actions that modify external systems.

Review Persistent Permissions

Remove permissions that are no longer needed.

Use Approved MCP Servers

For enterprise environments, follow the organization's approved-server policy.

Prefer Fine-Grained Controls

Tool-level controls are easier to reason about than unrestricted server access.

Review External Changes

If Copilot creates an issue, modifies a pull request, or performs another external action, review the result just as you would review a local code change.

Keep Production Access Separate

A development agent should not receive production credentials merely because an MCP integration makes them technically accessible.

Advantages

More Granular Control

Developers can manage individual MCP tools rather than treating every capability as identical.

Fewer Approval Interruptions

Persistent controls can reduce repeated decisions for trusted operations.

Better Separation of Capabilities

The built-in GitHub MCP Server can be managed independently from manually configured servers.

Better Enterprise Governance

Organizations can control which MCP servers developers can use.

Easier Agent Workflows

Agents can use external tools while still operating within defined boundaries.

Disadvantages and Trade-Offs

More Configuration

Fine-grained controls introduce additional settings developers need to understand.

Permission Drift

A permission granted for one workflow may remain enabled after it is no longer necessary.

External Tool Risk

MCP expands the range of systems an AI agent can interact with.

Enterprise Restrictions Can Be Confusing

Developers may encounter settings they cannot change because of managed policies.

More Capabilities Mean More Responsibility

Giving an agent access to additional tools increases the importance of monitoring and review.

A Practical MCP Permission Strategy

A simple strategy for individual developers is:

Step 1
Enable only required MCP servers
        |
        v
Step 2
Identify required tools
        |
        v
Step 3
Allow routine read operations
        |
        v
Step 4
Keep write operations controlled
        |
        v
Step 5
Review external changes
        |
        v
Step 6
Remove unnecessary permissions

For teams, add an organizational layer:

Enterprise Policy
       |
       v
Approved MCP Servers
       |
       v
Team Configuration
       |
       v
Developer Permissions
       |
       v
Agent Tool Calls

This provides a clearer security boundary than allowing every developer to connect arbitrary MCP servers.

What JetBrains Developers Should Take Away

The important change in Copilot for JetBrains is not simply that MCP is available.

The more important development is control over how MCP is used.

Developers can now think at several levels:

Should MCP be available?
        |
        v
Which server should be enabled?
        |
        v
Which tools does that server expose?
        |
        v
Which tools should Copilot use?
        |
        v
Which operations require approval?

That layered approach becomes increasingly important as AI agents move from generating code toward performing real development work.

MCP can make an agent much more useful because it gives the model access to tools and external context. But that same capability means permissions should be intentional rather than accidental.

Summary

GitHub Copilot's MCP controls in JetBrains give developers more ways to manage how AI agents interact with external tools.

Copilot for JetBrains 1.18.0 adds a separate control for the built-in GitHub MCP Server and persistent per-tool controls for MCP servers in agent sessions.

The GitHub MCP Server can expose operations involving repositories, issues, pull requests, and other GitHub features, while the underlying GitHub permissions still determine what the authenticated user can actually do.

For individual developers, the practical approach is to enable only the MCP capabilities required for the task, distinguish read operations from write operations, and review external changes.

For organizations, centralized allowlists, managed settings, and approved MCP registries provide additional governance.

As AI agents become more capable, MCP should be treated as part of the application's permission boundary, not simply as another Copilot feature.