AuditMe

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

Annotations already disclose the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds one genuinely useful behavior fact beyond them: an API key is required. It omits, however, what approval actually triggers (are fixes applied to the site?), whether a decision can be revised, and why idempotency is false.

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 filler, with the action front-loaded and the prerequisite trailing. Nothing is wasted or 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?

An output schema exists, so return values are covered, and the annotations cover the safety profile. But for a required-3-param mutation gate in a fix-approval workflow, the description never explains the approval lifecycle or how the IDs are obtained, leaving a real gap 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% ('Workflow run ID', 'Decision', 'Approval ID'), so the schema already carries the parameter documentation and baseline is 3. The description adds no syntax, format, or source info for any of the three required parameters.

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 specific verb pair ('Approve or reject') plus resource ('pending fix changes'), which an agent can act on immediately. It does not, however, differentiate itself from siblings such as generate_fixes (the likely upstream producer of these pending fixes) or workflow_execute, so the agent must infer the relationship.

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

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

The description gives no when-to-use guidance, no prerequisites beyond the API key, and no indication of where runId/approvalId originate (e.g., workflow_status or generate_fixes). The phrase 'pending fix changes' implies an existing approval item but never states how to reach that state.

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 readOnlyHint=false, destructiveHint=false, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds one piece of behavioral context the annotations do not carry: the API-key authentication requirement. It says nothing about whether the call mutates stored state or what the comparison costs in time/quota, and the verb 'compare' sits uneasily with readOnlyHint=false.

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 filler, with the core action front-loaded. It is efficiently written; the brevity borders on under-specification, but that is a completeness concern rather than a conciseness flaw.

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?

An output schema exists, so return values need not be explained, and the auth requirement is stated. Still, for an open-world, non-read-only tool competing with 13 siblings, the description leaves an agent guessing about what the comparison actually produces and what state, if any, it changes.

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

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

Both parameters are fully documented by the schema (100% coverage) with URI formats and descriptive labels ('Your URL', 'Competitor URL'). The description adds no extra semantics such as trailing-slash handling, protocol requirements, or whether subdomains count as the same site, so the schema 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 states a clear verb and resource pair ('Compare your site against a competitor'), so an agent knows the operation immediately. It offers no differentiation from the 14 sibling tools, however, many of which (seo_audit, monitor_site, detect_regressions) could plausibly relate to site comparison.

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

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

There is no guidance on when this tool is the right choice versus seo_audit, monitor_site, or get_site_info, and no exclusions. The only usage-adjacent statement is the credential prerequisite ('Requires API key'), which is a precondition rather than a when-to-use rule.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful non-annotation detail (API key requirement) but says nothing about what constitutes a regression or what gets returned.

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 and the core action front-loaded. It is efficient, though extremely terse for a comparison 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?

An output schema exists, so return-value explanation is not required, and annotations cover safety. Still, the description leaves the regression definition and the baseline-vs-current intent implicit, and its 'audit results' wording does not match the URL inputs.

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 URI parameters are documented in the schema, so the baseline of 3 applies. The description only vaguely gestures at 'two audit results' and adds no format or ordering meaning 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 ('Compare') and outcome ('detect regressions'), which is distinguishable from siblings like compare_competitors or seo_audit. However, it says it compares 'two audit results' while the schema takes two URLs to audit, leaving the actual operation slightly ambiguous.

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 indication of when to use this versus seo_audit, compare_competitors, or monitor_site, and no named alternatives. The only actionable guidance is the 'Requires API key' prerequisite, which is a setup note rather than usage 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 idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely non-structured context: output is deterministic and data-driven, not AI-generated, and an API key is required. It does not, however, explain what, if anything, gets persisted when readOnlyHint is false.

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 the core purpose first and the key prerequisite last. 'No AI hallucination — all fixes are data-driven' is mildly redundant but reinforces a genuine selling point, so only a minor deduction.

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 an output schema present, the description need not explain return values. It covers purpose, determinism, and the API key prerequisite, which is sufficient for a low-complexity 2-param tool; the only gap is the missing generate-vs-approve relationship.

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

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

Schema description coverage is 100%, so both url and topN are fully documented in the schema. The description hints at volume via 'top audit issues' but adds no syntax or constraint detail beyond what the schema already provides; 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 gives a specific verb+resource: 'Generate deterministic fix suggestions for top audit issues.' An agent knows exactly what it produces. It does not explicitly distinguish itself from the sibling approve_fixes, so it falls short of a 5.

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 context is implied ('for top audit issues') and one prerequisite is stated ('Requires API key'), but there is no explicit when-to-use vs alternatives guidance and no mention of the generate-then-approve relationship with approve_fixes.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds some value by framing the payload as static explanatory material (including 'limitations'), but it does not disclose important behavior such as whether the result is cached/static or how the optional category filter scopes the response.

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 sentence with the resource front-loaded and the payload contents following. The list is dense but each item earns its place by telling the agent what it will receive; no filler or repetition.

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?

An output schema exists, so return values needn't be re-explained, and the description still usefully previews the content scope. The only real gap is silence on the category filter and on the static nature of this reference material, which is minor given full schema coverage and annotations.

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% for the single optional 'category' parameter, so the schema already carries its meaning and example values. The description never mentions the category filter, adding no syntax or filtering semantics beyond what structured data provides, which lands on the baseline.

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

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

States a specific verb and resource ('Get audit methodology') and then enumerates exactly what the resource contains: scoring, 159 checks across 16 categories, severity logic, data sources, and limitations. An agent can tell this apart from seo_audit or generate_fixes because it is clearly documentation about the audit rather than an audit action, though no sibling is named explicitly.

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

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

There is no explicit statement of when to reach for this tool versus seo_audit, get_opportunities, or the other siblings, and no prerequisites or exclusions. The content enumeration only weakly implies usage (read this to understand scoring), which is less than clear context.

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

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

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true), and the description usefully adds the API-key requirement, which is auth context not in the structured fields. It does not explain what the non-read-only behavior actually does or what state is affected, leaving a gap for a tool whose 'get_' name sits awkwardly against readOnlyHint=false.

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 padding, and the primary function is front-loaded ahead of the prerequisite. It is not a 5 only because the lead sentence describes an outcome rather than the tool's action, so the front-loading spends its first words on the wrong thing.

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?

An output schema exists, so return values need not be described, and the auth prerequisite is disclosed. However, for a tool with a mismatched name/description and twelve siblings, the description leaves the core question — what it retrieves and when to prefer it — under-specified.

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

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

There is a single parameter with 100% schema description coverage ('URL to analyze'), so the schema already carries semantics and the baseline is 3. The description adds nothing about the URL (e.g., is it a page, a property, a competitor site?) 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?

The name and title say 'Get Opportunities', but the description instead talks about 'prioritizing audit issues' — a related but not identical effect, so the tool's actual action (retrieve opportunity data for a URL) is never plainly stated. It does imply analysis over a target, but does nothing to distinguish it from siblings like seo_audit or generate_fixes.

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 only guidance is the prerequisite 'Requires API key'. There is no statement of when to call this versus the many comparable siblings (seo_audit, generate_fixes, get_site_info) and no exclusions or context triggers.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the shape of the returned explanation content, with no note on how AuditMe-specific check wording is versioned or scoped.

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 verb and resource, and the four returned sub-sections are packed into a compact list 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?

With an output schema present and annotations covering the read-only/idempotent profile, the definition only needs to frame purpose and content. It is nearly complete; the sole gap is guidance on when to choose this over get_audit_methodology.

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 single enum parameter is fully documented in the schema, so the schema does the heavy lifting. The description adds no syntax, default, or selection guidance for the seven enum values, matching the baseline 3 expected at high 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 pairs a specific verb ("Get explanation") with a specific resource ("an SEO concept") and even enumerates the sub-sections returned (definition, why it matters, how AuditMe checks it, best practices). It does not, however, distinguish itself from the similarly explanatory sibling get_audit_methodology, so an agent must still infer the boundary.

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

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

Usage is only implied: the content breakdown (definition, rationale, checks, best practices) suggests calling it when a user needs an SEO concept explained. There is no explicit "use this when / not when" clause and no alternative tool is named, even though get_audit_methodology and seo_audit overlap in explanatory territory.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds what information surfaces (title, description, tech stack, crawl status), but says nothing about rate limits, whether the result is cached, or behavior when the URL is unreachable.

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 short sentence, front-loaded with the verb and resource, and the field list is compact. Every clause 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The remaining gap is the absence of usage routing against siblings such as monitor_site, which is minor for a single-parameter read tool.

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

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

There is a single parameter (url) and schema description coverage is 100%, so the schema already fully documents it. The description adds no additional meaning about the URL format or constraints, which is the expected baseline when the schema does the work.

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

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

Specific verb (get) plus resource (site information) with an enumerated field list (title, description, tech stack, crawl status). It is distinguishable from heavier siblings like monitor_site and seo_audit by the word 'basic', though no sibling is named explicitly.

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

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

Usage is only implied: 'basic site information' hints this is the lightweight lookup to call before or instead of an audit or monitoring tool. There is no explicit when-to-use, when-not, or named alternative, so an agent must infer the routing.

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

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

Annotations already declare this is a readOnly, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description usefully adds the auth requirement ('Requires API key'), which annotations do not convey, but says nothing about rate limits 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 short sentences, output content front-loaded, with the auth prerequisite last. 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 single-param read-only tool with an output schema, the description need not explain return values, and it correctly notes the API key requirement. The only gap is the absence of guidance on how it relates to sibling monitoring/audit tools.

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

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

There is a single parameter with 100% schema description coverage ('Site URL to monitor'), so the schema already carries the parameter semantics. The description adds no format or scope detail beyond what the schema 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 ('Get') and resource ('monitoring overview for a site') and even enumerates the payload (alert rules, recent alerts, severity breakdown). It does not explicitly distinguish itself from the closest sibling get_site_info, so it falls short of a 5.

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

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

The description gives no when-to-use or when-not guidance and names no alternative among the many siblings (get_site_info, detect_regressions, seo_audit). 'Requires API key' is a precondition, not usage 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 disclose non-read-only, non-destructive, idempotent behavior, so the burden is partly lifted. The description adds the useful auth requirement ('Requires API key'), but says nothing about what creation changes or what a list returns. Note the idempotentHint=true sits oddly with a create action, though the description does not contradict it directly.

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, front-loaded sentences with no filler. The only blemish is the inaccurate 'baseline' mention, which costs a sentence its full value.

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

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

For a six-parameter, dual-action tool with an output schema and full schema coverage, the description covers the essentials: the two modes and the auth requirement. Return details are handled by the output schema, so the remaining gap is minor.

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. The description echoes 'hypothesis' (a real parameter) but also mentions 'baseline', which is not a parameter at all, adding a small amount of 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?

States a concrete verb pair (create/list) and the resource (SEO experiments), so the agent knows the tool's job. It does not differentiate itself from any sibling, and the name 'run_experiment' is looser than the actual create/list behavior described. The reference to 'baseline' also doesn't map to any real parameter.

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 the two modes via 'create or list', which mirrors the 'action' enum, so usage is inferable. There is no guidance on when to choose this over sibling tools like monitor_site or seo_audit, and no exclusions or prerequisites beyond the API key note.

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 idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one genuinely new behavioral fact — 'Requires API key' — but omits runtime expectations (audit duration, rate limits, failure modes) for a 159-check operation.

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

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

Three tight sentences, front-loaded with the operation and scope. The clause listing return contents is somewhat redundant given an output schema exists, but it costs little and stays brief.

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 annotations covering safety, a 100%-covered single param, and an output schema handling return values, the description only needs to frame the operation — which it does, plus the API key prerequisite. Only the absence of any sibling-routing context keeps this from being fully 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?

There is a single parameter with 100% schema description coverage, so the schema already fully documents it. The description's 'on a URL' adds nothing beyond the schema's 'URL to audit', which is the expected baseline here.

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

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

States a specific verb and resource ('Run full unified audit ... on a URL') and quantifies scope with 159 checks across 16 categories, which is far more informative than a bare name restatement. It stops short of explicitly distinguishing itself from siblings like detect_regressions or compare_competitors, so an agent must infer the boundary.

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

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

The description offers no when-to-use or when-not-to-use guidance and never names an alternative among the 13 siblings. An agent gets no routing signal for choosing this over monitor_site or detect_regressions.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the mutation profile is partly covered. The description adds an auth prerequisite ('Requires API key'), which is genuinely useful context beyond the annotations, but it fails to disclose that the tool can delete keywords via 'remove', a behavior an agent would want flagged given destructiveHint=false.

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 the core operation front-loaded and zero filler. Size is appropriate for a simple three-parameter tool.

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

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

An output schema exists, so return values need not be explained, and the schema documents all parameters. Still, the description omits the 'remove' action entirely and provides no routing guidance against 13 sibling tools, leaving meaningful gaps for a multi-action tool.

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

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

Schema description coverage is 100%, so the schema already documents 'action', 'keyword' and 'targetUrl' including which are required for which action (baseline 3). The description adds no parameter meaning beyond listing the add/list behaviors, and it never mentions 'targetUrl' or the remove path.

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 (track) and resource (keywords for a site), so the agent knows it manages tracked keyword data. However, the description says 'Add or list' while the schema's action enum also includes 'remove' — the purpose statement undercounts what the tool does, and it doesn't distinguish itself from siblings like get_opportunities.

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 versus sibling tools; the only constraint offered is 'Requires API key'. There is no mention of when-not-to-use or which alternative handles related keyword work.

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, non-idempotent, non-destructive, open-world, so the safety profile is covered structurally. The description adds one behavioral fact beyond the schema: an API key is required. It does not mention that workflows are long-running or that async polling via workflow_status is available (that lives only in the schema), so additional disclosure is thin.

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 sentence that front-loads the action and scope, with the auth prerequisite trailing. Nothing is wasted, though it is arguably too terse for a five-parameter, multi-mode 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?

An output schema exists, so return values need not be explained, and all parameters are documented in the schema. However, for a tool with five distinct workflow modes, the description never explains what audit vs. analyze vs. fix actually do, leaving an agent to infer mode selection from the enum names 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 100%, so every parameter (intent, url, topN, async, competitorUrl) is already documented, including the enum values and the async/polling behavior. The description's parenthetical list of intents merely restates the schema enum, adding no new syntax or meaning. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (Execute) and resource (workflow), and enumerates the five workflow types (audit, analyze, fix, monitor, competitor), which lets an agent identify the tool's scope. It does not, however, distinguish itself from siblings like seo_audit, monitor_site, or compare_competitors, which cover overlapping ground.

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 enumerated workflow types imply when the tool applies, and 'Requires API key' is a useful prerequisite. But there is no explicit when-to-use versus the sibling tools (e.g., why choose the competitor workflow here rather than compare_competitors), so usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds the auth requirement ('Requires API key'), which is genuinely beyond the annotations. It does not mention polling behavior or rate limits, so it is a modest addition.

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, purpose front-loaded, zero filler. Every clause carries information an agent can act on.

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

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

Complexity is low: one required param, an output schema describing the return, and annotations covering safety. The description is nearly sufficient, with the only real gap being how it relates to workflow_execute.

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

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

Only one parameter (runId) with 100% schema description coverage, so the schema carries the semantics and the baseline is 3. The description adds nothing about the runId format or where it comes from.

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: 'Check status and results of a workflow run'. This is unambiguous aside from not explicitly contrasting with the sibling workflow_execute, which an agent could confuse with it at a glance.

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 offered. It never states that this tool is the follow-up to workflow_execute for polling a run, nor does it set conditions or exclusions. The only context given is an authentication prerequisite, which is not usage direction.

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