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

Annotations already declare readOnlyHint/closed-world/non-destructive, so safety needs no repetition. The description adds real behavioral value by naming the derived outputs (CPA, revenue, profit, ROAS) and that they appear only when optional conversion inputs are supplied — information unavailable anywhere else since there is no output schema.

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

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

Two sentences, no filler, and the primary computation is front-loaded ahead of the optional-output clause. Every phrase 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 stateless, zero-required-parameter calculator whose annotations already cover safety, the description supplies purpose, optional inputs and resulting outputs — enough to call it correctly. The one gap is not spelling out the input-combination rule (pick two of cpc/cost/clicks) that a solver-style tool implies.

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 0%, so the description carries the full burden, and it does so reasonably: spend (cost), clicks, cpc, conversion rate and order value are all tied to their roles and resulting metrics. It could be sharper about which two of the three core inputs must be paired to solve for the third, but the semantic mapping is present.

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 exactly what is computed (cost per click) and inverts the relationship (solve for spend/clicks from a CPC), which is a specific verb+resource. It never explicitly contrasts itself with the nearby cpm_calculator or ctr_calculator siblings, so an agent must rely on the metric name alone to disambiguate.

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

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

It clearly frames two usage modes ('from spend and clicks' vs. 'solve for spend/clicks from a CPC') and states the condition under which extra outputs appear (supply conversion rate and order value). It does not state when to prefer this over cpm_calculator/ctr_calculator, but the conditional input guidance is genuinely actionable.

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, and openWorldHint=false, so the safety profile is covered. The description adds the inverse-solve behavior, which is genuinely useful, but says nothing about the output shape or the exactly-two-inputs rule implied by required=0.

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 primary use case and then the inverse. Zero 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 three-optional-parameter calculator with no output schema this is close to adequate, but the agent still cannot tell whether to supply two or three numbers or what the response contains. A short clause on input combinations and return value would complete 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 0%, so the description must carry the burden. It does map the quantities in domain terms (spend, impressions, CPM) and hints that any two determine the third, but the schema names 'cost' while the description says 'spend' and the required combination is never made explicit.

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 resource (cost per 1,000 impressions) and both directions of the computation — derive CPM from spend and impressions, or solve for spend/impressions from a CPM. The CPM focus clearly separates it from the cpc_calculator and ctr_calculator siblings.

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 'or solve for...' clause implies the two usage modes, but it never states when to pick this tool over cpc_calculator/ctr_calculator or what combination of inputs is required. Usage is inferable, not 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 readOnly, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that this is a pure computation with an invertible mode, but does not disclose behavior when all three values are supplied, precedence rules, or handling of zero impressions.

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 that front-loads the primary computation and appends the inverse mode. Nothing is wasted and no rephrasing of the title.

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

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

For a stateless math tool with no output schema and no annotations gap, the description covers the operation and the output unit (%). The remaining ambiguity — how many parameters to pass and which wins when three are given — is minor but real given 0% schema coverage.

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

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

Schema coverage is 0% and no parameter is required, so the description must carry the meaning; it does partially, naming clicks, impressions and a CTR percentage and implying that two of the three are supplied. It still omits units for clicks/impressions and does not state the exactly-two-inputs constraint.

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

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

Names a specific metric (CTR as a percentage) and the exact inputs it derives it from, plus an inverse mode that solves for clicks or impressions. That is enough for an agent to distinguish it from cpc_calculator/cpm_calculator siblings, though it never explicitly names those alternatives.

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 two modes (compute CTR from clicks+impressions, or back-solve for a missing variable) imply how the tool is used, which is more than nothing. There is no explicit when-to-use versus the sibling calculators and no statement of what is invalid input.

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=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuine behavioral detail beyond that: it parses HTML into an H1-H6 outline and explicitly reports missing H1s, multiple H1s, and skipped levels.

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 dense sentence with the core action and the flagged conditions front-loaded; no filler or redundancy.

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

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

For a simple one-parameter, read-only analyzer with no output schema, the description adequately covers input and detected issues. It stops short of describing the returned structure or how malformed HTML is handled, which is a minor 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?

Only one parameter (html) with 0% schema description coverage, but its meaning is self-evident and the phrase 'from HTML' confirms the input is raw HTML source. No further syntax, encoding, or fragment-vs-document guidance is offered.

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 pair (extract, flag) and a concrete resource (the H1-H6 outline from HTML), including the exact anomalies it detects. It is clearly distinct from the calculator/generator siblings, though it never names or contrasts with 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 gives no when-to-use guidance, prerequisites, or alternatives; it only says what the tool does. An agent must infer from the name that this is an SEO/HTML-audit step.

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 one genuinely useful behavioral note — that language codes are validated — but says nothing about what happens on invalid codes, error behavior, or whether output is returned as a string or file.

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 no filler, so nothing needs trimming. It is efficient, though the brevity leaves obvious gaps that a slightly longer description could have filled.

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 generator with no output schema, an agent still needs the input shape (required entries array, lang/url pairing, purpose of xDefault) and ideally the return format. The description supplies neither, leaving the two undocumented parameters to be inferred purely from raw JSON Schema types.

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 0% and the description documents neither 'entries' (a required array of lang/url objects) nor 'xDefault'. 'Language code validation' is a faint hint about the 'lang' field but gives no format (ISO 639-1? with region?) and omits the required entries structure entirely.

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 (generate) and resource (hreflang alternate link tags) with a clear scope of multilingual/regional pages, which distinguishes it implicitly from siblings like meta_tag_generator or xml_sitemap_generator. It does not name an alternative explicitly, so it stops 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 phrase 'for multilingual/regional pages' implies the applicable context but never states when to use this over sibling generators or any prerequisite conditions. No exclusions or alternatives are offered, 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds a real behavioral detail worth noting – stop words are ignored and 2-3 word phrases are supported – but says nothing about output shape or ordering beyond 'most repeated'.

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, no filler, with the core action front-loaded and the stop-words caveat appended where it belongs.

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?

A read-only analyzer with no output schema and 3 params; the description covers purpose and the stop-word behavior and gestures at returns ('counts and density %'). It stops short of describing the actual return structure or how phraseLength and limit interact, leaving gaps for the agent.

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 0% schema coverage the description must compensate. It does map phraseLength (2-3 word phrases) and hints at the text param domain (text/HTML) and the 'most' truncation for limit, but the limit parameter itself, its default of 15, and the max of 50 are never explained.

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 (find the most repeated) with resource (words or 2-3 word phrases in text/HTML) and output format (counts and density %). Clear enough to distinguish from word_counter, though it never names the sibling to sharpen 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 implied by the SEO-analytics framing (keyword density), but there is no explicit when-to-use guidance and no mention of when to prefer word_counter or other siblings. Adequate but leaves routing 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, non-networked operation. The description adds one behavioral trait beyond that — that length warnings are emitted — but says nothing about warning thresholds, error behavior, or the form of the generated output.

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 verb and output list front-loaded and no filler. It is appropriately sized for what little it chooses to say.

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 generator with zero schema coverage and no output schema, the description is too thin: it omits the required-parameter contract, the unknown inputs (url, author, keywords), and any sense of what the returned tags or warnings look like.

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 0%, so the description must carry the parameter burden. It names only title, description and robots, leaving url, author and keywords unexplained, and it mentions canonical and viewport as if they were inputs when they are outputs derived from url. It never states that title and description are required.

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 'Generate' plus the specific resource (meta tags) and an enumeration of the tag types produced. It is distinguishable from siblings like open_graph_generator and schema_markup_generator, though the description never explicitly contrasts itself with 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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. With twelve closely related SEO siblings, the lack of routing guidance is a real 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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond purpose — it does not say whether output is HTML tags, a JSON object, or text, nor whether generation is deterministic or requires network access for image validation.

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 ten-word sentence with the action front-loaded and no filler. It is efficient, though its brevity reflects under-specification rather than disciplined trimming.

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 7-parameter, 3-required tool with no output schema, the description should at minimum indicate the output format and the role of the required fields. Neither is present, leaving a substantial gap 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 0% across 7 parameters, and the description names none of them, so the agent learns nothing about title, description, url, image, type, siteName, or twitterHandle semantics. The mention of Open Graph/Twitter Cards gives only the vaguest domain hint (e.g., that twitterHandle is Twitter-specific), which is far from compensating for a fully undocumented 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 ('Generate') and resource ('Open Graph and Twitter Card meta tags'), which distinguishes it from the broad meta_tag_generator sibling by naming the exact tag families produced. It stops short of explicitly contrasting itself with that sibling, so it is clear but not fully differentiated.

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 choose this over meta_tag_generator or schema_markup_generator, nor any prerequisites or exclusions. Only the purpose is stated; context must be inferred entirely from the 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that output is derived purely from the supplied rules and sitemaps, but says nothing about output format, ordering, or how conflicting allow/disallow entries are resolved.

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 no filler. Every clause corresponds to a real input of the 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 low-complexity generator with no output schema, the description should at least say what it returns (e.g. the robots.txt text) and note required fields. It covers inputs adequately but leaves the return shape and required-parameter behavior unspecified.

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 0%, so the description carries the burden. It does map the two top-level params ('allow/disallow rules' and 'sitemap URLs'), but omits crawlDelay, userAgent matching/wildcards, and the required nested userAgent field, leaving meaningful gaps.

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 artifact ('Generate a robots.txt') plus the input sources (per-user-agent allow/disallow rules, sitemap URLs). An agent can distinguish it from xml_sitemap_generator by the output artifact, though the description never explicitly contrasts the two.

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 despite a crowded sibling set of SEO generators. The agent must infer that this is the tool for robots.txt rather than xml_sitemap_generator from the name alone.

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 no behavioral context of its own: nothing about what the returned JSON-LD looks like, whether it is validated against schema.org, or where it should be embedded.

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 the payload format, and the type list is compressed into a single enumeration. 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 single-parameter generator whose schema already encodes the five shapes, the essentials are present, but with no output schema the description should say what is produced (raw JSON-LD vs. a script tag) and how it should be used. That gap keeps it at minimum-viable.

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 0%, so the description must compensate, and it partially does by naming the five type values that act as the oneOf discriminator. However, it says nothing about the per-variant required fields (e.g., Article needs headline/author/datePublished, Product needs price/currency), leaving the caller to read the required arrays.

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 ('Generate') and resource ('JSON-LD structured data') and enumerates the five supported schema.org types, which cleanly separates it from siblings like open_graph_generator and meta_tag_generator. It stops short of an explicit sibling callout, which keeps it out of the top band.

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 prerequisites, and no alternative named (e.g., when to prefer open_graph_generator or meta_tag_generator instead). The SEO-tool context implies the usage but the description itself offers nothing.

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 agent knows this is a side-effect-free local computation. The description adds the set of metrics produced, but says nothing about determinism, unit/currency assumptions, or how the break-even figure is derived. Adequate given annotation coverage, but not rich.

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

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

A single front-loaded sentence with zero filler; the verb and the deliverable metrics come first. It is efficient, though the brevity is achieved by omitting information the agent actually needs rather than by tight editing.

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 5 parameters, 0% schema description coverage, and no output schema, the description should carry the burden of explaining inputs and return shape. It lists only output metrics and omits parameter units, the percent-vs-fraction convention, and the default/meaning of 'months', leaving the agent to guess at call semantics.

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 0% across 5 parameters, so the description is the only place meaning could be added — and it adds none. It lists outputs, not inputs, and gives no units or interpretation for monthlyInvestment, monthlyVisitors, conversionRatePct (percent vs fraction), valuePerConversion, or months (only hinted at by 'over a period').

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 (Estimate) and resource (SEO return), then enumerates the computed outputs: conversions, revenue, ROI %, cost per conversion, break-even. That clearly separates it from the CPC/CPM/CTR calculator siblings, though it never names or contrasts with them 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 guidance, no prerequisites, and no mention of when a sibling calculator (e.g. cpc_calculator or ctr_calculator) would be the better pick. Usage is only inferable from the tool name and the output list.

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 context beyond that by disclosing the computed metrics and that HTML input is tolerated, but says nothing about return shape or how reading/speaking time is derived.

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

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

Two short sentences, front-loaded with the capability list and ending with the input-format caveat. No filler, every clause carries information.

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

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

For a single-input, side-effect-free utility with annotations covering safety and no output schema, the description is nearly sufficient — the agent knows what it computes and what input is accepted. Only the precise output details (units, time-estimate assumptions) are left implicit, which is minor here.

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 0% and the single 'text' property is a bare string, so the description carries the burden — and it does add real meaning by stating the input 'Accepts text or HTML', which the schema does not convey. That is a meaningful clarification for the only 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?

States a concrete verb (count) plus the exact resources measured (words, characters, sentences, paragraphs) and additional outputs (reading/speaking time), which makes it distinguishable from siblings like keyword_density or heading_structure_analyzer. It stops short of explicitly contrasting itself with any named sibling, so it lands at clear-but-not-routing.

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

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

The description never says when to reach for this tool versus keyword_density or heading_structure_analyzer, nor states any prerequisites or exclusions. Usage is only inferable from the purpose statement, which is the 'no guidance' band.

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 fully covered elsewhere. The description adds only 'valid,' hinting at output validation, but says nothing about limits (e.g., sitemap URL-count caps), return format, or 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?

A single sentence, front-loaded with the action and output, with zero filler. Every clause adds something: the artifact, the input, and the optional fields.

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 simple (one required parameter) and annotations cover safety, but with no output schema the description should state what is returned (XML string, file, URL) and briefly describe validation behavior. Those gaps keep it at a minimum-viable level.

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 0%, so the description must carry the weight; it names the three optional fields (lastmod, changefreq, priority) and situates them in sitemap semantics, but gives no format details (e.g., lastmod date format, priority range) and never mentions the required 'loc'. Partial compensation only.

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 artifact ('Build a valid sitemap.xml') plus the source input ('from a list of URLs'), making the tool's function immediately clear. It does not explicitly distinguish itself from siblings like robots_txt_generator or meta_tag_generator, but the unique output artifact makes separation obvious in practice.

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 prerequisites, and no mention of alternative tools or when this should not be used. The usage context (SEO sitemap creation) is only implied by the tool name and output, so an agent gets no explicit routing help.

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