[機能要望]アクセスするプロジェクトを限定する機能

[satoshi256kbyte]

概要

MCP Server の設定において、アクセス対象のプロジェクトを限定できる機能をご検討ください。
設定ファイルのイメージは以下の通りです。
MCP クライアントからいかなるプロンプトが入力されても、指定したプロジェクト以外への操作が行われないようにしたいです。

{
  "mcpServers": {
    "backlog": {
      "command": "docker",
      "args": [
        "run",
        "--pull", "always",
        "-i",
        "--rm",
        "-e", "BACKLOG_DOMAIN",
        "-e", "BACKLOG_API_KEY",
        "ghcr.io/nulab/backlog-mcp-server"
      ],
      "env": {
        "BACKLOG_DOMAIN": "your-domain.backlog.com",
        "BACKLOG_API_KEY": "your-api-key",
        "BACKLOG_PROJECT_ID": "your-project-id"
      }
    }
  }
}

背景

私の所属組織では、各作業者が複数の Backlog プロジェクトを扱っています。
各プロジェクトは案件が異なるため、万が一 A プロジェクトの情報を B プロジェクトに誤って投稿すると、インシデントにつながります。
このような状況でも Backlog MCP Server を安心して利用できるよう、設定レベルでアクセス対象プロジェクトを制限できる機能を求めています。

コンテキストでアクセス範囲をある程度制御できることは理解していますが、コンテキストが常に守られるとは限らず、誤アクセスのリスクは完全には排除できません。そのため、現状では実案件で Backlog MCP Server を採用する判断に至っていません。

補足

Backlog MCP Server 自体は非常に有用なプロダクトだと考えています。ぜひ本機能のご検討をお願いいたします。

[allenthich]

I am also interested in seeing this implemented as it's normal to have access to many different projects.

I would be open to submitting a PR, but what would the best approach here be?

We could create a transformer that filters for allowed project id(s). However, not all MCP tool calls made through the Backlog API support project id filtering. Would this lower the risk enough for safely making targeted project tool calls?

Tools that support SINGLE projectId (27 tools)

These tools accept only one projectId (as z.number()):

• addIssue
• addPullRequest
• addPullRequestComment
• addVersionMilestone
• addWiki
• deleteProject
• deleteVersion
• getCategories
• getCustomFields
• getDocumentTree
• getGitRepositories
• getGitRepository
• getIssueTypes
• getProject
• getPullRequest
• getPullRequestComments
• getPullRequests
• getPullRequestsCount
• getVersionMilestoneList
• getWiki
• getWikiPages
• getWikisCount
• updateProject
• updatePullRequest
• updatePullRequestComment
• updateVersionMilestone

Tools that support MULTIPLE projectIds (3 tools)

These tools accept an array of projectIds (as z.array(z.number())):

• getIssues - Fetches issues across multiple projects
• countIssues - Counts issues across multiple projects
• getDocuments - Fetches documents across multiple projects

Tools that DO NOT support projectId (17 tools)

These tools operate without needing a project context:

• addProject - Creates a new project (doesn't need existing projectId)
• deleteIssue - Uses issueId/issueKey directly
• getDocument - Uses documentId directly
• getIssue - Uses issueId/issueKey directly
• getIssueComments - Uses issueId/issueKey directly
• getMyself - Returns current user info
• getNotifications - User's notifications across all projects
• getNotificationsCount - Count of user's notifications
• getPriorities - Global priority list
• getResolutions - Global resolution list
• getSpace - Returns space-level information
• getUsers - Returns users in the space
• getWatchingListCount - User's watching list count
• getWatchingListItems - User's watching list items
• markNotificationAsRead - Uses notification ID directly
• resetUnreadNotificationCount - Resets user's notification count
• updateIssue - Uses issueId/issueKey directly

@trknhr Would be curious to hear your thoughts!

[trknhr]

Thank you for taking the time to make the list. it’s very helpful.
Actually, I’ve been working on this for a while, but hadn’t completed it yet.
Now I’m creating a PR for it: #23
It’s still a work in progress, but I really appreciate all your help!

[satoshi256kbyte]

@trknhr

Thank you for your consideration.
Please proceed at your own pace; we appreciate your cooperation.
We look forward to the release.

[katayama8000]

@satoshi256kbyte

This is a great proposal for multi-project safety. However, I'd like to clarify one technical risk:

If the AI happens to know the API Key, it could bypass the MCP Server entirely by writing a script to call the Backlog REST API directly for any project.

Given this REST API bypass possibility, do you still consider this server-side restriction a must-have feature for your production use?

I’d love to hear your thoughts on whether this level of protection meets your security requirements.

[satoshi256kbyte]

@katayama8000

Thank you for your comment. I apologize for the delayed response.

As you pointed out, I agree that as long as the AI recognizes the API key, it is difficult to guarantee perfect security through MCP server-side restrictions alone.

However, when I think deeply about the possibility that the AI could bypass these restrictions, an extreme thought crosses my mind: wouldn’t that also render the tool restrictions within the MCP ineffective?

While preventing an AI from directly using API keys maliciously (or due to a malfunction) may be the role of a separate layer (such as a proxy or wrapper), I believe that having the option to “narrow down the available functions via settings” on the MCP server itself holds certain value in the following ways, even if it is not perfect:

• Prevention of human error: It physically prevents developers from unintentionally calling tools.
• Defense in Depth: While not perfect, it minimizes the attack surface.

Of course, I understand there are trade-offs regarding implementation costs and maintenance, but I would appreciate it if you could reconsider this as part of efforts to enhance practicality.