Citation Intelligence MCP

domain_am_i_cited

Idempotent

Check if a domain is cited by AI engines across multiple queries. Returns per-query presence, rank, and citation rate to measure AI search visibility for brands or content.

Instructions

Check whether a domain is cited by an AI engine across a cluster of queries. Returns per-query presence, rank, and a citation-rate summary. Use to measure visibility for a brand, product, or content site in AI search.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain to check, e.g. 'automatelab.tech' (without protocol).
`engine`	No	LLM engine to check for citations. 'auto' runs all available LLM engines and returns per-engine breakdown + cross-engine consensus. Pin to a specific engine to reduce cost. 'bing_serp' and 'brave_serp' measure web rank, not LLM citations — use check_citations for those.	auto
`queries`	Yes	Queries to test the domain against. 1-20 queries per call.

Output Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes	Whether one or multiple engines were queried.
`domain`	Yes	The domain that was checked.
`engine`	No	Engine used (single_engine mode only).
`engines`	No	Per-engine summary rows (multi_engine mode).
`results`	No	Per-query results (single_engine mode).
`summary`	No	Aggregate summary (single_engine mode).
`surface`	No	Engine surface type (single_engine mode only).
`consensus`	No	Cross-engine consensus stats (multi_engine mode).
`fetched_at`	Yes	UTC ISO-8601 timestamp.
`per_engine`	No	Full per-engine detail (multi_engine mode).

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.2Oct 2, 2026

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the return shape (per-query presence, rank, citation-rate summary), which is useful, but says nothing about cost, engine selection behavior, or why readOnlyHint is false for a 'check' operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with zero filler, front-loaded with the core action and return format. Efficient, though it spends a sentence on return values that the output schema already covers.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value disclosure isn't strictly needed, and annotations carry the safety profile. The remaining gap is sibling differentiation among citations_check, domain_cited_for, and citations_* tools, which the description does not resolve.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents domain, engine, and queries, including the cost tradeoff of pinning an engine. The description adds no parameter detail beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('check') and resource ('whether a domain is cited by an AI engine across a cluster of queries'), which distinguishes it from audit_* tools. However, it doesn't differentiate from close siblings like citations_check or domain_cited_for, so the agent can't tell them apart from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The final sentence gives a use case ('measure visibility for a brand, product, or content site'), which implies when to reach for it. But there are no explicit when-not conditions and no named alternatives despite several look-alike siblings, leaving routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.