Skip to main content
Browsary can host Model Context Protocol (MCP) servers backed by project functions. Two resource types are involved:
  • MCP servers – define the set of functions exposed under a slug.
  • MCP client configs – link an MCP server to an API key so tools such as Claude Desktop can authenticate.

​
MCP servers

​
GET /:project/api/mcp-servers

Returns all servers visible to the caller. Each view is produced by toMcpServerView and includes { id, name, slug, description, functions[] }.

​
PUT /:project/api/mcp-servers

  • Body
{
  "name": "browser-tools",
  "slug": "browser-tools",
  "description": "Functions safe for MCP",
  "functionIds": ["fn_123", "fn_456"]
}
Slug collisions inside the project are rejected. functionIds is optional; when provided, they are normalized and stored in the mcp_server_functions table.

​
GET / PATCH / DELETE /:project/api/mcp-servers/{serverId}

  • GET – requires read permission. Returns the same view as the list endpoint.
  • PATCH – accepts name, description, slug, and functionIds. Changing slug enforces uniqueness. Function assignments are fully replaced when provided.
  • DELETE – removes the server and its function relations.

​
GET /:project/api/mcp-servers/{serverId}/mcp

Exposes the server over SSE so MCP-compatible clients can connect.
  • Auth – API key sent via x-api-key or Authorization header.
  • Requirements – the API key must be linked to the server through at least one MCP client config (see below).
  • Behavior – Browsary spins up an MCP server, maps function parameters to JSON schema, validates incoming arguments with AJV, and executes the backing function version. Responses are sent as SSE frames that MCP clients understand.

​
MCP client configs

​
GET /:project/api/mcp-client-configs

Lists the available configs with their linked servers and API keys.

​
PUT /:project/api/mcp-client-configs

  • Body
{
  "name": "Claude desktop",
  "description": "Workstation access",
  "mcpServerId": "mcp_123",
  "apiKeyId": "key_456"
}
  • Behavior – validates that the MCP server belongs to the project and that the API key belongs to the current user (unless they are an admin). Names must be unique within the project.

​
GET / PATCH / DELETE /:project/api/mcp-client-configs/{configId}

  • GET – returns the detailed view.
  • PATCH – accepts name, description, mcpServerId, and apiKeyId. Colliding names are rejected. When you switch the server or key the relations are updated automatically.
  • DELETE – removes the configuration and severs access for the associated API key.
With these two resource types you can approve exactly which function sets an API key can reach via MCP, powering secure tool integrations.