Machine API and the MCP server: let your tools (and AI agents) talk to Veritome

Beyond the browser, Veritome speaks two machine dialects — a REST API for scripts and integrations, and an MCP server for AI assistants. Both authenticate with the same organisation-scoped API keys (see API keys and organisation data export for creating and revoking them; API access is a Manage-plan feature).

The REST API

The API is documented by a machine-readable OpenAPI 3.1 specification at /api/v1/openapi — point any client generator or API tool at it. The surface is deliberately compliance-shaped:

• Systems — list, read one, and intake: POST /api/v1/systems registers a system programmatically, returning 201 for a new record or 200 if it already exists, and 402 when your plan's system limit is reached. Wire it to your procurement or architecture-review process and shadow AI gets a paper trail the moment someone requests a new tool.
• Obligations — list the engine-materialised obligations across your systems, read one, and PATCH its status, owner or due date with a read & write key. This is the one write on obligations; classification, evidence and approvals stay in the product.
• Incidents, evidence and risk items — cursor-paginated reads of the Art. 73 register, the evidence library and the Art. 9 risk register, enough to build dashboards or feed a GRC warehouse.
• Reports — the generated-report archive.
• Audit log — reads with cursor pagination and a since parameter, built for SIEM ingestion — see SIEM ingestion: pull the audit log, and Webhooks for the push-side counterpart.

Every request is authenticated, org-scoped, rate-limited per key and audit-logged like any user action. A 403 means the key's scope or your plan does not allow the call; a 429 means the per-minute limit was hit.

The MCP server

The Model Context Protocol is the standard for giving AI assistants controlled access to tools. Veritome's MCP server lives at POST /api/mcp — stateless streamable HTTP, one JSON-RPC message per request, no sessions — and exposes a small, deliberate toolset: list_systems, list_obligations, list_incidents, list_evidence, list_risk_items, query_audit_log, and register_system.

Point an MCP-capable assistant (Claude, or anything else that speaks the protocol) at the URL with your key as the bearer token, and you can ask questions like "which of our high-risk systems have overdue obligations?" or "file an intake for the new support chatbot" — answered from your live data, under your key's permissions, with every call landing in the audit log.

Two properties worth knowing before you wire an agent up:

• The server is stateless and org-scoped. The assistant sees exactly what the API key sees — one organisation, nothing else.
• Reads dominate. The only MCP write is register_system, and it needs a read & write key; a read-only key gets a clear refusal. An agent cannot complete obligations, change classifications or touch evidence through MCP. Compliance decisions stay with people.

Which to use

Scripts, pipelines, SIEM: the REST API. Conversational access from an AI assistant your team already uses: MCP. They are the same data behind the same keys — pick per consumer, not per project.