Once your knowledge is curated and approved, the last step is letting your agents reach it. This is a practical guide to doing exactly that over MCP, with the real tools, requests, and responses the live API returns, plus the REST equivalents for anything that isn’t MCP-native.

The Model Context Protocol (MCP) is an open standard for giving an agent tools it can call. Curated Data ships a hosted MCP server, so there’s nothing to run or scale yourself. You point an MCP client at one URL, sign in with OAuth or use a scoped API token, and your agent can search and fetch your approved knowledge as first-class tools.

Step 1: choose OAuth or an API token

Compatible remote MCP clients discover Curated Data OAuth automatically. Sign in, select an organization, and approve the scopes and classifications the client may reach; access tokens are short-lived and the grant is revocable. For clients without OAuth, go to Settings → API Tokens and create a token. API tokens look like ckd_live_…, carry one or more scopes (read, write), and are limited to a set of classifications. For a read-only retrieval agent, a read token scoped to the classifications it should see is all you need. The token serves exactly one workspace’s currently approved documents; it can never read another company’s knowledge.

Step 2: point your MCP client at the server

The endpoint is /api/curated-data/mcp on your app host. It’s a stateless Streamable-HTTP MCP endpoint: every call is a single POST carrying its own bearer token; there’s no server session to open or tear down. Claude Code can connect and launch the OAuth flow with one command:

$ claude mcp add --transport http curated-data \
    https://curateddata.megacorp.company/api/curated-data/mcp

# Run /mcp, choose curated-data, then sign in and approve access.

Step 3: discover the tools

An MCP client lists tools with a tools/list JSON-RPC call. The server exposes nine, each a thin adapter over the same token-scoped surface the REST API uses:

• search_knowledge: full-text search over your approved concepts.
• get_concept: fetch one concept by path, with its inbound/outbound links.
• list_concepts: list approved concepts, filterable by type or tag (paginated).
• recommend_knowledge: analyze source material and draft reviewed changes.
• ingest_source: queue a URL crawl or raw-text ingestion job.
• suggest_update: submit a missing or changed answer for curation.
• get_import: poll an ingestion or suggestion job.
• propose_concept: create a new concept as a draft (needs the write scope).
• update_concept: update a concept’s open draft (needs the write scope).

Write-scoped tools are deliberately un-privileged: even with a write token, new or changed knowledge enters the human review workflow and is never auto-approved. An agent can suggest knowledge; only a human reviewer can make it real.

Step 4: call a tool

Here’s a raw tools/call against the endpoint: the exact request an MCP client sends under the hood, and the response your agent gets back:

$ curl https://curateddata.megacorp.company/api/curated-data/mcp \
    -X POST \
    -H "Authorization: Bearer ckd_live_••••••••" \
    -H "Content-Type: application/json" \
    -H "Accept: application/json, text/event-stream" \
    -d '{
      "jsonrpc": "2.0",
      "id": 1,
      "method": "tools/call",
      "params": {
        "name": "search_knowledge",
        "arguments": { "query": "active user", "limit": 3 }
      }
    }'

MCP wraps tool output in a content array; here the text is the JSON search result:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [{
      "type": "text",
      "text": "{\"results\":[{\"path\":\"metrics/active-user.md\",
        \"title\":\"Active user\",\"type\":\"metric\",
        \"classification\":\"internal\",\"rank\":0.61,
        \"headline\":\"A user with at least one <b>session</b> in the trailing 28 days…\"}]}"
    }]
  }
}

Prefer plain HTTP? The REST API is identical underneath

Anything that isn’t MCP-native can use the frozen REST v1 surface at /api/curated-data/v1. It’s the same token, the same approved document revisions, the same classification scoping, just plain requests:

$ curl 'https://curateddata.megacorp.company/api/curated-data/v1/search?q=active+user' \
    -H "Authorization: Bearer ckd_live_••••••••"
# → { "results": [ { "path": "...", "rank": 0.61, "headline": "…" } ] }

$ curl https://curateddata.megacorp.company/api/curated-data/v1/concepts/metrics/active-user \
    -H "Authorization: Bearer ckd_live_••••••••"
# → the concept: frontmatter, body, version, inbound/outbound links

There’s also a machine-readable contract at /api/curated-data/v1/openapi.json if you’d rather generate a client.

Handle rate limits gracefully

Requests share the organization's plan quota across every token. A token can have a stricter override. When an organization or token window is exhausted, the API returns 429 withRateLimit-Policy, RateLimit, and a Retry-After header (in seconds):

HTTP/1.1 429 Too Many Requests
Retry-After: 37
RateLimit-Policy: "org-minute";q=60;w=60, "org-day";q=5000;w=86400
RateLimit: "org-minute";r=0;t=37, "org-day";r=4832;t=28794

{ "error": "RATE_LIMIT_EXCEEDED", "scope": "organization", "window": "minute" }

A well-behaved agent should back off for the number of seconds in Retry-After rather than hammering the endpoint. That’s the only edge case most integrations hit.

That’s the whole integration

Mint a scoped token, point your client at one URL, and your agent retrieves approved knowledge as it answers, over MCP or REST, from each document's current approved revision. Everything it can reach was approved by a human and is scoped to exactly what that token is allowed to see. No pipeline to babysit, no vector store to keep in sync, just your approved knowledge, one call away.