Burs-IA Tools

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-fetch profile is covered; the description adds substantive context on top: it returns a 0-100 score, per-check notes and an evidence hash, it is free, and it is explicitly not a security certification. What it does not disclose is timing or rate-limit behaviour for a live multi-endpoint crawl, which is the main remaining unknown.

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 front-loaded clause states purpose before the check list. The return-value and disclaimer clauses each carry distinct information, so 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?

With no output schema, the description correctly compensates by naming the return shape (score, per-check notes, evidence hash), and the sole parameter is fully documented in the schema. It stops short of saying what a caller should expect when checks fail or time out, which matters for a live open-world audit, but nothing essential to invoking it is missing.

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

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

Schema coverage is 100% and the single url parameter already documents 'Domain or https URL, e.g. example.com'. The description adds nothing about accepted formats, redirect handling or whether http:// is tolerated, so this is the standard baseline-3 case where the schema does all 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?

The description opens with a specific verb and resource ('Audit how ready a public website is for AI agents') and then enumerates exactly which signals are inspected (A2A agent card, llms.txt, MCP discovery, OpenAPI, robots.txt, agents.json, skills, x402, sitemap). That enumeration also makes it self-evidently the aggregate counterpart to the individual bursia_check_* siblings, so an agent can distinguish it 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 rather than stated: it is clearly for auditing a public site, and the individual check tools in the sibling list are the obvious alternative, but the description never says 'use this for a one-shot overview, use bursia_check_llms_txt for a single check' or any equivalent. The only explicit boundary is a scope disclaimer ('not a security certification'), which is useful but is not routing guidance.

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

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

'Pure computation, free' usefully confirms determinism, no network, and no cost, aligning with openWorldHint=false and readOnlyHint=true and adding a little value beyond them. However, it says nothing about how encode vs decode is selected at runtime or what the response looks like.

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 operation, zero padding. Every clause earns its place.

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

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

For a trivial two-parameter utility the description covers purpose and cost, but the undocumented mode values and the absence of both an output schema and a stated return shape leave a real gap an agent must resolve by trial.

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 critical 'mode' parameter has no enum and no documented values, yet the description never states the accepted strings. An agent must guess whether to pass 'encode'/'decode', 'e'/'d', or similar, which risks an invocation error.

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 (encode/decode) and resource (base64 text) in both directions, so the tool's function is immediately obvious. It doesn't name sibling tools like bursia_url_encode or bursia_hash, so it relies on the name for differentiation.

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

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

Usage is implied by 'encode text to base64 or decode base64 to text', which tells the agent what operations are supported, but there's no explicit when-to-use vs the adjacent encoding siblings (url_encode, html_escape, hash) and no stated alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and 'Pure computation, free' corroborates that this is a side-effect-free, zero-cost operation. However, nothing is said about edge cases such as acronyms, digits, or what happens when an unrecognized 'to' value is supplied.

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 capability front-loaded and the cost/safety note trailing. 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 simple two-parameter pure function the description is nearly sufficient, but the missing exact enum tokens for 'to' and the lack of error behavior for invalid values leave a real gap an agent could trip on, especially with no output schema to infer from.

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 parameter meaning. It partially compensates by listing the accepted target formats, but never states the literal string values (e.g. 'kebab-case' vs 'kebab', 'snake_case' vs 'snake'), leaving an agent to guess exact tokens. 'text' is self-evident but undocumented.

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 (convert) and resource (text) and enumerates the exact target formats, which distinguishes it from siblings like bursia_slugify or bursia_base64 that also transform strings.

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 enumerated output formats, but there is no explicit when/when-not guidance and no routing away from neighboring text-transform tools. 'Pure computation, free' hints this is a safe local operation but doesn't select among alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the repeated 'Read-only' adds nothing, though 'free' contributes useful cost/rate-limit context. The description does not disclose what the check yields (boolean, status, fetched card contents) or how redirects/missing files are reported, leaving the agent guessing at the outcome shape.

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 front-loaded sentence naming the check and its exact paths, plus a two-word cost/safety tag – no filler. The mixed Spanish/English label is the only thing that makes the reader pause.

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

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

For a one-parameter, read-only probe with no output schema and full annotation coverage, the definition supplies the target endpoints, the input expectation, and the cost. Little else is needed 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?

There is a single parameter ('url', 'Domain or https URL') at 100% schema coverage, so the schema already does the work and baseline 3 applies. The description adds no detail on whether a bare domain is normalized, whether a full https URL must be well-formed, or whether subpaths are ignored.

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 (check) and resource (the A2A agent card at /.well-known/agent-card.json or /.well-known/agent.json), which distinguishes it from path-adjacent siblings like bursia_check_agents_json and bursia_check_llms_txt. It never names those siblings explicitly, and the Spanish phrase 'Ficha de agente A2A' is mildly jarring next to the English rest of the text, but the endpoints make the scope 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?

'Check one agent-readiness item' implies this is a single-item probe that feeds a broader readiness assessment, and the sibling bursia_agent_readiness exists for the aggregate case, but neither is stated. There is no when-not guidance, no note on which of the two well-known paths takes precedence, and no mention of prerequisites such as the site needing to be publicly reachable.

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=true, so 'Read-only, free' is largely redundant. The genuinely additive detail is the disclosure of both candidate paths, which tells the agent what is actually probed; however, nothing is said about what happens on 404/timeout or how the result is reported.

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 resource, with the path detail in parentheses where it belongs. 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 one-parameter read-only probe with annotations covering the safety profile, this is nearly sufficient; the only real gap is that with no output schema the description gives no hint of what a result looks like (present/absent, status, parsed content).

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

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

Single parameter at 100% schema coverage, and the schema already documents 'Domain or https URL'. The description adds no format or normalization guidance beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('Check') and a specific resource ('Directorio de agentes / agents.json'), and even names the two well-known paths probed. An agent can distinguish it from siblings like bursia_check_llms_txt or bursia_check_robots by the file it targets, though it never names those siblings explicitly.

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

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

'Check one agent-readiness item' implies this is a single-item check in a family that includes bursia_agent_readiness as the aggregate, but the description never says when to prefer the aggregator over this single check, nor any prerequisites (e.g., public site only).

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=true, so 'Read-only' simply repeats structured data. The only non-redundant detail is 'free', with no information on how a missing or malformed llms.txt is handled, whether the fetch follows redirects, or how errors surface.

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 target resource front-loaded after the verb, and zero filler. Nothing to trim and nothing 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?

The tool has no output schema, so the description is the only place to learn what a check returns (found/not found, status, content). It is silent on that, leaving an agent unsure how to interpret results, and it never mentions the aggregate tool it complements.

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 one parameter at 100% schema description coverage ('Domain or https URL'), the schema already carries the semantics. The description adds no further meaning, such as whether bare domains are normalized or whether path components in a URL are ignored — though baseline 3 applies when coverage is complete.

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

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

The description names a specific verb and resource: check the llms.txt file at /llms.txt on a public website, framed as 'one agent-readiness item'. That narrows it against the aggregate sibling bursia_agent_readiness without ever naming it, so the distinction is inferred rather than 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?

The phrase 'one agent-readiness item' implies this is a single check drawn from a larger readiness audit, which hints at usage context. It never states when to call this versus bursia_agent_readiness or the other per-artifact checks (robots, sitemap, agents.json), and gives no preconditions or exclusions.

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 and openWorldHint, so the safety profile is covered; the description adds only the useful 'free' cost signal and the list of probed paths. It says nothing about what a result looks like (found/not-found, HTTP status handling) or rate/timeout behavior for a network call.

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 front-loaded sentence that names the resource, the checked paths, and the safety/cost traits, with no 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?

For a one-parameter, network-touching checker this is mostly sufficient, but with no output schema the description should indicate what the tool returns (e.g. whether the path exists / a boolean readiness result) and how failures are reported. 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?

There is a single parameter at 100% schema coverage whose description ('Domain or https URL') already covers it, so the baseline is 4. The description adds that the target must be a public website, which slightly constrains the URL input 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 ('Check one agent-readiness item on a public website') and then names the exact MCP discovery endpoints probed, which distinguishes it from sibling checkers like bursia_check_agents_json or bursia_check_agent_card without opening any schema.

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

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

The phrase 'one agent-readiness item' implies this is a single-check building block within the bursia suite, but the description never names when to use it versus bursia_agent_readiness or the other check_* siblings, nor any preconditions such as requiring a publicly reachable domain.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine context by naming the exact paths probed and that there is no cost, but says nothing about what happens on a 404/timeout or what the result contains.

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 target, followed by a two-word cost/safety note. Nothing is wasted and nothing important 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 one-parameter probe with no output schema, the definition is adequate but incomplete: it doesn't indicate what a result looks like (found/not found, discovered URL, spec validity) or that a negative result is a normal outcome, which matters when interpreting a check 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% for the single 'url' parameter ('Domain or https URL'), so the schema carries the semantics. The description adds no format nuances beyond that (e.g., how bare domains are normalized to https).

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 ('Check') and a precisely scoped resource (the OpenAPI discovery endpoints /openapi.json and /.well-known/openapi.json on a public website). The phrase 'one agent-readiness item' implicitly separates it from the aggregate sibling bursia_agent_readiness and the other bursia_check_* probes, but never names 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?

Usage context is implied: it checks a single agent-readiness item, and 'Read-only, free' signals a cheap safe probe. However, it never says when to prefer this over bursia_agent_readiness (the aggregate) or the other check_* tools, nor any exclusions.

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=true, and 'Read-only, free' merely restates that. The description adds the 'public website' scope constraint, which is useful, but says nothing about what the result looks like (present/absent/invalid) for a check tool with 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?

One short sentence with the key scope and safety traits front-loaded; nothing is padded. The mixed-language fragment costs a little polish but no real 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 read-only single-URL check the essentials are present, but with no output schema the agent cannot tell what a response contains (a boolean, a file excerpt, a score) or how failures are reported. A sentence on the return shape would close the remaining 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?

Single parameter at 100% schema coverage, so the baseline is 3. The description adds no syntax detail beyond the schema's own 'Domain or https URL' note — e.g., it doesn't confirm both bare domains and full URLs are accepted and normalized.

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

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

States a specific verb and resource: checks the robots.txt agent-readiness item on a public site. That distinguishes it from siblings like bursia_check_llms_txt and bursia_check_sitemap, though the bilingual fragment 'robots.txt para agentes' is slightly awkward and adds no clarity.

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 'one agent-readiness item' implies this is a sub-check alongside bursia_check_agents_json, bursia_check_agent_card and bursia_agent_readiness, but no explicit when/when-not guidance or alternative routing is given. Usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so "Read-only, free" largely restates structured data and earns little credit. "On a public website" usefully confirms no auth is required. However, nothing is said about what happens when the sitemap is absent or malformed, or what the result looks like (no output schema exists), leaving meaningful behavioral gaps.

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

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

One short sentence, front-loaded with the action and the specific artifact checked, with zero filler. Nothing could be removed without loss.

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

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

For a single-parameter read-only checker the input side is fully covered, and annotations carry the safety profile. But with no output schema, the agent has no idea what a result contains (boolean presence, parsed entries, status codes), which is a real gap for deciding whether to call it or the aggregate 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 with 100% schema description coverage ("Domain or https URL"), so the baseline is 3. The description adds only the implicit note that /sitemap.xml is appended to whatever base URL is passed, which is mildly useful but not elaborated.

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 plus resource: it checks the sitemap.xml item at /sitemap.xml on a public site. That names the exact artifact, which implicitly separates it from siblings like bursia_check_robots or bursia_check_llms_txt. It never mentions the aggregate bursia_agent_readiness, so the relationship to the parent tool is left 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?

"Check one agent-readiness item" implies the context (auditing a site's agent-readiness) but gives no explicit when/when-not guidance. It does not tell the agent to prefer bursia_agent_readiness for a full audit or to run other check_* siblings alongside this one. Usage is inferable but not stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and "Read-only, free" merely restates that. The genuinely additive part is disclosing which endpoints are fetched (/.well-known/skills/index.json or /.well-known/agent-skills/index.json), which tells the agent what network probing occurs, but nothing is said about failure modes or result shape.

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 that leads with the action and the resource before the path detail. The trailing "Read-only, free" is minor filler that duplicates the annotations, keeping it just short of a 5.

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

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

With no output schema, the description should indicate what a check returns (found/not found, parsed content, errors), and it does not. The safety profile and target are adequately covered, but the result contract for a one-parameter probe tool 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?

Only one parameter with 100% schema coverage, so the schema already documents "Domain or https URL." The description adds the qualifier "public website," hinting that non-public/local targets are out of scope, but supplies no further format or normalization guidance. Baseline 3 applies when the schema carries the load.

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 (check) and a precisely scoped resource (the Habilidades/SKILL.md agent-readiness item), even naming the exact well-known paths probed. That endpoint specificity is what separates it from siblings like bursia_check_llms_txt, bursia_check_agent_card, or bursia_check_agents_json without the agent needing to open any schema.

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

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

"Check one agent-readiness item" implies this is the granular, single-check tool versus the aggregate bursia_agent_readiness, but no alternative is named and no when-to-use/when-not condition is stated. The agent must infer the routing from the word "one".

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 and openWorldHint, and the description's "Read-only, free" largely restates that, though "free" adds the useful fact that no key or quota applies. It does not say what a negative result looks like (missing file vs. malformed content), whether both paths are tried, or whether redirects/HTTP errors are surfaced — meaningful gaps for a network probe.

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 scope, followed by the concrete probe targets and the safety/cost note. Nothing is redundant or padded.

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

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

For a one-parameter read-only probe with full schema coverage and annotations, the description covers what is checked and the cost/safety profile. The only shortfall is the absence of any hint about the shape of the result (found/not-found, discovered endpoints), which an agent must infer since no output schema exists.

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

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

Schema coverage is 100% and the single param is documented as "Domain or https URL", so the schema does the work; the description adds nothing about accepted forms (bare domain vs. path vs. trailing slash). 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 (check) and a narrowly scoped resource (the x402 agent-readiness item), and names the exact well-known paths it probes (/.well-known/x402 and /.well-known/x402.json). This distinguishes it cleanly from the many sibling checkers (bursia_check_agents_json, bursia_check_llms_txt, bursia_check_mcp_discovery) without needing 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?

"Check one agent-readiness item" implies this is the single-item probe and that bursia_agent_readiness is the aggregate, but the alternative is never named and no when-not condition is given. An agent can infer the relationship but must guess rather than be routed.

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; the description adds that it is 'pure computation, free', reinforcing that it needs no network or auth. It says nothing about invalid-CIDR behavior or the output format, so it is a modest supplement rather than a full behavioral picture.

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, front-loaded with the returned values and no filler. The verbless fragment style is slightly terse 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?

With no output schema, the description usefully enumerates what comes back, and the single-parameter scope is clear. Only error/invalid-input behavior is missing, a minor gap for a deterministic computation 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 0%, so the description carries the burden for the single 'cidr' param. Saying 'an IPv4 CIDR block' does clarify the expected input format (IPv4 CIDR, not a range or IPv6), which compensates partially, but notation details such as whether host bits are allowed are left unstated.

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 the exact outputs (network, broadcast, first/last host, size) for an IPv4 CIDR block, so an agent knows precisely what it returns. It does not differentiate itself from the adjacent sibling bursia_ip_classify, which also operates on IPs, 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?

There is no statement of when to use this versus bursia_ip_classify or any other sibling, and no exclusions. 'Pure computation, free' hints at cost/offline safety but gives no selection 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 and openWorldHint=false, so the safety profile is covered; the description still adds genuinely new information with 'pure computation, free', telling the agent there is no side effect, no network dependency, and no billing. It does not state how malformed hex input is handled, which keeps it below 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 plus a short qualifier, with the core action front-loaded and the operational note last. Nothing is padded or repeated from 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?

With no output schema, the description appropriately names the three values returned (RGB, HSL, relative luminance) so an agent knows what it will get back. The remaining gaps are the exact input hex format and the shape/naming of the response object, which are minor for a one-argument pure function.

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 parameter is documented only as type string, so the description carries the burden for the hex parameter. It confirms the input is a hex color but adds nothing about accepted forms (with or without a leading '#', three-digit shorthand, case), which is the main usable detail an agent would want.

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

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

The description names a specific verb (convert) and resource (hex color) and enumerates the outputs: RGB, HSL, and relative luminance. It is immediately distinguishable from most siblings, though it never mentions the adjacent bursia_contrast_ratio tool, so sibling differentiation is only implicit.

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 by the purpose: an agent with a hex value that needs other color representations will infer this is the tool. There is no explicit when-to-use framing and no statement of when to prefer bursia_contrast_ratio instead for WCAG-style comparisons.

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 and openWorldHint, and the description goes further: it says the same audit runs on every site (uniform methodology), that results are ordered by impact, and that no cost is involved. What it doesn't cover is return format/depth or latency for auditing 4 live sites.

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: what it does, how it works, what you get back, then the cost/safety note. The core comparison is front-loaded and nothing is repeated or padded.

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

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

With no output schema, the description carries the burden of describing returns, and it does: a ranking, impact-ordered gaps, and your advantages. For a one-parameter tool this is nearly complete; only the response shape details (scores, per-site breakdown) are left 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 coverage is 100% and already documents the comma/space-separated 2-4 URL format with 'yours first'. The description only echoes the upper bound ('up to 3 competitors'), adding no new syntax or constraint information, so the baseline 3 applies.

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

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

States a specific verb (compare) and resource (AI-agent readiness of your site vs competitors) and makes the multi-site scope explicit with 'up to 3 competitors'. It implicitly distinguishes itself from the single-site sibling bursia_agent_readiness, though it never names that sibling to make the split 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?

Usage is implied by 'Compare your website with up to 3 competitors', and 'Read-only, free' signals low-risk invocation. However, there is no explicit statement of when to pick this over bursia_agent_readiness or the individual check_* tools, and no prerequisites beyond the ordering hint.

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. The description usefully adds that this is pure computation and free, reinforcing the no-side-effect profile, but it does not explain invalid-input behavior or the exact output structure.

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 words. The core function and the output flags are front-loaded, and the pricing/side-effect note is compact.

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 read-only computation tool, the description covers what it computes, that it returns AA/AAA flags, and that it is free and pure. However, with no output schema and 0% parameter schema coverage, it should say more about input format and the exact returned values.

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 for undocumented parameters. It says the inputs are "two hex colors," but does not specify whether a leading # is required, whether 3/6/8-digit forms are accepted, or how alpha is handled.

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

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

The description names a specific computation (WCAG contrast ratio) over a specific resource (two hex colors) and mentions the AA/AAA pass flags. It is clearly distinguishable from a general color converter, though it does not explicitly name the sibling color tool.

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 or when-not-to-use guidance, and no alternative tool is mentioned. "Pure computation, free" describes cost and side-effect profile rather than usage conditions.

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, and the description corroborates with "Pure computation, free," signalling no auth or cost. It also adds a constraint the annotations don't cover: only 5-field expressions are supported, and run times are reported in UTC with a fixed count of 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?

Two short sentences, zero filler, with the core action and output front-loaded before the cost/behavior note. Every clause earns its place.

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

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

With no output schema, the description does the necessary work of naming both return components and the timezone. The only missing piece is what happens on an invalid or malformed expression, which matters for a tool whose sole input is a free-form string.

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 single parameter is undocumented in structured form; the description partially compensates by specifying the expected format is a 5-field cron expression. It gives no example syntax, field ranges, or handling of 6-field (seconds) expressions, so compensation is incomplete.

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 (Explain) and resource (5-field cron expression) plus the exact deliverable (plain-English explanation + next 5 run times in UTC). No sibling tool does anything cron-related, so the agent can select it unambiguously.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named; usage is only implied by the stated purpose. In practice there is no competing cron sibling, so the gap is low-risk but still 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 and openWorldHint=false, and the description reinforces this with "Pure computation, free" — telling the agent no network call, no auth, no cost. The hard 5,000-row limit is a concrete behavioral constraint beyond the annotations. It omits error behavior for malformed CSV or mismatched column counts, keeping it 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?

Three short sentences, zero filler, with the core transformation front-loaded and the limit and cost profile trailing. Nothing repeats the tool name or schema verbatim.

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 should clarify the return shape, but "JSON rows" leaves open whether the result is an array of objects keyed by header names or arrays of values. The undocumented `separator` and unstated error behavior are also gaps for an otherwise simple two-parameter tool.

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

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

Schema coverage is 0%, so the description must carry the parameter burden. It clarifies the `csv` parameter's expected shape (first row = headers), but the `separator` parameter is never mentioned — no default, no accepted values, no note that it overrides comma detection.

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 ("Convert CSV ... into JSON rows") plus the header convention, which pins down the exact transformation. The direction is unambiguous relative to the inverse sibling bursia_json_to_csv, so an agent can pick between them 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?

Usage is only implied by the transformation described; there is no explicit "use this when..." statement or pointer to bursia_json_to_csv for the reverse case. The 5,000-row cap gives a useful boundary but is a limit, not a selection 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=true and openWorldHint=false, so the safety profile is covered. The description adds that the operation is pure computation and free, which reinforces the absence of side effects and cost, but it does not disclose date parsing behavior, timezone handling, or what happens if the inputs are reversed.

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 operation and output units, with zero wasted language. The cost/computation note is brief and relevant.

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 two-parameter computation tool with read-only annotations and no output schema, the description is close to adequate and usefully names the output units. However, the missing input date format and edge-case behavior are notable gaps for a tool with 0% schema description coverage.

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

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

Schema description coverage is 0%, so the description must compensate for the two required parameters. It only indicates that the inputs are 'dates' and does not specify accepted formats (e.g., ISO 8601, date-only, timestamps) or ordering semantics, leaving an agent unable to invoke the tool with confidence.

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 operation and resource: computing the difference between two dates, with output units (days, hours, minutes). This is clear enough for an agent to distinguish it from conversion-oriented siblings like bursia_timestamp_convert or bursia_timezone_convert, though it does not explicitly name 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 phrase 'Pure computation, free' hints that the tool has no side effects or cost, but there is no explicit guidance on when to use this versus sibling tools such as bursia_timestamp_convert or bursia_timezone_convert. No prerequisites, exclusions, or alternative-selection criteria are 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=true and openWorldHint=true, so the safety profile is covered. The description does add two useful nuggets beyond that: only public records are queried and the call is free (no key/auth/cost). It says nothing about caching, rate limits, NXDOMAIN/error behavior, CNAME following, or whether multiple records are 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, front-loaded with the core action and the acceptable record set, with zero filler. Every sentence earns its place.

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

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

For a single-parameter read-only lookup with full schema coverage and no output schema, the description covers purpose, scope (public only), and cost. It stops short of describing the shape of the response (single value vs. record set) or failure modes, which would help an agent parse results.

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

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

Schema description coverage is 100% and the single parameter is already documented as 'Domain or https URL'. The description adds no extra meaning about the parameter, so the baseline 3 applies.

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

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

States a specific verb ('look up') and resource ('public DNS records') and even enumerates the record types covered (A, AAAA, MX, TXT, NS, CAA). The function is unambiguous and distinct from any sibling, but it does not explicitly contrast itself with adjacent lookups such as bursia_tls_certificate.

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 contextual remark is 'Free.', which is a pricing note rather than usage guidance. There is no statement of when to use this versus alternatives, no prerequisite/permission discussion, and no hint about when NOT to use it (e.g. private/internal zones).

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 `readOnlyHint: true` annotation, the description adds behavioral context by stating it is 'Pure computation' and 'free'. This manages user expectations regarding external dependencies or costs, which is helpful operational transparency.

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, highly effective sentence that encapsulates the entire tool's function and limitations efficiently. Every word contributes to clarifying the tool's boundaries.

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 low complexity and single parameter, the description is complete. It provides the necessary guarantees (no network calls, pure computation) and limitations (syntax only, no lookup) that an agent needs to use 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%, but since there is only one parameter and it is clearly named 'email', the description does not need to define the input value. It is optimally concise, earning a high score without repeating schema data.

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 ('Check') and clearly defines the target resource ('email address'). It distinguishes the function by stating it checks syntax, differentiating it from potential lookup or sending 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?

It provides explicit usage constraints by stating what it does not do ('no mailbox lookup, nothing is sent'). This helps the agent decide immediately if this tool fits the user's specific request for verification vs. validation or sending.

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 safety is covered; the description adds useful context that it is pure computation with no cost. It also discloses the hex output encoding, but says nothing about determinism guarantees, accepted text encoding, or default algorithm 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 operation plus accepted algorithms are front-loaded before the 'pure computation, free' qualifier.

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 usefully notes hex output, and the annotations cover the safety profile. The main omission is the default/optionality of the algorithm parameter, which matters for correct invocation of a 2-parameter tool.

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

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

Schema coverage is 0%, so the description must carry the load and it partially does by listing the four accepted algorithm values. However, it never states whether 'algorithm' is optional or what the default is, and gives no constraints on 'text' (length, encoding), leaving real 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 ('Hash') and resource ('a text') and enumerates the supported algorithms, so the agent knows exactly what computation happens. It does not name the nearest sibling (bursia_hmac, the keyed variant), so a subtle ambiguity remains, but the purpose itself is unmistakable.

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?

'Pure computation, free' implies no key, no network, no side effects and hints at the distinction from an HMAC tool, but the alternative is never named and there is no explicit when-to-use/when-not statement. Usage is inferable rather than stated.

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

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

With readOnlyHint=true and openWorldHint=false already declared, the description adds genuine non-obvious context: nothing is stored or logged, it is pure computation, and it has no cost. That is exactly the kind of extra assurance worth adding on top of annotations, though the default algorithm when omitted is left undisclosed.

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

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

Three short sentences, front-loaded with what it computes, then the safety note, then the cost note. No filler and nothing repeats 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 a small, single-purpose pure-compute tool with no output schema, the description covers inputs, output encoding, safety, and cost. Only the default algorithm behavior is missing, which is a minor but 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 coverage is 0% and there are no enums, so the description has to carry the load — and it does, naming all three parameters' roles and enumerating the valid algorithm values (sha256, sha512) plus the hex output format, which the schema omits entirely. The one gap is that the default/optional status of 'algorithm' is never stated.

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 ('Compute an HMAC ... of a message with a key') plus the supported algorithms and output encoding (sha256/sha512, hex), which cleanly separates it from the plain-hash sibling bursia_hash. It does not explicitly name that sibling, so differentiation is inferential rather than 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?

'Use test keys only' is a real usage constraint, and 'pure computation, free' sets expectations, but neither sentence tells the agent when to pick HMAC over bursia_hash or bursia_base64. Usage is implied by the verb rather than explicitly routed.

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, and 'Pure computation, free' corroborates that this is side-effect-free with no cost. Beyond that it adds nothing about output shape or the effect of the mode switch.

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

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

Two short sentences, front-loaded with the action and followed by an operational note. No wasted words.

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

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

For a simple two-param tool this is close, but the undefined 'mode' parameter is a genuine gap given 0% schema coverage and no output schema, and it determines which of the two advertised operations actually runs.

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 nothing documents the two parameters. The description never mentions the 'mode' parameter at all, leaving the agent to guess its accepted values (escape vs unescape) and whether it is required or has a default.

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 (escape/unescape) and resource (HTML special characters), which is clear and distinct from siblings like bursia_url_encode or bursia_base64. It doesn't explicitly contrast with those siblings, but the resource scope is unambiguous.

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

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

Provides no guidance on when to choose this over bursia_url_encode or other encoding siblings, and does not say when to escape versus unescape. Only the ambient 'free' note hints at 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 already declare readOnlyHint=true and openWorldHint=false, and 'Pure computation, free' reinforces the no-side-effect, no-cost profile consistently. However, nothing is said about what happens on a malformed input (error vs. valid=false) or what the returned fields look like.

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 waste; the core action is front-loaded and the 'pure computation, free' qualifier is a compact, useful signal about cost and safety.

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

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

For a trivial one-param tool this is close to sufficient, but with no output schema the description should say what is returned (boolean? country code? reason for failure). 'Report its country' hints at it but leaves the return shape ambiguous.

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 one parameter with 0% schema description coverage, so the description carries the burden. The single string named 'iban' is largely self-explanatory, but the description adds no guidance on accepted format (spaces, lowercase, country prefix) — a real gap given the zero coverage.

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

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

States a specific verb (validate) and resource (IBAN checksum) plus a secondary output (country), which is far more informative than the bare name. It is distinguishable from siblings like bursia_luhn_check, though it never names that alternative 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: an agent infers this is the tool for checking IBAN validity. There is no statement of when to prefer it over related validators (luhn_check, email_syntax) or of any exclusions or preconditions.

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; the description reinforces this with 'Pure computation, free,' telling the agent the call is offline, side-effect-free and costless. It adds genuine context rather than restating the hints, though it says nothing about behavior on malformed input.

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: what it returns is front-loaded, and the secondary note about cost and locality is a short trailing clause. 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 one-parameter pure function with no output schema, the description effectively enumerates the return categories, which is the main thing an agent needs. Only the accepted input formats and invalid-input behavior are 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 0%, so the description must carry the load, and it only implies the single parameter is an address. It does not say whether IPv6 is accepted or whether CIDR notation is allowed -- a relevant ambiguity given the sibling bursia_cidr_info exists.

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 (Classify) and resource (an IP address) and enumerates the exact labels returned: version plus public/private/loopback/link-local/reserved. That makes it clearly distinguishable from siblings like bursia_cidr_info or bursia_dns_records, though it does not name 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?

Usage is implied by the purpose -- reach for this when you need to categorize a single address -- but there is no explicit when-to-use, when-not-to-use, or pointer to bursia_cidr_info for subnet-level questions. The agent must infer the boundary itself.

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?

Annotation readOnlyHint=true plus openWorldHint=false already establish that this is a safe, closed-world read, and 'pure computation, free' reinforces that with cost/side-effect context the annotations do not carry. The 'max 500' cap is a genuinely useful disclosure about output truncation. However, nothing is said about what happens on invalid JSON input, what the path notation looks like, or whether arrays are compared by index or content.

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 plus a short qualifier; zero filler, and the core capability is front-loaded before the cost/limit note.

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

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

For a two-input pure function with no output schema, the description says what shape the result takes (added/removed/changed paths) and notes the 500 cap, which covers the essentials. It omits input encoding expectations and truncation semantics (are extra diffs dropped, or is an error returned), which matter 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 0% and the two parameters are bare 'type: string' with no descriptions. The phrase 'two JSON documents' gestures at before/after, but with JSON documents normally being objects, an agent is left guessing whether it must pass serialized JSON strings or raw objects — a real failure mode for a single required parameter mistake. The description does not close that 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?

Specific verb + resource + output shape: 'Compare two JSON documents and list added, removed and changed paths'. It clearly separates itself from siblings like bursia_json_format, bursia_json_validate and bursia_json_path, which operate on a single document or extract a path rather than diffing 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?

Usage is implied (use it when you have a before and an after JSON document), and 'pure computation, free' signals there is no cost or side effect to worry about. But no alternatives are named and no exclusions or preconditions are given, e.g. nothing tells the agent to validate malformed inputs first or to prefer bursia_json_path for single-document queries.

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. The description adds 'Pure computation, free', confirming no side effects or cost, but does not explain accepted mode values, error behavior, or output shape.

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 core action and followed by a useful operational note. It is efficient, though borderline terse given the undocumented 'mode' parameter.

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 two-parameter formatting tool, the description still omits critical calling information: what values 'mode' accepts, whether invalid JSON produces an error, and what the return value looks like in the absence of an output schema.

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

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

Schema description coverage is 0% for both parameters. The description implies a mode distinction between pretty-print and minify but never states accepted values for the 'mode' field or clarifies the expected JSON input format, leaving the semantics underspecified.

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(s) and resource: 'Pretty-print or minify JSON'. This clearly distinguishes the tool from JSON validation, diffing, or path extraction, though it does not explicitly name those 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?

'Pretty-print or minify' implies when to use the tool for formatting, but there is no explicit guidance on when to choose this over siblings like bursia_json_validate or bursia_json_diff. The 'free' note is contextual, not usage 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 and openWorldHint=false, so safety is covered. "Pure computation, free" usefully confirms no cost or side effects, but the description omits what happens when the path doesn't resolve or the JSON is malformed, which matters for a path extractor.

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, operation first, with zero filler. The path example is the highest-value information and is 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?

The tool is narrow and annotations cover safety, but with no output schema the description should say what is returned (raw value, stringified, or error on missing path). Error semantics and the json-string input format are the remaining 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 0%, so the description must carry the load; the path example "a.b[0].c" is genuinely valuable for the path parameter. However, it leaves the json parameter ambiguous — the schema types it as a string but the description doesn't clarify it is a JSON-encoded string rather than an object.

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 ("Read a value from JSON") plus the path syntax, which separates it from siblings like bursia_json_format, bursia_json_validate and bursia_json_diff. It doesn't explicitly name a sibling, but the read-a-single-value framing is distinctive enough.

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 over bursia_json_format or bursia_json_validate, and no mention of behavior on invalid paths. Usage is only implied by the description of the operation.

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 safety profile is covered. The description reinforces this with 'Pure computation, free', adding cost and no-side-effect context beyond the annotations, but it does not describe output format, escaping behavior, or error handling.

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 waste and the core purpose front-loaded. Every phrase contributes useful 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 simple pure-computation tool with annotations covering safety and no output schema, the description is nearly complete. It could say more about the returned CSV shape, but the essential behavior is conveyed.

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

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

The single parameter has 0% schema description coverage, so the description must compensate. It does clarify that the input should be a JSON array of objects, which is meaningful beyond the schema's bare 'type: string', but it does not address nesting, key ordering, or CSV escaping semantics.

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

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

The description states a specific verb and resource: converting a JSON array of objects into CSV. This makes the direction of conversion clear and implicitly distinguishes it from the sibling csv_to_json tool, though no sibling is explicitly named.

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 conversion direction, and 'Pure computation, free' indicates it is safe and costless. However, there is no explicit guidance on when to choose this over csv_to_json or other formatting tools, nor any stated preconditions.

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 safety is covered. The description adds genuinely new context beyond the annotations: it discloses the return content (error position, or top-level type and size) and that the call is 'pure computation, free' — useful cost/latency information an agent can factor into planning.

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 front-loaded sentence that states the action, the return shape, and the cost profile with zero filler. Nothing extraneous and nothing 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 single-parameter pure validator with no output schema, the description covers what it does, what comes back (including the failure case), and that it is free. Only meaningful gap is the absence of any guidance on JSON dialect/strictness expectations, which is minor for this tool class.

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 one required parameter at 0% schema description coverage, so the description must carry the weight. 'Check whether a text is valid JSON' implies the input is the text to validate, but adds no detail on encoding, size limits, or whether whitespace/duplicates are tolerated — adequate but thin.

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 whether a text is valid JSON'. The added note about what it returns (error position or top-level type and size) makes it clearly distinct from formatting/diffing siblings like bursia_json_format or bursia_json_diff, though those siblings are never named.

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: an agent can infer this is the tool to reach for when it needs to know if a string parses as JSON. There is no explicit when-to-use vs when-not, and no pointer to bursia_json_format for pretty-printing or bursia_json_path for querying.

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

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

With readOnlyHint=true and openWorldHint=false already declaring the safety profile, the description still adds a substantive behavioral fact not in the annotations: the signature is NOT verified, so results are untrusted. The 'pure computation, free' note adds cost/latency context. Missing only notes on malformed-token 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 clauses, front-loaded with the operation and the most important caveat (no signature verification) before the safety warning and cost note. 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 one-parameter, no-output-schema tool this covers operation, trust level, and safety. The one gap is return shape — whether the result is a JSON object with separate header/payload fields or raw text — which the absent output schema leaves undocumented.

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% for the single 'token' parameter, so the description must carry the semantics. 'Decode a JWT header and payload' implies the input is a JWT string, but it does not state the expected format (compact JWS, three dot-separated segments) or what happens with a non-JWT input.

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 (Decode) and resource (JWT header and payload) and immediately delimits scope with 'WITHOUT verifying its signature'. An agent can tell exactly what operation it is getting, and no sibling among the many conversion/validation tools overlaps with JWT decoding.

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?

'Do not paste live secrets' gives a clear usage constraint, and the absence of any JWT verification tool in the sibling list means there is no alternative to route away from. It stops short of explicitly saying when to reach for this versus, e.g., a JSON formatter on a decoded payload, 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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine context beyond those fields – a 2,000-char input cap and a cost profile ('free', 'pure computation', implying no external calls or rate limits). It stops short of describing the return shape (single distance value, similarity ratio, or both) or how similarity is scaled, which is the main behavioral 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?

One tight sentence with the primary concept ('Edit distance and similarity') front-loaded, followed by the size constraint and cost note. Nothing extraneous, though the parenthetical could be ordered to pair with the parameter list.

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, annotation-covered computation tool this is close to sufficient, but two things an agent needs are missing: which distance metric is computed (Levenshtein algorithm details like substitution vs transposition cost) and what the response contains (distance and/or similarity, and similarity's scale). With no output schema, the description is the only place to state those.

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% with two required string params named only 'a' and 'b', so the description must carry the meaning. It does communicate 'two texts (max 2,000 chars each)', which covers the shared constraint of both parameters, but it doesn't clarify which is source vs target, whether order affects output, or per-parameter semantics.

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

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

States a specific verb-equivalent ('edit distance and similarity') and resource ('two texts'), which clearly distinguishes it from siblings like bursia_text_stats or bursia_json_diff. It never names the metric explicitly (Levenshtein is only in the tool name), so it's clear but not fully self-contained, and no sibling is named for contrast.

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-to-use guidance and no alternatives are named, despite 'bursia_text_stats' and 'bursia_json_diff' existing as plausible mistaken choices. The only guidance-adjacent content is the implied constraint 'max 2,000 chars each' and 'pure computation, free', which hints at cost but doesn't route the agent between tools.

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

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

With readOnlyHint=true and openWorldHint=false already declared, the description adds useful behavioral context beyond annotations: 'Pure computation, free' confirms no external calls or cost, and 'Do not send real card numbers' is an important privacy warning. It does not describe the return value or error behavior, but the annotations already cover the safety profile.

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 zero waste, front-loading the purpose before adding privacy and cost notes. Every sentence earns its place and the structure is easy to scan.

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 single-parameter validator with annotations and no output schema, the description covers purpose, safety, and cost. It could be slightly more complete by indicating the return value (e.g., valid/invalid boolean), but it is otherwise sufficient 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 0%, so the description must compensate for the single required 'number' parameter. It provides examples (cards, IMEI) but does not clarify input format details such as whether spaces, hyphens, or non-digit characters are accepted. This is minimum viable parameter guidance.

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: 'Validate a number with the Luhn checksum', and adds concrete examples ('cards, IMEI') that distinguish it from sibling validators such as iban_validate or email_syntax. An agent can immediately tell what this tool does and when it 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?

The description gives clear usage context through the examples ('cards, IMEI') and a privacy warning ('Do not send real card numbers'), but it does not explicitly name alternatives or state when not to use this tool versus another validator. The implied usage is strong, though not fully explicit about alternatives.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real context on top by naming the external host contacted and summarizing the return payload (names, descriptions, remote URLs) and cost ('Free'). It omits result-count limits or pagination behavior, 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 short, front-loaded sentences: action, return shape, cost. Nothing is wasted, though the one-word 'Free.' sentence is clipped and could have been folded into the previous sentence for smoother structure.

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

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

For a one-parameter read-only search with no output schema, the description covers what the tool does, where it goes, and roughly what comes back. Missing only operational detail such as result limits or pagination, which is a modest gap rather than a blocker.

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

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

The single parameter is fully described in the schema (100% coverage), so the baseline of 3 applies. The phrase 'matching a text' slightly reinforces that query is free-text rather than an ID, but adds no syntax, filtering, or matching-rule details.

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

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

States a specific verb+resource ('Search the official MCP Registry') plus the concrete upstream endpoint (registry.modelcontextprotocol.io), and scopes it to text-matching servers. No sibling performs registry search, so no disambiguation is needed and an agent can identify the tool immediately.

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

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

Usage is implied by the purpose — use it to look up MCP servers by text — but the description never says when to prefer it over adjacent siblings like bursia_check_mcp_discovery or bursia_agent_readiness, nor does it state any prerequisites or exclusions. 'Free' hints there is no key/cost barrier, which is useful but indirect.

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, but the description adds meaningful context beyond them: 'Nothing is stored' clarifies persistence behavior and 'Pure computation, free' rules out side effects and cost. It stops short of disclosing the character set or default length, which are the remaining behavioral unknowns.

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 capability plus length constraint is front-loaded before the non-storage caveat.

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-optional-parameter utility with annotations covering the safety profile and no output schema, this is nearly complete. The only gaps an agent might care about are the default length and the character-class guarantees of the output.

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, and it does supply the valid range (8-128 chars) that the schema omits. However, it never states the default when 'length' is omitted, nor the generated character composition (symbols, casing, ambiguity exclusions).

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 a random password') plus scope ('8-128 chars') and implementation quality ('cryptographic generator'). This is clearly separable from the sibling utilities like bursia_uuid and bursia_hash, which produce different artifacts.

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 reach for this tool versus alternatives (e.g., a UUID for identifiers) and no preconditions or exclusions. The agent must infer the use case from the name and purpose 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 and openWorldHint, so the safety profile is covered. The description adds operationally useful context beyond that: it performs a live GET, does not follow redirects (a real behavioral trait that affects results), and is free of charge. It doesn't describe output shape, but that is minor given the explicit header list.

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

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

Two tight sentences: the operation and covered headers are front-loaded, followed by operational constraints and cost. 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 single-parameter read-only audit with no output schema, the description supplies the essentials: what is fetched, what is evaluated, and the no-redirect behavior. The absence of any note on return format or result granularity is the only gap, and the header enumeration largely compensates.

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

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

Schema coverage is 100% and the single 'url' parameter is fully documented as 'Domain or https URL'. The description adds a marginal constraint (HTTPS only), but otherwise the schema carries the parameter explanation, 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 (audit) and resource (HTTP security headers), and enumerates exactly which headers are checked (HSTS, CSP, X-Content-Type-Options, frame protection, Referrer-Policy, Permissions-Policy). This clearly distinguishes it from siblings like bursia_tls_certificate and bursia_dns_records without needing to open any schema.

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

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

Sets clear preconditions for use: the target must be a public HTTPS page, and it clarifies that no redirects are followed. It stops short of naming alternatives or exclusions (e.g., 'use tls_certificate for certificate chain issues'), so the agent must infer sibling 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=true and openWorldHint=false, so safety is covered; the description adds that it is free and purely computational, reinforcing the no-side-effect nature. It does not disclose how invalid or non-semver inputs are handled, which is the main behavioral question for a parser of this kind.

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, front-loaded with the operation and its return values, with no filler. It is appropriately sized for a simple pure function, though it wastes a slot that could have carried operand ordering.

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

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

There is no output schema, and the description does cover the return contract (-1, 0, 1), which is a real strength. It is still incomplete for a 2-param tool with zero schema documentation because argument ordering and invalid-input behavior are left 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% and the description never mentions the parameters at all. Critically, it does not say which operand is 'a' and which is 'b', so an agent cannot infer the sign convention (a<b → -1) from the description alone.

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

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

States a specific verb (compare) and resource (semantic versions) and even specifies the result domain (-1, 0, 1). No sibling covers semver, so no differentiation is needed, but it stops short of spelling out ordering semantics (prerelease/build metadata rules) that would make the purpose fully 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 phrase 'pure computation, free' implies the agent can call it liberally without side effects or cost, which is a useful signal. However, there is no explicit guidance on when to use this versus doing a string equality check or a different comparison tool, and no stated prerequisites or excluded cases.

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 safety profile is covered. The description still adds real context beyond that: "pure computation" confirms no network/side effects and "free" discloses cost, which is not encoded 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 short sentences, the purpose front-loaded and the cost/behavior note second. Every clause carries information; nothing is padded.

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

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

For a one-parameter, no-output-schema utility the definition is minimally sufficient: the agent knows the input is text and the result is a slug. It omits the transformation rules and any example output, which for a slugifier are the details most likely to surprise a caller.

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% for the single `text` parameter, so the description carries the burden of explaining it and does not. It says nothing about slugification rules an agent would need to predict output — lowercasing, diacritic stripping, separator choice, or max length.

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?

"Turn a text into a URL-safe slug" gives a specific verb (turn into) and a specific output artifact (URL-safe slug), which an agent can distinguish from neighbors like bursia_url_encode (percent-encoding) or bursia_case_convert. It stops short of naming those siblings explicitly, so differentiation is inferential rather than 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?

"Pure computation, free" implies the tool is safe to call at will and needs no credentials, which is a light usage signal. There is no explicit when-to-use guidance and no mention of when an alternative (e.g., url_encode, case_convert) would be the better pick.

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 safety is covered; the description adds genuinely new behavioral facts — that execution is pure computation with no cost or external dependency. It stops short of stating determinism, size limits, or how the token estimate is derived beyond the ~4 chars/token heuristic.

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 compact clauses, front-loaded with the operation and its outputs, with the operational note trailing. No filler, nothing repeated from the schema or annotations.

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

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

For a one-parameter utility with no output schema, the description enumerates the returned metrics (chars, words, lines, tokens) plus the token heuristic, which is nearly all an agent needs. Only the exact result shape and edge-case behavior remain unstated, 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 description coverage is 0%, but the single required parameter is named "text" and the description says counts are computed "of a text," so its meaning is effectively conveyed. No detail is added on accepted encoding, empty input, or whether whitespace-only lines count, so it does not fully compensate for the coverage gap.

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

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

States a specific verb (count/estimate) and enumerated outputs (characters, words, lines, tokens) for a clearly scoped resource: a text input. It is trivially distinguishable from siblings like bursia_levenshtein, bursia_slugify, or bursia_case_convert, which transform or compare text rather than measure 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?

"Pure computation, free" signals the operational context (no network, no billing, no side effects), which helps an agent decide to call it casually. However, it never states when to prefer this over alternatives or any exclusions/edge cases (empty string, unicode, large inputs), 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?

'Pure computation, free' usefully adds that there are no side effects and no cost/rate limit, going beyond the readOnlyHint/openWorldHint annotations. However, it does not disclose how ambiguity between seconds and milliseconds is resolved, what the output looks like, or timezone assumptions for ISO 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?

Two short, front-loaded sentences with zero filler; the operation and the cost profile are each stated once.

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 and annotations cover safety, but with no output schema the description should state the return format (direction of conversion, ISO timezone/offset) and the seconds-vs-milliseconds disambiguation rule. Those gaps are the main risk 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 0% for the single 'value' parameter, but the description does clarify that it accepts either a Unix timestamp or an ISO 8601 string. It omits how the tool distinguishes numeric seconds from milliseconds and whether an explicit mode is possible.

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

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

Names a specific verb and resource plus the exact formats involved ('Unix seconds/milliseconds' and 'ISO 8601'). It is clear what the tool does, though it never distinguishes itself from the closely named sibling bursia_timezone_convert.

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 no when-to-use or when-not-to-use guidance, and no mention of alternatives such as bursia_timezone_convert or bursia_date_diff, which an agent could easily confuse with this tool. The format list only weakly implies the 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 already declare readOnlyHint=true and openWorldHint=false; the description reinforces this with 'pure computation, free,' which usefully confirms no cost or side effects. It does not disclose the return shape (no output schema) or any errors for invalid zone identifiers.

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 plus a short qualifier, front-loaded with the action and scope. Nothing is wasted and the example zone lands early.

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

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

For a two-parameter pure-compute tool the bar is modest, and the description covers purpose and zone format. However, with no output schema and no parameter descriptions, it should state the accepted datetime format and what the returned value looks 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 description coverage is 0%, so the description must carry parameter meaning. It clarifies that timeZone takes an IANA identifier and gives an example, but leaves the required 'datetime' parameter completely undefined (ISO 8601? local? offset? epoch?), a critical gap for a conversion tool.

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

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

States a specific verb and resource ('Show a date/time in another IANA time zone') with a concrete example zone. The scope is unambiguous and separable from the sibling bursia_timestamp_convert, though it never names that 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?

No explicit when-to-use/when-not guidance or named alternative. The phrase 'date/time' implicitly contrasts with the timestamp-based sibling, and 'pure computation, free' hints it needs no network or auth, but the agent must infer which of the two conversion tools to pick.

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

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

Annotations already cover readOnly and openWorld, and the description adds real value on top: it discloses that it connects only to the verified public IP (an SSRF-safety behavior an agent should know) and that the call is free. It stops short of describing failure modes, timeouts, or redirect/port handling.

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

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

Three short sentences, front-loaded with the action and return payload, followed by the two constraint facts. No filler and nothing 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?

With no output schema, the description usefully enumerates what comes back and states the target restriction and cost, which is enough to invoke it correctly. Minor gaps remain around error behavior and non-standard ports, but nothing essential is missing for a one-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?

Schema coverage is 100% and the single 'url' parameter is documented as 'Domain or https URL'. The description reinforces the constraint with 'public HTTPS host' but adds no format, normalization, or edge-case detail 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 ('Read the TLS certificate of a public HTTPS host') and enumerates the returned fields (issuer, subject, validity dates, days left, SANs, protocol). This is unmistakably distinct from siblings like bursia_dns_records or bursia_security_headers.

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 target scope is clear ('public HTTPS host'), and 'Free' plus 'Connects to the verified public IP only' implies the intended safe, non-authenticated lookup use. However, it never says when to choose this over neighboring network-inspection tools or what to do for private/non-HTTPS hosts.

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 safety profile is covered. The description adds meaningful context beyond annotations: 'pure computation' implies determinism/no side effects, and 'free' communicates no cost or quota concern.

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 lists the supported categories and ends with a useful behavioral qualifier. No wasted language.

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

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

With three required string parameters at 0% schema description coverage and no output schema, the description should specify valid unit formats or examples. It does not, so an agent must guess how to populate 'from' and 'to' outside of temperature.

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 parameter semantics. It only partially does: it lists temperature unit codes (c, f, k) but gives no format or examples for length, mass, volume, or data-size units, leaving 'from' and 'to' ambiguous.

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: convert units, with explicit supported categories (length, mass, volume, data size, temperature). It clearly distinguishes this from sibling conversion tools like color_convert and timestamp_convert.

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 clear purpose, but there is no explicit guidance on when to use this versus other conversion tools or any exclusions. 'Pure computation, free' gives useful context but not selection criteria.

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 description's 'Pure computation, free' confirms and extends that with a cost statement, which is useful added context. It says nothing about output format or error behavior for invalid input, so it adds some value but not rich behavioral detail.

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 operation and ending with the cost/behavior note. No wasted words.

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

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

For a trivial two-parameter utility with no output schema, the description is nearly sufficient, but it leaves the mode parameter's accepted values entirely unspecified, which is the one thing an agent must know to call 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% and the description only implicitly covers 'text'. The 'mode' parameter is untyped and undocumented, and the description never states the accepted values (encode vs decode) or that mode selects between them, leaving the agent to guess the string literal.

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 (percent-encode/decode) and resource (a text for URLs), which cleanly separates it from the parsing sibling bursia_url_parse. However it does not explicitly name url_parse or a sibling, 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 description gives no when-to-use guidance, no mention of the alternative bursia_url_parse, and no conditions or exclusions. Usage is only implied by the verb pair.

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. 'Pure computation, free' reinforces the no-side-effects, no-cost profile, which is useful confirmation but adds little beyond the structured data, and nothing is said about return shape or edge cases like malformed input.

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

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

Two short sentences, front-loaded with the action and followed by the operational note. No wasted text.

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 single-parameter parser this is nearly sufficient, but with no output schema the description should at least indicate what the returned structure looks like (which parts, how query params are represented) to let an agent use the result 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%, so the description carries the burden for the single url parameter. It implies URL components and query parameters are what get extracted, but says nothing about whether relative URLs, encoding, or malformed inputs are accepted.

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: split a URL into its parts and query parameters. That is clearly distinct from the sibling bursia_url_encode, though the description never names 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?

No guidance on when to use this versus alternatives such as bursia_url_encode or bursia_json_path. The 'pure computation, free' note implies a safe, stateless call but not a usage condition.

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 safety and locality profile is known. The description adds genuinely new context by confirming pure local computation with no cost, but it omits the default count, any upper bound, and whether output is a list vs a single 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 with the core action front-loaded and a supporting note on cost/locality. Nothing is redundant or padded.

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

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

For a single-parameter, no-output-schema utility whose return value (UUID strings) is self-evident, the description covers the essentials. The only real gaps are the default value and any cap on count, which are minor for this tool class.

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 load. 'One or more' conveys that 'count' is a quantity of UUIDs, but the description never states the default when count is omitted, nor any maximum, so the parameter is only partially 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?

The description states a specific verb and resource: 'Generate one or more random UUID v4 values.' The 'v4' qualifier and 'one or more' scope make the output unambiguous. It does not name any sibling, but none of the listed siblings (hash, password_generate, base64) could be confused with UUID generation, so ambiguity is low.

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?

'Pure computation, free' implies the tool needs no network, auth, or payment, which is implicit guidance on when it is safe to call. However, it never states when to prefer it over alternatives or what constraints apply (e.g., a cap on count), leaving usage to inference.

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