Talk to your Pitchko data

Pitchko exposes its AI-visibility, pitch deck, and SEO-audit data as a Model Context Protocol server, so an MCP-capable assistant — Claude, Cursor, or anything else that speaks the protocol — can answer questions against live data instead of a pasted screenshot.

Endpoint https://pitchko.io/api/mcp Read-only Scopes aeo:read · decks Streamable HTTP · stateless 60 req/min per key

What you can ask

`list_tracked_brands`

Your agency's tracked brands, with the ids the other visibility tools take. Needs aeo:read.

Arguments: agency_id?, limit? "Which brands are we tracking for AI visibility?"

`get_visibility_report`

The latest completed scan: overall score, per-engine and per-category breakdown, competitors, and GEO actions. Needs aeo:read.

Arguments: brand_id, include_prompts?, agency_id? "How visible is Acme in AI answers right now — and where are we losing to competitors?"

`get_visibility_history`

The trend line across scans, newest first. Needs aeo:read.

Arguments: brand_id, limit?, agency_id? "Is Acme's AI visibility improving month over month?"

`list_decks`

Your decks — own plus agency — newest first, with lifecycle status, brand, and timestamps. Needs decks.

Arguments: limit?, created_before? "Did last night's decks finish generating?"

`get_deck`

One deck's status; once completed, the PDF and PPTX download links. Needs decks.

Arguments: deck_id "Give me the download link for the Acme deck."

`list_audits`

Your agency's SEO audits: url, mode, status, score and grade. Needs aeo:read.

Arguments: agency_id?, limit?, created_before? "Which client sites have we audited this month, and how did they score?"

`get_audit_report`

One completed audit's full report: category grades, template-level issues, PageSpeed summary, narrative. Needs aeo:read.

Arguments: audit_id, agency_id? "What are the top three SEO problems on acme.com, and how do we fix them?"

The visibility and deck tools return the same JSON as the corresponding REST endpoints — field-by-field detail lives in the API reference; the audit tools are MCP-only today. A pk_test_ sandbox key connects exactly the same way: the visibility tools return a fixture brand, sandbox-created decks simulate the full lifecycle, and the audit tools ask for a live key.

Connect

Mint an API key (Dashboard → Settings → Developers) with aeo:read for the visibility and audit tools, decks for the deck tools, or both. The connection succeeds with either scope; tools/list shows only the tools your key can call, and a call outside your key's scopes gets 403 insufficient_scope naming the scope to add. A key with neither scope fails at the handshake rather than half-working.

Claude Code

claude mcp add --transport http pitchko https://pitchko.io/api/mcp \
  --header "Authorization: Bearer $PITCHKO_API_KEY"

Claude Desktop · Cursor · VS Code · any config-file client

{
  "mcpServers": {
    "pitchko": {
      "type": "http",
      "url": "https://pitchko.io/api/mcp",
      "headers": { "Authorization": "Bearer <your API key>" }
    }
  }
}

Good to know

There is no write tool — on purpose. A scan is hundreds of live LLM calls against your plan's spend meter, and a deck generation spends a paid credit; an MCP client is a model choosing its own tool calls. Spending stays where a human authorises it: the dashboard, the weekly schedule, and the REST API you call deliberately from your own code.
null is not 0. 0 means the brand was queried and never mentioned; null means the metric was not measured. The server repeats this in its tool descriptions so well-behaved assistants see it before the first call — worth restating in your own system prompt too.
POST only. Opening the endpoint in a browser sends a GET and returns a JSON-RPC error by design — that is the server declining to hold an SSE stream open, not a fault.
Tools only. Protocol versions 2025-06-18 and 2025-03-26; no resources, prompts, or sampling; no session state, which is what makes it safe on serverless.

Integration Guide API Reference OpenAPI 3.1 (JSON) Changelog