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

Annotations only give readOnly=false, openWorld=false, destructive=false. The description adds real behavioral context beyond them: immutable revision preservation, explicit budget consent, stable retry keys (idempotency), and a clear 'starts no paid baseline/provider work' guarantee. It stops short of describing atomicity or partial-failure 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, no padding, ending on the most decision-relevant exclusion. The opening sentence is the weakest element—vague filler ahead of the more informative behavioral clauses.

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, and the complex nested drafts payload is fully documented in the schema, so the description covers the important guarantees (immutability, consent, retry stability, no paid work). It does not address return/confirmation semantics or partial-acceptance behavior for a tool that accepts up to 20 drafts.

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%, including rich nested descriptions for drafts, provenance, and trust references, so the schema already carries full parameter meaning. The description adds no parameter-level detail beyond it, which is the expected baseline of 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?

"Manage project-scoped AI tracking" is a vague category verb that does not state the actual operation—accepting and saving suggestion drafts—even though the name and the drafts schema description do. It never distinguishes itself from siblings like suggest_ai_tracking_prompts, ai_tracking_suggestions_preview, or ai_tracking_suggestions_generate, which all concern the same AI tracking suggestion pipeline.

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?

No when-to-use guidance and no named alternative. "This does not start an automatic paid baseline" is a scope exclusion but not a tool-selection rule; it never explains when an agent should pick this over the preview/generate/suggest siblings.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, which already indicate a non-read, non-destructive mutation. The description adds little beyond 'Add' implying a mutation. It doesn't note idempotency behavior, duplicate handling, or label uniqueness despite having an idempotency_key parameter.

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 concise sentence, zero waste. Front-loaded with the core action. Could arguably add a bit more given the two undocumented params, but for its length it's efficiently written.

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 tool with no annotations describing side effects, no output schema, and 50% param coverage, the description is thin. It doesn't address duplication behavior despite an idempotency_key, what response is returned, or how it relates to list_competitors/remove_competitor workflow. Sibling tools suggest a competitor workflow the description fails to contextualize.

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 50% — the domain and project_id parameters have descriptions while label and idempotency_key do not (2 of 4 undocumented). The description mentions 'tracked competitor domain' and 'project' but adds no meaning beyond schema. With partial coverage, the description could compensate for the undocumented label and idempotency_key but doesn't.

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 'Add a tracked competitor domain to a project' uses a specific verb (Add) plus resource (competitor domain) and scoping (to a project). It clearly distinguishes from siblings like list_competitors and remove_competitor.

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?

No when-to-use guidance is provided. With siblings list_competitors and remove_competitor, there is no guidance on when adding vs removing/list is appropriate, nor whether a project must exist first or if there are limits on competitor count per project.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds context about optional attachments (tags, target URL, schedule) and the @language qualifier, but says nothing about idempotency or what happens on duplicate keywords despite an idempotency_key parameter existing.

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 with no filler, and the core action is front-loaded before the location guidance. The second sentence is dense but each clause carries real 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 13-parameter tool with nested per-keyword overrides and no output schema, the description only covers the headline features and one sourcing hint. It omits the string-vs-object keyword forms, per-keyword overrides, and the 500-item ceiling, leaving the agent to reconstruct much of the call from the schema alone.

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 only 38%, so the description has to compensate. It names tags, target URL, and schedule, and explains the @language qualifier for location_key, but leaves city, topic, device, intent, country, location and idempotency_key entirely unexplained beyond the schema.

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

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

States a specific verb and resource: 'Add one or more keywords to a project', and enumerates the optional attributes it accepts. It never distinguishes itself from nearby siblings like create_saved_keywords or research_keywords, so an agent must still infer which one applies.

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 concrete cross-tool workflow: 'Use search_locations and pass its location_key verbatim', which tells the agent how to source a required value. It stops short of saying when to use this tool versus create_saved_keywords or update_keyword, so no exclusions or alternatives 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?

Goes well beyond the annotations: discloses that generation is paid with no guaranteed maximum, that the idempotency UUID must be stable across retries, that outputs are unvalidated hypotheses with no measured popularity, and that saving requires a separate acceptance step. These are exactly the mutation-side behaviors an agent needs and none are in 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?

Two sentences, zero filler. The generation step and its constraints are front-loaded, and the acceptance caveat follows immediately.

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 taking a deeply nested frozen preview contract with no output schema, the description adequately conveys consent, idempotency, and non-persistence. It could say more about what the call returns (hypothesis objects/IDs) and its cost/confirmation behavior, but the core invocation contract is 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 the baseline is 3, but the description adds interpretive meaning: consent is explicitly 'paid consent', idempotency_key is the 'stable retry UUID', and preview is the 'exact reviewed preview' that must be reused on retries. project_id is not addressed in prose but is self-evident from schema.

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

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

States a specific verb and resource: generate editable hypotheses (prompts) from the reviewed preview. It signals its place in the preview → generate → accept chain, which differentiates it from siblings like ai_tracking_suggestions_preview and accept_ai_tracking_suggestions, though it never names those tools directly.

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 preconditions are given: it operates on the exact reviewed preview, requires explicit paid consent, and results are not persisted until separate acceptance. It stops short of explicitly naming the preview and accept sibling tools or stating 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 already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: it never calls a model, never reserves budget, and the estimate is not a guaranteed maximum. That is meaningful disclosure about side effects and result trustworthiness beyond 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?

Two tight sentences with zero filler. The intent (review before generation) is front-loaded and the cost disclaimer follows immediately, so nothing is 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?

For a read-only, non-destructive preview tool with a fully documented nested schema and annotations covering safety, this is close to complete. Its reference to an 'estimate' hints at return content despite no output schema. A slightly clearer statement of what the preview returns would close the last 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 every parameter is already documented in the schema. The description names the conceptual inputs (business context, competitors, model, market) but adds no syntax, formatting, or edge-case detail beyond what the schema provides. 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 title names it as a preview and the description implies the same with 'forecast.' It states it reviews business context, competitors, model, and market before generation, which is a specific scope. However, the verb 'Review' is slightly vague and it never explicitly names itself as a preview vs. the sibling 'ai_tracking_suggestions_generate', so an agent must infer the difference.

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?

'...before model generation' implies this is the pre-flight check to run prior to the generate step, which is useful sequencing context. But it never names the alternative tool (ai_tracking_suggestions_generate) or states when-not to use it. Usage is implied rather than made 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 readOnlyHint=false, openWorldHint=true, destructiveHint=false, and the description is consistent with them while adding real value: it flags the limited/non-representative dataset, the credit/BYOK requirement, the mandatory cost cap, and the write-scope auth need. It stops short of describing return format, pagination, or exactly how credits are spent, which keeps it from a 5.

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 the operation front-loaded and the constraints following. No filler, though the prerequisites sentence could be marginally tighter.

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 12-parameter paid-read tool with a fully documented schema and no output schema, the description covers the essential context: provider scope, dataset limitation, and credit/auth requirements. It leaves out how rows are returned or bounded, but the schema already covers limit/estimate_only, so 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%, so the schema already carries full parameter semantics and the baseline of 3 applies. The description adds only a passing reference to the two provider datasets and does not clarify the cost-cap or idempotency semantics beyond what the schema states.

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 ("Inspect") and resource ("provider-observed ChatGPT or Google AI Overview mentions and citations"), so the core operation is unambiguous. However, it offers no differentiation from the large AI-tracking family of siblings (compare_ai_prompts, get_ai_tracking_trends, list_ai_tracking_samples, export_ai_tracking_evidence), so an agent cannot tell from the description alone which one to pick.

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 discloses prerequisites (BYOK or deployment credits, explicit cost cap, project write scope) and a scope caveat (limited provider dataset, not all conversations), which is useful implied context. But it never states when to choose this over the sibling AI-tracking tools or when not to use it, leaving the selection decision 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?

Discloses behavioral traits well beyond annotations: cache misses spend the project's budget, successful snapshots are cached 24 hours, history_unavailable marks a cost-incurring history failure, unknown accounting yields a failed (isError) response with retained summary evidence that does not survive reload, and aggregate views are bounded to fetched rows.

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 cost/scope requirement is front-loaded and every sentence carries decision-relevant information about budget, caching, and failure modes. It is dense but appropriately sized for a tool with this much conditional behavior.

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

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

For a write-scope, budget-spending tool with no output schema, the description covers cost implications, caching, partial-failure semantics, response evidence, and the estimate/guard workflow. An agent has everything needed to call it safely 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: estimate_only is a free provider-free dry run, max_cost_cents is only a best-effort guard (not a hard cap), and result rows carry a 'within fetched rows' caveat for aggregation.

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 (analyze) and resource (backlinks) scoped to a target domain or page, using the project's provider budget. The purpose is unambiguous, but it does not name sibling tools like estimate_backlinks_cost or load_more_backlink_rows to distinguish itself 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?

Gives actionable workflow guidance: run with estimate_only first as a free dry run, then use max_cost_cents as a best-effort guard, and compute aggregates from fetched rows only. It lacks explicit when-not-to-use guidance or routing to the separate estimate_backlinks_cost sibling.

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 declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds the substantive behavioral facts an agent needs: an API write scope is required, a cache miss can consume the project's own DataForSEO budget, every call requires an explicit cost cap, and fresh never removes that cap. That is exactly the kind of cost/auth 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?

Four sentences, all earning their place, with the budget/scope warning front-loaded. Dense but not redundant; a little more framing on what the report contains would improve readability.

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 sketching the three possible return shapes (estimate, cached report, charged report). Combined with the cost-cap and scope guidance, an agent has enough to call it correctly, though the composition of the report itself is only loosely described.

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 real meaning on top: it explains the estimate_only + max_cost_cents=0 pairing for a free estimate and clarifies that fresh bypasses cache without lifting the cost cap. These cross-parameter interactions are not spelled out in the schema.

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

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

The description conveys that this is the paid Domain Overview analysis that returns an estimate, a cached report, or a report with charged keyword and page module outcomes, which is a specific verb+resource. It stops short of naming the sibling tools (estimate_domain_overview_cost, load_domain_overview_keywords/pages) that a reader would compare against, so differentiation is implied rather than explicit.

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

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

It gives a concrete recommended workflow: call with estimate_only=true and max_cost_cents=0 first for a free estimate, and notes fresh=true bypasses cache. It does not explicitly say when to prefer estimate_domain_overview_cost or the load_domain_overview_* readers over this tool, so exclusions are absent 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 and readOnlyHint=false, so the safety profile is covered. The description attempts context ('Preserve immutable revisions, explicit budget consent, and stable retry keys') but this phrasing is opaque about what archiving actually does to the prompt, its revisions, or associated runs — no reversibility, scope-of-effect, or consequence is disclosed.

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?

Only three short sentences, so it is not bloated, but the opening is a generic filler line and the actual action is never front-loaded. The 'preserve/consent/retry keys' clause reads as boilerplate rather than earned content.

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 archive operation with no output schema and no annotations beyond the destructive hint, the description should explain what archiving entails (soft delete vs. hard, effect on revisions/runs, reversibility). Instead it is vague and does not tell the agent what to expect after calling 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 description coverage is 100% and both params (project_id, prompt_id) are self-documented with patterns and scope notes. The description adds no parameter 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 name and title say 'archive_ai_tracking_prompt', but the description opens with the generic 'Manage project-scoped AI tracking' without ever stating that the tool archives a prompt. It restates a broad domain rather than the specific verb+resource, so it adds nothing over the title and is arguably less precise than the 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?

No when-to-use guidance, no prerequisites, and no alternatives named — even though obvious siblings exist (archive_ai_tracking_topic, archive_ai_tracking_schedule). The only directional hint is the negative 'This does not start an automatic paid baseline', which is narrow and does not route the agent between archiving 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 readOnlyHint=false, so the agent knows this mutates/destroys state. The description does not say what archiving does to the schedule, whether it is reversible, or what permissions are required; the vague 'Preserve immutable revisions, explicit budget consent, and stable retry keys' is not actionable and could even read as reassuring in a way that muddies the destructive framing. Only the 'no automatic paid baseline' line adds concrete behavioral value.

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?

At three sentences it is not bloated, but the middle sentence ('Preserve immutable revisions, explicit budget consent, and stable retry keys') is opaque boilerplate that earns no place, and the vague opener is front-loaded where the action verb should be. Under-specification disguised as conciseness.

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 mutation with no output schema, the description should at minimum explain what archiving means (soft vs. hard, reversibility, effect on associated runs/prompts). None of that is present, leaving the agent with the vague 'Manage...' framing plus annotations to infer the rest.

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?

Both parameters (project_id, schedule_id) are fully documented in the schema with patterns and scope notes (100% coverage), so the schema carries the burden. The description adds nothing about parameter meaning, which is acceptable but no better than 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?

The description opens with 'Manage project-scoped AI tracking,' a vague verb+domain that never states what the tool actually does to a schedule. Only the title and tool name ('archive_ai_tracking_schedule') convey the archiving action; the description itself is closer to marketing framing than a statement of function, and it does not distinguish itself from update_ai_tracking_schedule or archive_ai_tracking_prompt.

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 when-to-use guidance, no mention of siblings like update_ai_tracking_schedule (the non-archiving alternative), and no prerequisites. The only routing-adjacent sentence is the negative disclaimer 'This does not start an automatic paid baseline,' which hints at a side effect rather than when this tool should be chosen.

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 readOnlyHint=false, so the safety profile is known, but the description does not disclose what archiving destroys, whether it is reversible, or what it does to related prompts/runs. 'Preserve immutable revisions' hints at retention but is not tied to the archive action, and the budget/retry-key sentence reads as unrelated boilerplate.

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, but they are not front-loaded with the actual operation and none of them explain archiving. The content is brief yet mostly filler, so it fails the 'every sentence earns its place' test despite its size.

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, non-open-world mutation with no output schema, the description should at minimum say what gets archived and what happens to dependent entities. Instead it omits the core action entirely, leaving the agent under-informed about a destructive call.

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 topic_id and project_id both documented (patterns and scope enforcement). The description adds no format, syntax, or scoping meaning beyond that, 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?

The name says 'archive_ai_tracking_topic', but the description never mentions archiving or topics. It opens with the vague 'Manage project-scoped AI tracking' and spends its remaining sentences on 'immutable revisions, explicit budget consent, and stable retry keys', which do not describe what this tool does. A sibling-aware agent cannot distinguish it from create/update/list_ai_tracking_topic on the description alone.

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

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

No when-to-use guidance is given relative to update_ai_tracking_topic or archive_ai_tracking_prompt. The only conditional clause, 'This does not start an automatic paid baseline', is a narrow exclusion about billing rather than a routing rule, so the agent still cannot tell when archiving is the right call.

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 readOnlyHint=false, so the mutation nature is established. The description adds the scope (applies to every supplied keyword id) but doesn't disclose side effects like whether delete is permanent, whether partial failures occur, or rate limits on 500-keyword batches. With destructiveHint already set, the description adds modest value.

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 sentence, front-loaded with the operative verb, and lists operations efficiently. No wasted words, though it could arguably add one sentence on per-operation parameter requirements without bloat.

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

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

The tool has 8 parameters with a nested 'schedule' object and no output schema, and the description covers only the operation dimension. It doesn't clarify which parameters apply to which operations (e.g., set_frequency uses frequency or schedule?), nor disclose behavior when incompatible params are passed alongside an operation. For a multi-mode mutate tool, more behavioral specification is warranted.

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 63%, so the schema documents most parameters including operation enum values, frequency enum, target_url, and idempotency_key format. The description adds mild value by naming the operation types in prose, but the description-to-operation mapping isn't explicit (e.g., no statement that 'add_tags' requires the tags param). The 37% uncovered schema surface (schedule nested object, jitter_minutes) isn't compensated by description detail.

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

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

Description uses a specific verb+resource ('Bulk mutate keywords') and enumerates the exact operation types (adding tags, removing tags, setting frequency, setting target URL, deleting). It distinguishes from siblings like update_keyword (single) and set_keyword_target_url, though it doesn't explicitly name a distractor 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?

The word 'Bulk' implies this is for many keywords at once versus single-keyword siblings, providing implicit usage context. However, no explicit guidance is given about when to use this vs set_keyword_target_url or update_keyword, nor any mention of required project_id context or alternative tools for single-keyword operations.

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 establish the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description's job is to add context like what gets halted, whether cancellation is undoable, and how run_id/retry keys behave. Instead it offers opaque phrases ('preserve immutable revisions, explicit budget consent') that don't clarify the effect of a cancel and add little over 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?

It is short, but it is not front-loaded: the actual action never appears, and the three sentences are jargon-heavy clauses that don't earn their place. The negative 'does not start an automatic paid baseline' is filler that consumes space without conveying usable 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 mutation tool with a rich AI-tracking sibling set, the description should explain cancellation semantics (idempotency, state transition, relation to retry keys), but it omits all of this. The schema covers inputs fully, yet the behavior of the operation remains unexplained, leaving an agent unable to predict the outcome.

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 params (project_id, run_id) are fully documented with patterns in the schema, so baseline 3 applies. The description adds no additional meaning about the identifiers or their scope beyond what the schema already states.

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 says only 'Manage project-scoped AI tracking', which never identifies the actual action (canceling a run). The specific verb+resource exists only in the tool name/title, so the text is essentially a vague restatement of the namespace rather than a purpose statement. It does not distinguish itself from create_ai_tracking_run, retry_ai_tracking_run, or get_ai_tracking_run.

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 when-to-use guidance and no mention of sibling alternatives such as retry_ai_tracking_run or get_ai_tracking_run. The only scoping sentence ('does not start an automatic paid baseline') is a confusing non-exclusion that doesn't tell an agent when to pick this tool.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses substantial behavior: it requires either a guaranteed hard cap or explicit actual-cost consent with an advisory estimate limit, requires project write scope, and warns the tests are synthetic rather than observed visibility. This is exactly the kind of cost/auth/caveat 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?

Three tight sentences, front-loaded with the primary action, then the visibility caveat, then the requirements. No waste, though the requirements sentence stacks two distinct constraints and could be split for cleaner scanning.

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 17-parameter tool with a complex oneOf cost model, no output schema, and no cost-relevant annotations, the description covers the essential cost-consent, scope, and caveat context and even sketches the return content (answers, brand mentions, citations). It stops short of the idempotency/retry semantics, but those are covered in the 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?

Schema description coverage is 100%, so every parameter (cost_policy, max_cost_cents, estimate_credentials_ref, etc.) is already documented in the schema. The description restates the cost-policy concept at a high level but adds no parameter-level detail beyond what the schema 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 (run the same synthetic prompt against supported models and compare answers, brand mentions, citations) and explicitly carves out what it is not ('not observed ChatGPT/AIO visibility'), which separates it from the ai_tracking and ai_visibility siblings. An agent can tell what this does 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 'not observed ChatGPT/AIO visibility' line gives clear context for when this tool is the wrong choice versus observed-visibility tools, and the cost/scope prerequisites are stated. However, it never names a concrete alternative sibling to route to, so the when-not guidance 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 cover the safety profile (readOnlyHint=false, destructiveHint=false), and the description adds real behavioral value beyond them: priority=0 renumbers existing providers, omitted priority preserves a reconnected provider's place, and primary=true is a deprecated alias that promotes priority 0 while primary=false is a no-op. It does not mention idempotency behavior despite having an idempotency_key parameter, which is the main gap.

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 action is front-loaded and the dense semicolon-clauses are packed with provider-specific detail rather than filler. It is long but nearly every clause conveys a distinct fact; slightly more structure (e.g., separating the priority rules) would improve scanability.

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 mutating tool with a nested credentials object, no output schema, and low schema coverage, the description supplies the provider-specific knowledge an agent could not infer from the schema. Missing pieces are secondary: idempotency semantics, what enabled/cost_per_check do, and any return/verification guidance.

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 only 30% schema description coverage across 10 parameters, the description must compensate, and it does for credentials.login, credentials.api_key, credentials.endpoint, priority, and primary. However, top-level login, secret, enabled, cost_per_check, and idempotency_key are left entirely unexplained in both schema and description. Partial compensation, not full.

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: 'Connect or update credentials for a project provider,' then enumerates the valid provider ids by category (dataforseo/serpapi vs ga4/gsc/plausible). It is clearly distinguished from credential-unrelated siblings such as update_provider_settings and disconnect_provider by focusing on credentials, though it never names those alternatives 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?

Gives concrete operational context: which providers accept which credential fields, when credentials.login defaults to the project domain, when endpoint is needed, and how priority behaves for reconnected vs new providers. It does not state when to prefer this over test_provider_connection or update_provider_settings, so it stops short of explicit 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the bar is lowered. The description adds real context beyond them: the deep link inherits existing project access controls, and three producer kinds (site_audit, ai_visibility, prompt_explorer) are reserved and rejected. It does not describe what a successful save returns or any rate limits.

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 with no filler, and the core action is front-loaded in the first sentence. The reserved-kind clause is compressed but readable; a slightly more explicit framing of the access-control note would improve it, but nothing is wasted.

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

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

For a write tool with nested objects, no output schema, and 6 parameters, the description covers the important behavioral context: access-control inheritance and the reserved-kind rejection. Remaining gaps (return shape, idempotency semantics) are handled by the schema descriptions, so the definition is close to 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%, so the schema already documents kind, body size limits, project_id enforcement, provenance and idempotency_key. The description's mention of provenance and the reserved kinds largely repeats what the kind parameter description already states. 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: saving an agent analysis (report), with a qualifier about provenance. It is clearly distinguishable from siblings like get_agent_report and list_agent_reports. It does not explicitly name those siblings, but the create-vs-read distinction is unambiguous from the wording.

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: this is where an external agent persists an analysis it produced. The reserved-kind sentence tells the agent when this tool will reject a call, which is useful, but there is no explicit when-to-use/when-not or routing to an alternative tool (e.g., get_agent_report for retrieval).

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 (write, non-destructive, closed-world), the description discloses that revisions are immutable, that explicit budget consent is involved, and that no automatic paid baseline is started. These are real behavioral traits not present in the structured fields. Some phrases ('budget consent,' 'stable retry keys') are cryptic and map to no schema field, which weakens the clarity but does not negate the 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?

Three short sentences with no padding, which is good. However, it front-loads the vaguest sentence ('Manage project-scoped AI tracking') and the middle sentence is a cryptic list that does not clearly connect to creating a prompt. Efficient but not well-structured around the actual action.

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

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

This is a create mutation with eight parameters, nested provenance objects, and no output schema. The description covers the immutability/cost angle but says nothing about what is created or how the generation_reference / provider_dataset_reference provenance objects are expected to be supplied. The rich schema (88% coverage) and annotations carry most of the weight, leaving this just adequate.

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 88%, so the schema already documents nearly all eight parameters (text, label, paused, category, topic_id, project_id, and the two nested provenance objects). The description adds no parameter-level meaning, so the baseline 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 tool name signals creation, but the description opens with the generic verb 'Manage project-scoped AI tracking,' which does not actually state that a prompt is created. It never distinguishes this tool from its obvious siblings update_ai_tracking_prompt, archive_ai_tracking_prompt, or list_ai_tracking_prompts. An agent can infer the purpose from the name but the description itself is vague.

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 when-to-use guidance and no named alternative (e.g., update vs create vs archive). The only usage-relevant statement is the negative scope note 'This does not start an automatic paid baseline,' which clarifies cost behavior but not tool selection. This is essentially no 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 it is a non-read-only, non-destructive, open-world mutation, so the safety bar is partly met. The description adds genuinely useful context beyond that: paid provider work requiring "explicit budget consent," immutable revisions, and stable idempotent retry keys. It stops short of explaining permissions or what happens on retry with a changed payload, but the consent/idempotency disclosure is real added value.

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 with no padding, so it is appropriately sized. However the leading sentence is near-filler ("Manage project-scoped AI tracking") and the most decision-relevant point (this launches paid work) is buried in the trailing clause, so front-loading is weak.

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 12-parameter, 10-required mutation with no output schema, the description conveys the consent/idempotency theme but omits the critical preview-first workflow (budget_revision, consent_revision, credential_version all "returned by preview") and any notion of the response. The rich schema compensates for parameter detail, but the dependency chain an agent must follow is left unstated.

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 including the consent const, revisions, and idempotency_key is already documented in the schema. The description loosely echoes these concepts ("immutable revisions, explicit budget consent, stable retry keys") but adds no format or constraint 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?

The opening verb is generic ("Manage project-scoped AI tracking") rather than stating that this creates a run; the create-specific intent is only inferable from the title and from clauses about revisions/consent. The closing line ("does not start an automatic paid baseline") does help scope it against an auto-launch path, but a sibling like preview_ai_tracking_run is never named for contrast. Purpose is roughly clear but not sharply stated.

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 guidance or named alternative. The schema repeatedly references values "returned by preview," implying preview_ai_tracking_run must be called first, yet the description never states this prerequisite or when to choose this tool over retry/cancel/schedule siblings. Only a faint negative scoping ("not an automatic paid baseline") 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 only establish that this is a non-read-only, non-destructive write with no open-world effect. The description adds real behavioral context beyond that: immutable revisions are preserved, budget consent must be explicit, and the operation is idempotent via stable retry keys. It also clarifies that no paid baseline auto-starts, which complements the schema's enabled=false default.

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, front-loaded sentences with no padding, which is structurally sound. However, the first sentence spends its budget on a vague verb phrase instead of the actual create action, and the "stable retry keys" claim points at functionality not represented anywhere in the schema.

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 8-parameter tool with a deep nested configuration object, a required preview-derived revision set, and no output schema, the description omits the prerequisite workflow (obtain budget/consent/credential revisions via preview) and any reference to the sibling that performs it. The description leaves the agent without the context needed to call this correctly on the first attempt.

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 nested configuration object documents every field (budget_revision, consent_revision, credential_connection_id, etc.), so the schema does the heavy lifting. The description's "explicit budget consent" loosely maps to the consent parameter, but "stable retry keys" references no parameter in the schema, adding noise rather than meaning.

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 "Manage project-scoped AI tracking," a generic verb that does not match the tool's actual action (creating a schedule) and does not distinguish it from siblings like update_ai_tracking_schedule, archive_ai_tracking_schedule, or create_ai_tracking_run. Only the name/title conveys the create-schedule action; the prose itself never states it.

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?

"This does not start an automatic paid baseline" is a useful negative scope statement, but there is no guidance on when to call this versus preview_ai_tracking_run, update_ai_tracking_schedule, or list_ai_tracking_schedules, and no stated prerequisite (e.g. that a reviewed preview must be obtained first). Usage must be inferred entirely from the schema.

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 (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds some behavioral context, notably that no automatic paid baseline is started, which sets cost expectations for this mutation. However, 'immutable revisions, explicit budget consent, and stable retry keys' is cryptic jargon that doesn't clearly tell the agent what side effects or prerequisites to expect.

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 with little padding, and the negative cost statement is placed last. However, the middle sentence is dense, abstract jargon whose wording doesn't earn its place by informing the caller about this specific 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 create mutation with no output schema and fully documented parameters, the safety profile is covered by annotations. What is missing is downstream context: what a 'topic' scopes (prompts, schedules, runs) and how it relates to the surrounding ai_tracking tool family. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so all four parameters (project_id, name, paused, description) are documented in the schema. The description adds nothing about parameter formats or constraints, 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 opens with 'Manage project-scoped AI tracking,' which is a vague verb rather than the create action the name implies. It never states that a new topic is being created, nor does it distinguish itself from update_ai_tracking_topic or list_ai_tracking_topics. Only the name/title carry the actual purpose.

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 when-to-use guidance and no mention of alternatives such as update_ai_tracking_topic or archive_ai_tracking_topic. The single negative statement ('does not start an automatic paid baseline') hints at a cost boundary but is not framed as a selection criterion against siblings.

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

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

Annotations confirm this is a non-read, non-destructive mutation (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It does not state whether channels default to something, whether idempotency_key guarantees deduplication behavior, whether unmapped conditions silently ignore irrelevant parameters, or what the response contains. For a create operation with no output schema, this is thin behavioral disclosure.

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-sentence description is concise, but it is under-specified rather than efficiently specified. It provides a topical overview without the operational detail needed for a tool with 16 parameters and 10 condition enums. Conciseness is earned by packing the right info tightly, not by brevity alone.

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

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

Given the tool's complexity (16 params, 10 condition_type enums, condition-specific parameter couplings) and low schema coverage (25%), the description should map conditions to their relevant optional parameters and explain cross-field dependencies. It does none of this. The absence of this mapping makes the tool hard to invoke 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 only 25% (most params are undocumented), and the description mentions only the four trigger categories. It does not explain which parameters apply to which condition_type (e.g., change_pct applies to change_pct condition, drop_positions to position_drop, competitor_domain to competitor_overtake, serp_feature to serp_feature), which is the essential semantic mapping for correctly invoking this tool. The description adds no parameter-level guidance beyond naming the trigger types.

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 clear verb+resource ('Create an alert rule') and enumerates the specific trigger categories: project rank changes, thresholds, SERP features, or competitors. This distinguishes it from sibling tools like create_webhook and create_signal. However, it doesn't name alternative events or clarify that these categories map to specific condition_type enum values.

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?

No guidance on when to use this vs update_alert_rule, list_alert_rules, or delete_alert_rule. The description doesn't specify prerequisites such as needing a valid project_id or recipient_ids configuration, nor does it clarify how condition_type interacts with the optional parameters. With 16 parameters and many sibling alert tools, the lack of selection context is a notable gap.

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 (readOnlyHint=false, destructiveHint=false) partially cover the safety profile. The description adds valuable behavior: 'The raw token is returned once in the response and cannot be retrieved again; store it securely.' This is important operational context beyond the annotation declarations. No contradiction with annotations since readOnlyHint=false aligns with a create/mutation operation.

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, efficient and front-loaded with the core purpose followed by the critical security note. No redundant phrasing or filler. Slightly more could be said about idempotency or scope selection, but the current length is well-balanced.

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 create tool with 5 params (80% schema-covered), no output schema, and readOnlyHint=false, the description covers the key behavioral risk (one-time token return). It doesn't detail the response shape, but for a creation tool without an output schema this is acceptable. Could note that scopes map to access tiers, but the schema enum already covers that.

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 80%, so most parameters (name, scope, project_id, expires_in_days) carry inline documentation. The description adds the critical warning that the token is one-time-returnable, but doesn't address idempotency_key (which has no schema description) or add semantics beyond what the schema provides. Baseline 3 is appropriate; no major compensation needed.

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

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

Clear verb+resource: 'Create a new API key for the authenticated project.' It distinguishes itself from sibling tools like create_project_api_key, create_personal_token, and revoke_api_key by clarifying it creates keys for 'the authenticated project,' though it doesn't explicitly differentiate from list_api_keys or the project-scoped variants.

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 implies usage via 'for the authenticated project' but doesn't explicitly state when to choose this over create_project_api_key or create_personal_token, nor explain the distinction between API keys and personal tokens. Given the large sibling set with overlapping create-key tools, this is a notable gap — no exclusions or alternative 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 only declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, leaving the description as the primary behavioral disclosure source. The description usefully discloses that the raw token is returned only once (a critical one-time-visibility behavior) and that admin permission is required. These add real value beyond 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?

Two sentences, zero wasted words. Every sentence earns its place: one states the purpose, the other discloses the critical one-time-return behavior and the admin prerequisite.

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 token creation tool with no output schema referenced, the description covers the key behavioral facts: single-return of raw token, admin requirement. With 4 parameters and low schema coverage, it could have elaborated more on scope/expiration semantics, but the essential agent decision-making info is present.

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 only 25% (only 'name' has a description). The description adds the crucial semantic that the returned value is a raw account-wide token visible only once, which helps understand parameter intent. While it doesn't detail expires_in_days or scope semantics specifically, the description compensates somewhat for the low schema coverage by explaining the token's nature.

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

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

The description clearly states 'Create a personal access token' with a specific verb and resource. It distinguishes from siblings like revoke_personal_token and list_personal_tokens, though it doesn't explicitly name them.

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 mentions 'Requires an admin PAT' which gives a prerequisite, and the context of 'raw account-wide token returned once' implies single-use visibility. However, it doesn't explicitly state when to use this vs create_api_key or create_project_api_key, which are closely related siblings.

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

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

Annotations declare readOnlyHint=false, which correctly signals this is a write operation, and the description confirms it with 'Requires a personal access token with write scope.' However, the description doesn't disclose what happens on successful creation (returned project ID?), whether projects are immediately active, or whether the domain must be verified. With minimal annotation coverage (no openWorldHint or destructiveHint context), the description carries moderate burden but only covers the auth angle.

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 with no wasted wording. The description is appropriately brief and the key behavioral caveat (write-scope token) is front-loaded with the core action. It earns its place without fluff.

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 creation/mutation tool with no output schema and only 50% parameter coverage, the description is underdeveloped. It doesn't state what a successful creation returns, how to reference the new project afterward, why idempotency_key matters, or what domain validation/tracking entails. Among 100+ siblings, the description provides insufficient context for an agent to correctly create a project and use 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 description coverage is 50% — name and domain have descriptions, but tracking_scope and idempotency_key have NO descriptions. The description adds nothing about these undocumented parameters. tracking_scope's enum (city/country) leaves the agent guessing what it filters. idempotency_key is a critical semantic concept (deduplication) that the description doesn't explain at all, and the description doesn't compensate for this 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?

The description states 'Create a project' which identifies the action and resource, but it doesn't specify what creating a project entails or how it differs from similar creation tools among siblings (create_saved_view, create_signal, create_webhook, etc.). The verb+resource is clear but the scope and nature of a 'project' (a core entity with domain tracking) isn't elaborated.

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?

No guidance on when to use this tool or what prerequisites/context are needed beyond the auth note. The description doesn't mention that this is typically a foundational setup step, when to use tracking_scope, or contrast with update_project/delete_project for lifecycle management. It only mentions the auth requirement, not usage context.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, which is sparse. The description adds meaningful context: 'The raw key is returned once' — a critical behavioral fact warning the agent that the secret cannot be retrieved again after creation. This is valuable transparency beyond 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?

Two sentences, zero waste. 'Create a project-scoped API key for CI or automation' plus the critical one-time-return warning. 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?

The tool is a mutation (creates a resource) with no output schema, no enums, and moderate complexity (3 params). The description captures the essential purpose and the one-time-return caveat, but doesn't explain the idempotency_key semantics, what happens if creation fails/duplicates, or whether this key can be revoked via a sibling tool (revoke or list_project_api_keys). Given the annotation sparseness, a bit more context would help.

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 67% (2 of 3 params documented). The description mentions 'project-scoped' which implies project_id is required, and says 'raw key returned once' indicating creation semantics. However, it adds little beyond the schema for the two documented parameters, and idempotency_key (the one undocumented param) gets no additional explanation in the description despite being non-obvious in purpose.

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

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

The description clearly states the verb+resource (create a project-scoped API key) and purpose (for CI or automation), which distinguishes it from 'create_api_key' (likely a general API key creator) and 'create_personal_token'. It doesn't explicitly call out sibling differentiation but the 'project-scoped' scoping does differentiate it.

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 key is for 'CI or automation' which gives some sense of when to use it, but it doesn't provide exclusions or explicitly mention alternatives like create_api_key or create_personal_token. No guidance on when NOT to use this tool versus the other key/token creation tools is given.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait: duplicates that are already tracked or saved are silently skipped rather than erroring. It does not mention auth needs, rate limits, or the 500-item cap.

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, with the core purpose front-loaded and the dedup rule immediately following. 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 create tool with annotations covering safety and a schema covering params, the description covers purpose and idempotency, which is adequate. It omits what a successful call returns and the 500-item batch limit, which an agent would want before a bulk save, and there is no output schema to fill that 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 67%, and the schema itself documents keywords and project_id (including the prj_ pattern and a pointer to list_projects). The description adds no parameter-level detail beyond restating 'keyword ideas', so the baseline 3 for a mostly self-documenting schema 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 (save) and resource (keyword ideas) and adds a scope qualifier ('without starting paid rank tracking') that implicitly separates it from add_keywords. However, it never names the sibling it differs from, so the differentiation relies on the reader inferring the contrast with rank-tracking 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?

The 'without starting paid rank tracking' phrasing implies the use case (research-only keyword storage), and the skip rule implies re-running is safe. But there is no explicit when-to-use vs add_keywords/research_keywords guidance and no prerequisites 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 include readOnlyHint=false, openWorldHint=false, destructiveHint=false, meaning this is a mutating but not destructive operation within a bounded API. The description does not describe side effects (e.g., whether creating a view overwrites an existing one, whether validation rejects the request, response behavior). Given the readOnlyHint=false already signals mutation, the description adds the validation note but little else about behavioral effects.

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

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

The description is compact and front-loaded, getting to the point in the first sentence. The second sentence adds useful validation context. It is appropriately sized for the tool's complexity, though it could be slightly more organized.

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

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

Given the complex nested config schema with two variants (keywords vs competitors surfaces), the description is reasonably complete. It lacks details about return values but there is no output schema, so some expectation explanation would help. The dual-surface ambiguity mentioned in purpose is the main completeness 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 80%, so the schema documents most parameters well (project_id, name, config). The description adds value by enumerating known valid values for the country/serp filters within config, which is genuinely useful context beyond the schema. The idempotency_key parameter is not described in the schema and remains unexplained, a minor 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?

The description states the tool creates a saved keyword view for a project, using a specific verb+resource. However, the input schema shows the config can represent two surfaces (keywords or competitors), yet the description only mentions 'keyword view' and the surface parameter permits both 'keywords' and 'competitors'. This creates slight ambiguity about whether it also creates competitor views.

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 provides helpful known-valid values for country and serp filters, which acts as implicit usage guidance. However, it does not distinguish this from siblings like create_alert_rule, list_saved_views, or explain when a saved view should be created vs. other operations. No explicit when/when-not 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 readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds useful constraints like the 8KB payload limit and the source/type validation rules, plus the happened_at default-to-now behavior. But it doesn't fully disclose the full behavioral surface for a mutation tool - e.g., whether idempotency is guaranteed, any rate limits, or what happens on duplicate signals.

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?

A single compact paragraph that front-loads the core purpose, then efficiently lists the optional parameters with their types and defaults. Every sentence earns its place; there's zero padding. The enum constraints and format examples are packed into a concise but complete description.

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 create-type tool with 9 params (only 2 required), the description covers the essential semantics well: required source/type constraints, optional happened_at, url, severity, and payload limits. It would benefit from noting whether idempotency_key provides deduplication guarantees, but given the high schema coverage (89%), enums on 2 params, and default behaviors documented, the completeness is strong for the tool's complexity.

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 high at 89%, so the schema carries most of the parameter documentation weight. The description adds value by explaining the 'type' pattern examples ('deploy.completed', 'cms.page_updated'), source enum values, and specifying event context. However, it doesn't elaborate on the idempotency_key purpose or keyword_id semantics beyond schema, which the schema describes reasonably well.

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

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

Description uses a specific verb+resource ('Ingest a signal') and clearly defines the resource as an external event (deploy, CMS content change, or custom API event) explaining ranking movements. It distinguishes itself from sibling tools by its unique purpose of creating signals versus reading/searching them (list_signals exists as 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?

The description clearly states it's for ingesting external events that may explain ranking movements, giving concrete examples (deploy, CMS content change, custom API event). It implies this is for signaling the system about external events but doesn't explicitly contrast with alternatives or state when NOT to use it. However, the sibling list_signals clearly pairs with it, and the 'key-scoped project' scoping gives context.

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

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

Annotations already declare this is a non-read-only, non-destructive, open-world write, so the safety profile is covered. The description adds nothing beyond that — it does not say an invitation email is dispatched, what happens when the user is already a member, or how idempotency_key affects retries, which are the behavioral details an agent would actually need.

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?

A single tight sentence with the action front-loaded and no filler. It is efficient, though it is arguably too terse given the mutation it performs and the untapped room for routing guidance.

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 tool with no output schema, four parameters, and an unexplained idempotency key, the description is under-specified. It omits the side effect (email sent), the behavior for already-existing members, and any distinction from resend/update siblings, leaving the agent without enough to invoke it confidently.

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 75%: email, project_id, and role all carry schema descriptions, and the enum already enumerates the three roles that the description merely repeats. The undocumented idempotency_key is not explained in the description either, so it neither compensates for the gap nor adds meaning 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?

The description states a specific verb and resource ('Invite a user to a project team') and names the grantable roles, so the agent immediately knows the operation. It does not, however, distinguish this from closely related siblings such as resend_team_invite or update_team_member_role, leaving the boundary between creating a new invite and re-issuing an existing one to inference.

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 guidance on when to use this tool versus alternatives: nothing says whether an existing pending invite should be handled with resend_team_invite instead, nor any prerequisite such as project admin rights. The agent must infer the usage context entirely from the tool 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?

The description notes 'The HMAC secret is write-only,' which is valuable behavioral context beyond annotations — it tells agents not to expect the secret back in responses. However, annotations already declare readOnlyHint=false (mutation is expected), and the description adds little else about what happens on creation, validation failures, or delivery behavior. The write-only secret note is the main added value.

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 communicate the core purpose and the key behavioral caveat (write-only secret). No wasted words. Could arguably add more but for what it covers, it's tight and front-loaded.

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 create tool with no output schema, the description is thin. It doesn't mention what response to expect (webhook id? confirmation?), how the created webhook appears in list_webhooks, what auth/permissions are required, or the meaning of the idempotency_key parameter which affects retry semantics. Given 6 parameters and no output schema, more context would help.

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 50%, meaning 3 parameters (enabled, description, idempotency_key) lack schema descriptions. The write-only HMAC note adds meaning beyond the schema's 'Secret you provide to sign webhook deliveries with HMAC,' clarifying the secret won't be retrievable later. However, the description doesn't explain the idempotency_key parameter, which is significant for a create operation.

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 it creates a webhook endpoint with specific verb+resource ('Create a webhook endpoint'). It clearly distinguishes from siblings like list_webhooks, update_webhook, and delete_webhook, which are separate operations on the same resource.

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?

No guidance on when to use this tool versus alternatives. There's no mention of prerequisites like needing to list webhooks first, no mention that this is a create operation distinct from update/delete, and no context about when a webhook would be appropriate. The schema does show required params (project_id, url, hmac_secret) but the description gives no usage 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?

The annotations already declare destructiveHint=true and readOnlyHint=false, which covers the safety profile. The description adds value by noting the user-confirmation requirement, which goes beyond the annotation signal. Mutations aren't described as reversible, and no return-format information is given, but annotations do the heavy lifting here.

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 wasted words. The purpose and the critical usage constraint (confirmation) are both delivered compactly and front-loaded.

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 tool with annotations declaring the destructive nature, this is reasonably complete. It adds the user-confirmation requirement which is critical safety context. No output schema exists, but for a delete operation, return value explanation is generally less critical. Could mention irreversibility, but the destructiveHint annotation plus confirmation instruction largely covers 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 67%, meaning rule_id and project_id have descriptions while idempotency_key has none (only length constraints). The description doesn't elaborate on any parameters beyond what the schema provides. The idempotency_key, undocumented in schema, is also not explained in the description — a minor 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?

The description clearly states the action (delete) and the resource (alert rule) plus the identifier method (by rule id). It distinguishes from siblings like update_alert_rule and create_alert_rule through the verb-resource pairing, though it doesn't explicitly call out the sibling distinction.

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 adds the important context that this should 'Use only after the user confirms deletion' — a clear usage constraint appropriate for a destructive action. It implies this is a user-confirmation-gated operation but doesn't name alternatives or exclusions explicitly.

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 destructiveHint: true annotation already flags this as a destructive operation, and the description's 'Use only after the user confirms deletion' reinforces it. However, the description doesn't disclose what happens after deletion (permanence, whether it's recoverable, related data affected). The description aligns with rather than contradicts 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?

Two short sentences, zero filler. The description is front-loaded with the core action and immediately follows with the critical usage constraint. Every word 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 destructive tool with a single required parameter and good annotation coverage, the description covers the essential points: what it does and the confirmation requirement. A more complete description might note that deletion is permanent or irreversible, and the idempotency_key behavior isn't explained, but the tool is relatively simple.

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% (keyword_id and project_id both have descriptions; idempotency_key lacks a description). The description points to keyword_id but doesn't add semantic context beyond the schema's own parameter descriptions. Baseline 3 is appropriate since schema does the heavy lifting for 2 of 3 params.

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

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

The description clearly states the tool deletes one keyword by keyword id, distinguishing it from sibling tools like delete_project, delete_alert_rule, delete_webhook, etc., which target different resources. The scope ('one keyword by keyword id') is specific and unambiguous.

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

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

The description explicitly states 'Use only after the user confirms deletion', which is a clear usage constraint that can trigger confirmation workflows. However, it doesn't explicitly mention alternatives (like delete_saved_keyword for saved keywords, though the name distinction implies this).

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 annotation destructiveHint=true already flags destructiveness, and the description adds meaningful context: it enumerates exactly what gets destroyed (keywords, rank history, settings) and emphasizes irreversibility ('This cannot be undone'). This goes beyond the annotation by specifying the full blast radius and requiring user confirmation.

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 waste. Every sentence earns its place: the first defines scope and consequences, the second sets the usage gate. Front-loaded with the primary verb and action.

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 mutation with no output schema, the description covers the key context: what is destroyed, irreversibility, and user-confirmation requirement. The idempotency_key parameter is not described, and there's no mention of post-deletion state or error handling, but for a delete operation with the destructive annotation and clear scope, this is reasonably 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 50%, with project_id documented in the schema (including a pattern and pointer to list_projects) but idempotency_key undocumented in the schema. The description doesn't explain idempotency_key semantics. However, the description clarifies the destructive outcome tied to project_id, adding operational meaning. The undocumented idempotency_key is a minor gap given schema coverage of the key 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 clearly states 'Permanently delete a project and all of its keywords, rank history, and settings.' It uses a specific verb (delete) with a specific resource (project) and enumerates the cascading scope, distinguishing it clearly from sibling deletion tools like delete_keyword, delete_saved_view, and delete_alert_rule, which operate on different resources.

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

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

The description explicitly states 'Use only after the user confirms deletion,' providing a clear precondition for safe usage. It doesn't name specific alternative tools, but given the large sibling list and the destructive nature, the confirmation requirement is the key usage gate. Exclusions/alternatives are not explicitly named, but the cascading scope makes the use case self-evident.

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 annotations already declare destructiveHint=true, so the destructive nature is covered. The description adds the confirmation requirement ('only after the user confirms deletion'), which is valuable safety context beyond the annotation. It doesn't discuss irreversibility explicitly, but that's implied and the confirmation gate compensates. No contradiction with 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?

Two concise sentences with no waste. The first states the action, the second the critical usage precondition. Efficient and front-loaded. Could arguably score 5, but the description is slightly terse and could benefit from noting the irreversible nature more directly.

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 simple delete operation with destructiveHint=true annotation, the description plus annotations adequately convey the essentials: what it does, confirmation requirement, and two key parameters documented. No output schema exists, but delete operations typically return minimal responses, so this is acceptable. The description is reasonably complete for the tool's simplicity.

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 67% — project_id and saved_keyword_id are described in the schema, but idempotency_key has no description. The description adds nothing about parameters beyond what the schema provides. Baseline 3 applies given the schema covers most parameters, though the undocumented idempotency_key is a minor 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?

The description "Delete one saved keyword" clearly states the verb (delete) and resource (saved keyword), with specificity about scope (one). It distinguishes from siblings like delete_keyword (regular keyword) and delete_saved_view (different resource), though it doesn't explicitly name the distinctions.

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 provides clear context on when to use it: "Use only after the user confirms deletion." This is important confirmation-before-deletion guidance. However, it doesn't explicitly state when NOT to use it or name alternative tools (like delete_keyword for regular keywords with project_id context), so a small gap remains.

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 annotations declare destructiveHint=true and readOnlyHint=false, so the safety profile is already disclosed. The description adds the user-confirmation requirement on top, which is useful context. However, it doesn't mention whether deletion is reversible, cascading, or what happens to related views/keywords. Given annotations already cover the destructive nature, the description adds modest incremental value.

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

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

The description is two short sentences with zero filler. Every word earns its place: the action, the resource, and a critical safety directive. Perfectly sized for a destructive delete operation.

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 fairly simple delete operation with clear annotations and 67% schema coverage, the description is mostly adequate. However, the undocumented idempotency_key parameter and lack of detail on side effects (e.g., whether deleting a view affects anything downstream) leave minor gaps. The destructive confirmation guidance compensates somewhat, but this could be more complete.

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

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

Schema coverage is 67% (view_id and project_id are described; idempotency_key has no description). The description doesn't add parameter-specific meaning beyond the schema. The idempotency_key is undocumented in both schema and description. With 2 of 3 params documented in schema, the baseline 3 applies; the description adds no parameter clarification.

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

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

The description clearly states what the tool does: 'Delete a project saved view.' This is a specific verb (delete) plus resource (saved view). The purpose is straightforward and aligns with the sibling create_saved_view. It scores 4 because while clear, it doesn't differentiate much from other delete tools like delete_project or delete_keyword, though the resource name disambiguates sufficiently.

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 provides important context: 'Use only after the user confirms deletion.' This is a clear usage directive indicating it's a destructive action that requires user consent. It doesn't explicitly mention alternatives or when-not-to-use, but the confirmation requirement is valuable safety guidance. No alternative tools are named for comparison.

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 readOnlyHint=false, so the description's mutation nature is covered. The description adds the 'Requires admin access' permission context, which adds value beyond annotations. No contradiction detected. However, it doesn't disclose what happens to the webhook's associated behavior (e.g., no further events sent, idempotency 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?

Two short sentences, no wasted words. Front-loaded with the action verb. Could arguably be more concise but the current length is appropriate for a deleting operation.

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 destructiveHint annotation and a clear purpose, this is largely sufficient for a simple resource deletion. However, the idempotency_key parameter is completely unexplained, there's no mention of what happens post-deletion, and the admin access requirement is the only behavioral context. Adequate but with gaps for a destructive operation.

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%: project_id and webhook_id are well-described in the schema ('list_projects returns valid project ids'), but idempotency_key is undocumented in both schema and description. The description adds no parameter-level meaning beyond the schema. Baseline 3 is appropriate given moderate schema coverage.

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

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

The description states 'Delete a webhook endpoint' with a specific verb and resource, clearly distinguishing it from siblings like create_webhook and update_webhook. However, it doesn't explicitly differentiate from other destructive operations beyond the verb-resource combination.

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 includes 'Requires admin access' which hints at a precondition, but provides no guidance on when to use this vs alternatives, no consequences of deletion, and no context about irreversible effects relative to other webhook operations. There's no when-not-to-use 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 readOnlyHint=false and destructiveHint=false, and the description usefully adds that existing snapshots are retained — a real behavioral guarantee not derivable from the structured fields. It does not address idempotency-key replay semantics or the reversal path, so it falls short of a 5.

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 sentence, front-loaded with the action and followed by the important side-effect qualifier. Nothing is wasted and nothing is 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?

For a simple three-parameter mutation with annotations covering the safety profile and no output schema, the description is nearly sufficient — the retention guarantee is the key thing an agent needs. It is only slightly thin on the idempotency contract and reversal tooling.

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%: monitor_id and project_id are documented in the schema, but idempotency_key has no description anywhere, and the description text says nothing about any parameter. The description does not compensate for the coverage gap, so it sits below the high-coverage baseline of 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 (disable) and resource (the project sitemap monitor), so the agent knows exactly what happens. The distinction from enable_sitemap_monitor is obvious from the verb, though the description never names or contrasts the sibling 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?

There is no when-to-use/when-not guidance, no prerequisites (e.g. permissions), and no pointer to enable_sitemap_monitor as the reversal path. Usage is only implied by the verb.

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 readOnlyHint=false, so the safety profile is established. The description reinforces this with the confirmation requirement ('Use only after the user confirms deletion'). However, it doesn't disclose what happens to downstream artifacts (e.g., whether associated webhooks, alerts, or keywords are affected), which would add meaningful transparency for a destructive disconnect operation.

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

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

The description is a single, tight sentence with a guardrail attached. Two sentences, zero waste. Every word earns its place—the verb, target, scope, and usage constraint are all present.

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 mutation tool with no output schema and incomplete parameter coverage (idempotency_key undocumented), the description could do more. It doesn't address reversibility, side effects on related resources, or the response format. However, it's a focused action ('disconnect a provider') and annotations carry some safety context. Adequate but not rich.

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%, so project_id and provider_id are already documented in the schema. The description adds no parameter-level detail beyond that. The idempotency_key (the third, undocumented param) is not explained anywhere—its purpose and when to set it are unknown. Baseline 3 applies since schema does most of the param work, but the undocumented idempotency_key gap slightly limits compensation.

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

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

The description uses a specific verb+resource structure: 'Disconnect a provider from a project.' This clearly distinguishes it from sibling tools like connect_provider, update_provider_settings, set_provider_enabled, and set_provider_priority. The scope (project + provider) is explicit.

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

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

The description states a clear when-to-use constraint: 'Use only after the user confirms deletion.' This is an explicit usage guardrail for a destructive operation. It doesn't name alternatives like delete_project or set_provider_enabled for similar scenarios, but the confirmation requirement is valuable and specific.

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 genuinely non-obvious behavior beyond the annotations: enabling is deferred to the next scheduled worker sync rather than triggering an immediate fetch. Annotations only cover safety (readOnlyHint=false, destructiveHint=false), so this scheduling disclosure is the valuable addition, though it omits idempotency semantics and 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?

Two short sentences, zero filler, and the deferred-fetch caveat is placed immediately after the action statement so it cannot be missed. Nothing to trim.

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 and annotations only cover the safety profile, so the description carries the rest. It covers the key timing behavior but omits prerequisites, idempotency_key semantics, and outcomes such as an already-enabled monitor. Sufficient to call correctly, not complete.

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

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

Schema coverage is 67%, and the schema itself richly documents monitor_id (including its default to project_id) and project_id. The description adds nothing about parameters, and idempotency_key has no description at all in either place, so the baseline 3 for mid coverage 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 ('Enable the project sitemap monitor'), so the agent immediately knows this toggles the monitor on. It does not explicitly name the counterpart disable_sitemap_monitor, but the verb makes the direction of the toggle unambiguous 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?

Usage is implied by the verb 'enable' rather than stated: there is no guidance on prerequisites (a configured sitemap, an existing monitor), no mention of disable_sitemap_monitor as the inverse, and no note on what happens if the monitor is already enabled. Adequate but with clear gaps for a state-changing toggle.

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, destructiveHint=false, openWorldHint=false), and the description adds genuinely useful behavioral facts: it is free and does not call a provider, so no budget is consumed. It does not detail the shape of the eligibility result, but the added cost-safety context is 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?

Two short clauses with the key fact ('Free') front-loaded and the sibling routing at the end. Every word 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?

For a cost-estimation tool with no output schema and fully documented parameters, the description covers purpose, cost behavior, and the follow-up paid operation. It could state what the eligibility result contains, but nothing essential for correct invocation 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 all seven parameters (mode, target, project_id, result_limit, target_scope, max_cost_cents, include_subdomains) are fully documented in the schema. The description adds no parameter-level meaning beyond that, 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?

The description states a specific verb (returns/estimates) and resource (cost and eligibility of a backlinks analysis) and explicitly contrasts itself with the paid sibling 'analyze_backlinks'. An agent can tell this is the free pre-flight costing 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 names the alternative 'analyze_backlinks' as the paid operation, implying the workflow of estimating here before spending. It is clear context, but there is no explicit when-not-to-use or a statement that this is a required prerequisite, 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context beyond that: the call is free, does not hit a provider, and returns both cost and eligibility — useful for an agent deciding whether a paid run will succeed.

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?

A single tight sentence with 'Free' front-loaded, followed by what it returns and the paid counterpart. No filler, no 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?

No output schema exists, and the description states the return payload (cost and eligibility), which is the key information an agent needs. Combined with 100% schema coverage and read-only annotations, nothing essential is missing for correct invocation.

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 8 well-documented parameters (including the enum and the max_cost_cents cache-only note), so the schema carries parameter semantics fully. The description adds no parameter-level detail, making the baseline 3 correct.

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 (estimate cost/eligibility of a Domain Overview analysis) and immediately scopes it as non-provider-calling. It explicitly names the sibling paid operation analyze_domain_overview, so an agent can distinguish 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?

The description names the paid alternative analyze_domain_overview and frames this tool as the pre-flight check ('Free', 'without calling a provider'), which strongly implies when to use it. It stops short of an explicit directive such as 'call this before analyze_domain_overview' or stating when this check is unnecessary.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context by stating it is 'Free' and runs 'without calling a provider', but it does not disclose rate limits, caching, or response structure beyond what annotations already imply.

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

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

The description is two short sentences with zero waste, and it is front-loaded with the most important fact ('Free') followed by a precise explanation of what it returns and how it relates to the paid operation.

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 six parameters fully documented by the schema, safety hints provided by annotations, and no output schema, the description adequately covers the tool's purpose and return nature ('cost and eligibility'). It could more explicitly tie the estimate to the passed parameters, but the definition is otherwise complete enough for an agent to invoke 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 every parameter is already documented in the schema. The description adds no parameter-specific meaning, syntax, or constraints beyond what the schema provides, making the baseline 3 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 ('Returns the cost and eligibility') and resource ('keyword research'), and explicitly distinguishes the tool from its paid sibling by naming 'research_keywords'. An agent can tell exactly what this tool does and what it does not do 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 clearly positions the tool as the free, no-provider-call estimator and names the paid alternative ('the paid operation is research_keywords'), giving explicit when/when-not guidance. The routing condition between this tool and the paid sibling 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 already establish the safety profile (readOnlyHint=true, openWorldHint=false, destructiveHint=false), so the bar is lower. The description adds genuine but vague behavioral context — that results carry original provenance, may be in "partial states," and include "cost uncertainty" — which usefully signals incomplete/approximate data, though it never explains pagination, page-size behavior, or what a partial state means operationally.

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?

A single front-loaded sentence with the verb leading and no filler sentences — structurally tight. It is slightly jargon-dense ("partial states," "cost uncertainty") in a way that costs clarity more than it costs length.

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 five-parameter, cursor-paginated export with no output schema, the description leaves the return shape largely unexplained; the format parameter's schema text only partially compensates. Annotations cover safety, but with no output schema the description should have described what an evidence page contains. It is minimally sufficient rather than 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%, so limit, cursor, format, run_id, and project_id are already fully documented in the schema, including the CSV-vs-JSON distinction and cursor semantics. The description adds nothing 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?

It has a discernible verb+resource ("Read ... AI tracking evidence") and a scope ("project-scoped"), but the central noun "evidence" is undefined and the descriptor does not distinguish this from the many AI-tracking siblings such as get_ai_tracking_run, get_ai_tracking_history, or export_rank_history. The tangent about "original provenance, partial states, and cost uncertainty" muddies rather than sharpens what the tool yields.

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 statement of when to use this tool versus the many adjacent AI-tracking readers/exports, and no prerequisites or exclusions are given. Usage is only weakly implied by "project-scoped AI tracking evidence."

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/openWorld=false/destructive=false; the description reinforces this by explicitly stating the side effects it never performs, adding real context about scope. It stops short of describing return format or pagination.

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

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

Two tight sentences with the read scope front-loaded and the boundary clause following. No filler, though the second sentence could be slightly more concrete.

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

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

For a read-only export tool with no output schema, the description should explain what the returned evidence looks like; it only implies 'normalized retained JSON' and leaves the response shape to inference, which is a noticeable 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% with detailed patterns and formats for all five parameters, so the schema carries the burden. The description adds no parameter-level meaning beyond what the schema already provides.

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

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

States a read/export operation over 'retained Local evidence and quality/cost uncertainty' for a local monitor run, which distinguishes it from list_local_monitor_runs and get_local_monitor_run_results. However, phrasing like 'honest quality/cost uncertainty' is jargon-y and it never names the sibling tools directly.

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 when-NOT guidance via negation ('never launches provider work, schedules, or accounting writes'), which helps scope it, but gives no explicit when-to-use condition or named alternative among the local-monitor siblings.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: cursor-paginated output, version 1 legacy rows vs version 2 raw observations/attempts with frozen scope/time and quality metadata, and that streamed CSV requires a different mechanism.

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, no filler, and the core function (cursor-paginated JSON export) is front-loaded before version nuance and the alternative endpoint. Every sentence 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 read-only export tool whose annotations cover safety and whose schema documents most parameters, the description is nearly complete: it conveys format, pagination, versions and the CSV alternative. The only real gap is the lack of differentiation from get_rank_history.

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 75%, so most parameters are self-documenting. The description adds meaning on top of the schema by explaining version 1 vs 2 semantics and framing the export as cursor-paginated, complementing the cursor and version parameter descriptions.

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 (export project rank history) and format (cursor-paginated JSON), and the version semantics further sharpen the scope. However, it never names the obvious sibling get_rank_history, so an agent must infer the distinction from naming alone.

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 closing sentence routes agents to the REST endpoint for CSV dumps, which is useful when-not guidance. But it offers no guidance on choosing this tool over the sibling get_rank_history, leaving the primary alternative unaddressed.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that with the authorization constraint that a report ID never grants cross-project access, telling the agent the report_id is meaningless outside its owning project. It does not describe error behavior when the report is missing or not in the project.

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 with zero padding, and the core action is front-loaded before the access constraint. 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 simple, fully annotated, two-parameter read tool with no output schema, the description is essentially complete: what it reads, that it reads exactly one, and the cross-project access limit. Only minor gaps remain, such as what a saved analysis contains or how a not-found/wrong-project report is surfaced.

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 carry their own descriptions including the project-scoping of report_id, so the schema does the heavy lifting. The description reinforces the report_id/project_id relationship but adds no syntax, format, or validation 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 ('Read') and resource ('one saved analysis') that map cleanly to the tool name get_agent_report and separate it from list_agent_reports and create_agent_report. It stops short of explicitly naming those siblings, so an agent must infer the single-vs-list distinction from the name alone.

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?

'Read one saved analysis' implies the usage context (retrieve a single already-saved report by ID), but there is no explicit when-to-use, when-not-to-use, or pointer to the alternative list_agent_reports. The second sentence is a security constraint, 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral information beyond that: the read is cost-free and specifically does not trigger paid work, which matters in a catalog with many paid estimate/analysis tools.

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 with no filler; the operation and its non-billing constraint are front-loaded. Every sentence carries weight.

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