MisarSEO MCP Server

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

Goes well beyond the annotations by disclosing the daily check cadence, the important latency caveat that the first snapshot lands on the NEXT scheduled pass rather than immediately, the cost profile (free, internal SSRF-safe fetch, no paid provider), and a hard quota of 20 URLs per project. The idempotency claim duplicates idempotentHint=true but is consistent with it.

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 action and the tracked signals, followed by cadence, cost, idempotency and quota. All five clauses carry information, though the 'FREE' emphasis and the 'never a fabricated similarity score' aside lean slightly promotional rather than purely functional.

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?

With three simple parameters, full schema coverage and annotations covering the safety profile, the description supplies the operational facts an agent needs (timing, cost, quota, idempotency). The only gap is that with no output schema it never indicates what is returned on success (e.g. a monitor ID) or how to subsequently read detected changes.

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 url, label and projectId are already fully documented with validation, normalisation and SSRF-rejection semantics. The description reinforces the url scope ('not a domain to crawl') but adds no new per-parameter syntax or format detail, so baseline 3 applies.

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?

States a specific verb (start monitoring) and a precisely scoped resource (one competitor page, not a domain to crawl), then enumerates exactly what is tracked: title/meta, line-level content diff, outbound links, structured-data types. This clearly separates it from siblings like get_competitor_monitor_changes, list_competitor_monitors and remove_competitor_monitor.

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 establishes clear context for when this tool applies (setting up ongoing daily change tracking on a single page) and clarifies the scope limit 'not a domain to crawl'. It does not, however, explicitly name alternatives such as list_competitor_monitors for reviewing existing monitors or remove_competitor_monitor for stopping one, so routing relies on inference.

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?

Adds real behavioral context beyond the annotations: it is a mutation (consistent with readOnlyHint=false) but FREE (no credits), and it documents the Google disavow-file format constraint. Cost information is not derivable from annotations, though idempotency and openWorldHint are left for the annotations to carry.

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 action, then the cost/mutation warning, then the entryType semantics. It is one long sentence with a parenthetical aside, so slightly denser than ideal, but every clause carries information.

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 5-parameter mutation tool with no output schema and full annotation coverage, the description covers cost, mutation status and format semantics. It omits what the call returns or confirms, but the annotations and schema absorb most remaining ambiguity.

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, but the description goes further by explaining why 'value' must be a bare host for 'domain' and why no subpath form exists per Google's format. This clarifies the semantics of a required parameter beyond the enum text.

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?

States a specific verb and resource: 'mark one URL or domain for disavowal' within 'Disavow file management'. An agent can immediately separate this from list_disavow_entries, remove_disavow_entry and export_disavow_file without opening a schema.

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?

Gives explicit selection guidance between the two entryType modes — 'url' for exactly that page, 'domain' for the domain and its subdomains, plus the caveat that subpaths cannot be disavowed. It does not, however, say when to reach for this tool versus add/remove/list siblings in the disavow family.

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?

Annotations already declare readOnly=false, destructive=false, idempotent=true; the description adds real value beyond them: cost (FREE/no credits), the fact it is a mutation, the new-record default status, and the white-hat guarantee that contact fields are manually entered rather than scraped. Idempotency is not restated, but there is no contradiction.

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?

Dense but well front-loaded: purpose first, then cost/safety, then scope note, then routing. Every clause carries information, though the 'Link Building Tool:' prefix is slightly redundant with the tool name.

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 9-parameter mutation with no output schema, the description covers cost, mutation status, white-hat constraints, default state, and next-step routing. Remaining gaps (label, targetUrl usage) are minor relative to what the schema already explains.

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 56%, and the schema documents projectId, domain, url, note, and targetUrl. The description adds a genuine constraint on the contact* fields (plain typed free text, never auto-scraped), but says nothing about label or targetUrl semantics, so it only partially compensates for the coverage gap.

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?

Opens with a specific verb+resource+scope: 'add one prospect domain/page to a project's list.' This is clearly distinguishable from siblings like update_link_prospect, add_link_prospect_note, and import_link_prospects_csv.

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 names the follow-up tool (update_link_prospect_status) and the lifecycle starting point ('prospected'), so an agent knows this is the entry step. It does not, however, contrast with import_link_prospects_csv for bulk adds or with add_link_prospect_note for appending activity.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: it is FREE (no credits) and that it is a MUTATION, plus append-only single-entry semantics ('add one ... entry'). It does not describe anything contradictory.

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?

One tight sentence with the resource and verb front-loaded and examples inline. The 'Link Building Tool:' prefix is slightly redundant but provides category context cheaply.

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-required-param mutation with no output schema, the description covers purpose, cost, and mutating nature, while annotations carry the safety/idempotency profile and the schema documents two of three params. Only minor gap is the return/confirmation behavior, which is arguably not essential.

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 67% and both projectId and prospectId carry their own 'get one from list_projects / list_link_prospects' descriptions. The description adds content examples that clarify the note parameter's intent, but nothing about length limits or format beyond the schema. Baseline 3 is appropriate.

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: 'add one manual activity-log entry to a prospect', with two concrete examples ('emailed on 9/5', 'follow-up sent') that pin down what a 'note' is. It is distinguishable from list_link_prospect_activity (read) and add_link_prospect (create prospect), though it doesn't name those siblings explicitly.

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?

Usage is implied by the examples and by 'one manual activity-log entry', giving an agent a reasonable sense of when to log an activity. However there is no explicit when-not guidance and no routing to related siblings like update_link_prospect_status for actual status changes.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, yet the description adds genuinely new behavior: partial-failure semantics where unresolvable ids are silently dropped instead of failing the call, org-scoping of accepted ids, and the return shape `{ added }`. It stops short of covering invalid portfolioId handling or auth prerequisites, so it is strong but not exhaustive.

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 short sentences, front-loaded with the action, then the return/error semantics, then the cost profile. No filler and nothing repeated from the schema or annotations.

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?

There is no output schema, and the description compensates by naming the return payload `{ added }`. Combined with the silently-dropped-id rule and the free/no-credits note, an agent has enough to call this correctly and interpret the result.

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 earns above baseline by adding a semantic constraint on projectIds that the schema does not express — only ids resolving to a project in the caller's organization are accepted, and the rest are silently dropped. It does not restate the array bounds or ID format the schema already covers.

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?

States a specific verb and resource ("Adds projects to a portfolio") and distinguishes itself from the sibling pair create_portfolio and remove_portfolio_projects. An agent can identify the operation without opening the schema.

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?

Usage is implied by the verb but there is no explicit when-to-use guidance and no named alternative (e.g. remove_portfolio_projects, create_portfolio). The cost note ("no credits are spent") is decision-relevant context, but it describes the operation rather than routing the agent between tools.

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?

Annotations already cover the write/side-effect profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely non-structured context: no external SEO provider is called, no credits are spent, and a hard cap of 100 notes per config – all useful operational facts not present in annotations.

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 tight sentences with zero filler, front-loaded with the core action followed by cost, scope, and limit. Every clause carries information the agent can act on.

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 4-param write with a fully-described schema and no output schema, the description covers cost, scope, and the 100-note constraint. It lacks only a pointer to the read/remove counterparts, so it is complete enough but not exhaustive.

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 schema already documents projectId, configId, date, and label, including the config-lookup hint via get_rank_tracker. The description reinforces that configId is config-level rather than keyword/device scoped, a marginal add over the schema, landing at the 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?

States a specific verb and resource – 'Adds a chart note to a rank tracker's own timeline' – which is precise and distinguishable from sibling writes like add_rank_tracking_keywords or add_link_prospect_note. The object (a chart annotation on the rank timeline) is 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?

Clarifies when this applies with 'Config-level, not per-keyword or per-device,' which tells the agent the correct scope before calling. It does not name the natural alternatives (list_rank_annotations / remove_rank_annotation) or exclusions, so it stops short of a 5.

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?

Goes well beyond the annotations: discloses that duplicates are silently skipped, that `added` may be lower than keywords sent, that it can fail with a plan-limit error (a count cap, not a spend cap), and that no rank check or metrics refresh is triggered. This is exactly the operational context annotations cannot carry.

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-loads purpose, then layers return semantics and free/failure behavior in a compact run of sentences. Dense and largely waste-free, though the plan-limit explanation is slightly long-winded.

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?

No output schema exists, so the description correctly supplies the return shape ({ added, addedIds }) and its counter semantics, plus follow-up guidance. An agent has everything needed to call it and interpret results.

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 parameters are already documented, and the duplicate-skip note appears in both places. The description adds semantics around the `added` output counter rather than the input params themselves, so baseline 3 is appropriate.

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?

States a specific verb+resource ('Adds keywords to an existing rank tracker config'), immediately distinguishing it from create_rank_tracker, list_rank_tracking_keywords, and remove_rank_tracking_keywords in the sibling set.

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?

Clarifies it operates on an existing config, that it is free/no credits spent, that it does not trigger a rank check, and routes to get_rank_tracker as the follow-up. It stops short of naming explicit alternative tools for other cases, but the 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?

Goes well beyond the annotations by disclosing that it is a MUTATION, that it costs one AI-gateway operation per field per page (up to 20), that there is no bulk discount, that partial failures are isolated per entry, and that org-admin rights are required. This is rich behavioral context an agent could not derive from readOnlyHint/destructiveHint alone.

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?

Dense but front-loaded narrative where every clause earns its place: purpose, cost, failure isolation, and prerequisite in a handful of sentences. No filler or redundancy.

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 non-idempotent mutation tool with no output schema, the description covers the critical gaps: cost model, partial-failure behavior, and authorization requirement. Nothing an agent needs in order to call it correctly 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 coverage is 100%, so both params are already documented (pageUrls with its 1-10 range and projectId with the list_projects pointer). The description's 'up to 10 pages' restates the schema's maxItems constraint rather than adding new syntax or format meaning, so baseline 3 applies.

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?

States a specific verb and resource ('AI-drafts title AND metaDescription') with a clear scope ('up to 10 pages in one call'), which inherently distinguishes it from the single-page sibling draft_patch. An agent immediately knows this is the batch variant.

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?

Gives strong usage context: batch-of-up-to-10, cost implication (one operation per field per page), and a prerequisite ('Requires an org admin'). It does not explicitly name draft_patch or state when to prefer one over the other, so it's clear context without explicit alternatives.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds real value on top: it is FREE (no credits) and that idempotency is per UTC day, so a second same-day call does not write twice. It does not describe the return payload, but the write effect is well characterized.

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-loads the action and central mechanic, then layers the cost, mutation/idempotency caveat, and use case. Dense and mostly waste-free, though the sentence count is higher than strictly needed for a two-param 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?

For a no-output-schema mutation tool, the description covers effect, cost, idempotency granularity, and sibling relationships, which is enough to call it correctly. The only minor gap is no explicit statement of what the call returns.

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 required params (domain, projectId) are already documented with examples and sourcing (list_projects). The description adds no syntax or format beyond the schema, so the baseline 3 applies.

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?

States a specific verb (capture) and resource (domain-authority snapshot) with timing ('now'), and positions it against two named siblings: it uses the same resolver as get_domain_overview and feeds get_domain_authority_history. An agent can distinguish it from both without opening schemas.

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 it is useful ('a domain get_domain_overview would not auto-capture on its own — e.g. a tracked competitor rather than the project's own domain') and clarifies the relationship to get_domain_overview and get_domain_authority_history. Clear when-to-use and implicit when-not (the project's own auto-captured domain).

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?

Adds substantial context beyond the readOnly/idempotent annotations: it is FREE, purely local, with no upstream call, no billing, and no market dependency. It also discloses a real limitation — navigational detection only covers destination/account phrasing, and brand-name navigational queries deliberately return `unknown` rather than a guessed label.

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 purpose and output labels, then the operational characteristics, then the caveat. It is dense but long, and a few clauses (the 'free-tier fallback' lineage) serve explanation more than invocation, keeping it just under 5.

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 two-parameter, no-output-schema tool this is close to complete: it names the labels, the input bounds, the cost profile, and the accuracy limitation. The one gap is the return shape (e.g., per-keyword label mapping vs. a plain list), which neither the description nor an output schema specifies.

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 parameters are already documented; the description only echoes the 1-200 keyword bound that the schema's minItems/maxItems already encode. It adds no format guidance for keywords or projectId beyond the schema, so the baseline 3 applies.

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?

States a precise verb+resource (classify keywords' search intent) and enumerates the exact output labels, so the agent knows what it produces. It also distinguishes itself from keyword research by noting it operates on wording alone 'with no research/volume data yet'.

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?

It clearly frames when this is the right call: a bare keyword list that has no research/volume data yet, using the same heuristic research_keywords applies as its free-tier fallback. It stops short of explicitly naming a sibling alternative and stating when NOT to use this (e.g., when volume/CPC data is required).

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?

Adds substantial behavior beyond the annotations: it discloses that successfulModelCount is the denominator (raw counts, not percentages or rankings), that entities[0] is always the target brand with competitors in submitted order, that a failed model reports status error with mentioned/cited null (not false) because it was never checked, and that it requires a paid plan and charges per-request.

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-loads the core 'what it does' in the first sentence, then layers in scope limits, output semantics, and cost. It is dense and long, but virtually every clause carries distinct information an agent needs, so only minor trimming would be possible.

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?

With no output schema, the description carries the full burden and delivers: it explains mentionedByCount/citedByCount denominators, entities[0] ordering, and error/null handling per failed model. Combined with the cost and plan disclosures, an agent has everything needed to call and interpret it correctly.

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 the schema already documents brand, competitors, models, prompt, projectId, and the optional web/locale params. The description's added detail (entities ordering, persona nature of models, per-answer comparison) mostly pertains to output semantics rather than the parameters themselves, so baseline 3 is appropriate.

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?

States a specific verb+resource: runs ONE prompt through the explore_ai_prompt pipeline and checks a brand plus competitors against the same per-model answers. It explicitly distinguishes its scope ('what one prompt's observed answers show for the named entities') from a comprehensive cross-prompt visibility score, and names the pipeline it builds on.

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?

Gives clear context: use it for a single-prompt, bounded entity comparison, and explicitly warns it is 'never a comprehensive cross-prompt visibility score.' It also discloses cost/plan requirements. It stops short of naming an alternative sibling to use when comprehensive, cross-prompt visibility is actually needed.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds critical context they don't convey: the post goes LIVE and PUBLIC immediately, there is no draft state and no undo. That directly changes agent behavior (mandatory human approval) and exceeds what the structured hints 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 sentences, front-loaded with the action and its immediacy, then the approval requirement, then the scope limit. No filler; every sentence carries an actionable constraint.

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 non-idempotent, destructive write with no output schema, the description supplies the missing behavioral essentials: immediate public effect, irreversibility, required human confirmation, and unsupported post types. An agent has everything needed to invoke it safely.

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% and all three parameters (summary, projectId, languageCode) are documented in-schema with constraints and sourcing. The description adds no parameter-level syntax or format detail, so the baseline 3 for a fully-documented schema applies.

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?

States a specific verb (Publishes) and resource (a new "What's New" post on the linked Google Business Profile location). It is unambiguous and clearly distinguished from read-side siblings like list_gbp_posts or delete_gbp_review_reply.

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?

Gives explicit pre-call procedure (show the user the exact text and get explicit approval) and a scope limit (only standard posts, no event/offer/alert). It does not name an alternative tool or restate the when-not condition in terms of siblings, but the usage 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?

Annotations cover the safety profile (readOnlyHint=false, non-idempotent, non-destructive, closed-world), and the description adds non-obvious behavior beyond them: the location is string-composed into the query as '<keyword> in <locationLabel>' and is explicitly NOT geocoded. That is a real implementation trait an agent would otherwise assume wrongly.

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 compact sentences, front-loaded with the definition, followed by the composition rule and the next-step tools. No filler and no repetition of schema or annotation data.

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 mutation config-creation tool with no output schema, the description covers what is created, how the location is interpreted, and which tools consume/read the result. The only minor gap is that it does not mention the created config's identifier being returned for later use.

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, but the description adds genuine semantics for locationLabel: it explains how the value is composed into the query and warns that no geocoding occurs. It does not cover languageCode, which the schema handles.

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?

States a specific verb and resource ('Creates a local pack rank check config') and immediately defines the resource's semantics: where businessName sits in Google's local pack for one keyword at one location. This clearly distinguishes it from siblings like create_local_rank_grid_config and create_rank_tracker.

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 routes the agent through the lifecycle: run checks with run_local_pack_rank_check and read them with get_local_pack_rank. It also flags cost context ('FREE: database only'). It does not state when NOT to use it (e.g. grid vs single-location), but the use case is unambiguous.

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?

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false). The description adds context the annotations cannot: the call is database-only and FREE, i.e. it persists a config without triggering a paid rank run, and centerLabel is effectively mandatory in substance, not just by schema. The non-idempotent behaviour (what happens if a duplicate config is created) is left unstated.

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 core definition, then the centerLabel constraint, then the workflow and cost note. Every sentence carries information, though the rhetorical clause 'a heatmap with no stated centre is a claim about nowhere' is slightly ornate for a tool definition.

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?

Covers creation semantics, the required labelling constraint, the follow-up tools for running and reading, and the cost model — enough for an agent to call it correctly without an output schema. It stops short of documenting duplicate-config behaviour or what the created config ID looks like for subsequent run/get calls.

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 already 100%, so the baseline is 3. The description goes beyond it by explaining the semantics of the grid itself (3x3 points around a centre, organic-only rank, one keyword/domain per point) and by giving centerLabel a stated requirement plus rationale rather than only an example value.

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?

States a specific verb+resource ('Creates a geo-grid rank-tracking config') and immediately defines the object: a 3x3 grid around a centre coordinate checking ORGANIC rank for one keyword/domain. This is precise enough to separate it from the sibling run_local_rank_grid and get_local_rank_grid, which it names as the lifecycle partners.

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 tells the agent what to do after creation ('Run it with run_local_rank_grid and read it with get_local_rank_grid'), which routes the agent into the correct workflow. It does not, however, address the closest alternative (create_local_pack_rank_config) or state when a grid config is preferable to other rank-tracking setups.

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?

Annotations already declare a non-read-only, non-destructive, non-idempotent write, so the safety profile is covered. The description adds genuine value beyond them: it discloses the return shape ({ id }), the empty starting state, and the cost profile ('FREE: database only, no SEO data provider is called and no credits are spent') — a real operational trait an agent could not infer from structured fields.

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 short sentences, zero filler, each carrying distinct information (what it does, what it returns, what to do next, and what it costs). The next-step guidance and cost note are front-loaded rather than buried.

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?

No output schema exists, but the description supplies the return value ({ id }), the follow-up action, and the cost/credit implication, which is everything an agent needs to invoke this simple single-parameter creation tool correctly.

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% (the single 'name' parameter is documented as 1-100 characters), so the schema carries the parameter semantics. The description adds no format or constraint detail beyond it; the 'no member projects' note describes state, not the parameter. Baseline 3 is appropriate for a one-parameter tool with 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?

States a specific verb and resource ('Creates a portfolio') and immediately disambiguates it from the sibling add_portfolio_projects by declaring the initial state ('Starts with no member projects'). An agent can distinguish this from list_portfolios, get_portfolio, delete_portfolio and rename_portfolio without opening the schema.

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 routes the agent to the follow-up tool ('use add_portfolio_projects next'), which is the natural workflow after creation. It does not state exclusions or prerequisites (e.g. naming collisions, uniqueness constraints), so it falls short of a full when/when-not specification.

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?

Annotations only say it is a non-read-only, non-idempotent, non-destructive create. The description adds the crucial behavioral fact that creation is FREE (database only, no credits) — a claim annotations cannot express — plus the constraint that scheduled checks are the sole mechanism for data collection. This is exactly the 'beyond annotations' value the dimension rewards.

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 single paragraph is front-loaded with the action and return value, then routes to the follow-up tool, then discloses constraints. Dense but every sentence earns its place; four separate facts in four sentences with 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 an 11-parameter create tool with no output schema, the description supplies the return value (configId), the follow-up workflow, the uniqueness constraint, the scheduling semantics, and the cost — everything an agent needs to call it correctly and without surprise.

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 parameters (domain, devices, scheduleInterval, serpDepth, etc.) are already fully documented in the schema. The description confirms the shape (domain + market + devices + schedule) and clarifies 'manual' means no schedule, but adds no syntax or defaults beyond the schema. Baseline 3 per the high-coverage rule.

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?

Names a specific verb ('Creates') and resource ('rank tracker config') and enumerates the config contents (domain + market + devices + schedule). It also names the sibling it hands off to (add_rank_tracking_keywords) and the reader (get_rank_tracker), distinguishing it from other create_* tools.

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 the next step (add keywords with add_rank_tracking_keywords), that positions come only from the schedule and are read via get_rank_tracker, and that nothing triggers an on-demand check. It also states the uniqueness constraint (one tracker per domain+market per project) and that repeats are a validation error, so an agent knows when not to call it.

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?

Annotations declare it's a write (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds valuable context: returns { id }, no SEO provider calls, no credit spend. It could go further by stating what happens on duplicate name or permission requirements.

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 tight sentences: the first states the action and result shape, the second gives the cost/free-tool context. Front-loaded with the core verb+resource and 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?

Covers the essentials for a create tool: what it makes, the ordering behavior, return shape, and cost profile. Missing only edge-case guidance (duplicate names, limits, permissions), which is minor given the 100% schema coverage.

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 schema fully documents all 3 parameters including the widgetTypes enum with descriptions. The description adds the print-order concept for widgets but this is already stated in the schema. Baseline 3 is appropriate.

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?

States a specific verb (Creates) and resource (report definition) with the key detail of print order for widgets. Distinguishes from set_report_widgets by implying creation rather than modification, but doesn't explicitly name any sibling for comparison.

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 FREE clause hints at cost guidance but doesn't specify when to use this vs set_report_widgets, rename_report_definition, or render_report_definition. No explicit when-to-use or when-not-to-use guidance is provided.

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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the safety profile. The description goes beyond this by revealing the side effect on scheduled scans and the admin-role requirement, which the annotations do not convey.

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 short sentences, no filler. The core action is front-loaded, with the side effect and prerequisites following without redundant restatement of the tool name.

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 destructive, idempotent delete with no output schema, the description covers the essential points: what is deleted, the consequence, and the authorization requirement. It is nearly complete, lacking only a note on reversibility or failure behavior, which is minor given annotation coverage.

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 monitorId and projectId are fully documented in the schema, including their provenance. The description reiterates where to get monitorId but adds no format or constraint detail beyond the schema; baseline 3 applies.

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?

States a specific verb+resource ('Deletes a brand monitor') and adds the consequential effect 'stopping its scheduled scans', which distinguishes it from siblings like remove_competitor_monitor. An agent can immediately tell what it does.

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 a concrete prerequisite ('Requires the admin role in the calling organization') and points to list_brand_monitors for obtaining the ID. There is no explicit when-not-to-use guidance (e.g., prefer keeping the monitor vs deleting), but the 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds genuinely new behavioral context beyond those hints: the removal is public-facing and takes effect immediately, plus a user-confirmation requirement, which the annotations cannot express.

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 short sentences, each carrying distinct information (what is deleted, its visibility/timing, the confirmation requirement), with the core action front-loaded and 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 two-parameter destructive tool with no output schema and rich annotations, the description supplies what an agent most needs: exact scope, irreversibility via public/immediate framing, and a confirmation gate. Minor omissions (error or permission behavior on an already-deleted reply) are acceptable since the tool is idempotent.

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 reviewId and projectId are already documented in the schema, including the get_gbp_reviews provenance that the description repeats. No additional format, constraint, or example is added, so the baseline of 3 applies.

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?

States a specific verb and resource: 'Removes the owner's published reply from one Google review'. The scope ('one Google review') is explicit and it is distinguishable from the sibling reply_to_gbp_review, which adds or edits a reply rather than deleting one.

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?

Gives the prerequisite for the key parameter ('reviewId from get_gbp_reviews') and an operational caution ('Confirm with the user before calling'), which tells the agent when this call is appropriate. It does not, however, explicitly contrast itself with the alternative reply_to_gbp_review or state when not to use it.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the destructive nature is known. The description adds context the annotations do not: the deletion is cascading, taking the config's entire check history with it, and it demands user confirmation. That is exactly the extra behavioral detail the annotations cannot express.

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 short sentences, zero filler. The irreversible consequence is front-loaded and capitalized, and the confirmation requirement follows immediately after.

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 two-parameter deletion tool with no output schema and fully documented parameters, the description covers what is deleted, how far the deletion reaches, and the confirmation requirement. Only a note on how to discover existing configs (or on error behavior for a bad configId) is arguably absent.

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%: configId documents its provenance (from the matching get_* tool without configId) and projectId points at list_projects. The description adds no parameter-level meaning, so the baseline 3 applies.

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?

Names a specific verb (Deletes) and resource (local pack rank check config), which cleanly separates it from sibling delete_local_rank_grid_config and from create_local_pack_rank_config. No schema inspection is needed to know what it acts on.

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 gives one directive — 'Confirm with the user before calling' — which is a gating condition rather than a when-to-use rationale. It never states when to prefer this over alternatives such as delete_local_rank_grid_config or disabling a config instead of deleting it, so usage is only 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable specifics beyond annotations: that the whole run and point history are deleted (scope of destruction) and a user-confirmation requirement. This is genuine added context.

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 short sentences, front-loaded with the action and the critical 'INCLUDING history' warning before the confirmation instruction. No waste.

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 2-param destructive delete with full schema coverage and annotations, the description covers the key extras an agent needs: destruction scope and confirmation requirement. No output schema is needed for a delete. Minor gap: no mention of irreversibility beyond 'deletes'.

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 configId and projectId fully documented in the schema. The description adds no parameter syntax or format details. Baseline 3 is correct when schema does the heavy lifting.

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?

States a specific verb (Deletes) and resource (geo-grid rank-tracking config), enough to distinguish from siblings like delete_local_pack_rank_config. Doesn't explicitly name the sibling it differs from, but the resource is specific.

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?

Adds a 'Confirm with the user before calling' instruction, which is useful guidance for a destructive op. However, it does not say when to use delete_local_rank_grid_config vs delete_local_pack_rank_config or other config deletion tools.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds blast-radius detail the annotations cannot express: deletion is scoped to the grouping and does not cascade to member projects, and no external provider call or credit spend occurs. It does not cover permissions or error behavior.

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 short sentences, zero filler, with the core action front-loaded and the side-effect and cost caveats following in priority order. 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?

For a single-parameter destructive tool with no output schema, the definition covers action, blast radius, idempotency context, and cost. Only permission requirements and failure modes are unaddressed, which is a minor gap on a tool whose annotations already mark it destructive.

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?

One parameter with 100% schema description coverage, and the schema already tells the agent to use list_portfolios to find the ID. The description adds nothing about the portfolioId itself, so this is the baseline 3.

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?

States a specific verb and resource ('Deletes a portfolio') and immediately disambiguates it from the similarly named remove_portfolio_projects by clarifying that member projects are untouched and only the grouping is removed. An agent can pick between the two without opening either schema.

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?

Cost guidance is explicit ('no SEO data provider is called and no credits are spent'), which is real usage signal in a toolset full of credit-consuming calls, but there is no explicit when-to-use/when-not or named alternative tool. The routing to remove_portfolio_projects is only implied by the 'member projects untouched' clause.

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?

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds context annotations do not carry: the operation is database-only, invokes no SEO data provider, and consumes no credits. It does not say whether the deletion is permanent or what happens to dependent report schedules.

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, zero filler, with the core action front-loaded and the cost consequence immediately after. Every clause carries information an agent can act on.

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 destructive, annotation-covered delete with no output schema, the description covers cost behavior but omits cascade/reversibility facts, notably whether associated report schedules are also removed. Adequate but with a clear gap given the sibling delete_report_schedule.

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% and both parameters are fully documented in the schema, including the 'Required.' marker and pointers to list_projects and list_report_definitions. The description adds nothing about either parameter, so the baseline 3 applies.

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?

States a precise verb+resource ('Deletes a report definition'), which cleanly separates it from get_report_definition, rename_report_definition and render_report_definition. It does not explicitly name the nearest confusable sibling, delete_report_schedule, so an agent must rely on the resource noun alone to distinguish the two deletions.

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?

There is no explicit when-to-use or when-not-to-use guidance and no alternative is named. The 'FREE' note does give a decision-relevant cost signal (no credits spent), which helps an agent route among operations, but it is not usage guidance in the strict sense.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known; the description adds genuinely useful context beyond them — the required admin role and the fact that no SEO data provider is called and no credits are spent. It does not, however, state whether the parent report definition survives or whether re-creation is needed.

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 short sentences, purpose first, then the permission prerequisite, then the cost/side-effect note. No filler; each sentence contributes a distinct, actionable fact.

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 two-parameter delete with no output schema and strong annotations, the description covers purpose, gating, and side-effect cost sufficiently. The only minor gap is not telling the agent what happens to the underlying report definition or how to restore the schedule.

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% — both projectId and reportDefinitionId are documented in-schema with sourcing hints (list_projects, list_report_definitions). The description adds no additional parameter-level meaning, so baseline 3 applies.

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 ("Deletes a report definition's schedule"), which cleanly separates it from the sibling delete_report_definition (the definition itself) and upsert_report_schedule (the writer counterpart). An agent can pick the right tool without opening the schema.

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?

It states a prerequisite (admin role) and that it is free/credit-less, which frames cost and gating, but it never says when to delete a schedule versus using upsert_report_schedule to change it, nor what effect removal has on the parent definition. Usage is implied rather than explicit.

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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so safety is covered by structured data. The description adds value beyond them by disclosing the auth requirement and the downstream effect that scheduled checks stop, which an agent would not infer from the annotations alone.

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 short sentences, front-loaded with the action and its effect, then auth requirement, then ID provenance. Every sentence carries distinct operational information with 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 destructive two-parameter mutation with no output schema, the description covers effect, permissions, and ID source, and both params are fully documented in the schema. It stops short of stating whether the deletion is recoverable or what happens to historical trend data, which would complete the picture.

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%, with both parameters documented in the schema including that projectId is required and where to obtain it. The description reinforces the ID source but adds no syntax, format, or constraint beyond what the schema already provides, so baseline 3 applies.

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?

States a specific verb and resource ('Deletes a tracked prompt') and adds the consequential side effect ('stopping its scheduled checks'), so the agent understands this is more than a record removal. It does not explicitly distinguish itself from the many other delete_* siblings, but the named resource is 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?

Gives a hard prerequisite ('Requires the admin role in the calling organization') and routes the agent to the source of the ID ('Get the trackedPromptId from list_tracked_prompts'). No explicit when-not or alternative-tool guidance, but the context needed to invoke successfully is present.

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?

Annotations already carry destructiveHint, idempotentHint and readOnlyHint, so the bar is lower, yet the description adds real context beyond them: FREE/no credits, org admin requirement, and the important nuance that already-published patches are unaffected. This directly addresses the surprising part of a destructive-hinted mutating 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?

Three tight sentences, front-loaded with the primary effect ('stops auto-publishing...') before the scope caveat and the cost/permission notes. No filler and every sentence carries distinct information.

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 two-parameter mutation with no output schema, the description covers effect, scope, side effects on existing patches, cost, and the admin prerequisite. Nothing an agent needs to decide to call it correctly 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 description coverage is 100%, so both parameters and the issueType enum are already documented in the schema. The phrase 'for this issue type' reinforces the scoping of issueType but adds no syntax or selection guidance beyond the enum, so baseline 3 applies.

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?

States a specific verb and resource ('stops auto-publishing freshly AI-drafted patches for this issue type') and defines scope precisely as per-issue-type. Named context (publish_patch, drafted patches) makes it distinguishable from the sibling enable_patch_auto_publish even though that sibling isn't named explicitly.

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?

Clearly establishes the when: this affects future auto-drafts and routes them back to manual publish_patch calls, and clarifies already-published patches are untouched. It never states the inverse action ('use enable_patch_auto_publish to restore'), so the alternative is only implied rather than explicit.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the crucial blast radius detail that it destroys TWO bindings plus the stored grant and breaks Ahrefs data for all organization members, not just the caller. The admin-role prerequisite is authorization context the annotations do not carry.

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, zero filler, and the destructive scope statement is front-loaded before the permission note. Every clause carries operational weight.

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 one-parameter destructive mutation with no output schema, the description covers what is destroyed, who is affected, and the role requirement. It could go slightly further by noting the operation is not undoable without reconnecting (and which tool re-establishes the connection), but nothing essential 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?

Single parameter with 100% schema description coverage; the schema already explains projectId and points to list_projects. The description adds no additional parameter meaning, so the baseline of 3 applies.

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?

States a specific verb (disconnect/full disconnect) and precisely enumerates the resource scope: both the Rank Tracker and Site Audit bindings plus the stored grant. This cleanly distinguishes it from sibling disconnects like disconnect_bing and from set_ahrefs_project, which is the inverse operation.

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?

Gives clear context for invocation: it is the 'full' teardown, it affects every member of the organization rather than just the caller, and it 'requires at least the admin role.' It never explicitly names the alternative (e.g., a partial unbind or set_ahrefs_project for rebinding), so it stops short of full when/when-not routing.

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?

Beyond the destructiveHint/idempotentHint annotations, the description discloses blast radius ('Breaks Baidu push submission for every member of the organization, not just the caller') and an authorization requirement (admin role). Those are exactly the side-effect and permission facts an agent cannot derive from the structured fields.

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 identifies the action, the second front-loads the two facts that affect the decision (scope of damage, role requirement). No filler or restatement of the name.

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 one-parameter destructive tool with no output schema and annotations already covering safety semantics, the description supplies the missing pieces: side-effect scope, permission gate, and target resource. Nothing needed to invoke it correctly is absent.

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?

With a single parameter at 100% schema description coverage, the schema already documents projectId fully (including how to obtain it). The description only implies project scoping through the phrase 'a project's connection' and adds no format or constraint detail, so the baseline 3 applies.

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?

States a specific verb and resource ('Remove a project's Baidu Webmaster connection'), which cleanly separates it from the disconnect_ahrefs/disconnect_bing/disconnect_yandex/disconnect_ga4 siblings that share the same verb. No schema lookup is needed to know what it does.

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?

It gives a concrete prerequisite ('requires at least the admin role') and warns about org-wide impact, which tells the agent when the call is appropriate and when it may fail. It stops short of naming alternatives or exclusions, e.g. pointing at get_baidu_connection to verify state first or set_baidu_connection to restore it, so it is clear context rather than full 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so safety is partly covered. The description earns credit for adding the blast radius ('breaks Bing Webmaster data for every member of the organization, not just the caller') and the authorization requirement — both genuinely beyond what annotations convey.

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, front-loaded with the action, then the consequence and prerequisite. No filler or redundancy; every clause carries information.

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 one-parameter destructive mutation with no output schema, the definition covers purpose, org-wide impact, and role requirement — enough to call it safely. Minor gap: it does not say what state the project is left in after disconnection.

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?

Single parameter with 100% schema coverage; the schema already documents projectId fully, including where to obtain it. The description adds no syntax or semantic detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb (unlink) and resource (a project's Bing Webmaster site), which cleanly distinguishes it from the parallel disconnect_ahrefs/disconnect_baidu/disconnect_ga4/disconnect_gbp/disconnect_yandex siblings. An agent can identify the target integration without opening the schema.

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 a precondition ('requires at least the admin role') but never states when to prefer this over the inverse operation set_bing_site or other disconnect variants, nor what happens on subsequent calls. Usage is implied by the name and prerequisite rather than explicitly guided.

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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, but the description adds real context beyond them: the blast radius is organization-wide ('Breaks Analytics data for every member of the organization, not just the caller') and it states the authorization requirement. It does not discuss reversibility or how to reconnect.

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 short sentences: the action first, then the consequence and permission requirement. No filler, no repetition of the name or annotations.

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 single-parameter destructive mutation with no output schema, the description covers purpose, org-wide impact and required role, which is nearly everything an agent needs. Minor gaps remain around whether the link can be restored and what happens to historical data.

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 (projectId) with 100% schema coverage, including guidance to get it from list_projects. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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 gives a specific verb and resource: 'Unlink a project's Google Analytics property.' It is unambiguous about what is being removed, but it never names or distinguishes itself from the other disconnect_* siblings (ahrefs, baidu, bing, gbp, yandex), so sibling differentiation comes only from the tool name.

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?

Usage is implied by the name and the tool is clearly the inverse of set_ga4_property, but the description gives no explicit when-to-use/when-not guidance or alternatives. It does supply one useful prerequisite ('requires at least the admin role'), which lifts it above pure implication.

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?

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds material context they cannot convey: the deletion is scoped to MisarSEO's own record only and the Google location itself is untouched, plus the cascading side effect that all GBP tools break until relinking. This is exactly the behavioral detail an agent needs before invoking a destructive unlink.

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 filler, and the effect-plus-scope caveat is front-loaded before the downstream consequence. Every clause earns its place and the em-dash clause clarifies the blast radius efficiently.

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 single-parameter destructive toggle with no output schema, the description covers what is removed, what is not, and the operational fallout — enough for an agent to call it correctly and warn appropriately. No meaningful gap remains given annotations already carry the safety profile.

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% — projectId is documented in-schema with required-ness and a pointer to list_projects. The description adds no parameter-level detail, so the baseline of 3 applies; the schema does the work here.

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?

'Removes the project's link to its Google Business Profile location' names a specific verb (removes) and a precise resource (the GBP link record), and is immediately distinguishable from the write-side sibling set_gbp_connection. An agent knows exactly what operation this is without opening the schema.

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 the consequence-driven context ('every GBP tool stops working for the project until it is linked again'), which tells the agent when this action is appropriate and what it costs. It does not explicitly name set_gbp_connection as the counterpart/reversal route, so the routing guidance is strong but not fully explicit.

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?

Goes well beyond the annotations: annotations say only destructiveHint=true and idempotentHint=true, while the description discloses that data is broken for every organization member, not just the caller, and sets a minimum permission (admin role). Those are exactly the impact and authorization facts an agent needs before calling.

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 load-bearing: the first names the operation, the second front-loads the blast radius and permission requirement. No filler or restated title.

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 single-parameter, no-output-schema, destructive tool, the description covers the essentials: what is unlinked, how broad the damage is, and who is allowed to do it. Nothing an agent needs to invoke it safely 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?

Only one parameter (projectId) and schema coverage is 100%, so the schema already carries its meaning including where to obtain the ID (list_projects). The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource: 'Unlink a project's Yandex Webmaster host.' This clearly distinguishes it from the connect-side sibling set_yandex_host and from the other disconnect_* tools (ahrefs, bing, ga4, gbp), which target different integrations.

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 a precondition ('requires at least the admin role') and implies scoping to one project, but never states when to use this versus alternatives (e.g., re-pointing a host via set_yandex_host) or what happens if the host is already unlinked. Usage is inferable from the purpose but not spelled out.

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?

Annotations already declare the safety profile (readOnly=false, destructive=false), yet the description adds substantial context the annotations don't: it is a mutation that creates/overwrites a per-page+field draft but does not publish, it consumes an AI-gateway operation in specific cases, and it requires an org admin. These are exactly the behavioral facts an agent needs beyond the structured hints.

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 verb and scope, and every sentence carries load (cost, mutation, alternative, auth). It is dense and somewhat run-on with heavy parenthetical nesting, which slightly hurts scanability but wastes no 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?

With no output schema, the description still covers everything an agent needs to call this correctly: what it creates, that it isn't published, the cost model, the auth requirement, and the sibling to use instead. Nothing material is missing for a 4-parameter mutation 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%, and the schema already documents value, issueType, pageUrl and projectId in detail, so baseline is 3. The description adds meaning beyond the schema by tying value to cost (skips the AI operation) and to the free deterministic canonical/redirect cases, which the schema only partially conveys.

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?

States a specific verb (drafts) and resource (a title/metaDescription/canonical/redirect fix for one page's finding), naming the exact issue classes it covers. It explicitly distinguishes itself from publish_patch and implies the batch alternative, so an agent can tell what it does and doesn't do without opening any schema.

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/when-not and routing: use publish_patch to publish, and use value when an explicit replacement is needed instead of AI drafting. It also names conditions that change cost (canonical/redirect free, title/metaDescription cost unless value given), giving the agent decision-relevant 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?

Discloses traits well beyond the annotations: a 20-per-project-per-day cap, that it is FREE, that it is a MUTATION, and that it requires org admin rights. Annotations already mark it non-readonly, non-destructive, and idempotent, so the description's added caveats about limits, cost, and permissions are genuinely valuable.

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 that are front-loaded with the core effect before the cap, exception, and permission notes. Every clause carries information, though the embedded draft_patch value-argument clause makes it slightly dense rather than crisply scannable.

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 2-parameter mutation with no output schema, the description supplies everything needed: the behavioral change, the cap, cost, permission requirements, and the critical exception. Annotations cover the safety profile, so no essential context 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 coverage is 100%, so both parameters are already documented, giving a baseline of 3. The description adds meaningful interpretation by clarifying that the rule applies only to freshly AI-drafted patches and never to hand-typed replacement values, which shapes how the issueType scope should be understood.

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?

States a specific verb (enable) and resource (patch auto-publish) for a given issue type, and describes the exact behavioral change: AI-drafted patches publish immediately rather than waiting for a manual publish_patch call. This lets an agent distinguish it immediately from the sibling publish_patch and disable_patch_auto_publish tools.

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?

Clearly explains the operational context (replaces the manual publish_patch step, applies per issue type, requires org admin) and notes the key exception that hand-typed draft values are never auto-published. It does not explicitly point to disable_patch_auto_publish as the reversal path, leaving that inference to the sibling name.

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?

Goes well beyond the annotations: discloses that a paid plan is REQUIRED, that one shared gateway operation is charged per call (not per model), and that an extra operation is spent only when both analyzeSentiment and highlightBrand are set. It also honestly warns that persona labels are not vendor-verified and that 'claude'/'perplexity' have no real vendor route.

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 tightly-packed sentences, front-loaded with what it does, then the critical persona caveat, then the cost model. Every sentence earns its place with 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?

Covers purpose, the crucial interpretation caveat, cost/auth preconditions, and roughly what it returns ('each answer verbatim, with real citations'), which is sufficient given there is no output schema.

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?

With 86% schema coverage the schema carries most parameter detail, but the description adds non-obvious semantics: webSearch is shared across all personas, and the analyzeSentiment+highlightBrand combination triggers an extra charge. This meaningfully enriches the schema beyond field definitions.

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?

States a specific verb+resource ('Runs one prompt through up to 4 model personas') and scope ('returns each answer verbatim, with real citations when webSearch is on'), which cleanly distinguishes it from siblings like research_ai_prompts and get_direct_vendor_answers.

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?

Gives strong interpretive guidance ('treat every answer as a model answering as X, never as ground truth from X') and states the paid-plan precondition. It does not, however, explicitly name an alternative tool or the condition that selects this over research_ai_prompts, so it falls short of a 5.

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?

Adds significant context beyond annotations: FREE (no credits), UTF-8 encoding requirement, exact save instructions, and the Google disavow syntax. Annotations already cover read-only/idempotent safety; the description adds operational details about the output artifact itself.

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?

Single dense sentence pack with the critical output format front-loaded, followed by syntax definition and save instructions. No waste, every clause 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 single-parameter read-only export tool, the description covers everything needed: what it does, the output format, the syntax rules, encoding, and the downstream usage pattern. With annotations covering safety profile, no further behavioral disclosure is required.

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 projectId parameter is fully documented in the schema including how to obtain it. The description doesn't add parameter-specific meaning beyond what's in the schema — baseline 3 is appropriate.

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?

States a specific verb (export) and resource (disavow file) and precisely defines what the output represents — the exact .txt content Google's disavow tool accepts. This distinguishes it from siblings like list_disavow_entries, which lists entries rather than producing a Google-ready file.

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 context about free usage and the output format, but doesn't explicitly state when to use this vs list_disavow_entries or add_disavow_entry. Usage is implied rather than spelled out.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is lower; the description adds non-annotation context that it is credit-free and that the payload should be written verbatim with UTF-8 encoding. It does not mention size limits, truncation, or error behavior for large prospect lists.

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 short clauses, front-loaded with the tool family and action, with zero filler. 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?

There is no output schema, and the description compensates by naming the return field (`csvContent`), its format (CSV text), and required encoding — exactly what an agent needs to consume the result. Nothing essential is missing for a single-param export 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, and schema description coverage is 100% — the schema already documents `projectId` including its source (list_projects). The description adds no additional parameter meaning, so the baseline 3 applies.

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?

States a specific verb (export) and resource (a project's prospect list) plus the exact form of the output (CSV text). This clearly differentiates it from sibling read tools like list_link_prospects and the inverse import_link_prospects_csv.

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?

It notes the operation is FREE (no credits) and instructs the agent to save the returned `csvContent` to a .csv file as-is (UTF-8), which is useful post-call guidance. However, it gives no explicit when-to-use vs. alternatives guidance (e.g., list_link_prospects for paged JSON access, import_link_prospects_csv for the reverse direction).

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?

Annotations cover only the generic safety profile (readOnlyHint=false, idempotentHint=false), so the description carries real weight here and delivers: credit charges on the paid provider, the free provider aggregating one live SERP per keyword, resultTypes/includeSubdomains being ignored on the free tier, and the critical 'unmeasured sorts last, not zero' behaviour with the unmeasuredForSort field. This is exactly the context annotations cannot 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?

The text is dense and long, but front-loaded with the purpose before the caveats, and nearly every clause conveys a distinct operational fact. The credits/provider material is slightly repetitive in phrasing, which keeps it from a 5.

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 10-parameter, no-output-schema tool with only generic annotations, the description supplies the missing pieces: cost model, provider-dependent semantics, sorting pitfall, and a warning not to present an unranked list as ranked. Nothing an agent needs before calling it is absent.

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, but the description adds genuine meaning the schema does not: which parameters only the paid provider honours (resultTypes, includeSubdomains) and that omitting locationCode/languageCode falls back to the project default market. It stops short of explaining excludeDomains or the limit/offset relationship, keeping it at 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?

The description states a specific verb and resource ('compares domains competing in search results for a supplied keyword set') and explicitly distinguishes itself from the sibling get_keyword_gap, which it calls 'the inverse'. An agent can pick this tool over its neighbours without opening a schema.

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?

It names the intended use case (market and search-intelligence reports), an explicit exclusion ('not radius-based local SEO'), and the alternative tool plus the question that should route to it instead. This is about as complete as routing guidance gets.

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?

Annotations already cover read-only/idempotent/non-destructive, and the description goes well beyond them: it discloses the exact comparison scope, the notComparableCount fallback for pages a shorter crawl missed, the precise boundary of newIssues, the self-comparison validation error, the failure mode when no baseline exists, and that the call costs no credits.

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 core comparison and the notComparableCount caveat lead, and the error/cost facts are tacked on at the end. It is dense with two nested parentheticals, but each sentence carries distinct information rather than 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?

With no output schema, the description carries the return-value burden and does it: it names the issue categories, notComparableCount, addedUrlCount, and the health-score delta. For a read-only diff tool, nothing an agent needs to call and interpret it 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 description coverage is 100%, and the schema itself already documents auditId, projectId, and the baselineAuditId omission/fallback behavior in detail. The description adds comparison semantics but no parameter-level syntax or format beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource (compare a site audit against an earlier one) and enumerates the exact outputs: new issues, fixed issues, persisting count, health-score delta. An agent can distinguish this from sibling audit tools (get_audit_core_web_vitals, get_audit_https_report) purely from the description.

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?

Explains the conditions clearly: only pages both crawls visited are compared, an error is returned when no earlier completed audit exists, and it states the tool is free. It does not name an alternative tool to use instead when comparison is impossible, so it stops just short of explicit 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?

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds substantial non-schema context: no new fetch, source table, single simulated run vs aggregated CrUX, and 'charges no credits'. The remaining gap is pagination/response-size behavior, but for a cache-read tool this is 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?

Front-loads what the tool is and where the data comes from, then layers constraints in descending priority. It is dense and slightly run-on, but nearly every clause carries operationally relevant information rather than 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?

With no output schema, the description compensates by explaining return semantics (`allGood` computed only when all three metrics measured and good), the state classifier, cost, and error behavior. An agent has everything needed to call and interpret it.

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%, which sets the baseline at 3, but the description adds real meaning beyond the schema: the `state` filter values and their semantics, and what `pages[].allGood` encodes. The declared params (auditId, projectId) are already documented in the schema, so credit here is for the extra field/enum semantics.

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?

States a specific verb+resource (Core Web Vitals report) and pins the exact data source ('reads audit_lighthouse_results'), so an agent can distinguish it from the many get_*_report siblings at a glance. It also declares scope (per page/strategy) and the LAB-vs-field-data boundary.

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 tells the agent to 'ALWAYS narrow on state first' and enumerates the two meaningful states with their interpretation, plus a when-NOT ('never Search Console's real Chrome UX Report field data'). It also notes the error condition when the audit doesn't belong to the project, leaving little to inference.

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?

Goes well beyond the readOnly/idempotent/non-destructive annotations: it discloses that results derive entirely from already-computed crawl data with no new work, that TLS checks are deliberately unbuilt and surfaced via notDerivable, that homepageStatus.redirectsToHttps is null rather than assumed healthy, and that the call is free with no external call. This is exactly the 'checked vs never checked' nuance an agent cannot get from structured fields.

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-loads the report contents before the caveats, and each caveat (unbuilt TLS checks, null redirect status) carries real decision value. It is dense and slightly overlong with stacked parentheticals, but no sentence is pure 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?

There is no output schema, so the description carries the full burden and does so: it enumerates returned fields (notDerivable, homepageStatus.redirectsToHttps, state), explains their semantics, and covers the safety profile already implied by annotations. An agent has everything needed to interpret the response.

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 auditId and projectId are already documented in the schema, including that omission means the latest completed audit. The description only loosely echoes this ('latest completed crawl (or a named earlier one)') and adds no syntax or format detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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?

Names a specific resource (HTTPS report) and enumerates exactly what it contains: secure-page percentage, mixed-content and insecure-link counts, homepage HTTPS-path status, and HTTP URLs in the sitemap. Scoped to a project's latest or named crawl, which cleanly separates it from siblings like get_audit_core_web_vitals and get_audit_internal_links.

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 the prerequisite flow ('narrow on state first: no_audit vs analysed') and the auditId omission behavior, giving clear context for when the call is meaningful. However it does not name a specific alternative report tool or explicitly state when-not-to-use, so it stops short of full routing 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?

Annotations already declare readOnly/idempotent/closed-world, but the description adds genuinely non-derivable behavior: no new computation, free of credit charges, no external call, and a `notDerivable` block explaining what the report can never compute. The one ding is that it instructs the agent to narrow on `state`, which is not present in the input schema, leaving it unclear whether state is an input filter or a returned field.

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?

Content is front-loaded: what the report contains comes first, then scope disclaimers, then state semantics. It is dense and slightly repetitive ("INTERNAL LINKS ONLY" followed by a full external-links explanation), but nearly every sentence carries distinct scope or data-limitation information.

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?

With no output schema, the description does meaningful work describing return shape (totals.externalLinkOccurrences, notDerivable, state values) and the absence-of-data semantics, which is exactly what an agent needs to interpret results. The unresolved ambiguity about whether `state` is an input or an output field is the only real gap.

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% and both parameters (auditId, projectId) are already fully documented in the schema, including the "omitted means latest completed audit" default. The description adds no per-parameter syntax or format detail beyond that, so the baseline 3 applies; its `state` reference matches no declared parameter.

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 names a specific report and enumerates its exact contents: outbound/inbound internal link counts per page, orphan pages, dead ends, and click-depth distribution, scoped to a project's latest (or named) completed crawl. It also explicitly carves itself off from external-link tooling, so an agent can distinguish it from siblings like get_backlinks_overview or get_audit_structured_data without opening a schema.

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?

It gives a strong usage rule ("ALWAYS narrow on `state` first") and explains each state value so the agent knows when an empty result means no crawl vs. missing data. It does not name a sibling alternative for the adjacent use cases (e.g. external links, comparison audits), so it stops short of full alternative routing.

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?

Annotations already declare this as a safe, idempotent, closed-world read. The description adds substantial non-obvious behavior: it is free and charges no credits, makes no external call, derives entirely from crawl-time data, correctly warns that only BreadcrumbList's invalidCount is a per-type verdict and every other type is page-level, and documents the `notDerivable` section. This is far beyond what the annotations convey.

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 definition is long but front-loaded with the core purpose, then layered with caveats that each carry real weight (validity semantics, state handling, cost). It is dense rather than padded, though the cautionary sentences could be tightened slightly.

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?

With no output schema, the description carries the return-shape burden and does so: it describes typeGroups grouping, invalidCount, the `state` field with its values, and the `notDerivable` section. For a read-only report tool this is complete enough to call and interpret correctly.

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 `auditId` (optional, defaults to latest completed audit) and `projectId` (required) are already fully documented in the schema. The description adds no parameter-level detail beyond repeating the latest-vs-named-audit default, so the baseline 3 applies.

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?

States a specific verb+resource — a structured-data report grouped by schema.org @type for a project's latest completed crawl — and immediately contrasts it against cousins by naming the report's scope ('PRESENCE AND PARSE VALIDITY, NOT A RICH-RESULTS ELIGIBILITY CHECK'). An agent can distinguish it from other get_audit_* siblings without opening the schema.

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?

Gives concrete usage instructions ('ALWAYS narrow on `state` first') and explains what the `no_audit` and `analysed` states imply, including the critical note that `typeGroups: []` is a real finding, not withheld data. It does not explicitly route the agent away from sibling reports like get_audit_comparison, so it stops short of a full when-not rubric.

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?

Annotations declare readOnlyHint=false and openWorldHint=true but say nothing about cost or provider gating; the description fills both gaps by disclosing ~200-500 credit charges on the paid provider, unavailability on the free provider, and the SEO_DATA_UNAVAILABLE error semantics. This is exactly the context annotations cannot carry.

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 purpose, then cost and provider caveats — an efficient ordering. The closing remark about the absent spam-score column is editorial and slightly expendable, but it does preempt an agent expecting that field.

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?

With no output schema, the description still conveys the return shape (anchors with per-anchor counts), the billing model, provider availability, and the meaning of the SEO_DATA_UNAVAILABLE signal. Nothing needed to invoke or interpret the call correctly 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 description coverage is 100%, so every parameter (page, scope, target, pageSize, sortField, sortOrder) is already documented. The description adds only loose hints ('one page at a time', 'domain or URL') and no format or default details beyond the schema, so baseline 3 applies.

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?

States a specific verb+resource ('Anchor-text distribution for a domain or URL') and enumerates the payload per row (backlinks, referring domains, referring pages, dofollow). An agent can distinguish it from get_backlinks_overview or get_link_intersect without opening a schema.

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?

Gives clear motivating context for when it matters: revealing an over-optimised or hacked profile that is 'invisible link by link'. It also flags non-availability on the free provider. It stops short of naming an alternative tool for anchor data, so it earns a 4 rather than a 5.

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 adds substantial behavioral context beyond annotations: credit charges on the paid provider, the SEO_DATA_UNAVAILABLE error on the default free provider, the requirement to enable the Backlinks API for self-hosted deployments, and the critical distinction that the summary totals and referring-domain list count different populations. This goes well beyond the readOnly/openWorld/idempotent annotations.

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 return value in the first sentence, followed by tightly packed operational caveats. It is longer than average but each sentence carries distinct and necessary information about billing, availability, and result interpretation.

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 tool with no output schema and annotations that do not cover billing or provider behavior, the description supplies everything an agent needs: what is returned, cost, provider availability, error semantics, and a warning not to misinterpret the two result populations. Nothing essential 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 description coverage is 100%, so the schema already fully documents projectId, target, and scope. The description does not add parameter-specific syntax or format guidance, so the baseline score of 3 is appropriate.

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 states a specific verb and resource: returns a backlinks profile summary with total backlinks, referring domains, referring pages, rank, plus top referring domains by backlink count. It implicitly distinguishes this overview from sibling tools like get_backlink_anchors by focusing on the aggregate profile rather than detailed anchor text.

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?

It clearly explains when the tool is available versus unavailable, including the free-provider failure mode and self-hosted API prerequisite. It does not explicitly name a sibling alternative to use instead when the paid provider is unavailable, so it falls short of a full when/when-not/alternatives statement.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing that `today.lastRemain` is authoritative and null until the first push, and that `today.assumedDailyQuota` is a courtesy default rather than a real ceiling — genuinely useful behavioral context about the returned data.

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 purpose is front-loaded in the first clause, and the second clause spends its length on quota semantics that genuinely matter for interpretation. It is dense but every part is justified; the only minor weakness is the fragment-style opening rather than a clear verb.

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?

With no output schema, the description carries the burden of explaining returns, and it does so well for the quota fields (including the null-until-first-push behavior). It leaves the shape of the connection object itself implicit, but for a simple read tool this is nearly 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 description coverage is 100%, and the schema already documents projectId fully, including the 'Get one from list_projects' hint. The description adds no parameter-level meaning beyond that, so the baseline 3 for high-coverage schemas applies.

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 names a specific resource (the project's current Baidu Webmaster connection) and its additional payload (today's push-quota usage), which cleanly separates it from siblings like set_baidu_connection, disconnect_baidu, and submit_baidu_urls. An agent can identify this as the read-side counterpart without opening any schema.

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?

Usage is implied rather than stated: it's clearly the tool to call to inspect connection status and remaining quota, but there is no explicit when-to-use, prerequisite, or named alternative guidance. The quota explanation aids interpretation of results but is not routing 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?

Goes well beyond the annotations (which only cover read-only/idempotent/open-world safety) by disclosing that the call is FREE/zero-credit, requires BING_WEBMASTER_API_KEY, and returns structured failure modes ('not_configured', 'no_matching_site'). It also warns that some verified sites return empty results even when populated, a genuine edge case an agent cannot infer elsewhere.

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?

Dense but front-loaded: the identity and the get_bing_site_overview relationship come first, followed by cost/auth/error details. Every clause earns its place; only the trailing error-mode sentences make it slightly long for a two-parameter 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?

With no output schema, the description carries return-value disclosure itself by naming the { ok: false, reason: ... } shapes, and it covers cost, auth prerequisites, scope limits, and known false-empty behavior. Nothing an agent needs to invoke it correctly 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 description coverage is 100%, so both parameters (page, projectId) are already documented, including projectId's pointer to list_projects. The description adds no additional parameter meaning, so baseline 3 applies.

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?

States a specific verb (Get) and resource (own-site inbound-link page list for a project's matched Bing site) and explicitly positions it as the focused, single-call form of the backlinks field embedded in get_bing_site_overview. An agent can distinguish it from the broader overview sibling without opening either schema.

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?

Gives clear scope ('OWN-SITE ONLY') and explicitly rules out competitor/any-domain lookups, which is exactly the kind of when-not guidance that separates it from other backlink tools. It stops short of naming a specific alternative to use for competitor backlinks, so it is not a full 5.

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?

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds substantial context on top: it is free (no credits), requires a bring-your-own BING_WEBMASTER_API_KEY, returns structured { ok: false, reason } shapes ('not_configured', 'no_matching_site'), and discloses an unresolved upstream doc inconsistency about pageStats' `query` field.

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?

Information-dense and front-loaded, with the scoping sentence first and caveats after. The opening enumeration of five internal API method names is slightly verbose relative to what an agent needs, but every subsequent sentence (free tier, key requirement, null semantics, error shapes) 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?

With no output schema, the description carries the full burden of describing returns and it does so: which sections appear, when they are null, why, and the two failure reasons. An agent has everything needed to call and interpret the response.

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, but the description adds value beyond the schema by explaining the conditional-null semantics that link parameters to output sections — and crucially that a null section absent from `errors` means 'not requested,' not 'failed.' That meaning is not derivable from the parameter descriptions alone.

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?

States a specific verb and resource — per-query and per-page Bing search-performance detail for a project's matched site — and names the five underlying stat sections it composes. This clearly separates it from siblings like get_bing_site_overview, get_bing_url_info, and get_bing_keyword_research.

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?

Gives clear conditional guidance: queryTrafficStats/queryPageStats require `query`, pageQueryStats requires `pageUrl`, queryPageDetailStats requires both, and pageStats is always attempted. It does not, however, explicitly contrast when to call this versus get_bing_site_overview or get_bing_feed_details, so the routing is inferred from 'detail' rather than stated.

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?

Beyond the annotations (which already cover safety/idempotency), the description adds real behavioral value: no credit cost, the BING_WEBMASTER_API_KEY requirement, and two named failure modes with their reason strings. The return shape is only referenced indirectly ('the same Feed shape as one entry from Bing's GetFeeds list'), which leaves some ambiguity since that list isn't a visible sibling.

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?

One compact paragraph, front-loaded with the operation and its scope, then cost, auth, and error behavior in descending priority. Every sentence adds information; only the vendor-list reference slightly muddies the structure.

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?

With no output schema, the description carries the return-shape burden and does so only by reference to Bing's GetFeeds entry type. Auth, cost, and error states are covered, so an agent can invoke it correctly, but there is no pagination or response-field detail.

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% and both parameters are documented in the schema (feedUrl format/purpose, projectId sourcing from list_projects). The description adds no syntax, format, or constraint detail beyond what the schema already states, so the baseline of 3 applies.

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 names a specific verb+resource (fetch one Bing feed's details for a given feed URL) and scopes it precisely to 'one specific feed URL on a project's matched site.' This distinguishes it from siblings like submit_bing_feed (write) and list_bing_sites, and the title annotation reinforces the same framing.

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?

It gives clear operating context (free, read-only, BYO key) and the conditions that produce failure results ('not_configured', 'no_matching_site'), which help an agent anticipate prerequisites. It does not, however, explicitly state when to prefer this over alternatives such as get_bing_site_overview or when a feed URL is unavailable.

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?

Annotations already cover readOnly/openWorld/idempotent/non-destructive, and the description adds substantial behavioral value beyond them: size is FREE (no credits), it requires a bring-your-own BING_WEBMASTER_API_KEY, and it enumerates the exact error payloads (not_configured, no_matching_site). This is exactly the extra context an agent needs before calling.

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-loads what the tool returns before the API-key and error caveats, and every sentence carries information. Slightly dense with stacked clauses and em-dashes, but 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?

With no output schema, the description carries return-value burden and does reasonably well: it names the three data blocks returned and the failure responses. It doesn't detail the shape of the weekly history or related-query payloads, leaving a small gap.

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 all six parameters are already documented in the schema. The description adds only marginal meaning (date fields apply to keyword/relatedKeywords) which the schema itself already states, so the baseline 3 applies.

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?

States a specific verb+resource: real Bing impression data for a query, its weekly history, and related queries, naming the underlying GetKeyword/GetKeywordStats/GetRelatedKeywords methods. It distinguishes itself from derived/estimated keyword siblings by emphasizing Bing's own impression logs.

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?

Clearly frames the use case (real impression data vs derived/estimated metrics) and prerequisite (BING_WEBMASTER_API_KEY), giving the agent context for when this is the right choice. It stops short of explicitly naming an alternative sibling to use instead, so no exclusions are stated.

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?

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, and the description adds substantial non-redundant context: FREE/no credits, bring-your-own-key auth via BING_WEBMASTER_API_KEY, one key covering all verified sites, no per-project connect step, and the exact failure payloads ({ok:false, reason:'not_configured'} and 'no_matching_site'). These are the operational details an agent needs before calling and cannot get from annotations alone.

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?

It is a dense block, but it is front-loaded with the core purpose and each sentence carries distinct information (data scope, cost, auth, failure modes, boundaries). A slightly tighter grouping of the auth details could improve it, but 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?

With no output schema, the description compensates by enumerating returned data categories and documenting configuration failure modes. Combined with full annotation coverage and a fully-described single parameter, an agent has everything needed to invoke it correctly and interpret common failures.

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 (projectId) exists and schema description coverage is 100%, so the schema already carries the meaning including the pointer to list_projects. The description adds nothing specific about projectId beyond what the schema provides, matching the baseline-3 expectation for a fully-covered single param.

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 a specific verb+resource frame — 'Bing's own view of a project's domain' — and enumerates the exact data surfaces (daily performance, per-query stats, own-site inbound links, URL submission quota, crawl diagnostics, feeds). It also names the sibling tools it does NOT cover (get_bing_url_links, get_bing_url_info, get_bing_keyword_research), so an agent can separate it from its neighbors immediately.

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 routes per-URL lookup and keyword research to their own named tools, and states the own-site-only scope so the agent knows when this does not substitute for general backlink research. The when-to-use context (Bing Webmaster API data for a project's connected domain) is unambiguous.

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?

Goes well beyond the annotations (which only cover read-only/idempotent/open-world) by disclosing cost (FREE, no credits), the BYOK auth requirement (BING_WEBMASTER_API_KEY), and the exact failure payloads ('not_configured', 'no_matching_site'). This is exactly the operational context an agent needs before calling.

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 core purpose and scope are front-loaded, and the error/auth details are useful, but the single dense paragraph packs a lot together. Slightly long, though every clause carries information.

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?

With no output schema, the description carries the return-value burden and does so: it enumerates the metadata returned (anchor count, discovery/last-crawled dates, HTTP status, page classification) and describes the error object shapes. Auth prerequisites and cost are also covered.

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 all three parameters are already documented. The description reinforces includeChildren ('the same metadata for every URL Bing discovered under it') but adds no syntax or format 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.

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

States a specific verb (get index/crawl metadata) and resource (one URL on a project's matched Bing site), and even names the underlying endpoints GetUrlInfo/GetChildrenUrlInfo. It is clearly distinguishable from siblings like get_bing_url_links or get_bing_backlinks, which cover links rather than index/crawl 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 gives clear context for use and explicitly conditions the child-URL behavior on includeChildren. It does not, however, name alternatives or exclusions (e.g., when to prefer get_bing_url_links or inspect_urls instead), so routing is left partly to inference.

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?

Beyond the annotations (readOnly, idempotent, openWorld), it discloses cost ('FREE, no credits'), a prerequisite credential (BING_WEBMASTER_API_KEY), and two concrete failure envelopes ({ ok: false, reason: 'not_configured' } and 'no_matching_site'), plus the edge case of verified sites returning empty data. This is exactly the behavioral context annotations cannot carry.

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-loads the core identity ('GetUrlLinks: the inbound links...') and each subsequent sentence carries real information (cost, scope limits, key requirement, error shapes). It is dense and slightly run-on, but no sentence is 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?

With no output schema, the description compensates fully: it names the returned fields (anchor text + source URL) and the error response shapes, and flags the empty-result caveat. Nothing an agent needs to call or interpret this correctly 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 coverage is 100% — url, page, and projectId are all documented in the schema, including the 0-based pagination and the pointer to list_projects for the ID. The description adds no syntax or format detail beyond restating that it targets one specific page, so the baseline 3 is appropriate.

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?

States a specific verb and resource — inbound links (anchor text + source URL) pointing at one specific page on a project's matched Bing site — which distinguishes it from site-wide siblings like get_bing_backlinks and get_backlinks_overview. An agent can tell exactly what it fetches without opening the schema.

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?

Clear context: it's the per-URL Bing look, own-site only, with an explicit exclusion ('Bing exposes no competitor/any-domain backlink lookup'). It also warns that some verified sites return empty results. It stops short of naming the sibling alternatives an agent should use for competitor or site-wide backlink data, leaving that inference to the agent.

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?

Annotations cover safety (readOnly, idempotent, non-destructive) but say nothing about billing or cache behavior. The description adds the crucial nuances: polling is free on a cached result, but a scan whose cache expired (>~24h) re-runs the lookup and is charged and rate limited like a new scan. These cost/rate-limit disclosures go well beyond structured data and are consistent with the annotations.

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 purpose and status values, then cost semantics and the routing rule. Four dense sentences with parenthetical enumerations; the length is largely earned by the billing warning, though the status/result enumeration and the cost caveat could be tightened slightly.

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?

There is no output schema, so the description carries the return-value burden and does so: enumerated status values, the shaped result on success (share of voice, top cited pages, top prompts), and error.message on failure. For a 2-param polling tool, nothing an agent needs 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 description coverage is 100%, so both jobId and projectId are already documented in the schema. The description only restates that jobId comes from run_brand_radar_scan, adding no format or constraint detail beyond the schema. Baseline 3 is correct where the schema does the heavy lifting.

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?

States a specific verb+resource+scope: polls the status of a Brand Radar scan, keyed by jobId, and names its producer run_brand_radar_scan. An agent can distinguish it from the sibling scan-launch tool without opening either schema.

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 says to use this instead of re-running run_brand_radar_scan because the latter spends another monthly scan. It also gives an operational rule (collect results promptly, before the ~24h cache expiry) that tells the agent when polling is free vs. billable.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real behavior: no interpolation or back-filling, only scans that actually ran are returned, oldest-first ordering, and an explicit billing statement ('FREE — charges no credits').

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 sentences, front-loaded with what is returned before the comparison and the caveats. Each clause carries distinct information — payload, contrast with the sibling, empty/fill-in behavior, cost.

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?

With no output schema, the description carries the return-shape burden and does it reasonably well: it names the fields seen per scan and the ordering, and explains empty results as scans accumulate. It stops short of stating volume limits or pagination, a minor gap for a history endpoint.

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 target matching semantics, the YYYY-MM-DD pattern for since, and the projectId provenance ('Get one from list_projects') are already documented. The description adds no parameter-level detail beyond that, which is the expected baseline when the schema does the work.

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?

States a specific verb and resource ('recorded AI-visibility history for one brand or domain') and enumerates the payload ('mentions, cited sources and competitors'), plus the ordering ('oldest first'). It is immediately distinguishable from run_brand_radar_scan and from the status sibling.

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 names the alternative and the condition that selects it: 'Answers whether visibility in AI answers is moving, which a single run_brand_radar_scan cannot.' It also sets a when-not expectation by noting the result is empty for a target never scanned.

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?

Annotations cover the safety profile (readOnly/idempotent/openWorld), and the description adds substantial context beyond them: pay-per-call key budget consumption, required env-var credential, exact failure reasons ('not_configured', 'no_domain'), one API call per check, no pagination, and query-only with no submission API.

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 core purpose, and each sentence carries real information (pricing model, credential, error states, pagination limits). It is dense and the em-dash asides make it longer than strictly necessary, but nothing is 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?

With no output schema, the description compensates fully by describing the response contract: the engine marker on every success and the two failure reasons. For a paid, credentialed, single-call tool, nothing an agent needs to call it correctly 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 description coverage is 100%, so all seven parameters are already documented. The description reinforces semantics (targetDomain defaulting to the project domain, depth being Brave's ceiling, competitorDomains being free within the fetched set) but adds little that the schema does not already state; baseline 3 applies.

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?

States a specific verb and resource ('Checks where a project's domain ... ranks in REAL Brave Search results for one keyword') and immediately distinguishes itself from the server's free SearXNG/openserp-backed rank checks by naming the engine. An agent can tell it apart from other rank tools without opening the schema.

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?

Gives strong context: it is a PAID, bring-your-own-key tool requiring BRAVE_SEARCH_API_KEY, and it contrasts itself with the free-tier rank checks. However, it never names a specific sibling tool to use instead when the paid source is not wanted, so routing is inferred from category rather than an explicit alternative.

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds substantial context beyond them: it is FREE with no credit cost, it spends Google's per-property request quota and is rate limited per user, it requires GSC to be connected, the last ~3 days are excluded for data lag, dates are Pacific Time, ctr is a 0-1 fraction, position is a 1-based average, and it returns exactly one of four enumerated states with explicit branching guidance.

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?

It is dense and long, but front-loaded with the core purpose before the state enumeration, and nearly every sentence carries actionable content (free, rate limited, four states, timezone/lag caveats). The state list is essential rather than padding, though a few clauses could be tightened.

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?

With no output schema and no annotations covering return values, the description fully carries that burden: it explains the four states, clarifies that findings may legitimately be empty with coverage as proof (including truncated), warns against misreporting the three unmeasured states as 'no cannibalisation found,' and notes that thresholds ship with each report.

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 the schema already documents all three parameters, including the sort and window enums and the projectId source (list_projects). The description reiterates threshold context but adds no syntax or format detail beyond the schema. Per the rubric, a 3 is the correct baseline when schema coverage is this high.

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 states a specific verb and resource precisely: it finds queries where the project's connected Search Console property competes with itself, defined concretely as 'two or more of its own pages drawing impressions for the same query.' This is far more specific than a restatement of the name. It stops short of naming the sibling it is distinct from (e.g. list_rank_cannibalisation, which measures cannibalisation from rank data), so it is clear but not sibling-differentiating.

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?

It gives clear conditions for use: Search Console must be connected for the project, it is read-only and free, and it is rate limited per user via Google's per-property quota. It also states what the states imply and how to branch. It does not explicitly name an alternative cannibalisation tool or the condition that would select one over this, so it falls short of the explicit when-not/alternatives bar.

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?

Annotations already state readOnly and idempotent, but the description adds substantial return-behavior detail: newest-first ordering, omission of checks with no detected changes, the specific diff fields (line counts, sample, title/meta/status-code before/after), and an explicit non-fabricated similarity statement. This goes well beyond the safety annotations.

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 first sentence front-loads what the tool returns and its ordering, and the second sentence explains entry contents. Both sentences carry useful information, especially because no output schema exists.

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?

With no output schema and minimal annotations beyond safety, the description supplies the return-shape details an agent needs: ordering, excluded records, and the fields in each diff entry. It is complete for invoking the tool and interpreting results.

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 all three parameters are documented in the schema, including limit's default and cap. The description does not add new parameter syntax or format guidance, so baseline 3 is appropriate.

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 names the exact resource (detected changes for one monitored competitor URL) and its ordering (newest first), which distinguishes it from monitor-management siblings like list_competitor_monitors. It stops short of explicitly naming an alternative tool, so it is clear but not fully sibling-routing.

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?

Usage is implied: call this after obtaining a targetId to inspect that monitor's change history, and no-change checks are excluded. There is no explicit when-to-use condition or a named alternative to use instead, so guidance is only 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?

Annotations already declare the read-only/idempotent safety profile, but the description adds substantial behavior beyond them: no live Search Console call, rate limiting only against abuse, the Search Console connection prerequisite, and a three-state result contract with explicit branching instructions. This is exactly the kind of context annotations cannot carry.

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 purpose, then behavior, then the state-branching contract, and essentially every sentence earns its place. It is dense and slightly long, but there is little waste; the state-branch guidance in particular is load-bearing.

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