> ## Documentation Index
> Fetch the complete documentation index at: https://docs.forge.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP Requests

> Discover, review, connect, and govern MCP servers and tools through the Forge Registry.

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](/secure/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

```text theme={"system"}
Discover or add server
        ↓
Analyze provenance, tools, and risk
        ↓
Define audience and tool access
        ↓
Approve or request access
        ↓
Install client configuration and credentials
        ↓
Enforce at the MCP Gateway and audit use
```

### 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:

| Credential model             | Typical owner    | Result                                                                |
| ---------------------------- | ---------------- | --------------------------------------------------------------------- |
| Organization credential      | Administrator    | All approved users share the configured upstream connection.          |
| Per-user OAuth or credential | Individual user  | Each installation uses the user's authorized upstream connection.     |
| Service-account credential   | Automation owner | Non-interactive clients use a dedicated principal with narrow scopes. |

Never paste upstream secrets into request descriptions, tool arguments, client
configuration committed to source control, or support tickets. See [Access](/secure/roles)
for service accounts and [MCP Gateway](/secure/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.