MCP Servers

CodeCargo maintains an organization-wide catalog of Model Context Protocol (MCP) servers. Once a server is registered and vetted, you can grant it — along with a specific subset of its tools — to individual Agentic Jobs. The same curated, enabled set of servers can also be published as a spec-compliant MCP registry that GitHub Copilot can consume directly.

Once a server is enabled, each use is a separate choice. A server can be used in any of them, all, or none.

Permission Required

Managing the MCP server catalog requires the organization administration permission (OrgAdminister). Only Org Admins can register, vet, enable, or remove servers.

Org MCP Catalog

Navigate to Organization Settings → MCP to manage your catalog. From here you can register a custom server with Register MCP Server or import one from the upstream GitHub MCP registry with Add from registry.

Organization Settings → MCP: the GitHub Copilot registry card above a list of five servers (Datadog, PagerDuty, Atlassian, Acme Runbooks, and a disabled Sentry), each with its transport, URL, allowed tool count, last connection test, and credential state. Atlassian is flagged for re-vetting because its upstream version moved.

Registering a Server

When you add a server, you configure:

Field	Description
Transport / Location	How CodeCargo connects to the server
Egress allowlist	The hosts CargoWall permits the server to reach
Tool cap	The maximum set of tools this server exposes for grants
Credential kind	How the server authenticates outbound requests

The Register MCP Server panel with fields for name, description, the https endpoint URL, credential kind, CargoWall egress hosts, the Enabled and Expose to Dispatch switches, and default allowed tools.

For an HTTP-transport server, the endpoint URL must be an absolute https URL — for example https://mcp.example.com/mcp. Plain http is rejected, including http://localhost and other loopback addresses, because CodeCargo attaches the server's credential to every call it makes. The URL also has to be written out in full: ${VAR}-style placeholders are not expanded, and the value is sent exactly as you enter it.

The same rule applies to entries imported from the GitHub MCP registry. If an upstream entry publishes a plain-http endpoint, the import is refused rather than creating a server that cannot be called.

Testing a server's connection

If a server's URL doesn't meet these requirements, Test connection tells you which setting to change instead of reporting a general connectivity failure. Re-save the server with a valid https URL and test again.

Importing from the GitHub MCP Registry

Instead of registering a server from scratch, you can import one from the upstream GitHub MCP registry. Imported entries retain their registry provenance and are pinned to a specific version. A daily background refresh checks for upstream changes and flags entries with drift for you to re-vet — imported servers never update automatically.

Enabling a Server

A newly registered or imported server starts disabled. Review and harden its configuration, then enable it. Only enabled servers can be granted to Agentic Jobs.

Making a Server Available to Dispatch

Once a server is enabled, you can make it available to Dispatch by turning on Expose to Dispatch in the server's settings. Dispatch can then call that server's tools while it chats, plans, and runs work — for every user in the organization, so review the server's tools with that audience in mind before exposing it. This is independent of granting the server to an Agentic Job — a server can be available to Dispatch, granted to jobs, both, or neither.

The Approval switches in a server's settings: Enabled, so jobs may be granted this server, and Expose to Dispatch, so the assistant may use it for every org user.

Credentials

Credential values are write-only — once saved, they are encrypted and cannot be read back, and are injected only at job dispatch time. If a server's credential kind is GITHUB_APP, CodeCargo mints a short-lived, run-scoped GitHub App installation token for each run instead of storing a static secret.

Granting MCP Access to Agentic Jobs

Once a server is enabled, it becomes available to grant to an Agentic Job. A grant pairs a server with a specific subset of its tools, and that tool subset is frozen on the job's thread so it stays identical across every turn of a run. See Agentic Jobs → MCP Server Access for how to configure grants.

If a server's tool cap is later narrowed, any tools removed from the cap are automatically revoked from existing grants the next time the job runs.

GitHub-Consumable Registry

CodeCargo can serve your organization's enabled MCP servers as a standards-compliant MCP registry (v0.1) that GitHub Copilot can fetch directly.

Accessing the Registry

The registry is served anonymously (with CORS enabled) behind an unguessable capability URL:

/mcp-registry/{token}

The GitHub Copilot registry card under Organization Settings → MCP manages your organization's registry base URL. The URL is shown only once, when it is generated. If it was lost or leaked, Rotate URL mints a new one and the previous URL stops working immediately; Revoke turns the registry off.

The GitHub Copilot registry card: four servers served, when the registry URL was created and last used, and Rotate URL and Revoke buttons.

Using It with GitHub Copilot

A Copilot organization admin pastes the base URL into their Copilot MCP registry allowlist. Copilot then fetches <base URL>/v0.1/servers from that base URL itself — no manual server-by-server configuration is required on the Copilot side.

Credentials Are Never Served

The registry never exposes a stored credential value. For servers that require a secret, the registry response includes only a placeholder indicating that a secret header is required — Copilot users must supply their own value.