> ## Documentation Index
> Fetch the complete documentation index at: https://docs.browsary.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP servers & client configs

> Expose project functions via the Model Context Protocol and manage client credentials.

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**

```json theme={null}
{
  "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**

```json theme={null}
{
  "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.