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

No annotations provided, so the description carries the full burden. It does disclose meaningful behavior: bulky raw fields are omitted, and it clarifies the three-state semantics of the citation matrix ('not_run' does not mean a miss). It also states the signed-in requirement. Lacks disclosure about pagination, performance, or what happens with invalid/expired scanIds.

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

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

The description is information-dense and well-organized, front-loading the purpose. However, it is somewhat long and lists many field categories in one long sentence, which slightly reduces scannability. Still efficient overall with no wasted filler.

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

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

Despite no output schema, the description thoroughly enumerates the return contents (scores, per-engine summary, matrix, competitors, gaps, check counts) making return expectations clear. It compensates for missing schema by detailing the citation matrix states. Could add pagination or error behavior, but the core information is well covered for a single-item detailed fetch tool.

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

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

Only one parameter (scanId), and schema coverage is 100% with a clear description. The description reinforces the source of the id (from list_audits) in the prose, adding workflow value beyond the schema. With a single well-documented param, the baseline 3 applies; description adds provenance clarity, supporting a 4.

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

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

Specific verb+resource ('Get one audit in detail by scanId'). Clearly distinguishes from sibling list_audits by stating it retrieves a single detailed audit. Rich detail on what is included (scores, citation summary per engine, matrix, competitors, gaps, check counts).

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

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

Explicitly ties usage to scanId from list_audits, establishing a clear workflow context. It states the audit is for AI-visibility and notes the requirement of a signed-in account. However, it doesn't explicitly contrast with siblings like get_visibility or get_engine_answers regarding when to choose one over another, though the distinct purpose is strongly implied.

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

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

The description provides several useful behavioral details: answer text is capped at ~4000 chars per engine with a truncated flag, a not-found prompt returns availablePrompts, and there's an account/auth requirement (works on Starter and up, free trial has no MCP access). With no annotations provided, the description carries the full transparency burden and does disclose observable behaviors well. However, it doesn't describe the return structure or cite-position format beyond what's stated, leaving some gaps.

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

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

The description is a single dense paragraph that front-loads the core purpose ('THE RECEIPTS behind the tracking grid') and packs in engine-scoping, output contents, truncation, prompt-sourcing, and access constraints. It's information-dense but coherent; every sentence earns its place. A lighter structural breakdown would improve readability, but nothing is wasted.

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

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

For a 3-param tool with 100% schema coverage and no output schema, the description is thorough: it explains what's returned (answer text, brands cited, source URLs, citation position), the truncation cap, the prompt-matching fallback, and access-tier requirements. It maps cleanly onto siblings (get_visibility) and the input schema. The main gap is the absence of a sample output shape, which the description compensates for reasonably.

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

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

Schema coverage is 100% — brand, engine, and prompt each have descriptive help text in the schema, including engine key aliases and the prompt-sourcing hint. The description adds context by naming get_visibility's prompts[].prompt as the copy source and explaining the availablePrompts fallback. Both layers reinforce rather than repeat, keeping this dimension at baseline-plus.

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

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

Purpose is stated with a specific verb and resource: it returns the stored answers/evidence ('REceipts') for a brand and one tracked prompt on the most recent day, including citation position. It clearly differentiates from get_visibility (tracking grid) by positioning itself as the underlying receipts/evidence layer. The scope (per prompt, optional per engine, most recent day) is explicit.

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

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

The description tells you when to use it (to get receipts behind the tracking grid, pulling actual answer text per engine) and how to prepare input (copy exact prompt text from get_visibility's prompts[].prompt). It also names the sibling tool the data comes from and clarifies access constraints (Starter+ required, free trial excluded). While it doesn't explicitly enumerate when NOT to use it, the alternative source (get_visibility) is referenced and the use-case context is clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses auth requirements, plan restrictions, and the fact that it returns only the most recent day (not a history). It also states the output format (compact JSON) and that it's designed to be read directly. For a read tool with no annotations, this is solid coverage, though it doesn't detail all response fields exhaustively.

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

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

Front-loaded with the highest-value identifier ('LATEST DAILY TRACKING GRID'). Densely informative throughout — each sentence adds value covering engines, per-cell status, visibility score, target audience, plan constraints. Slightly long but every segment earns its place.

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

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

For a read-only reporting tool with a single documented parameter and no output schema, the description provides comprehensive coverage: input format, engines tracked, per-cell semantics, companion tool, auth/plan requirements. Could add pagination or date-range behavior, but for a single-brand daily snapshot it's largely complete.

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

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

Schema coverage is 100% and the description reiterates the 'brand id OR bare domain' format with an example ('acme.com'), which matches the schema description. The description adds the context that the brand id comes from list_brands, slightly enriching beyond schema. Baseline 3 is appropriate given full schema coverage.

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

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

Clearly describes the specific verb+resource: returns a daily per-prompt × per-engine tracking grid for a brand. Explicitly distinguishes from siblings by naming get_engine_answers as the tool for viewing what engines actually said. Strong differentiation.

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

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

States it requires a signed-in account and works on Starter and up, with the free trial having no MCP access — useful constraints. Explains when it applies (latest daily grid) and directs users to get_engine_answers for engine-level detail. Lacks explicit 'when not to use' phrasing but provides clear context.

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

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

The description transparently discloses key behaviors: Live summary semantics, UTC windows ending ~2 days ago due to reporting lag, the paid plan requirement (Starter+), and the {configured:false, message} fallback when GSC isn't connected. No annotations exist, so the description carries the full burden and does so well.

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

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

The description is front-loaded with the core purpose and bundles headline totals, splits, and time series. The two-sentence functional part is tight and dense with no waste. The trailing condition about the fallback response adds genuine value.

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

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

Despite a rich multi-part output (headline totals, top queries, top pages, country/device splits, day-by-day series) and no output schema, the description enumerates each return component explicitly. It also covers parameter semantics (window ending ~2 days ago) and failure modes, making it materially complete.

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

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

Schema coverage is 100% and both parameters already have descriptions. The description adds marginal extra context (the ~2-day lag aligns with the schema's 'ends ~2 days ago' note) but doesn't add new meaning beyond what the input schema documents. Baseline 3 is appropriate given full schema coverage.

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

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

The description uses a specific verb+resource ('SUMMARY for a domain over the last N days') and enumerates the exact data returned (headline totals, top queries, pages, country/device splits, time series). It also delivers a clear 'Best default for...' positioning statement, distinguishing it from siblings like gsc_query and gsc_status.

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

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

The description states when to use it ('Best default for how is my search traffic doing?') and implicitly contrasts with more granular siblings (gsc_query, gsc_status). It also states the paid-plan prerequisite and the failure condition, giving clear usage context. It doesn't explicitly name alternative tools but the 'Best default' framing plus sibling presence provides guidance.

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

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

No annotations are provided, so the description carries the full transparency burden. It discloses the GSC 2-day data lag explicitly, explains the UTC window behavior, notes the paid-plan requirement, mentions output shape (rows with keys[] plus clicks/impressions/ctr/position), and states pagination behavior when capped. The only gap is lack of detail on what happens with oversized result sets beyond startRow pagination.

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

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

Comprehensive but compact — three sentences packed with high-value information (dimension list, use cases, lag disclosure, pagination, plan requirement, return shape). Every sentence earns its place, nothing redundant with the schema. Front-loaded with the core purpose.

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

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

For an 11-parameter, highly flexible tool with no annotations and no output schema, the description is remarkably complete. It covers the key decision (dimension selection for different analytical goals), the datetime handling (days vs date range, UTC, lag), filtering patterns, pagination, access requirements, and return format. This addresses essentially every practical question an agent would face in selecting and invoking this tool.

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

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

Schema coverage is 100%, so all 11 parameters are described in the schema itself, giving a baseline of 3. The description adds value above that: it explains the mutual exclusivity/priority between days window vs explicit date range, gives a concrete filter example pattern, and demonstrates dimension combinations. It doesn't fully document the interplay between type/enum values and dimensions, but builds meaningfully on the schema.

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

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

Description clearly states it runs arbitrary GSC Search Analytics queries with specific verb+resource ('raw, flexible tool'). It names all six dimensions, explicitly enumerates use cases (['date'] for trends, ['country']/['device'] for splits, filters for focusing), and distinguishes itself as the raw flexible option versus sibling gsc_overview which is more curated.

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

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

Provides explicit when-to-use guidance with concrete dimension recipes (day-by-day trends, splits, query/page focus) and operational details: trailing window ends ~2 days ago due to GSC lag, default rowLimit 100 with pagination note, paid plan requirement (Starter+). Though it doesn't name alternative tools explicitly, it positions itself as the flexible counterpart to overview tools, giving clear context.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does well by disclosing that this is a read-only status/connection check, explicitly stating what it reports (OAuth config, connected flag, email, verified properties), and reassuring the agent it is the 'truthful signal' vs whoami. It does not mention error behavior, auth failures, or rate limits, but for a status-query tool these are less critical. It frames itself as authoritative without overstating.

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

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

The description is a single well-structured paragraph, front-loaded with the core purpose and then enumerating the specific data returned. The final sentence about whoami is valuable differentiation. It's slightly longer than strictly necessary and the last sentence could arguably be folded into the sibling-differentiation, but every clause adds operational value — no filler.

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

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

For a zero-parameter status tool with no output schema, the description is thorough: it enumerates exactly what fields the agent can expect (connected flag, email, verified property list). It could be improved by noting the possible absence of values (e.g., what happens when not connected — does `connected` default to false or is the field omitted?), but given the tool's simplicity and the lack of output schema, this is a solidly complete description.

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

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

There are 0 parameters and schema description coverage is 100%, so per the rubric the baseline is 4 and no parameter documentation is needed. The description compensates naturally by explaining what the tool RETURNS rather than its inputs. Nothing is missing regarding parameter semantics since there are no parameters to describe.

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

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

The description is very specific: it names the verb (GSC connection check), the resource (Google Search Console for this workspace), and precisely enumerates what it returns (OAuth config state, `connected` flag, account email, verified properties list). It explicitly distinguishes from the sibling `whoami` tool by stating 'whoami does not report GSC state — this tool is the truthful signal.' This is excellent sibling differentiation.

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

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

The description clearly indicates when to use it (to check GSC connection state for the workspace) and explicitly contrasts with `whoami`, telling the agent that whoami is NOT the right tool for GSC status. It doesn't name a specific alternative tool to use instead for verifying GSC properties, but the exclusion of whoami plus the contextual framing (`authoritative`, `truthful signal`) provides strong usage guidance. Could add more explicit when/why vs. `gsc_overview` and `gsc_query`, which are related siblings.

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

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

With no annotations, the description carries the full burden and delivers: ordering (newest first), exact returned fields (scanId, domain, date, scores, open-gap count), a crucial caveat about scoring_epoch score comparability, and an auth requirement (signed-in account). This is more than most tool descriptions provide.

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

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

Three dense sentences, zero fluff. The first sentence front-loads the action and output fields; the second delivers the critical epoch caveat; the third ties to get_audit and auth. Every sentence earns its place.

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

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

Even without an output schema, the description lists the return fields and the critical epoch warning. It also covers auth and points to get_audit for detail. For a simple one-parameter list tool, nothing important is missing.

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

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

Schema covers 100% of the single parameter (domain) with a clear description. The tool description adds no additional meaning about the domain filter, so it doesn't exceed the baseline. It does mention workspace scope, but that's not parameter-specific.

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

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

The description opens with 'List recent AI-visibility audits (scans) for your workspace, newest first'—a specific action and resource. It distinguishes from sibling get_audit by noting 'Pass a scanId to get_audit for the full breakdown,' making the list-vs-detail boundary explicit.

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

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

The description tells users when to use get_audit instead ('Pass a scanId to get_audit for the full breakdown') and warns about comparing scores across epochs. It doesn't explicitly exclude other siblings like run_scan or list_gaps, but the context makes the tool's role clear. Lacks an explicit 'use this when...' statement but the guidance is strong.

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

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

No annotations are provided, but this is a simple, non-destructive list operation with zero parameters. The description clearly frames it as a discovery/list operation without side effects. It doesn't describe output format or pagination, but with no params and no annotations, the behavioral surface is minimal and adequately communicated.

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

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

Two sentences, both earning their place. The first states the purpose; the second explains downstream utility. Zero wasted words.

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

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

For a parameterless, side-effect-free listing tool, the description is complete. It states what's listed (brands/domains), the scope (workspace), and downstream consumption. No output schema means some ambiguity about return format, but the simple nature of the tool makes this acceptable.

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

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

Zero parameters exist, so the schema imposes no burden. The baseline for 0-param tools is 4. The description adds context about the return value (brands/domains usable by other tools), which is more than sufficient for a parameterless tool.

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

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

Clear verb+resource: 'List the brands/domains tracked in this Cituna workspace.' Distinguishes from siblings by specifying it lists brands/domains, which none of the sibling names (list_gaps, list_keywords, list_content_queue) claim to do.

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

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

Explicitly states when to use it: 'Handy for discovering which domains you can pass to the audit and gsc_* tools.' This gives actionable guidance on how the returned data is consumed downstream, effectively explaining when to reach for this tool.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that the operation is free and 'reads stored data,' implying non-mutating behavior. It also states 'Requires a signed-in account,' which is a real authentication requirement. However, it doesn't describe return format, ordering, pagination, or what happens with an empty queue. Decent but not rich.

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

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

The description is two sentences and front-loads the core purpose (what the pipeline shows) before giving usage guidance. No wasted words. It earns a 4 rather than 5 because it interleaves multiple concerns (what it lists, when to use, auth) into a somewhat dense first sentence rather than cleanly separating them, though nothing is redundant.

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

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

This is a single-parameter read tool with a complete schema and no output schema, so the bar is moderate. The description covers purpose, scope, usage context, and auth. Missing: what return values look like (since there's no output schema, the description could reasonably mention the shape of returned data) and behavior with an empty pipeline. Adequate but could be more complete.

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

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

Schema coverage is 100% with a single domain parameter already described as 'Bare domain, e.g. acme.com.' The description reinforces it's domain-scoped ('for a domain') but doesn't add meaning beyond the schema. Baseline 3 is appropriate since the schema fully documents the parameter. The description adds no format or edge-case detail beyond the schema's example.

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

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

The description clearly states what the tool does: lists the AutoSEO content pipeline for a domain, showing topics waiting to be written and articles already generated/published with their source keyword/prompt. This is a specific verb (list) + resource (content queue/pipeline) + scope (per domain). It distinguishes from siblings like list_gaps and list_keywords by describing the pipeline state rather than gaps or keywords.

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

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

The description explicitly says 'Use it to see what is in flight before queueing more,' which provides clear when-to-use guidance. It also gives an implicit when-not-to-use by contrasting with queueing actions (queue_article sibling). The phrase 'before queueing more' sets up a clear workflow sequence that an agent can follow.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the auth requirement (signed-in account) and explains the resolution semantics for domain vs scanId. However, it doesn't describe the return format (no output schema exists), pagination, or ordering of gaps, which would strengthen transparency for the agent.

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

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

The description is two sentences and delivers substantial information in a compact form. It front-loads the core purpose before moving to usage details. Slightly dense but no wasted words; could arguably be considered concise for the amount of behavioral information conveyed.

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

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

For a read tool with no output schema and both parameters fully documented, the description does a good job: it specifies required auth, both invocation modes, and hints at the sibling tool for mutation. The main gap is not describing what the response looks like given there's no output schema, though the enumerated fields in the first sentence partially compensate.

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

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

The schema already covers both parameters at 100% (domain and scanId both get descriptions), so the baseline is 3. The description adds value by clarifying the disjunction ('pass a scanId OR a domain'), the fallback behavior (domain uses its newest audit), and the source of scanId (from list_audits). This meaningfully supplements the schema.

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

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

The description clearly states what the tool does: lists the fix/action queue for a domain, enumerating exactly what fields each gap contains (gapKey, status, title, category, impact, effort, concrete fix). It's specific about verb+resource, and it distinguishes itself from siblings like set_gap_status (which updates) and list_audits (which returns audits).

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

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

Explicitly explains the two invocation modes (scanId OR domain) and how each resolves, tells the reader to use set_gap_status for updates (naming an alternative), and requires a signed-in account. This is strong when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It explicitly discloses it's free, reads stored data, spends no quota, and requires a signed-in account. This is thorough behavioral disclosure for a read-only tool, though it doesn't specify response format or pagination.

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

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

The description is somewhat wordy — the parenthetical 'the part that makes this actionable' and 'or not ranking' add color but could be trimmed. However, it's front-loaded with the purpose and the actionable guidance is woven efficiently into one paragraph. Mostly tight with minor verbosity.

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

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

For a read-only list tool with good schema coverage and no output schema, the description is quite complete. It lists all the fields returned, explains the join value, and covers auth requirements and cost. Slightly more detail on what happens with no results or edge cases would push it to 5, but this is strong.

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

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

Schema coverage is 100%, so both parameters are documented. The description adds value by explaining the 'stage' filter semantics ('none' is 'the useful one: keywords with nothing written for them yet') and gives a concrete domain example ('acme.com'), going beyond what the schema prose provides.

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

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

The description clearly states what the tool does: it returns the keyword board for a domain with Google position, search volume, competition, verdict, and content state. It explicitly differentiates from siblings by framing this as 'the join you want before writing anything.' Strong verb+resource specificity.

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

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

The description explicitly explains when to use it ('before writing anything' to see which keywords still have no page behind them). It also names related concepts and distinguishes by noting it's 'free, reads stored data, spends no quota,' which implicitly sets expectations vs scan tools like run_scan or gsc_query.

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

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

No annotations are provided, so the description carries the full burden. It explicitly discloses this is a WRITE ACTION, requires a Pro plan or higher, and describes the side effects (stops suggestions, marks published, prevents competing pages). This gives strong behavioral context beyond mere 'marks published', including persistence of state changes and side effects on content generation.

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

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

The description is a compact, front-loaded block that begins with the core purpose. It's fairly dense and information-packed; could arguably be tightened, but each sentence contributes meaning (purpose, side effects, timing, action-type flag, plan requirement). Reasonably sized for a mutating tool.

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

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

Given no output schema and no annotations, the description covers the key operational details: when to call, what values to pass, exactness requirement, side effects, and access-level requirement. Slightly under-specified on what the tool returns or how to confirm success, but complete enough for reliable invocation in most cases.

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

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

Schema coverage is 100% with 4 params, so baseline is 3. The description adds value beyond schema by emphasizing keyword must match exactly what list_keywords shows, and URL must be full https. It also clarifies the 'title' default behavior implicitly through the schema description. The key constraint about keyword-exactness is added in prose, elevating it above baseline.

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

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

Description clearly states the verb+resource: telling Cituna a page for a keyword is LIVE. It thoroughly explains the specific functional purpose (stop suggesting the topic, show as published on Keywords board, stop offering competing pages). Distinguishes well from siblings, which are read/query tools like list_keywords and gsc_overview.

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

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

States when to use ('right after you publish') and provides concrete invocation guidance (pass keyword exactly as list_keywords shows it, full https URL). Explicitly names list_keywords as source for the keyword value. Lacks an explicit when-NOT-to-use statement, but the clear trigger context is sufficient.

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

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

No annotations are provided, so the description carries the full burden. It explicitly flags 'WRITE ACTION' and the plan-tier requirement, which is critical for an agent to know before invoking. It also discloses the duplicate-notice return behavior. It doesn't describe side effects on existing queue entries or confirm what a successful call returns, but the disclosed mutation nature and plan gating are strong.

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

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

Four sentences, each earning its place: purpose/effect, input format, duplicate behavior, and access restriction. Slightly dense but front-loaded with the core action first. No fluff or repeated schema content, though the paragraph is a bit long without breaks.

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

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

The tool has 5 params, is a mutating write action with no output schema, and zero annotations. The description covers the write nature, plan gating, duplicate handling, input formatting, and a cross-reference to list_keywords. The main gap is not describing what a successful response looks like, but given no output schema exists, the description compensates reasonably well.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains that keyword must match list_keywords exactly, that numbers serve dual roles (provenance and prioritisation), and that volume/position/competition are optional priority signals. This elevates the score above baseline.

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

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

The description clearly states the verb 'Queue' and resource 'an article for a keyword', and explains the downstream effect (AutoSEO drafts it on the next run). It distinguishes itself from siblings by being the only queue-writing tool, and even references list_keywords for correct keyword entry. This is specific and unambiguous.

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

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

The description explicitly instructs how to format input ('Pass the keyword exactly as it appears in list_keywords'), explains when to include extra numbers ('when you have them... to prioritise the queue'), and describes the duplicate-notice behavior when a topic/article already exists. It also states planning restrictions (Pro+ vs Starter/trial read-only). This is comprehensive guidance.

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

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

No annotations are provided, so the description carries full disclosure burden. It explicitly discloses that it's a WRITE ACTION, consumes one scan from quota, adds tracked brands to brand cap, may replay a shared measurement, and adds no entry to list_audits in the replay case. This is exemplary transparency for a resource-consuming mutation tool.

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

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

The description is dense and informative, front-loaded with purpose then caveats then alternatives then plan requirements. Every sentence carries distinct information with no filler. Slightly longer than strictly necessary but every clause earns its place given the multiple behavioral caveats needing disclosure.

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

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

For a write action with no output schema and no annotations, the description covers purpose, quota/brand implications, replay behavior, when-not-to-use, plan tier requirements, and param-level nuance. Despite no output schema, the description mentions the returned result shape (scores, citation matrix, competitors, top gaps), making this highly complete for the complexity involved.

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

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

Schema description coverage is 100%, so both url and competitors have adequate schema docs. The description adds moderate value beyond schema: it clarifies url accepts bare domain or full URL, states competitors count limit (up to 8), and notes that passing competitors forces a fresh run. This exceeds baseline 3 slightly but the schema already handles param details.

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

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

The description clearly states the verb+resource (Run an AI-visibility audit) and specifies the output (scores, citation matrix, competitors, top gaps). It distinguishes this from sibling tools by naming get_audit/list_audits as read alternatives for existing audits, situating run_scan as the fresh-data option.

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

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

Explicit guidance on when to use vs alternatives: 'Prefer list_audits/get_audit to read an existing audit for free; use run_scan only when fresh data is needed.' Also explains caveats (7-day replay for untracked domains, brand-cap impact) and plan-tier requirements (Pro or higher, read-only on Starter/trial) that tell the agent when this tool is not usable.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does a good job flagging that this is a WRITE ACTION requiring a Pro plan. However, it doesn't disclose what happens on failure, whether changes are reversible, or what the response looks like on success. It hints at WRITE ACTION but provides no evidence destination or side-effect details beyond the status change.

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

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

Two sentences, no wasted words. Each sentence earns its place: the first establishes purpose and parameter provenance with an example, the second delivers the critical plan-level constraint. Danger cue 'WRITE ACTION' is front-loaded for safety.

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

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

For a 3-param, all-required, enum-driven tool with no output schema and no nested objects, the description covers purpose, parameter sourcing, an example, and the plan prerequisite. The only minor gap is lack of success/error response semantics, but given the tool's simplicity and the 100% schema coverage, the description is appropriately complete.

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

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

Schema coverage is 100%, and the description adds complementary value rather than redundancy. It ties gapKey and domain to list_gaps as their provenance source ('Use the gapKey and domain from list_gaps'), giving the agent concrete operational knowledge about where to obtain these values — this exceeds what the schema alone provides. The description does not restate the enum values or definitions already in the schema.

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

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

The description uses a specific verb+resource pair ('Update one gap's status in the action queue') with explicit enumerable status values (todo / doing / done). It clearly distinguishes from siblings like list_gaps (read) and queue_article (different resource), and names the working context (action queue for gaps).

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

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

The description explicitly states the source of required parameters ('Use the gapKey and domain from list_gaps') and provides a concrete example ('e.g. mark the schema gap for acme.com done'). It also names a prerequisite — the Pro plan requirement — and explicitly excludes Starter/trial use, which clearly directs when this tool should NOT be invoked.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well: it describes the data returned (account, backend URL, plan, usage meters), discloses a limitation ('when available' for usage meters), notes failure behavior ('Fails with an actionable message if the API key is missing, invalid, or revoked'), and clarifies what it does NOT report. The only minor gap is not describing the exact error/response format, but the disclosure is solid.

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

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

The description is compact and front-loaded with the most important facts (identity, URL, plan, usage). It covers substantial ground in three sentences with zero fluff. Minor deduction because it packs many data points into one long first sentence, making it slightly dense rather than optimally scannable, though still efficient.

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

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

For a zero-parameter tool with no output schema, the description is complete: it specifies exactly what data is returned, when to use it, what it does NOT cover (Search Console, with pointer to gsc_status), and failure behavior. There is no under-specification given the tool's simplicity. The description fully addresses its purpose with no gaps.

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

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

The tool has 0 parameters, and schema coverage is 100% (empty object schema). Per the rubric, 0 params earns a baseline of 4. The description appropriately focuses on what the tool returns rather than parameters, which is correct for a no-parameter auth/connection check tool.

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

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

The description clearly states the tool returns authenticated account identity (email, workspaceId, role), backend URL, plan, and usage meters, with a specific verb ('Return'). It distinguishes itself from siblings by explicitly noting it does NOT report Search Console state and directing users to gsc_status for that, providing clear sibling differentiation.

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

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

The description explicitly says 'Use this first to confirm the connection works', giving a clear when-to-use instruction. It also explicitly excludes a use case ('Does NOT report Search Console state — call gsc_status for that'), naming the alternative tool. This is explicit guidance with a named alternative, meeting the top tier.

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