MCP server
A Model Context Protocol endpoint exposing 12 tools — the same tasks, webhooks, artifacts, and messages as the REST API. Connect your agent and it can register itself, then create and manage resources directly.
Endpoint
https://agtls.dev/api/mcpStreamable HTTP transport. The server is stateless — each request is independent — and accepts GET, POST, and DELETE.
Authentication
Auth is optional, mirroring the REST API. There are two ways to authenticate:
- Send an
Authorization: Bearer agt_…header on the MCP connection, or - Pass an
api_keyargument to any individual tool call.
Without a key, tools operate anonymously: created resources are public and return a claim_token. No key yet? Call the agent_auth tool (action: register) to mint one, then pass it as api_key on every subsequent call.
Client configuration
Most MCP clients accept a server config like this (the headers block is optional):
{
"mcpServers": {
"agtls": {
"url": "https://agtls.dev/api/mcp",
"headers": {
"Authorization": "Bearer agt_…"
}
}
}
}Tools
webhooks_readRead webhook endpoints and their captured events. With no `id`, lists your endpoints. With `id`, returns that endpoint (including its event count). With `id` + `event_id`, returns that single captured event. With `id` + `include_events: true`, returns the endpoint plus a page of its most recent events (honors `limit`/`after`).
webhooks_writeManage webhook endpoints and their captured events. Actions: `create` (requires `name`) returns the endpoint including the catch URL to POST to; `update`/`delete` act on an endpoint (`id`); `delete_event` removes one captured event (`id` + `event_id`); `clear_events` removes all events for an endpoint (`id`).
inboxes_readRead inboxes — durable work queues for agents — and their pending events. With no `id`, lists your inboxes. With `id`, returns that inbox (including its pending event count; expired events are never counted or returned). With `id` + `event_id`, returns that single pending event. With `id` + `include_events: true`, returns the inbox plus a page of its pending events (honors `limit`/`after`). Consumers should list events, process them, then call `inboxes_write` action=ack_event on each one to remove it from the queue.
inboxes_writeManage inboxes and deposit or consume their events. Actions: `create` (requires `name`) returns the inbox including the ingest URL to POST to; `ingest` deposits an event (`id` + `body`) and needs only the inbox ID — no auth required, even for org-owned inboxes, since the ID is the capability; events expire after a TTL (the inbox default, or a per-event `ttl_seconds` override) and are then invisible to every read; `ack_event` (`id` + `event_id`) removes one event once you've processed it — list, process, then ack each event to drain the queue; `clear_events` removes all events for an inbox (`id`); `update`/`delete` act on an inbox (`id`).
artifact_readRead artifacts. Pass an `id` to fetch a single artifact (with full content), or omit it to list artifacts. Anonymous callers can't list, but can fetch a public artifact by ID.
artifact_writeCreate, update, or delete a file artifact. `create` requires `name` and `content` (markdown by default, or html); `update`/`delete` require `id`.
messages_readRead scheduled messages. Pass an `id` to fetch a single message (with its delivery status), or omit it to list messages. Anonymous callers can't list, but can fetch a public message by ID.
messages_writeSchedule or cancel a message. `schedule` fires an HTTP request at a URL at a future time — provide either `scheduled_at` (absolute Unix seconds) or `delay_seconds` (relative to now). `cancel` deletes a scheduled message (requires `id`); if it hasn't fired yet, it never will.