Skip to main content
The MCP Registry is the organization catalog for Model Context Protocol servers and their tools. It gives teams one place to bring MCP servers into Forge, understand what they expose, decide who can use them, and deliver the approved configuration to supported AI clients. The Registry is not the MCP runtime. The MCP Gateway handles the live connection, credential exchange, tool discovery, policy evaluation, and audit trail after a server is approved and installed.

​
What the MCP Registry provides

Each MCP Registry item provides a durable record of:
  • Server name, slug, description, owner, source, and provenance.
  • Transport and endpoint configuration, including remote and local server details when available.
  • The discovered tool inventory, input schemas, descriptions, and enabled or disabled state.
  • Authentication and connection requirements, including user-scoped or organization-scoped credentials where supported.
  • Risk analysis, scanner findings, versions, connection health, and usage history.
  • Access rules for users and groups, and the request and approval history for the item.
Registry entries can represent servers discovered from connected clients, servers added from the Forge catalog, or remote and local servers registered by an administrator. Discovery creates visibility; it does not grant access.

​
Review risk information

Risk analysis helps a reviewer understand what the server and its tools can reach or change before granting access. Depending on the available evidence, the Registry can show:
  • An overall risk tier and plain-language summary.
  • The affected server or tool and the behavior that needs review.
  • Referenced URLs, packages, and versions observed in the server definition or related artifacts.
  • Supporting evidence, likely impact, and recommended next steps.
  • Links to the corresponding Inventory record or Investigation when broader context is available.
Treat missing evidence as unknown rather than safe. Compare the analysis with the requested audience, upstream credential scopes, enabled tools, and the server’s intended business purpose.

​
Who can do what

​
Console users

Users with organization administration or Registry review access can:
  • Add, edit, disable, and remove Registry entries.
  • Review server provenance, transport, credentials, tools, findings, and connection status.
  • Enable or disable individual tools without removing the server.
  • Configure Registry access for specific users and directory groups.
  • Review, approve, deny, cancel, and expire MCP access requests.
  • Approve a server for a limited audience or require a new request for a wider audience or additional tools.
  • Review usage and audit history before changing an access decision.
Registry changes affect what users can discover and install. The gateway and content policies still enforce the resulting decision at runtime.

​
Self-serve users

Eligible members can use the Registry to:
  • Browse servers and tools made available to their audience.
  • Inspect descriptions, required connection steps, tool schemas, risk labels, and approval status.
  • Install or connect an approved server in a supported client.
  • Select an individual tool or approved tool set when the organization allows tool-level access.
  • Request access to a server, selected tools, or a longer access duration.
  • Provide the business use case, urgency, users or groups, client, and workflow context needed for review.
  • Track request status, reviewer decisions, expiration, and denial reasons.
Self-serve access is bounded by organization policy and Registry ACLs. A server being visible in the catalog does not mean every user can call every tool.

​
Request access

An MCP request can target an existing Registry item, a discovered server, a catalog server, or a new remote server. When the tool inventory is available, the requester can limit the request to selected tools. The request can include the business case, urgency, requested users or groups, client, project, workflow, and requested expiration.

​
MCP lifecycle

​
Add or discover a server

Administrators can add a server from the Forge catalog, register a remote MCP endpoint, or promote a server discovered in endpoint, client, repository, or connected-system data. Record the canonical upstream source and owner before making the server available to users. For a local or custom server, validate the launch command, working directory, environment requirements, network destinations, and package provenance. Keep secrets in the supported credential flow rather than in a client configuration file or Registry description.

​
Review the tool inventory

Review every tool before approval, especially tools that can write, delete, send messages, change permissions, execute code, or access sensitive systems. Check:
  • Whether the tool name and description match the business purpose.
  • Required input fields and whether the schema permits broad or destructive targets.
  • Upstream scopes and credential ownership.
  • Whether the server can reach systems outside the intended boundary.
  • Scanner findings, version history, and recent usage.
Disable unnecessary tools and approve the smallest useful tool set. Tool selection is an authorization boundary, not just a user-interface preference.

​
Set audience and access

Registry access can be assigned to organization members and directory groups. Use a narrow pilot audience first, then expand after reviewing sessions, policy decisions, and gateway errors. Separate read-only and write-capable tools when the server exposes both. Registry-owned access rules are projected into the policy engine and evaluated at runtime. Organization-authored MCP ACLs can also exist; review both before debugging an unexpected allow or block.

​
Approve a request

Forge analyzes the server and request before human review. Analysis can include server identity, source, transport, tool inventory, scanner findings, requested scope, prior usage, and suggested access policies. An authorized reviewer can approve or deny after analysis completes. Approval can create the access and tool-policy projections needed to materialize the reviewed access; denial does not grant access.

​
Client setup and credentials

After approval, a user can install the Registry configuration in a supported AI client. The delivered configuration points the client at the governed MCP entrypoint and preserves the Registry item and user context needed for policy and audit. Credential behavior depends on the server: Never paste upstream secrets into request descriptions, tool arguments, client configuration committed to source control, or support tickets. See Access for service accounts and MCP Gateway for runtime credential behavior.

​
Access decisions at runtime

The effective decision for a tool call depends on more than catalog visibility:
  1. The server and tool are enabled in the Registry.
  2. The caller has a matching Registry access grant.
  3. The installation, server assignment, and credential are valid.
  4. MCP Registry ACLs and organization content policies permit the call.
  5. The upstream server accepts the credential and tool input.
The gateway removes disabled tools from tools/list when possible and checks the call again before execution. A successful installation therefore does not guarantee that every later call will succeed.

​
Operations checklist

Before broad rollout:
  • Assign a technical owner and business owner.
  • Confirm source, version, transport, upstream scopes, and data destinations.
  • Review every tool and disable unnecessary or destructive tools.
  • Start with a small directory group and a short access duration.
  • Test read, write, authentication failure, and denied-tool behavior.
  • Review gateway sessions, policy decisions, and audit events.
  • Define the upgrade, token rotation, incident response, and retirement path.
Use the request details and audit history when following a submitted access review; the Registry page is the source for the catalog and access state.