Data that only lives in one dashboard gets looked at once a month. SOV Tracker gives you two doors into the same numbers: a REST API that feeds your reporting stack, and an MCP server that puts your Share of Voice one question away in an MCP client that supports Authorization headers. One key opens both, and every MCP tool is read-only.
Endpoint
https://sovtracker.com/api/mcp (Streamable HTTP)
Authorization: Bearer avt_live_β’β’β’β’β’β’β’β’β’β’β’β’The same Bearer key authenticates the REST endpoints under /api/v1. Keys are shown once, on creation.
No SDK to install and no separate integration to maintain. The key you create in the dashboard is the only credential involved.
Keys are created in the dashboard under Settings. Every key starts with avt_live_ and carries a read permission; the MCP server only authorizes keys that have it. API and MCP access is part of the Pro plan and above.
Point any MCP client at the endpoint below. The server speaks Streamable HTTP and authenticates with the same Bearer header as the REST API, so there is no separate account, no extra install and no second password to manage.
Ask your assistant a question about your visibility and it calls the matching read-only tool, then answers from your own scan data instead of guessing. The same tools are available to your scripts through the REST API.
claude mcp add --transport http sovtracker https://sovtracker.com/api/mcp --header "Authorization: Bearer avt_live_β’β’β’β’β’β’β’β’β’β’β’β’"Generate the key under Settings β API in the dashboard. Pro plans and up.
Run in Claude Code, then check the connection with /mcp. Use your own key in place of the masked example.
ChatGPT: direct connection with a SOV Tracker Bearer key has not yet been validated. These examples cover clients that can send an Authorization header.
Three surfaces over one dataset: tools for your assistant, endpoints for your code, and a webhook that tells your systems when fresh data landed.
Every tool in this version is read-only and scoped to the organization that owns the key. There is deliberately no scan-trigger tool: an assistant that loops cannot burn your scan quota. Reading is safe by construction, so you can hand the connection to your whole team.
Four endpoints under /api/v1: GET /api/v1/sov for the current score, GET /api/v1/scans to list scans, POST /api/v1/scans to start one from your own code, and GET /api/v1/archive for the dated raw answers with cursor pagination. Same Bearer key, JSON responses.
The scan.completed event is delivered to your endpoint when a scan finishes, with the event name in the X-Sovtracker-Event header and an HMAC-SHA256 signature of the payload in X-Sovtracker-Signature so you can verify it. Endpoints are managed in dashboard Settings.
This is the complete list: 6 tools, all read-only, all scoped to the organization that owns the key.
| Tool | What it returns |
|---|---|
| get_visibility_summary | Latest completed scan: overall Share of Voice score, per-platform score and whether the brand was mentioned, plus the trend against the previous scan. |
| list_keywords | The keywords your organization tracks in AI answers, with their status (active or paused) and creation date. |
| get_scan_results | Row-level results for a scan: platform, keyword, mention, SOV score, sentiment and mention position, filterable by platform or keyword. |
| get_answer_archive | Dated raw AI answers from past scans, so you can read what a platform actually said on a given day. Long answers are truncated and paginated with a cursor. |
| get_business_card | Verified Entity Store card status: trust score, per-field-group freshness and the active-business attestation date. Read-only, like every other tool here. |
| get_ai_traffic | Human visits associated with AI tools over the last N days, reported in two separate signal classes: direct AI referral and AI-tagged. They are never merged into a single referral number. |
Read-only by design: no tool in this version writes data or starts a scan, so a looping assistant cannot spend your scan quota.
60 requests per minute per key on the MCP server, and the same limit on GET /api/v1/archive. Over the limit you get a 429, never a silent failure.
Both share one gate: the Pro plan and above. A key belonging to a lower plan is rejected before it reaches any data, and the same key works for the REST endpoints and the MCP server, so there is nothing extra to buy or wire up once you are on Pro.
No. This version of the MCP server exposes read tools only, and no tool can trigger a scan. That is a deliberate cost guard. Scans stay under your control: you start them from the dashboard, or from your own code with POST /api/v1/scans, which allows at most 30 scan starts per hour.
The MCP server allows 60 requests per minute per key, and GET /api/v1/archive applies the same 60 requests per minute. Starting scans is limited separately to 30 per hour. Going over a limit returns 429 rather than failing silently, so your integration can back off and retry.
scan.completed is the event that fires on its own, every time a scan finishes, with no extra configuration. It is signed with your endpoint secret so you can verify that the request really came from us. Other events depend on your alert rules; the full list and payloads are in the API reference.
Create a key in the dashboard, paste the endpoint into your MCP client, and ask your first question. API and MCP access is part of the Pro plan and above.