Cituna

View saved version →

---
name: autopilot
description: Run Cituna Autopilot, the weekly plan built only from evidence (Search Console queries, tracked prompts the brand is not named on, verified source gaps). It holds pages inside their 28-day window and proposes enrich, publish, title, pitch, fix or skip; nothing is written until the user picks rows. Use for "run the autopilot", "weekly SEO or AEO plan", "what should we work on this week", "get us cited".
---

# Cituna Autopilot: plan the week from evidence

Read [connection and evidence rules](../../references/connection-and-evidence.md) and
[autopilot rules](../../references/autopilot-rules.md). Writing goes to the sibling
`autopilot-write` skill; logging and the 28-day re-check to `autopilot-measure`.

One rule decides everything: **no evidence, no work.** Evidence is a Search Console query
with impressions, a tracked prompt the brand is not named on, or a verified source gap.
Everything else is enriched into an existing page or skipped. Building the plan costs only
reads (stored Cituna data is free; Search Console reads are metered but cheap). Model
writing happens only for the rows the user picks.

Options the user may add: `dry` (show the plan and stop, no question), `write N` (new pages
this week, default 2), `enrich N` (default 2), a brand or domain.

## 1 · Connect and load last week

1. `whoami`, `list_brands`, `gsc_status`, once per conversation. Use the named brand, the
   only brand, or ask. On Starter, say once that the plan and drafts work but applying needs
   Pro. If Search Console is not connected for the domain, drop the Search Console lanes, say
   the plan covers AI answers and sources only, and point to https://cituna.com/integrations.
2. Read the change log and last plan if they exist (see autopilot-measure): pages whose
   `hold_until` has not passed are held; open rows from last week come back first. If
   re-checks are due, run autopilot-measure first so this week's plan learns from them.

## 2 · Read (about ten calls)

| Call | Arguments | Keep |
| --- | --- | --- |
| `gsc_striking_distance` | `domain`, `days: 28`, `minPosition: 4`, `maxPosition: 60`, `limit: 40` | query, page, position, impressions |
| `gsc_zero_click_pages` | `domain`, `days: 28`, `limit: 20` | `snippet` and `page-two` rows with top queries |
| `gsc_cannibalisation` | `domain`, `days: 28`, `limit: 20` | non-brand queries split across pages |
| `gsc_coverage_gap` | `domain`, `days: 90`, `limit: 50` | silent URLs: page inventory, not work by itself |
| `get_visibility` | `brand` | prompts answered and not cited, per engine |
| `list_citation_sources` | `domain`, `range: "30d"`, `gapsOnly: true`, `limit: 15` | verified gaps, `yourPagesEnginesCite`, `whatEachEngineReads` |
| `list_keywords` | `domain`, `stage: "none"` | `content.existingUrl`: the page that already serves a keyword |
| `list_content_queue` | `domain`, `limit: 5` | `enabled`, `destination`, the `queued` topics |
| `list_articles` | `domain`, `status: "live"` | AutoSEO pages: `url`, `lastSentAt`, `editsNotSent`, `enrich.eligible` |
| `list_gaps` | `domain` | Cituna's own fix list |

Read every `history` block first. `windowTruncated: true` means a young property: deep
positions there mean Google barely knows the site, not that the content is weak. Do not page
through `list_content_queue` articles for the plan; they are large. `list_articles` gives the
AutoSEO pages as short rows, 50 a call; pass `nextCursor` as `before` only when an older page
is a candidate.

## 3 · Candidates

Sort every signal into the lanes in the rules:

- **Near page one:** striking rows at 4 to 20 with 20+ impressions, grouped by page. The
  page's searches are the evidence; what they ask that the page does not answer is the work.
- **Seen, not clicked:** zero-click rows with cause `snippet`. `page-two` rows go to
  enrichment, `ranking` rows are not title work, `branded` rows are skipped.
- **Unserved demand:*

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: autopilot-measure
description: Keep Cituna Autopilot's change log and re-check each change after its 28-day window, comparing Search Console clicks with the site's own trend and AI citations with the 30-day record, without claiming causes the data cannot show. Use for "log this change", "did our changes work", "28-day re-check", "what have we learned".
---

# Log every change, re-check it after 28 days

Read [connection and evidence rules](../../references/connection-and-evidence.md) and
[autopilot rules](../../references/autopilot-rules.md), which define the log line. A change
nobody logged cannot be learned from, so log on the day it goes live, not the day it merges.

## Log a change

1. Take the live date (deploy day), the URL, the type and the evidence from the plan row.
   For an AutoSEO page the live date is its new `lastSentAt` in `list_articles`.
2. Read the `before` numbers now, while they are easy to get:
   - The page: `gsc_query` with `domain`, `dimensions: ["page"]`, `startDate` = live date
     minus 28 days, `endDate` = live date minus 1, and a filter `{dimension: "page",
     operator: "equals", expression: <url>}`. Keep clicks, impressions, CTR, position.
   - The site, same window: `gsc_query` with `dimensions: ["date"]`, `rowLimit: 40`; sum the
     clicks and impressions.
   - Each evidence prompt: today's `get_visibility` cells (engines that answered, engines
     naming the brand) and the page's entry in `list_citation_sources.yourPagesEnginesCite`
     (30-day `count` and `byEngine`), if it has one.
   - A pitch: the host's `youOnThisSite` and `outreachStatus` from `list_citation_sources`
     with `search` set to the host.
   - A refresh: the title and description it replaced, from the `before` that
     `enrich_article` returned.
3. Set `hold_until` to the live date plus 30 days and `recheck_on` to the live date plus 33:
   the after-window runs from day 3 to day 30, and Search Console reports about 3 days late.
4. Append the line to the log (with a filesystem,
   `~/.cituna/autopilot/<domain>/changes.jsonl`; otherwise print it in a fenced block titled
   "Cituna change log" and ask the user to keep it for the next run).

## Re-check what is due

Read the log (or ask the user to paste it). Due: `recheck_on` on or before today. Early: at
least 14 days of after-data; report those as "so far", never as a result.

For each due change:

1. **Windows.** Before: the 28 days before the live date. After: day 3 to day 30. Read the
   page and the site for the after window exactly as for `before`. Check the `history` block:
   a window the property does not fully cover is reported as such.
2. **Search Console verdict.**
   - `title`, `description` or `refresh`: if the average position moved more than 3, the change is
     confounded (report it as a ranking move). Otherwise expected clicks = after impressions x
     before CTR.
   - `enrich` or `fix`: expected clicks = before clicks x (site clicks after / site clicks
     before), so a seasonal rise or fall does not count.
   - Win or loss only when actual and expected clicks differ by more than 2 x the square root
     of expected and by at least 5 clicks; otherwise flat. Under 100 impressions in the after
     window: too few impressions to judge, report the movement only.
   - `new-page`: no before. Report the impressions, clicks, position and top queries it
     earned in the after window (`gsc_query` with `dimensions: ["query"]` and the page filter).
3. **AI verdict.** Compare with the `before` snapshot. The 30-day record is the measure: read
   at the re-check, the page's `yourPagesEnginesCite` entry (`count`, `byEngine`, `queries`)
   covers about the after window. Missing before and listed now means engines started reading
   the page; more engines or citations means they read it more. Today's `get_visibility` cells
   for each evidence prompt say whether engines name the brand: absent to

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: autopilot-write
description: Write one page or enrichment a Cituna Autopilot plan approved, with a claims ledger for every fact and a separate fact-check pass, then publish through the user's repository or CMS, or Cituna's copy of an AutoSEO page, and record it in Cituna. Never writes without evidence or publishes by itself. Use for "write the approved page", "draft the enrichment", "fact-check this draft".
---

# Write, check and publish one approved row

Read [connection and evidence rules](../../references/connection-and-evidence.md),
[autopilot rules](../../references/autopilot-rules.md) and
[page rules](../../references/autopilot-pages.md). Work one row at a time and finish it
before the next.

## 0 · Pick the lane before writing a word

Nothing generated may be thrown away, so the publishing route is chosen first:

- **Write here:** draft with a ledger, fact-check, the user publishes (repository or CMS),
  then `mark_article_published` records the live URL.
- **Queue for AutoSEO:** `queue_article` hands the keyword to Cituna's AutoSEO, which writes
  its own draft. Check `list_content_queue.enabled` first: when AutoSEO is off the topic only
  waits. Never draft here as well; that draft would be discarded.
- **Enrichments are written here.** For a page AutoSEO wrote (it is in `list_articles`), the
  approved blocks go into Cituna's copy with `update_article`, and the page changes when the
  user sends the article from the Cituna app. Keep its edits in Cituna: `enrich_article`
  refuses a page edited on the site since Cituna sent it.
- **A refresh is Cituna's, not a draft:** a `title` row on an AutoSEO page that
  `list_articles` shows with `enrich.eligible: true` goes to `enrich_article`, which writes the
  title, description and up to two FAQ answers from the page's own queries and updates the
  live page. Draft nothing here for it.

## 1 · Re-check the row (free)

The row must carry its evidence: the queries with impressions and position, the prompt with
the engines that answered without the brand, or the source host with its `absent` check. A
request without evidence goes back through the autopilot gates; if none applies, stop and
offer to enrich an existing page or skip.

The plan may be days old, so re-run two gates for this row: the 28-day hold on the target
page, and `list_keywords` (`content.stage`, `content.existingUrl`) for the keyword. Queued,
drafted or published means stop and report the existing work. For an AutoSEO page, read its
row again with `list_articles`: `lastSentAt` for the hold, `enrich.eligible` for a refresh.

## 2 · Brief (reads only)

- **Searches** for an enrichment: `gsc_query` with `domain`, `dimensions: ["query"]`,
  `days: 28`, `rowLimit: 25` and a filter `{dimension: "page", operator: "equals",
  expression: <url>}`. For a new page: `dimensions: ["query", "page"]` with a `query`
  `contains` filter on its core words, to see what Google shows of the brand today.
- **Prompts:** `get_engine_answers` with `brand` and the exact `prompt`, all engines, once:
  who is named, which pages are cited, whether the brand's page is among them. For more on a
  cited host, `list_citation_sources` with `search` set to it.
- **The brand's facts:** in a repository, its facts files (pricing, plans, product docs) with
  `path:line`; otherwise the brand's own pages (fetch) or the user. Never from memory.
- **Link targets:** only URLs seen in this run (Search Console page rows, the coverage list,
  the sitemap).
- **What wins:** one web search for the primary query or prompt. Note the type of the top
  results (list, guide, tool, official page), their count, table, method and FAQ. Read at
  most 3 winners, headings only. Learn the shape; never copy text.
- **The live page** for an enrichment: one fetch for title, H1, description, H2s, opening.
  For an AutoSEO page, `get_article` also gives the stored text the blocks will change.

## 3 · Draf

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: citation-sources
description: Find the source sites and pages cited in Cituna's measured AI answers, compare engines, identify verified coverage gaps, and update requested outreach statuses.
---

# Inspect citation sources and outreach

Read [connection and evidence rules](../../references/connection-and-evidence.md).

1. Call `list_citation_sources` with the target domain. Match the requested
   `range` (`today`, `7d`, `30d`, `all`) and `engine` where relevant. The default
   range is 30 days; state it rather than implying all-time coverage.
2. Use `search` for a brand name, source host or URL fragment. Search can return
   cited pages excluded from outreach targets; preserve `excludedAs` and do not
   conflate all cited sources with suitable pitch targets.
3. Use `limit` and returned `nextOffset` to paginate targets. For a complete
   requested inventory, continue until `nextOffset` is null. Disclose truncation
   of other lists; pagination of targets does not establish completeness of
   search pages or `yourPagesEnginesCite`.
4. Report source hosts, sample page URLs, citation counts, engines, associated
   prompts and rivals. Use `get_engine_answers` for exact answer context, keeping
   its latest-day scope distinct from the source aggregation window.
5. Interpret `youOnThisSite` precisely: `linked` means linked to the brand,
   `mentioned` means named without a backlink, and `absent` means a completed
   page check found no brand. `unknown` and `unreachable` are not verified gaps.
   `gapsOnly: true` filters verified gaps and may undercount unexamined sources.
6. Show `yourPagesEnginesCite` to explain which owned pages already receive
   citations. Its 50-item cap can truncate results; absence from a capped list
   does not prove a page is never cited. Use `whatEachEngineReads` for engine
   comparisons and disclose that it covers all engines even when targets are
   filtered to one engine.
7. Prioritize observed source gaps by relevance and repeated citation evidence.
   Do not guarantee inclusion, recommendations or ranking improvements.

## Requested outreach status changes

Read the target list first. Call `set_outreach_status` with the exact returned
`host`, target domain, and one of `planned`, `pitched`, `placed`, `declined` or
`none` (clear). Use `planned` for a requested plan, not `pitched` unless the user
says outreach happened. Read `list_citation_sources` again to verify the change.

Updating a status does not send an email or obtain a placement. Draft outreach
copy if requested; this MCP has no tool for sending messages.

## Relevant tools

`list_citation_sources`, `get_engine_answers`, `get_visibility`,
`set_outreach_status`.

View saved version →

---
name: content-and-fixes
description: Use Cituna to prioritize visibility fixes and content opportunities, manage gap statuses, inspect keyword and article queues, queue requested articles, edit or refresh AutoSEO articles, skip queued topics, and record pages already published.
---

# Manage content opportunities and visibility fixes

Read [connection and evidence rules](../../references/connection-and-evidence.md).
For a weekly plan built from evidence, with drafting and 28-day re-checks, use the
`autopilot` skill.

## Prioritize existing work

1. Read `list_gaps` for an explicit scan ID or the domain's latest audit. Preserve
   gap keys, category, impact, effort and existing status.
2. Use `list_keywords` for keyword evidence and article stages. Filter
   `stage: "none"` for keywords with no content yet. The optional Search Console
   join is enabled by default and metered; `includeSearchConsole: false` skips
   that join. It does not make all MCP usage unmetered.
3. Inspect `list_content_queue` before proposing or queueing an article. Match
   the requested `status` (`all`, `live`, `review`, `rejected`, `attention`).
   For a complete article inventory, pass each returned `nextCursor` as `before`
   until there is no next cursor; `limit` accepts 1 to 50. Later pages contain
   articles only, so keep the first page's pipeline context. Disclose partial
   coverage if you stop early. Existing
   queued, drafted or published work should not be duplicated. Distinguish a
   live rank-check result from a period-average GSC position; missing rank-check
   results outside its range are not evidence of zero search visibility. For the
   articles alone, `list_articles` returns one short row per AutoSEO article with its live
   URL and when it was published, last sent to the site, edited and refreshed.
4. Rank actions using actual impressions, observed citation gaps, relevance and
   effort. Keep estimates labeled. Use the search-console and citation-sources
   workflows for supporting evidence without automatically changing state.

## Apply requested actions

| Intent | Tool and inputs | Verification |
| --- | --- | --- |
| Change a fix's status | `set_gap_status` with returned domain, `gapKey`, and `todo` / `doing` / `done` | Read `list_gaps` |
| Queue an article | `queue_article` with domain and exact keyword from `list_keywords`; include supported evidence when available | Read `list_content_queue` and keyword state |
| Record an already-live page | `mark_article_published` with domain, exact keyword, full HTTPS URL, optional title | Read content queue or keyword state |
| Edit an AutoSEO article's text | `get_article` with the `id` from `list_articles`, then `update_article` with only the fields to change (`sections`, `faqs` and `tags` replace whole lists) | Read back with `get_article` |
| Refresh a live AutoSEO article | `enrich_article` with the `id`, only when `list_articles` shows `enrich.eligible: true` | The returned `before` and `after` |
| Remove queued topics | `skip_queued_topics` with ids from `list_content_queue` (`queued[].id`) | Read `list_content_queue`; `notQueued` ids were not open |

Queueing schedules an AutoSEO draft on its next run and may have downstream
effects under the user's existing automation settings. It does not guarantee an
immediate draft or publication. Explain that effect when preparing the change.
Handle duplicate notices as existing work, not a new queued article.

`mark_article_published` records a page that is already live; it does not publish
or edit a CMS page. Use it only when the user has supplied/confirmed the actual
published page or the publication has otherwise been verified. It should not
be called merely because text was drafted in chat.

`update_article` changes Cituna's stored copy only: a page already on the site
changes when the user sends the article again from the Cituna app. `enrich_article`
does change the live pag

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: prompt-tracking
description: Select buyer questions worth tracking in Cituna using Search Console and existing evidence, and add, enable, disable, remove or replace tracked prompts when the user asks.
---

# Select and manage tracked prompts

Read [connection and evidence rules](../../references/connection-and-evidence.md).

## Recommend prompts

1. Resolve the brand with `list_brands`. Its brand `prompts` configuration, when
   returned, is the current set of `{text, enabled}` entries. Read `get_visibility`
   separately for questions measured in the latest saved scan and their engine
   results. That scan can predate configuration changes and is not the current
   prompt editor. Check `whoami` for workspace-wide prompt capacity. If current
   configuration is missing, say it is unavailable rather than assuming it empty.
2. When GSC is connected, use `gsc_query`, `gsc_query_mix` or
   `gsc_striking_distance` to identify observed buyer demand. `gsc_ai_searches`
   can supply conversational-query candidates, but its classifications do not
   prove AI-origin traffic. Respect history coverage and reporting lag.
3. Propose a small set aligned with the brand's actual offering, market and
   language. Include category discovery, relevant use cases, comparisons and
   buyer concerns where the evidence supports them. Avoid leading premises or
   questions designed solely to force a brand mention.
4. Show each proposed prompt, its supporting query/evidence, buyer intent and
   reason to track. Label rewrites or inferred questions as suggestions, never
   literal GSC queries. If GSC is unavailable, use the user's supplied topics and
   clearly disclose that demand is unverified.
5. Deduplicate against the current configured prompts and show the proposed additions and
   capacity implications. A request for recommendations alone does not authorize
   editing the tracked set. If the user asks to add/track specified prompts, apply
   that instruction without an extra approval loop.

## Apply changes

Use `set_prompts` with the real brand ID/domain and the exact requested text:

| User intent | Argument | Effect |
| --- | --- | --- |
| Track additional questions | `add` | Preserves current questions; duplicates ignored |
| Resume questions | `enable` | Re-enables existing questions |
| Stop tracking for now | `disable` | Stops checks while retaining the question |
| Delete specified questions | `remove` | Removes them; destructive |
| Explicitly replace the whole set | `replace` | Deletes questions omitted from the replacement |

Prefer `disable` for pausing. Use `remove` only for an explicit deletion request.
Use `replace` only when the user explicitly requests a complete replacement and
the exact final set is established. Never combine `replace` with other actions.
An empty replacement is refused by this MCP; to pause everything, use `disable`
with the existing exact questions. Explain which questions will leave tracking
before deletion when the user has not already been told. A prompt-config update
does not prove that stored historical scans were deleted. Never silently remove
existing questions to fit a capacity limit. Adding an already-present disabled
prompt does not resume it; use `enable` for that.

Inspect the returned `counts`, `added`, `removed`, `notFound`, and final `prompts`
list. An `ok: true` response can still include unmatched questions in `notFound`;
report those as unapplied rather than claiming every requested edit succeeded.
Read `list_brands` again and compare the target brand's saved `prompts` text and
enabled flags. If that read does not expose the configuration, distinguish the
tool's write receipt from an independent verification and point to the app's
prompt settings. Do not repeat a write just to verify it.

Use `get_visibility` to check measurements only. New or resumed prompts may not
have answers until the next scan; changed configurat

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: search-console
description: Use Cituna's connected Google Search Console properties to analyze queries, pages, clicks, impressions, ranking opportunities, zero-click pages, intent, coverage and AI-style searches.
---

# Analyze Google Search Console with Cituna

Read [connection and evidence rules](../../references/connection-and-evidence.md).

## Connection and scope

Call `gsc_status` and resolve the requested property from all connected accounts.
If disconnected, guide the user to https://cituna.com/integrations to connect
Google and verify the property, then recheck. Do not ask for Google credentials
or claim this MCP can connect, disconnect or verify a Google property directly.

Select the report that directly answers the request:

| Request | Tool |
| --- | --- |
| Traffic summary, top queries/pages, country/device splits | `gsc_overview` |
| Specific dimensions, filters, dates or pagination | `gsc_query` |
| Queries near page one worth improving | `gsc_striking_distance` |
| Pages with impressions and few or no clicks | `gsc_zero_click_pages` |
| Brand, competitor, commercial and other query intent | `gsc_query_mix` |
| Sitemap pages without observed impressions | `gsc_coverage_gap` |
| Multiple owned pages competing for the same query | `gsc_cannibalisation` |
| Queries with conversational or AI-style wording | `gsc_ai_searches` |

## Query and interpret correctly

- Use a bare `domain`, or the exact accessible `siteUrl` where supported. Observe
  each tool's schema: overview supports 1–90 days; several analysis tools and
  raw queries support 1–480 days. Never assume the same bounds for every tool.
- For `gsc_query`, choose dimensions from `query`, `page`, `country`, `device`,
  `searchAppearance`, `date`. Pair explicit `startDate` and `endDate`, or use
  trailing `days`. Filters combine with AND. Paginate with `startRow` when a
  response reaches `rowLimit`; disclose sampling if not retrieving every row.
- State dates and GSC reporting lag. Inspect returned `history`, actual covered
  dates and `windowTruncated` before describing a period as a full month/quarter.
  Use comparable windows and property scopes for trends.
- Use returned site totals for site totals. Named-query rows omit anonymized
  queries, so summing them may undercount. Calculate aggregate CTR from total
  clicks divided by impressions; do not average row percentages. Do not average
  positions without the appropriate weighting and scope.
- Striking-distance `priority` is an ordering heuristic, not forecast traffic.
  For zero-click pages, preserve the tool's distinctions between brand searches,
  snippet issues, page-two position and deeper ranking. Phrase causes as the
  report's classifications rather than independently proven diagnoses.
- No impressions is not proof a page is unindexed. `gsc_coverage_gap` compares
  sitemap URLs with observed impressions and cannot separate indexing failures
  from low visibility. Recommend checking URL Inspection when needed.
- `gsc_ai_searches` identifies query wording; it does not measure Google's AI
  Overviews/AI Mode totals or prove where an individual query originated. Keep
  those heuristic results separate from Cituna's measured AI-engine answers.
- Join GSC demand to prompt tracking, citations or content opportunities only
  with explicit matching evidence. If the match is semantic, label it as such.
- Google access is read-only. This plugin cannot submit sitemaps, request
  indexing, change Google settings or mutate GSC data.

## Relevant tools

`gsc_status`, `gsc_overview`, `gsc_query`, `gsc_striking_distance`,
`gsc_zero_click_pages`, `gsc_query_mix`, `gsc_coverage_gap`,
`gsc_cannibalisation`, `gsc_ai_searches`.

View saved version →

---
name: visibility-analysis
description: Use Cituna to inspect measured AI answers, brand mentions and citations, compare engines and competitors, review audit history, or run a visibility scan when requested.
---

# Analyze AI visibility with Cituna

Read [connection and evidence rules](../../references/connection-and-evidence.md).
Use this workflow for answers and audits. Use the sibling prompt-tracking skill
to edit tracked questions, citation-sources for cited pages, and search-console
for Google performance.

## Current visibility and actual answers

1. Establish the account and brand using the shared rules.
2. Call `get_visibility` with the returned brand ID or bare domain. Identify the
   latest measurement day and the exact strings in `prompts[].prompt`.
3. Call `get_engine_answers` for each requested prompt, copying its exact text.
   If no prompt is specified, start with the most relevant prompts and disclose
   the sample. Retrieve all requested prompts if the user requests full coverage.
   If `availablePrompts` is returned, select from that list instead of guessing.
4. Engine keys are `chatgpt`, `perplexity`, `gemini`, `claude`, `grok`,
   `aioverviews`, and `aimode`. Google AI Overviews and Google AI Mode are distinct
   surfaces. Omit the engine filter for a cross-engine comparison.
5. Report prompt, engine, date, measurement status, answer summary, brand mention
   or citation and cited position when returned, and source links. Mark answers
   with `truncated: true` as incomplete. Never infer an absent citation merely
   from text that may have been truncated.

## Audits, trends and competitors

- Use `list_audits` with a domain filter, then `get_audit` for the needed scan IDs.
  Explain score components and show the citation matrix without counting missing
  measurements as misses. Inspect `scoring_epoch` before score comparisons.
- For a weekly review, use actual dated audits that bracket the requested window.
  If history is insufficient, report the available snapshot and missing baseline.
  The daily visibility and answer tools return the latest stored day; they are
  not historical time-series endpoints.
- Use `competitor_discovery` to find candidates observed in engine answers and
  GSC that are absent from the tracked competitor list. Distinguish configured
  competitors from newly observed candidates, and show the evidence source.
  This tool discovers rivals; it does not edit the competitor list.
- For "why am I not cited", join the visibility grid and answer receipts with
  citation sources and, when connected, GSC evidence. Classify observed gaps
  without asserting that absent GSC rows prove non-indexation. Clearly label
  explanations about source selection as hypotheses.

## Requested fresh scan

First read recent audits to determine whether existing data answers the request.
Use `run_scan` only for an authorized fresh measurement with a clear target and
known quota effects. Accept the URL/domain and up to eight explicit competitor
domains supported by its schema. A scan can add an untracked brand. Respect
backend plan and write-scope checks.

An untracked domain without competitors can return a recent shared measurement
instead of a new run. MCP v1.7.2 trims the scan response and does not reliably
expose its measurement date, replay status or quota effect. Never invent those
fields or label every successful response fresh. Compare `list_audits` before
and after the requested run and use a returned scan ID/date when available.
If there is no new history entry, state that freshness could not be confirmed;
this alone does not prove a replay. Use account usage only when returned and
avoid attributing concurrent usage changes to this scan. Do not automatically
repeat a scan to resolve an uncertain result.

## Relevant tools

`whoami`, `list_brands`, `gsc_status`, `get_visibility`, `get_engine_answers`,
`list_audits`, `get_audit`, `c

Preview of the first 4,000 characters. Read full instructions →