MCP servers

An agent’s tools come from three places: the built-ins (web-search, wikipedia, …), the resources of its project (a dataset’s query, a vector dataset’s search), and MCP servers: remote servers speaking the Model Context Protocol, which expose their own tools, a ticketing system, a CRM, an internal API. The platform fetches a server’s tool list at the start of each run and hands it to the model with the others. An MCP server is declared once per project as a tool resource, with its credential encrypted and never shown again.

Declaring a server

curl -X POST https://api.gwenlake.com/v1/tools \
  -H "Authorization: Bearer $GWENLAKE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Jira",
    "slug": "jira",
    "project_id": "res.project.…",
    "configuration": {
      "type": "mcp",
      "url": "https://mcp.example.com/jira/sse",
      "auth": "headers",
      "credentials": {"headers": {"Authorization": "Bearer …"}}
    }
  }'

Field	Meaning
`url`	the server’s endpoint, `http` or `https` only
`transport`	`sse`, the only transport accepted today
`timeout`, `sse_read_timeout`	seconds, for the connection and for a quiet stream
`auth`	`headers` (static headers, an API key or a bearer) or `client_credentials` (an OAuth2 client)
`token_url`, `scope`	for `client_credentials`: where to exchange the client for a token, and the scope to ask
`credentials`	`{headers}` or `{client_id, client_secret}`; write-only

A read of the tool returns the configuration with has_credentials: true and no credential. PATCH /tools/{id} deep-merges the configuration: changing the URL keeps the headers, and credentials: {headers: {}} clears them. Rotating a token is one PATCH. With client_credentials, the platform exchanges the client id and secret for an access token at token_url just before the server is reached, and caches it until a minute before it expires. Nothing is stored. POST /tools/{id}/test reaches the server with the stored credential and answers its tool list, so a declaration is checked before an agent depends on it.

Why a resource and not a line in the agent

An agent definition may also name a server inline:

mcp:
  - ref: jira                      # a tool resource of the project: preferred
  - url: https://mcp.example.com/other/sse
    headers: {Authorization: "Bearer …"}
    timeout: 30

The inline form works, but its headers sit in clear in agent.md, on the storage and in every version. The resource keeps the credential encrypted, declares the server once for every agent of the project, and takes a rotation in one call. Only remote servers are accepted: an entry naming a local command is refused, since it would run arbitrary code where the agents run.

At run time

For each server the platform connects, lists the tools and hands them to the model alongside the built-ins and the resource tools. A server that cannot be reached fails the turn with a 502 naming it, rather than letting the agent answer with a tool missing. MCP tools do not appear in GET /agents/{id}/tools, which would need a network call per read; they exist for the run.

These endpoints are served by the platform and used by the Atlas interface; they are being opened on the public gateway progressively, and the Python library does not wrap them yet. The API reference lists what the gateway exposes today.

Get started

Concepts

Workspace

Data

Code

Build

Models

Inference

Agents

Client

Changelog

Declaring a server

Why a resource and not a line in the agent

At run time

​Declaring a server

​Why a resource and not a line in the agent

​At run time

Declaring a server

Why a resource and not a line in the agent

At run time