Skip to content
PRESHaiPRESHaiPRESHos Platform

MCP registry

The MCP registry is the agent-config building block for external capabilities: how a tenant gets an MCP server, under which scope, and under which rechecks. This is reference, not field practice; the worked verification flow lives under Skills, tools and MCP.

  • Two sides, never confused: the platform catalog (ai.mcp_catalog_source, ai.mcp_catalog_server, ai.mcp_catalog_server_version, PRESHos-managed, requirePlatformOps) and the tenant install (ai.mcp_servers rows, per org_id, never leaking across tenants).
  • Two paths in: catalog install via POST /api/v1/mcp-servers/install-from-catalog, or custom tenant MCP via /ai/mcp-servers/new (tenant-owned row, catalog_server_id null, with operational rechecks).
  • Surfaces: browse and install at /ai/mcp-servers, with Installed and Discover tabs. Search by name, key, or URL. Create custom at /ai/mcp-servers/new. Each row carries name, key, auth, credentials, and setup status.
  • The catalog carries frozen fingerprints: the expected identity of each catalog server is pinned at install time, so a changed server fails the recheck instead of running quietly.
  • Every mcp/call passes a two-check before executing. Installed does not mean trusted — the call re-verifies, then runs.
  • Verify before use, every time it matters: fingerprint recheck and DNS-pinned guarded fetch on custom installs. Installed does not mean trusted.
  • Zero credentials in session: credential values never enter the session. Auth arrives as grants; nothing secret is typed into chat, reasoning, or transcript, and the session never sees raw credential material.
  • Platform OAuth profiles from source: Google Drive com.google.drive/mcp, HubSpot com.hubspot/mcp. Anything else claiming profile status needs source confirmation.
MCP Servers registry with installed and discover tabs, auth and setup status per server

Catalog vs. custom

Section titled “Catalog vs. custom”
  • Catalog install adopts a platform-managed server: versioned, sourced, and rechecked by PRESHos. Prefer it wherever a catalog server covers the need — it carries the operational guarantees custom rows do not.
  • Custom tenant MCP is a tenant-owned row for servers outside the catalog. It works, but it carries operational rechecks the tenant owns: fingerprint recheck and DNS-pinned guarded fetch confirmed working before pilot users arrive.
  • Both paths land per org_id. An install in the wrong org scope reaches another tenant’s data or nothing at all — confirm where the install landed before granting it anywhere.

The Discover tab is the catalog surface: platform-managed servers available to install, with registry name, description, version, and transport columns. On this tenant the list reads empty — unavailable or no permission — so there is nothing to adopt here until access or catalog entries change.

  • Prefer catalog install wherever a catalog server covers the need; it carries the rechecks custom rows do not.
  • An empty Discover tab is an access question for the tenant admin, not a retry loop.
MCP Servers Discover tab showing the catalog surface with no viewable entries

The Installed tab is the tenant truth: one row per org_id install with name, key, auth, credentials, and setup status. Apollo sits at Error while Fireflies and Google Drive read Ready and TD SYNNEX UAT reads Testing — installed never means uniformly healthy.

  • Custom tenant installs enter through Add custom MCP (/ai/mcp-servers/new): tenant-owned rows with catalog_server_id null.
  • Per-user OAuth rows stay per-user; credential values never enter the session.
MCP Servers Installed tab with tenant rows and per-server auth and setup status

Session truth: only granted installs run

Section titled “Session truth: only granted installs run”

Install is adoption, not scope. A server reaches a running session only when all three hold:

  1. Installed for this tenant (catalog or custom, correct org_id).
  2. Granted to the agent running the session (per-agent scope, set at configuration time).
  3. Inside the session’s environment policy (runner, tool grants, secrets).

The session’s capability list is the truth for the run — the same rule as Plugins in session. A server missing from that list is a grant-or-environment question for the tenant admin, never a prompt trick. At invoke time catalog and custom servers behave identically; they differ only in how they were installed and rechecked.

The grant that decides session scope lives on the agent: the Default Agent MCP Servers tab lists what this agent carries into a run. Here Fireflies MCP (fireflies_mcp, global auth) and Google Drive (google_drive, user auth) are attached over http transport, with Attach MCP server for the next adoption and Discover tools to preview what Eve will pull in live at run start.

  • Only granted installs are callable inside the run — installed for the tenant but never granted to this agent means the session cannot reach it.
  • All MCP calls run through one governed mcp_call policy behind the control-plane proxy; the per-server policy sets the safest decision Eve applies.
Default Agent MCP Servers tab with Fireflies and Google Drive attached and Discover tools

Registry checklist (per tenant)

Section titled “Registry checklist (per tenant)”
  • Path chosen deliberately and recorded: catalog install or custom tenant MCP, with why.
  • Install landed under the correct org_id.
  • OAuth profile confirmed where applicable.
  • Granted to exactly the agents that need it — no broader.
  • Fingerprint recheck and DNS-pinned guarded fetch observed working before pilot users arrive (custom MCP: operational rechecks also confirmed).
  • Install recorded in the capabilities register with scope and date.

MCP wiring feeds tools; skills and tools shape behavior; the session does the workload behind approval gates. Sequencing and pitfalls: Skills, tools and MCP. This registry does not live under org Settings: tenant identity and membership stay under Tenant admins.

What next

Section titled “What next”