MCP Vendor Presets

What is MCP?

The Model Context Protocol (MCP) is an open standard that lets AI agents call external tools: a GitHub server exposes tools like create_issue, a Stripe server exposes refund.create, and so on. Each tool call is a JSON-RPC tools/call request against an MCP server. EvalGuard does not replace those servers — it sits in front of them as a gateway. You register each upstream server once, then route agent tool calls through POST /api/v1/mcp/invoke, where every call is role-checked, rate-limited, and audited before it reaches the upstream. The default is zero-trust: a tool with no permission row is denied (deny_no_permission).

Transports

A server's transport tells the gateway how to reach it. The gateway forwards tool calls over three network transports: http (streamable HTTP), sse (Server-Sent Events), and websocket.

stdio is a valid registration transport but the multi-tenant gateway does not spawn local subprocesses — invoking a stdio server returns a 501. To use one of the stdio presets below (Slack, Stripe, Postgres, and the other CLI-style servers), run a small local HTTP companion that exposes the stdio server over HTTP, then register that HTTP endpoint instead.

Auth shapes

Each server carries an authType plus a typed authConfig. Credentials are never stored inline — secret fields hold vault:// references. Registration accepts:

• none — no outbound credential.
• bearer — a static bearer token on the outbound Authorization header.
• api-key — a custom header name plus a vault:// value reference.
• oauth2 — issuer, token endpoint, client id, and a vaulted client secret.
• jwt — validate a presented JWT against the server's jwksUri (default algorithms RS256 / ES256).

The pipeline additionally understands two advanced outbound modes for self-hosted setups: mtls (mutual-TLS client certs) and token-exchange (RFC 8693 on-behalf-of delegation, so an agent calls the downstream server as the user rather than forwarding a confused-deputy credential).

Register a server, then invoke a tool

# 1. Register the upstream MCP server (transport + auth stored per-server)
POST /api/v1/mcp/servers
{
  "name": "GitHub (prod)",
  "url": "https://api.githubcopilot.com/mcp/",
  "transport": "http",
  "authType": "bearer"
}

# 2. Route a tool call THROUGH the gateway
POST /api/v1/mcp/invoke
{
  "serverId": "<mcp_servers.id>",
  "toolName": "create_issue",
  "arguments": { "repo": "acme/api", "title": "Broken login" },
  "jwt": "<optional bearer JWT, forwarded when authType='jwt'>"
}

# Allowed -> 200
{ "success": true,
  "data": {
    "decision": "allow",
    "reason": "all RBAC + rate-limit checks passed",
    "response": { },
    "latencyMs": 128
  }
}

# Denied -> 403 (role not in the tool's allowed_roles)
{ "success": false,
  "error": {
    "message": "caller role(s) [viewer] not in tool's allowed_roles [owner]",
    "code": "DENY_ROLE_NOT_ALLOWED"
  }
}

The code on a blocked call is the enforcement decision uppercased — DENY_NO_PERMISSION, DENY_ROLE_NOT_ALLOWED, DENY_RATE_LIMITED, or DENY_DISABLED. The presets below pre-load each server's tools with sensible allowed_rolesand risk levels so you don't hand-write these permission rows.