Addressing GitHub MCP's Key Issues: Token Scopes, Verbose Prompts, and Lack of Project Context

[d0lwl0b]

I’d like to share some practical difficulties I’ve encountered while using GitHub MCP, which affect both usability and workflow efficiency:

1. Restricted Token Scope in Private Repos
   Even when invited to a private repository, my GitHub MCP token could not be used to access issues or pull requests within that project. This seems like a token permission issue and has been reported as a potential token-scope limitation.

2. Overly Redundant and LLM-Unfriendly Prompts
   The prompts generated by GitHub MCP are often unnecessarily verbose and repetitive, making it difficult for LLMs to interact with it smoothly. This results in slower, less precise responses in agentic workflows.

3. No Built-in “Current Project” Focus
   GitHub MCP lacks a sense of contextual focus on the specific repository I’m working in. I’d prefer a tool that automatically centers on the current project’s issues and pull requests—similar to how gh CLI operates within a local Git context.

These limitations make me wonder whether a solution like opencode could be designed to offer more targeted, context-aware interaction—essentially combining the directness of gh with the extensibility of an agent-friendly SDK.

Has there been any discussion about enabling opencode to handle repository-scoped issues/PRs with the kind of focused, lightweight interaction that GitHub MCP currently lacks?

[d0lwl0b]

I've observed that GitHub MCP doesn’t naturally focus on the current project context. Whenever I enable it, the LLM tends to get distracted—even when I try to limit the number of available tools. The interaction feels scattered rather than purpose-driven.

A potential direction worth discussing: Could GitHub MCP offer a separate sub-project or a dedicated mode that is scoped strictly to the current repository? This would allow operations like issue and PR management to stay tightly coupled with the project I’m actually working in, similar to how gh CLI behaves inside a git repository.

This kind of focused, context-aware tooling would greatly improve workflow efficiency and reduce cognitive overhead when working with LLM-driven development.

[tommaso-moro]

Hi @d0lwl0b, thank you for sharing this :)

Regarding your points:

1. Restricted Token Scope in Private Repos

This is likely a permission issue that is unrelated to the MCP Server, could you check out this answer in an issue that was raised about this and let me know if it still doesn't solve the problem for you?

2. Overly Redundant and LLM-Unfriendly Prompts

It'd be super helpful if you could elaborate on this. Which prompts have these issues, and do you have any specific examples? If you have feedback or ideas on better prompts you'd consider, please share them!

3. No Built-in “Current Project” Focus

When using issues or pull requests tools in the GitHub MCP Server, you can easily tell the agent to query data from whatever repository you'd like, including the "current" one. So I am not sure I follow what the issue is exactly? Forcing the GitHub MCP Server to only query issues/PRs from the current project can be done via prompting, but we still want to the server to be able to access other projects too so it's up to the dev to specify the "scope" if that makes sense:) Can you please provide examples of the kind of behaviour you're getting using the GitHub MCP Server, and what you'd like to get instead? Just so that we understand this UX friction you're describing better

[d0lwl0b]

Hi @tommaso-moro , thank you for your detailed reply and follow-up. Below are my additional clarifications on each point based on my practical experience:

1. Regarding Token Scope

I can confirm that a Classic PAT resolves the private repository access issue. However, since I am contributing to a friend's personal private repository (not an organization project), I prefer to use a Fine-grained PAT to adhere to the principle of least privilege and ensure the security of my friend's repository. Currently, Fine-grained PATs appear to have permission limitations in cross-user private repository scenarios, which is a point I'd like to explore or see improved.

I am already using a Fine-grained PAT in my configuration, with only read-only permissions and a limited toolset (context, repos, issues, pull_requests, actions) granted, yet I still cannot access another user's private repository to which I have been invited.

2. Regarding Verbose Prompts and the LLM Experience

A typical scenario is: when I ask the LLM to "view the current project's issues," the agent often performs a series of exploratory operations first, such as:

• Calling list_repositories to enumerate all my personal repositories
• Even attempting to read other projects under my personal account first

This process is not only slow but also makes the interaction feel "roundabout." Even though I have tried to restrict tools via autoApprove and disabled in mcp.json, this pattern of "search first, then locate" persists. The core issue is that the tool itself lacks awareness of the most natural context: the repository corresponding to the current working directory.

The interaction I expect is similar to the direct, no-secondary-confirmation experience of gh issue list. The LLM should be able to operate directly based on the remote repository information configured in .git, rather than performing a round of "exploration" first.

3. Regarding the Lack of "Current Project" Focus

I fully understand that the GitHub MCP Server is designed as a general-purpose tool, and its ability to access multiple repositories is its strength. However, the problem is that in single-repository development scenarios, this generality becomes a source of distraction.

My idea is: could a "project-level" or "mode-level" focused solution be provided? For example:

• Supporting project-level override configurations in mcp.json, where a github-mcp instance scoped solely to that repository's remote address is automatically activated when I work in the root directory of a Git repository.
• Or providing a startup parameter like --scope-to-current-repo, which would bind all tools of that instance by default to the remote repository configured in the current .git, eliminating the need to repeatedly specify owner/repo in every conversation.

This way, developers could switch between "global general query" and "project-focused development" modes as needed, rather than relying on fragile prompt engineering to constrain behavior.

In summary, my core suggestion is:
Would it be possible to consider providing the GitHub MCP Server with a lightweight "project-focused mode" or an optional "sub-toolset"? This would allow it to bind directly and automatically to the current repository in a single-repo context, much like the gh CLI, thereby reducing cognitive load and ineffective interaction. This would be a significant improvement in experience for deeply integrating MCP into focused development workflows.

Thank you once again for your patient reading and discussion.

---

    "github-mcp": {
      "autoApprove": [
        "get_project",
        "get_project_field",
        "get_project_item",
        "list_gists",
        "list_project_fields",
        "list_project_items",
        "search_orgs",
        "search_users"
      ],
      "disabled": true,
      "timeout": 300,
      "type": "stdio",
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server",
        "stdio",
        "--read-only",
        "--toolsets",
        "context,repos,issues,pull_requests,actions"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "xxx"
      }
    },

cline config