Problem
The tools an organization actually works with are mostly its own: an internal work-tracking system, a telemetry store, a design system, a code-intelligence service, a deployment dashboard. MCP is the right shape for exposing these to an agent, and teams are willing to build the servers. The gap is governance and availability, not protocol.
There is no supported path for an organization to review a custom MCP server, approve it, and make it available to hosted sessions under policy. In practice the teams that most need a given server are not the teams that hold the administrative rights to configure one, so the request stalls: the server exists, the need is well understood, and it still cannot be used.
Where configuration is possible at all, it tends to assume a static credential held centrally. That is a poor fit for a server that enforces per-user authorization, and it is difficult to justify in security review.
This is deliberately separate from #2683, which asks how a session proves who it is acting for. This issue asks how a server becomes available and trusted in the first place. Both are needed; neither substitutes for the other.
What is missing
- No administrative surface for reviewing and approving a custom MCP server for organizational use.
- No way to scope an approved server to specific repositories, teams, or session types.
- No policy layer governing which tools on an approved server may be invoked, or under what conditions.
- No audit trail of which sessions used which approved server, on whose behalf, and to what effect.
- No clear division of responsibility between administrator-approved servers and servers declared in a repository.
Proposed behavior
- An administrator can register a custom MCP server for the organization, with an explicit scope.
- Approval is reviewable and revocable, and revocation takes effect for new sessions without requiring repository changes.
- Approved servers are discoverable by sessions within their scope, without each consuming team needing administrative rights.
- Tool-level policy is expressible, so an approved server can expose read operations broadly and write operations narrowly.
- Server credentials are held by the platform, never surfaced in prompts, model context, or serialized session state.
- Usage is auditable: which server, which tool, which session, which identity, and the outcome.
- Repository-declared servers remain supported, with a documented precedence and trust relationship between the two.
Example scenario
A platform team builds an MCP server over the organization's internal telemetry store. An administrator approves it and scopes it to the engineering repositories that need it. Sessions in those repositories can then query telemetry when investigating a defect, with each query authorized as the requesting user and recorded in the audit log. No team needs to embed a shared secret, and no team needs administrative rights of its own to benefit.
Acceptance criteria
- An administrator can approve a custom MCP server and scope it.
- Approved servers are available to in-scope sessions without per-team administrative configuration.
- Tool-level policy is enforceable.
- Credentials are platform-held and never exposed to model context.
- Usage is auditable per session and identity.
- Revocation is effective without repository changes.
Related
Problem
The tools an organization actually works with are mostly its own: an internal work-tracking system, a telemetry store, a design system, a code-intelligence service, a deployment dashboard. MCP is the right shape for exposing these to an agent, and teams are willing to build the servers. The gap is governance and availability, not protocol.
There is no supported path for an organization to review a custom MCP server, approve it, and make it available to hosted sessions under policy. In practice the teams that most need a given server are not the teams that hold the administrative rights to configure one, so the request stalls: the server exists, the need is well understood, and it still cannot be used.
Where configuration is possible at all, it tends to assume a static credential held centrally. That is a poor fit for a server that enforces per-user authorization, and it is difficult to justify in security review.
This is deliberately separate from #2683, which asks how a session proves who it is acting for. This issue asks how a server becomes available and trusted in the first place. Both are needed; neither substitutes for the other.
What is missing
Proposed behavior
Example scenario
A platform team builds an MCP server over the organization's internal telemetry store. An administrator approves it and scopes it to the engineering repositories that need it. Sessions in those repositories can then query telemetry when investigating a defect, with each query authorized as the requesting user and recorded in the audit log. No team needs to embed a shared secret, and no team needs administrative rights of its own to benefit.
Acceptance criteria
Related