Documentation

The GetCited MCP server

Last updated 19 September 2026

One HTTPS endpoint, one Bearer key, and 20 tools. Your coding agent audits the site, reads each finding with the measurement behind it, ships the fix in your repo, and asks again afterwards whether anything moved.

The server reports what is wrong and never proposes the fix: it does not know your codebase, and the agent calling it does.

Endpoint and authentication

URL: https://app.getcited.dev/api/mcp
Transport: Streamable HTTP. The npm package proxies it over stdio.
Auth: Authorization: Bearer vseo_… — create a key under Settings, API keys.
Rate limit: 60 requests a minute per key.

Without a valid key the endpoint still answers, with a guest server that can describe the product and nothing else: it reads no data, writes nothing, and calls no paid provider. Keys are shown once and stored hashed, so a lost key is replaced rather than recovered.

Connecting a client

Claude Code

claude mcp add --transport http getcited https://app.getcited.dev/api/mcp \
  --header "Authorization: Bearer $SEO_API_KEY"

Any client that speaks stdio

The npm package is a thin proxy onto the same endpoint, for clients that do not support a remote server yet.

claude mcp add getcited --env SEO_API_KEY="$SEO_API_KEY" -- npx -y getcited-mcp

By hand, in a client config file

{
  "mcpServers": {
    "getcited": {
      "type": "http",
      "url": "https://app.getcited.dev/api/mcp",
      "headers": { "Authorization": "Bearer ${SEO_API_KEY}" }
    }
  }
}

Cursor and VS Code one-click badges are in the repository README, alongside an llms-install.md that lets an agent set this up for itself.

The tools

Sites

list_projects: Every site in the workspace, with its id.
add_project: Track a site. Re-adding one that was removed brings it back.
remove_project: Stop tracking a site. Reversible; the data stays.
get_site_health: Scores, issue counts by severity, and what was last measured.

The queue

list_actions: Open findings, most urgent first, each with its evidence.
get_action: One finding in full: the page, the rule, the measurement that fired.
claim_action: Mark a finding as being worked on, so two agents do not collide.
complete_action: Report back what changed. The next crawl decides if it is closed.
dismiss_action: Refuse a finding, in your own words. The reason is kept.
run_audit: Crawl the site and refile the queue.

Rankings

add_keywords: Track keywords for a site.
list_keywords: What is tracked, and where it stands.
rank_history: Position over time for one keyword, and whether an AI Overview cited you.
check_rankings: Check positions now rather than waiting for the schedule.

AI visibility

add_geo_prompts: Track the questions your buyers actually ask.
geo_summary: How often each engine cited you, per engine, never blended.
check_geo: Ask the 5 engines now and record who they cited.
run_brain: Re-run the analysis over what is already measured.

Visitors

get_behavior_digest: Where visitors arrive, where they stall, aggregated.
get_page_profile: One page in detail: entries, exits, the steps before the drop.

Two things the tools will not do

Write your copy or your code. Every finding carries its location, the measurement that fired it and why it matters; what to do about it is the agent's call, and a refusal is recorded with its reason.
Close a finding because someone said so. There is no 'mark as done': complete_action records what changed, and the next crawl decides whether the problem is actually gone.

Measurements follow the same rule. Answers from AI engines are stochastic, so we report how often each engine cited you over a window and never invent a per-run AI rank, and a gap is only reported once three runs agree. How each number is measured has the rest.

Support

Questions, a tool behaving oddly, or a finding you think is wrong: the support page has the address. Data handling is in the privacy policy, and the terms cover the rest.