Tools
Three ways to let an agent reach something beyond its own files.
What every agent already has
Reading, writing and editing files, a shell, and search across its own drives. You do not switch those on. Beyond them, three ways to give an agent more.
Platform capabilities
Named, and switched on by listing them:
tools: ['web_search']web_search | Search the live web. We carry the keys; you do not bring your own |
A name we do not recognise is rejected when you create the agent.
MCP servers
Connect a server and its tools become available to the agent.
mcpServers: [{
name: 'linear',
url: 'https://mcp.linear.app/sse',
transport: 'sse', // or 'http'
headers: { Authorization: 'Bearer {{secrets.LINEAR_TOKEN}}' },
}]Put credentials in headers as {{secrets.NAME}}, naming a secret
the agent declared. A literal token would be stored in the version, and a version is
readable.
Your own endpoints
You describe the request; we make it. There is no code to deploy and nothing of yours runs in our runtime.
httpTools: [{
name: 'order_lookup',
description: 'Fetch one order by its number. Use before any refund decision.',
method: 'GET',
url: 'https://api.you.com/orders/{{params.id}}',
params: { id: { type: 'string', required: true } },
secrets: ['ORDERS_API_KEY'],
headers: { Authorization: 'Bearer {{secrets.ORDERS_API_KEY}}' },
}]{{params.x}} and {{secrets.X}} are resolved when the call is made
and never stored resolved.
description does the same job when does on a workflow: it is how the
agent decides this tool is the one. "Fetch one order by its number" is useful; "orders API" is
not.