Data handling and build provenance for the hosted Remote GitHub MCP service

[ChanghuLiu]

I am evaluating the hosted Remote GitHub MCP endpoint (https://api.githubcopilot.com/mcp/) for a read-only issue_read integration. The public documentation explains how the remote server is built from this repository and updated, but I could not find service-specific answers to these two questions:

1. Are MCP JSON-RPC tool-call arguments and results (request/response bodies) persisted or included in server/platform logs? If so, what retention period and controls apply? Please distinguish the Remote MCP service from Copilot Chat conversation history and ordinary GitHub audit logs.
2. Is a build/revision identifier exposed by the hosted endpoint, or can maintainers confirm how a deployed api.githubcopilot.com release maps to a source commit?

I understand internal infrastructure details may not be public. If these questions belong with GitHub Support or are answered in a Trust Center document, a pointer would help. No credentials or customer data are included here.

[Sagargupta16]

Question 2 first, because there is a concrete answer. The hosted endpoint reports its revision in the MCP handshake. An initialize call to https://api.githubcopilot.com/mcp/ today returned:

"serverInfo": { "name": "github-mcp-server",
                "version": "github-mcp-server/remote-7eab724bff5dde51eb8a4c1453d87d9ca568f877" }

The string after remote- is a 40-char git sha, and the same value goes out as the User-Agent on every GitHub API call the server makes (internal/ghmcp/server.go). That sha is not a commit in this repository (GET /repos/github/github-mcp-server/commits/7eab724b... returns 422). This matches docs/remote-server.md: the remote server is this repo used as a library, bound into GitHub infrastructure from an internal repository. So you can pin and record the deployed revision, but mapping it to a public commit needs a maintainer to say which library version that internal build vendors. Worth asking them to add that mapping to the version string.

Question 1 is not answered anywhere public. docs/policies-and-governance.md ("MCP-Specific Audit Logging") says MCP traffic appears in the standard GitHub audit log as ordinary API calls, with purpose-built MCP logging still on the roadmap. It says nothing about whether JSON-RPC request or result bodies are persisted, or for how long. The right owner for a retention statement is the GitHub Copilot Trust Center and your Data Protection Agreement, since the endpoint sits under api.githubcopilot.com; a support ticket from an org admin gets a written answer that a Discussion cannot. For a read-only issue_read integration the minimum-exposure setup is a fine-grained PAT scoped to the repos you need plus the X-MCP-Tools: issue_read and X-MCP-Readonly: true headers (or the /mcp/readonly URL), both documented in docs/remote-server.md, so the only data crossing the service is what that one tool returns.