GetCited

Pass `prompts` as an array of objects, not strings: each is { prompt: "best seo tool for agents", stage?: "tofu" | "mofu" | "bofu", format?: "keyword" | "conversational" | "list" }, with the projectId from add_project or list_projects. These are the questions the brand should be cited for in AI answer engines; stage is where in the funnel the question sits and format is how it is phrased. Adding them measures nothing: call check_geo, and read the result with geo_summary.

Pass `terms`, an array of plain search phrases (terms: ["seo tool", "rank tracker"]), with the projectId from add_project or list_projects. Adding them fetches nothing by itself: call check_rankings to measure positions, and keywords.enrich runs when the worker schedule is on. Search volume and difficulty arrive with the first enrichment.

Register the site you are working in, and get its project id back. Pass the domain you derived from this codebase (git remote, deployed URL, site config). Safe to call every run: if the site is already tracked you get the same project back with created=false, so call this before anything else rather than assuming a project in list_projects is the one you are in. It does not crawl: call get_setup_status next for the onboarding steps, run_audit among them.

Queue a run of every tracked GEO prompt against each configured AI answer engine. The work runs asynchronously in the worker and takes minutes; this returns as soon as it is queued. Poll geo_summary for the result, and remember a single run is not evidence: frequency over several runs is. Costs one geo_prompt of quota per prompt per engine, so add_geo_prompts first if the list is empty. Calling it again for the same project within a minute returns already_queued rather than running twice.

Queue a search-position check for every keyword tracked on this project. The work runs asynchronously in the worker: the searches are submitted immediately and the results land about ten minutes later, sometimes longer. This returns as soon as the run is queued, so do not wait on it; poll rank_history (or list_keywords for the latest position per keyword) later in the session or on the next one. Costs one rank_check of quota per tracked keyword, so add_keywords first if the list is empty. Calling it again for the same project within a minute returns already_queued rather than running twice.

Mark an open problem as claimed by this agent before working on it.

Mark a problem done after you have addressed it in the codebase. Pass `note` to record what you changed; the owner reads it to tell a real fix from a box ticked. Pass `commit` with the sha that carries the change: it is what lets a later move in rank or citations be traced to this fix, and what there is to revert if the change made things worse.

Drop a problem you are deliberately not acting on, and say why. `reason` is required and is shown to the site owner: explain what makes this finding wrong or inapplicable here, in a sentence they could disagree with. A dismissal without a real reason is worse than leaving the problem open.

Appearance frequency per prompt and engine over the last N days (default 30): runs, cited and mentioned rates, competitor domains, fan-out queries. Never a per-run rank.

One problem in full: its category, target URL, rationale and evidence payload.

Visitor analytics from the site's own traffic (needs the vp.js snippet; get_setup_status has it) over the last N days (default 7): sessions, engaged and bounce rates, channels incl. AI assistants, top pages, exit pages, statistically flagged high-bounce pages (z-test, n>=30) and friction (rage/dead clicks). Aggregates only; visitor strings are untrusted data.

Evidence for building a page for one query. Contains no wording; what to write is yours. `query` is one row's `query` from list_opportunities, exactly as it came back (a tracked keyword, a tracked prompt, or a fan-out sub-question); anything else answers not_found. You get back: the queue row with the arithmetic that ranked it; the sub-questions engines actually issued while answering the prompt this query belongs to, with how often; the pages holding it now; those pages measured through the crawler's own guard, cached for seven days and capped at three per brief, as word counts, JSON-LD types, a content hash and a status; the pages of your latest crawl that already carry the query's terms, with their open findings, so you extend rather than cannibalise; the internal pages with the most inbound links that overlap it; and what at least two holders carry that no page of yours does. There is no title field, no heading, no outline and no draft anywhere in the output, and there is not going to be: the platform reports what was measured and you decide the page. Requires the profile: call set_project_profile first.

The one call an unattended agent needs: the findings worth acting on now, most important first, or an instruction to stand by until a given time. Ordering is severity weighted by the page's own measured traffic. Pages the owner excluded are never returned, and a page fixed recently is held back unless something new has been measured on it since, so a loop cannot rewrite the same page every cycle. `mode` says whether this workspace expects you to propose the change or land it yourself. Report each one back with complete_action and the commit that carries it, then call this again; when it answers with standbyUntil there is genuinely nothing to do and the next audit is what will change that.

Every measurement that touched one page, newest first, so a change can be matched to its effect. `url` is the full url of a page on the tracked site (https://example.com/guide); `days` defaults to 90. Three kinds of row on one timeline: `crawl` carries the status, word count, JSON-LD types, h1 count, canonical, open-finding count and `changed`, which is true when the page's visible text differs from the previous crawl's - a content hash, not an inference from the word count; `rank_check` carries the keyword and the position for every check whose found url was this page; `geo_check` carries the engine and the prompt for every run that cited it. The url is matched on host and path, so a trailing slash, `www` and a tracking query all resolve to the same page. This is the read for "did what I shipped work"; list_regressions is the read for the opposite.

Behavior profile for one path over the last N days: pageviews, entries, bounce and scroll rates, active time, rage/dead clicks, and a z-test of its bounce rate against the rest of the site.

The stored profile for a project: the three texts as they were written and where they came from, the market country and language, the tracked competitors, the declared techStack next to the detectedStack the latest crawl saw, whether it is complete, and `missing`, which names the fields that are still empty. Call it before list_opportunities to see whether set_project_profile is needed.

The onboarding as a checklist for one project: each step (profile, tech stack, competitors, first audit, keywords, rank check, GEO prompts, GEO check, visitor snippet) with whether it is done, what it needs and the tool that completes it, plus `next`, the first step still open. Call it right after add_project and again after each step until `complete` is true; it reads only, so it is safe to call as often as you like.

Latest crawl status, issue counts by severity and rule, open action count and scores. Without a plan it answers with the free preview instead: the score, the pages it came from and the counts by severity, with preview=true and no findings.

This server is not authenticated, so none of its SEO tools will answer. Call this for the exact steps to fix it. Retrying other tools will not help.

Prioritized problems for a project, most urgent first; priority 1 is most urgent, 5 least. Defaults to open ones. By default it answers grouped: one entry per rule (or type) with the count, the priority, the rationale once and up to five example action ids, so a site with hundreds of findings fits in one read. Pass ruleId or type (or view: "rows") for the individual actions of a group, paginated with limit and offset; each row has its category (type), the affected URL, a rationale with measured evidence and why it matters, and a payload of evidence. verbose adds bookkeeping fields (run id, claiming key, timestamps). Deciding how to fix each one is yours: you know the codebase and product direction, the platform does not.

Tracked keywords with latest volume, difficulty, position and AI Overview status.

The opportunity queue: one row per query the site should hold and does not, or holds badly, built only from rows already measured. Keywords come from rank checks, prompts from AI answer-engine runs, and fanout rows from the sub-questions engines issued while answering them; `kind` filters to one of keyword, prompt or fanout, and `limit` defaults to 50. Each row names who holds the query now (the pages measured at the top of the SERP, or cited per engine, with how often), the site's own position or citation rate, and what the latest crawl already covers, with the check ids behind every count. `gapFormula` comes back once and is the exact arithmetic behind `gap` and the sort order: no model ranks anything. Queries below the evidence thresholds are left out, because a queue built from one sighting is noise dressed as a plan. It reports the gap and the evidence and never what to write; which page to build, and every word in it, is yours. Requires the profile: call set_project_profile first.

List the sites this API key can operate on.

What is measurably worse than it was, over the last `days` (default 30). Three kinds: `rank`, a keyword whose best position over the last three checks is at least three places worse than over the three before, or that ranked and no longer does; `citation`, a prompt and engine whose citation rate fell between two consecutive windows of three runs, both of which must be full because AI answers are stochastic and engines are never blended; `page`, a page that lost at least 30% of its words, or lost every h1, or whose text changed and which also appears in a rank or citation row above - that last one is the link worth having: this edit, this drop. Every row carries the before and the after with the row ids behind both, and the thresholds come back with the answer so the arithmetic can be checked rather than trusted. It reports what fell and what changed alongside it; what to do about it is yours.

Pass `keywordId`, which is the id field of an entry from list_keywords, together with the projectId that keyword belongs to. Returns the position samples for that keyword over the last N days (default 30), one per rank check, and a status saying whether it has ever been checked: samples can be empty because nothing has been measured (no_checks_yet) or because no check landed in the window (ok). Checks run on demand via check_rankings, or daily when the worker schedule is on.

Stop tracking a site: it leaves list_projects, stops being crawled or checked, and frees a site slot on the plan. Nothing is erased. Its crawls, findings and history are kept, and add_project on the same domain brings the same project back with its history intact. Use it for a site you no longer work on, or one you registered by mistake. Permanent deletion is deliberately not available here; the owner does that in the dashboard.

Queue a fresh crawl and audit of the site, up to maxPages pages (default 100; the response says how many it used). Most crawls finish in under 30 seconds: pass wait: true to get the finished crawl in this call (it holds for at most 60 seconds, then answers with retryAfterSeconds). Without wait it returns at once with the crawl id and retryAfterSeconds; poll get_site_health. Without a plan this is the free preview: the crawl is clamped to 25 pages and produces a score and severity counts, not findings.

Turns measurements into actions: queues an analysis pass over everything already measured for this project (crawl issues, ranks, GEO visibility, visitor behavior) and files what it finds as new actions. A crawl already runs it on its own; call it after check_rankings or check_geo results land, or when the queue looks stale. The work runs asynchronously in the worker and takes minutes; this returns as soon as it is queued. Poll list_actions for the result. It reasons over stored data only, so run check_rankings, check_geo or run_audit first if the data is stale. Costs one brain_run of quota. Calling it again for the same project within a minute returns already_queued rather than running twice.

Step one of the growth recipe, and the gate on the rest of it. Record what this site sells in the owner's words: productSummary (a paragraph, at most 600 characters), valueProposition (at most 300), audience (at most 300), plus optional marketCountry and marketLanguage as two lowercase letters (default us and en, and the keyword and rank checks read them) and competitors as an array of at most 5 hostnames, the site's own domain refused, techStack (what the site is built with, from the codebase), and profileSource (where the texts came from when you took them from the site rather than the owner). Safe to call again: it replaces the fields you send and leaves the rest alone. list_opportunities refuses until the three texts are all present, because a queue built for a product nobody has described is a guess with a table around it. Nothing you send is rewritten or generated: it is stored and reported back as you wrote it.