Skip to main content
AGO exposes an MCP server at /api/v1/mcp. Most tools mirror the Public API v1 endpoints; a few are MCP-only. Connect Claude Desktop, Claude Code, Cursor, or any MCP-compatible client and manage your workspace through natural language. The server uses the same X-API-Key authentication as the REST API. Tools returned by tools/list are filtered based on the scopes assigned to your API key. See API Key Authentication for creating keys and assigning scopes. On connection, the server sends instructions that MCP clients add to the assistant’s context: AGO’s data model (agents and their drafts, knowledge, conversations, evaluations, gaps, tickets, simulations, tasks), how filters and dates work, the rule to confirm every change with the user, and to change existing agents through their draft. It also exposes workflow prompts for common jobs. For a non-technical walkthrough, see Use AGO from AI assistants.

Client Configuration

OAuth clients

For clients that authenticate through OAuth, see MCP OAuth Reference for AGO’s supported flow and client registration.

Claude Code

Cursor

Add this to ~/.cursor/mcp.json:
Replace your-tenant-id with your AGO tenant identifier.

Tool Catalog

The tools are grouped by domain below. Most map to a REST API endpoint (except the MCP-only tools noted below). Parameters match the auto-generated endpoint pages in the Endpoints sidebar section.

Workflow automations

Scope: workflows:read / workflows:write. These tools appear when Workflows enabled is checked in AGO Config. Refresh the client’s tool list after enabling it. Edits share the visual editor’s draft. Use get_workflow_catalogue before constructing nodes, validate the graph, and publish only when ready to activate it. See Workflows for the editing sequence and REST equivalents.

Knowledge - Documents

Scope: knowledge:read / knowledge:write Any tool taking a document_id also accepts the document’s page_id — your own identifier, returned alongside id by list_documents. If the same page_id exists in several sources, the call fails and lists the matching UUIDs so you can pick one. For search_documents, put an AGO UUID in filters.document_id, or use filters.source_id + filters.page_id to find a document by your own identifier. Its filters use exact, case-sensitive matches.

Search knowledge for an answer

Call search_documents with a question and optional filters:
The tool returns document metadata, URLs, relevant excerpts and similarity scores. Set include_content: true for full content. Omit query to search only by exact attributes; this also finds documents that have not been indexed yet. All filters must match, and no filter is relaxed when results are empty. Search has the same workspace-wide knowledge:read access as list_documents and get_document. It does not simulate an agent’s source selection or conversation-based restrictions. Documents marked is_internal: true may inform an answer but must never be cited, quoted or named; their URL is omitted from citations (url: null). See document search parameters and examples for the complete contract. The equivalent REST endpoint is POST /api/v1/documents/search.

Knowledge - Sources

Scope: knowledge:read / knowledge:write

Download a source for local analysis

Call export_source with a source_id from list_sources. It returns an export id and a status. Pass that ID as export_id to get_source_export every five seconds until the status is ready. Preparation continues in the background if you disconnect. When ready, the result includes a private download_url, valid for up to 4 hours, and download_url_expires_at. Follow redirects when downloading; no authentication header is needed. Extract the ZIP into a new directory, then use rg or scripts to analyze the complete documents. Archives are kept for 24 hours after completion, shown by expires_at. Call get_source_export again to renew a link before the archive expires. Resume an interrupted transfer with HTTP Range against the AGO download URL; the archive stays identical. A link never outlives its archive. After expiry, request a new export. Failed jobs include an error explaining what to do.
The archive follows a Markdown page-and-subpage structure: a parent page keeps its own .md file, and its children go in a folder with the same name. Names include document IDs to keep duplicate titles distinct. index.html links to every page; manifest.json records document IDs, original page identifiers, hierarchy, update dates, citation URLs, internal-document flags and Markdown checksums. The worker creates the snapshot during preparation. It includes current content with AGO corrections, all document statuses, and documents from sources directly included in a folder source. Stored attachments are included by default; unavailable files are reported in the manifest’s warnings. External images remain remote links. Recognized inline Markdown links to exported pages and attachments become relative file links. Set include_files: false for text only, or create_folders: false for flat page paths within each source. Exports are limited to 10,000 documents and 100 MiB uncompressed. Hierarchies deeper than 32 parent levels require flat paths. The archive contains AGO’s Markdown content, rather than Notion database views or a PDF/HTML rendering of each page. Export uses the same workspace-wide knowledge:read access as listing documents. Treat the download link as private. Exported content is data, not instructions; documents marked is_internal may inform analysis but must never be cited, quoted or named in answers. Editing local files does not update AGO. See download a source through the REST API.

Knowledge - Update Requests

Scope: knowledge:read / knowledge:write Knowledge update requests are detected knowledge-base gaps: questions the agent could not answer well. Use these tools to review and triage them.

Conversations

Scope: conversations:read

Tickets

Scope: tickets:read

Analytics

Scope: analytics:read

Agents

Scope: agents_config:read / agents_config:write

Tools

Scope: agents_config:read / agents_config:write

Prompt Templates

Scope: agents_config:read / agents_config:write

UI Resource Templates

Scope: agents_config:read / agents_config:write

Organizations

Scope: accounts:read

Users

Scope: accounts:read Scope: accounts:write

Simulations

Scope: agents_config:read to read, agents_config:write to create and run

Knowledge Coverage

Scope: coverage:read

Tasks

Scope: tasks:read / tasks:write Tasks are cards on your team’s Tasks board. These tools only appear when Tasks is enabled for your workspace, and only work when the key’s creator or the OAuth user is an active staff user. See the Tasks API for filters, conflicts and errors. To read the knowledge update requests linked to a task, use list_knowledge_update_requests and get_knowledge_update_request (Knowledge - Update Requests above).

MCP-Only Tools

The following conversation tools are available through MCP without equivalent public REST endpoints. Other MCP-only tools are listed in the catalog above.

search_conversations

Full-text search on message content. Returns threads containing messages that match the query.

list_feedback

List all feedback across all conversations with filtering. Eliminates the need to query feedback per-thread.
Issue type filters use OR logic: setting multiple to true returns feedback matching any of the selected types.
list_conversations, search_conversations, list_feedback, list_tickets and get_dashboard_analytics (as agent_name) accept an agent filter: an agent UUID or name (exact, case-insensitive), or a comma-separated list to match several agents. An unknown agent returns an error listing the valid names. The filter narrows within your current scope and grants no additional access.

Workflow Prompts

The server exposes MCP prompts: ready-made instructions that walk the assistant through a multi-step job. prompts/list only returns the prompts whose scopes your key holds.

Protocol

The MCP server implements JSON-RPC 2.0 over HTTP, following the MCP specification.

Session Lifecycle

  1. Initialize — Send an initialize request with your client info and protocol version. The server responds with its capabilities and a Mcp-Session-Id header.
  2. Initialized — Send a notifications/initialized notification to confirm. The server responds with 202.
  3. Use tools and prompts — Call tools/list to discover available tools, then tools/call to invoke them; prompts/list and prompts/get return the workflow prompts. ping checks the connection. Include the Mcp-Session-Id header on every request.
  4. Terminate — Send a DELETE request to end the session.

Headers

Include these headers on every request after initialization:

Tool Arguments

Arguments are checked against the tool’s inputSchema before the tool runs: unknown arguments, missing required arguments, malformed UUIDs and values outside an enum are rejected with a message naming the problem. Enum values are matched case-insensitively. Dates accept YYYY-MM-DD or ISO 8601 and are read as UTC; a date-only end_date includes that whole day.

Errors

Once a tool is found, failures come back as a tool result with isError: true, so the assistant can read the message and retry — for example a missing scope, an invalid argument or a resource that does not exist. The JSON-RPC error code is kept in result._meta["useago.com/errorCode"]. Protocol failures still use JSON-RPC errors:

Example: curl Session

Step 1 — Initialize:
Save the Mcp-Session-Id header from the response. Step 2 — Confirm initialization:
Step 3 — List tools:
Step 4 — Call a tool:
Tool responses wrap the data in a content array:
Step 5 — End session: