fusion-pm-mcp

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fusion PM MCP Setup Guide

Fusion PM MCP 设置指南

When to use

适用场景

Use when a user asks:

what Fusion PM MCP is
how to install/configure it
how to verify it is working
how to troubleshoot a failing setup or stale/rate-limited results

Typical triggers:

"what is fusion pm mcp"
"help me set up fusion pm mcp"
"how do I get GitHub issues/PRs into Copilot without hitting rate limits"

当用户询问以下问题时使用：

Fusion PM MCP是什么
如何安装/配置它
如何验证它是否正常运行
如何排查安装失败或结果过期/触发速率限制的问题

典型触发问题：

"Fusion PM MCP是什么"
"帮我设置Fusion PM MCP"
"如何在不触发速率限制的情况下将GitHub工单/PR导入Copilot"

When not to use

不适用场景

Implementing or modifying the
```
fusion-pm-mcp
```
service source code — that belongs to the repository itself
General Fusion Framework/docs/EDS/backend-code retrieval — use
```
fusion-mcp
```
Authoring, triaging, or reviewing GitHub issues/PRs — use
```
fusion-issue-authoring
```
or repo-specific review skills once the MCP tools are available
Making destructive environment changes without user confirmation

实现或修改
```
fusion-pm-mcp
```
服务源代码——此类问题属于对应仓库的范畴
通用Fusion Framework/文档/EDS/后端代码检索——请使用
```
fusion-mcp
```
撰写、分类或审核GitHub工单/PR——在MCP工具可用后，请使用
```
fusion-issue-authoring
```
或仓库专属审核技能
在未获得用户确认的情况下执行破坏性环境变更

Required inputs

必要输入信息

Collect before proposing setup steps:

whether a GitHub token is available (
```
gh auth token
```
, or a PAT with
```
repo
```
scope) — supplied per-request, not stored in config
target client (VS Code is primary)

If details are missing, ask concise follow-up questions first.

在提供设置步骤前需收集：

是否有可用的GitHub令牌（
```
gh auth token
```
，或拥有
```
repo
```
权限的PAT）——每次请求提供，不存储在配置中
目标客户端（主要为VS Code）

若信息缺失，先提出简洁的跟进问题。

Instructions

操作步骤

Explain what this MCP server provides:
- a caching proxy over the GitHub REST API, exposed as MCP tools, so agents can read project data without hitting GitHub rate limits on every call
- hosted as a managed service — no local infrastructure required for most users
- tools (verify against
```
tools/list
```
  , the server's actual source is the source of truth over any stale doc):
```
api_get_issue
```
  ,
```
api_get_parent_issue
```
  ,
```
api_get_child_issues
```
  ,
```
api_get_issue_comments
```
  ,
```
api_list_milestones
```
  ,
```
api_get_milestone
```
  ,
```
api_upsert_issue
```
  ,
```
api_close
```
  ,
```
api_get_metadata_schema
```
  ,
```
api_get_pull_request
```
  ,
```
api_get_pr_comments
```
  ,
```
api_get_pr_reviews
```
  ,
```
api_get_pr_review
```
  ,
```
api_get_review_comments
```
  ,
```
api_resolve_review_comment
```
- responses are cached (default TTL 300s); there is no cache-invalidation tool — stale results clear on their own after the TTL
Guide user to set up the hosted production server — the only recommended path:
- no Docker, no local clone, no env vars to manage
- VS Code authenticates the MCP connection via Microsoft Entra (Equinor account)
- the caller also supplies their own GitHub token per request via the
```
X-GitHub-Token
```
  header (each user keeps their own identity and rate limit — don't suggest a shared/service token)
- use the manual config in
```
references/vscode-mcp-config.md
```
  (no one-click install link is published for this server)
- don't suggest local stdio or the full Docker dev stack — those exist only for contributors working on the
```
fusion-pm-mcp
```
  service itself; point them to that repo's
```
CONTRIBUTING.md
```
  instead of embedding setup steps here
Describe the authentication flow:
- on first tool invocation VS Code prompts sign-in with the Equinor Entra account (controls access to the MCP server itself)
- separately, the
```
X-GitHub-Token
```
  header carries the caller's own GitHub PAT through to the API on every request
- both must be valid; a 401 can come from either layer
Give a validation checklist:
- run
```
initialize
```
  and confirm a successful response
- run
```
tools/list
```
  and compare against the actual returned tool names — don't assume a fixed list, the surface has changed before
- run one non-destructive
```
tools/call
```
  (e.g.
```
api_list_milestones
```
  or
```
api_get_issue
```
  ) and confirm a non-empty result
Troubleshoot in documented order:
- Unauthenticated / hitting rate limits fast → no
```
X-GitHub-Token
```
  header configured; unauthenticated calls are capped at 60 req/hr
- ```
401
```
  or repeated sign-in prompts → re-authenticate via VS Code (sign out/in, or reload the MCP server); if that doesn't resolve it, treat it as a setup bug rather than a known transient issue
- Results look stale → there is no invalidate-cache tool; results self-clear after the cache TTL (a few minutes)
When setup fails or the user asks to file a bug, produce a bug report draft from
```
assets/bug-report-template.md
```
.
- default target repository:
```
equinor/fusion-pm-mcp
```
- include concrete repro steps, expected vs actual behavior, and troubleshooting already attempted
- include non-sensitive environment details only (OS, VS Code version)
- never include GitHub tokens, PATs, or Entra credentials
For uncertainty or repo-private constraints, state assumptions explicitly and link to authoritative docs instead of guessing.

解释该MCP服务器的功能：
- 作为GitHub REST API的缓存代理，以MCP工具的形式对外提供服务，使Agent无需每次调用都触发GitHub速率限制即可读取项目数据
- 作为托管服务运行——大多数用户无需本地基础设施
- 工具列表（以
```
tools/list
```
  返回的内容为准，服务器实际源代码比任何过期文档更权威）：
```
api_get_issue
```
  、
```
api_get_parent_issue
```
  、
```
api_get_child_issues
```
  、
```
api_get_issue_comments
```
  、
```
api_list_milestones
```
  、
```
api_get_milestone
```
  、
```
api_upsert_issue
```
  、
```
api_close
```
  、
```
api_get_metadata_schema
```
  、
```
api_get_pull_request
```
  、
```
api_get_pr_comments
```
  、
```
api_get_pr_reviews
```
  、
```
api_get_pr_review
```
  、
```
api_get_review_comments
```
  、
```
api_resolve_review_comment
```
- 响应结果会被缓存（默认TTL为300秒）；无缓存失效工具——过期结果会在TTL到期后自动清除
指导用户设置托管生产服务器——这是唯一推荐的方式：
- 无需Docker、无需本地克隆、无需管理环境变量
- VS Code通过Microsoft Entra（Equinor账户）对MCP连接进行身份验证
- 调用者还需在每次请求中通过
```
X-GitHub-Token
```
  头携带自己的GitHub令牌（每个用户保留自己的身份和速率限制——不建议使用共享/服务令牌）
- 使用
```
references/vscode-mcp-config.md
```
  中的手动配置（该服务器未发布一键安装链接）
- 不建议使用本地stdio或完整Docker开发栈——这些仅适用于开发
```
fusion-pm-mcp
```
  服务的贡献者；请引导他们查看该仓库的
```
CONTRIBUTING.md
```
  ，而非在此嵌入设置步骤
描述认证流程：
- 首次调用工具时，VS Code会提示使用Equinor Entra账户登录（控制对MCP服务器本身的访问权限）
- 另外，
```
X-GitHub-Token
```
  头会在每次请求中将调用者自己的GitHub PAT传递给API
- 两者都必须有效；401错误可能来自任意一层
提供验证清单：
- 运行
```
initialize
```
  并确认响应成功
- 运行
```
tools/list
```
  并与实际返回的工具名称对比——不要假设列表固定，该工具集之前有过变更
- 运行一个非破坏性的
```
tools/call
```
  （例如
```
api_list_milestones
```
  或
```
api_get_issue
```
  ）并确认返回非空结果
按文档顺序排查问题：
- 未认证/快速触发速率限制→未配置
```
X-GitHub-Token
```
  头；未认证调用的上限为每小时60次请求
- ```
401
```
  错误或重复登录提示→通过VS Code重新认证（登出/登入，或重新加载MCP服务器）；若仍无法解决，则将其视为设置Bug而非已知临时问题
- 结果看起来过期→无缓存失效工具；结果会在TTL（几分钟）到期后自动清除
当设置失败或用户要求提交Bug时，从
```
assets/bug-report-template.md
```
生成Bug报告草稿。
- 默认目标仓库：
```
equinor/fusion-pm-mcp
```
- 包含具体的重现步骤、预期与实际行为、以及已尝试的排查操作
- 仅包含非敏感环境信息（操作系统、VS Code版本）
- 绝不要包含GitHub令牌、PAT或Entra凭据
若存在不确定性或仓库私有约束，需明确说明假设，并链接到权威文档而非猜测。

Expected output

预期输出

Return:

short explanation of Fusion PM MCP and when to use it
hosted setup steps tailored to the user's environment
validation checklist:
```
initialize
```
,
```
tools/list
```
(compare against actual returned names), one
```
tools/call
```
(expect non-empty result)
troubleshooting steps mapped to observed symptoms
bug report draft (when setup fails/misbehaves or user requests) using
```
assets/bug-report-template.md
```
with default target
```
equinor/fusion-pm-mcp
```
assumptions and missing information called out explicitly

返回内容包括：

Fusion PM MCP的简短说明及其适用场景
针对用户环境定制的托管服务设置步骤
验证清单：
```
initialize
```
、
```
tools/list
```
（与实际返回名称对比）、一次
```
tools/call
```
（预期非空结果）
与观察到的症状对应的排查步骤
（当设置失败/异常或用户要求时）使用
```
assets/bug-report-template.md
```
生成的Bug报告草稿，默认目标仓库为
```
equinor/fusion-pm-mcp
```
明确指出假设和缺失的信息

References

参考资料

references/vscode-mcp-config.md
assets/bug-report-template.md

references/vscode-mcp-config.md
assets/bug-report-template.md

Safety & constraints

安全与约束

Never:

request or expose GitHub tokens, PATs, or Entra credentials
invent setup commands that are not supported by project documentation
claim setup succeeded without validation output
suggest a single shared GitHub token for hosted multi-user setups
run destructive commands without explicit user confirmation

Always:

prefer official repository documentation as source of truth
guide users to the hosted production server; do not suggest local stdio or Docker setups unless the user is contributing to the service itself, then link to that repo's
```
CONTRIBUTING.md
```
instead of embedding setup steps
recommend per-request
```
X-GitHub-Token
```
auth over shared tokens
separate confirmed facts from assumptions

绝对禁止：

请求或泄露GitHub令牌、PAT或Entra凭据
发明项目文档不支持的设置命令
在没有验证输出的情况下声称设置成功
为托管多用户设置建议单一共享GitHub令牌
在未获得用户明确确认的情况下执行破坏性命令

必须遵守：

优先以官方仓库文档为权威来源
引导用户使用托管生产服务器；除非用户是服务贡献者，否则不建议使用本地stdio或Docker设置，此时应链接到该仓库的
```
CONTRIBUTING.md
```
而非在此嵌入设置步骤
推荐使用每次请求携带
```
X-GitHub-Token
```
的认证方式，而非共享令牌
区分已确认的事实与假设