Skip to Content
ConceptsMCP servers as platforms

MCP servers as platforms

AgentValet can put a remote MCP server behind the same governance you use for any other platform. You connect the server once, its tools show up as grantable scopes, and from then on your agents reach it only through AgentValet: signed, scope-checked, approved where you require it, and audited.

To the server, AgentValet is the client. To your agent, the MCP server is just another platform in the catalog.

What “connecting” does

When you add an MCP server, AgentValet probes it to learn two things: what tools it exposes and how it authenticates. The tools become the server’s scopes (so you can grant an agent some-server:some-tool and nothing else). The authentication method decides how the connection is stored:

  • No auth for open servers.
  • Bearer token or a custom header for servers that take a static secret.
  • An API key in the URL query for servers that authenticate that way.
  • OAuth for servers that run their own authorization flow.

Whatever the secret is, it is encrypted in AgentValet’s vault on receipt. Agents never see it; it is decrypted in memory only at call time, exactly like a Slack or Gmail credential.

The OAuth case: one token per agent

OAuth MCP servers work differently from the static-secret cases, because there is no single shared key to paste. Instead, each agent that should use the server gets its own authorization.

Here is the full flow:

  1. You add the server and pick which agent to authorize.
  2. AgentValet registers itself with the server’s authorization server automatically (Dynamic Client Registration) and starts an OAuth flow using PKCE.
  3. Your browser is sent to the provider’s own consent screen. You approve there.
  4. The provider sends you back; AgentValet exchanges the code for tokens and stores them in the vault, keyed to that specific agent.

Because tokens are per agent, two agents on the same OAuth server hold separate credentials, and revoking one does not touch the other. When an access token nears expiry, AgentValet refreshes it lazily on the next call. When it replays the token to the server, it binds the token to that server’s own URL as the intended audience, so a token minted for one server can never be forwarded to another.

An agent might try to use an OAuth MCP server it has not been authorized for yet. Rather than fail silently, AgentValet turns that into a request you can act on:

  • The agent’s call comes back as “needs consent” instead of an error.
  • You get a notification (in the dashboard, and by push or email) that the agent wants to use the server.
  • Opening it takes you to a consent page that names the agent and the server, and a single Authorize button that runs the same provider consent flow and stores the resulting token for that agent.

Authorizing an agent for an OAuth server is an admin action. A non-admin member is shown a message to ask an admin instead.

Safety around the server URL

Every request AgentValet makes to an MCP server or its authorization server (discovery, registration, token exchange, the tool calls themselves) goes through a guarded fetch that blocks internal and private network targets, refuses plain HTTP, and does not follow redirects. This stops a maliciously crafted server URL from being used to reach services inside the network.

Limits to know

  • The connected-platform plan limit counts MCP servers like any other platform. When you are at your cap, connecting another is blocked and you are prompted to upgrade.
  • OAuth only works for servers that support automatic client registration. A server without it cannot be connected through the OAuth flow.
  • Demo workspaces cannot connect external servers.

Next

Last updated on
Scopes & permissionsApproval flow