BOZOS

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent with them. However, it adds no behavioral context beyond restating the purpose: it doesn't say what a failed validation looks like, whether a fingerprint is returned or persisted, or how the fingerprint is consumed downstream.

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 verb list and no filler. The trailing endpoint reference is slightly opaque to an agent but costs little space.

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 and the description never indicates what comes back (validation verdict, normalized action, fingerprint) or how failures surface. For a high-complexity nested 9-field input with no return documentation, this leaves a real gap an agent must guess at.

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

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

Schema description coverage is 100% and the nested action object is itself documented as 'A proposed agent action that can be normalized, reviewed, fingerprinted, and verified before execution.' The description adds nothing about the single 'action' parameter, so the schema does all the work – baseline 3.

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

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

States three specific verbs (validate, normalize, fingerprint) on a clearly named resource ('a proposed agent action'), so the purpose is unambiguous. It does not differentiate itself from the close sibling verifyApprovedAction, leaving the agent to infer the preflight-vs-verify boundary.

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

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

There is no when-to-use guidance, no statement of prerequisites (e.g., that it precedes verifyApprovedAction/execution), and no exclusions. The only routing hint is an HTTP endpoint URL, which tells the agent nothing about when this tool is the right choice.

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?

While annotations cover safety (read-only, non-destructive), the description adds critical operational behavior: 'Makes no outbound network requests and retains no payload.' This is vital context for security, confirming the audit is purely ephemeral and localized.

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 highly efficient, immediately front-loading its core constraint (no fetching) and concisely listing its function and external reference. Every sentence delivers necessary, high-value 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?

Given that annotations cover the safety profile and there is no output schema to explain, the description is complete. It clearly defines the input scope (caller-supplied bundle) and the fundamental limitations (no network activity) necessary for the 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?

Because the schema description coverage is 0%, the description must compensate. It provides high-level framing—that the parameters form a 'caller-supplied bundle'—but it does not add semantic meaning to any specific parameter like `llms_txt` or `agent_index` beyond what the schema types already indicate.

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

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

The description clearly states its function as an 'audit' of 'supplied crawler and agent discovery materials.' It immediately establishes a critical constraint: it operates 'without fetching URLs,' clearly differentiating it from network-dependent tools like `fetch` or `search` among the sibling list.

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 boundaries by stating that it 'Checks a caller-supplied bundle only' and 'Makes no outbound network requests.' This strongly directs the agent toward this tool only when local, pre-gathered data is available, preventing unnecessary calls to fetching tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered and generating text rather than writing a file is consistent with readOnlyHint. The description adds the meaningful scoping fact that all documented AI crawlers are enumerated, plus the REST equivalence, but says nothing about determinism of output, the meaning of 'a policy', or how defaults are applied. Some added value, no contradiction.

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

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

Two short sentences with zero filler, and the core purpose is front-loaded in the first sentence. The second sentence earns its place by mapping the tool to a known HTTP endpoint.

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

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

For a 7-parameter, all-optional generator with no output schema, the description covers what it produces but not the shape of the returned text (headers, ordering, whether it is copy-pasteable). It also leaves the loose 'allow or block' string typing entirely to the schema, which is adequate but not compensating for anything.

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

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

Schema description coverage is 100%, so all seven parameters (path, search, signals, sitemap, datasets, training, user_fetch) are documented in the schema with their defaults. The description contributes no additional parameter meaning, such as how 'search' relates to 'signals' or that the allow/block strings are the only accepted values.

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

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

States a specific verb (generate) and resource (robots.txt) plus the distinctive scope: it names every documented AI crawler and encodes an explicit allow/block policy. The phrase 'Same as GET https://bozos.si/api/v1/robots' clarifies it produces the file content. It does not, however, name or contrast with the sibling checkRobotsTxt, which is the most likely confusion point.

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

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

Usage is only implied: the agent can infer 'use this when you need to author a crawler policy' from 'for a policy', but there is no explicit when-to-use or when-not-to-use statement, and no routing to checkRobotsTxt for the validation case or to planAgentRetrieval for the planning case.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that — it does not name the canonicalization algorithm (e.g. RFC 8785 JCS, sorted keys, number handling), which is exactly the kind of detail that determines whether output is interoperable.

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, with no filler or repetition. The second sentence (REST endpoint equivalence) is of marginal value but costs almost nothing.

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

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

There is no output schema, so the description should specify the return shape — e.g. whether it returns the canonical JSON text, a hex SHA-256 digest, or both — and it does not. Combined with the unspecified canonicalization algorithm and the undocumented parameter, the definition is too thin 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?

With one parameter at 0% schema description coverage and an untyped schema (`value: {}`), the description carries the full burden and fails it: it never says whether `value` is a JSON object, a pre-serialized JSON string, or an arbitrary scalar. The word 'JSON' in the purpose line is the only weak hint about the input shape.

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 (canonicalize JSON) plus the secondary effect (compute SHA-256), which is enough to distinguish it from every sibling tool in the list. It stops short of naming the canonicalization scheme, so the agent knows the operation but not its exact semantics.

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

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

There is no when-to-use guidance, no mention of when a canonical form or a stable hash is required, and no alternatives or exclusions. The only orientation offered is an equivalence to a REST endpoint, which tells the agent nothing about tool selection.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds real behavioral context beyond that: it discloses the return contents (per-crawler allow/disallow, matching group and rule, sitemaps, Content-Signal lines, warnings) and flags directory crawlers that may ignore robots.txt for user-initiated fetches.

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

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

Four dense sentences, front-loaded with scope before inputs and outputs, and nothing is wasted. The trailing 'Same as GET https://bozos.si/api/v1/robots-check' is slightly redundant noise for an agent already holding the tool definition.

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

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

With no output schema, the description carries the return-value burden and does so explicitly, and it clarifies the no-fetch input model and the RFC basis. Annotations handle safety, so nothing material is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents path, agent, and robots including defaults ('default /', 'every crawler in the directory'). The description only restates that the robots text is passed in; it adds no syntax, encoding, or interaction 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?

Specific verb (evaluate) plus resource (robots.txt) with explicit scope: one named crawler or every AI crawler in the directory, per RFC 9309. It clearly separates itself from the sibling buildRobotsTxt (which constructs rather than evaluates) and from fetch (which retrieves).

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?

'Pass the robots.txt text; nothing is fetched' tells the agent this tool evaluates supplied text rather than downloading it, which is the key disambiguation against fetch. It does not name an alternative tool or state when not to use it, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety and side-effect behavior are covered. The description adds the equivalent REST endpoint, which aids mental mapping, but says nothing about return format or the 10,000-character truncation behavior (which lives only in the schema).

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

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

Two short sentences, front-loaded with the operation and followed by the endpoint reference. Nothing is padded, though the endpoint mapping is arguably optional.

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 ideally clarify what the counts look like in the response, and it only implies this through the verb 'count'. Combined with the missing differentiation from textStats, an agent has enough to call the tool but not full confidence about output shape or sibling selection.

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

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

Schema description coverage is 100%, so the schema already documents case, char, and the 10,000-character limit on text. The description's phrase 'a letter or substring' loosely maps to the char parameter but adds no syntax or default details beyond the schema. Baseline 3 applies.

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

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

The description names a specific verb (count) and enumerates the exact resources measured: characters, words, bytes, and occurrences of a letter or substring. That is clear and concrete. It does not, however, distinguish itself from the sibling textStats, which appears to overlap in purpose.

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

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

There is no guidance on when to use this tool versus alternatives such as textStats, nor any stated preconditions or exclusions. The only auxiliary information is an equivalence to an HTTP GET endpoint, which is context rather than usage direction.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds non-obvious behavior beyond the annotations: records carry a permalink, content is included unless records=ids, and dates have day precision with a strictly-after comparison.

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

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

Three tight sentences, front-loaded with the core action and followed by the delta rationale and return-shape caveat. Every sentence adds information and none is redundant.

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

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

With no output schema, the description carries the return-shape burden and does so: records include permalink and content (conditionally), filtered strictly after the given date. Combined with full schema coverage and rich annotations, an agent has everything needed to call this 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it clarifies that 'since' is strictly-after at day precision and that the 'records' mode controls whether content is returned at all. This goes beyond the parameter descriptions rather than restating them.

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 ('List dataset records added, changed, or removed after a date') and immediately clarifies scope as a record-level delta across every dataset or the ones named. An agent can distinguish this from any sibling without opening the schema, aided by the explicit REST equivalent.

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

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

It gives a clear use case ('so a cached copy can be updated without re-downloading'), which tells the agent when this tool is the right choice. It does not name a when-not condition or an alternative sibling, but no other sibling covers dataset deltas, so the guidance is contextually sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only a note that it mirrors a REST GET endpoint, which conveys determinism/purity but nothing about defaults, output shape, or edge cases. Adequate but not rich.

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

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

Two short lines with the operations front-loaded and no filler. The trailing URL reference is somewhat cryptic and doesn't earn its place as a behavioral note, keeping it from a 5.

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

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

For a 3-optional-param computation tool with no output schema, the description should ideally convey the shape of results (e.g. weekday name, ISO week number, day counts). It names the operations but not their outputs, leaving the agent somewhat under-informed despite the simple scope.

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

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

Schema description coverage is 100%, so the schema already documents 'to', 'add', and 'date' with formats and defaults. The description adds no parameter-level meaning beyond that (e.g. which params combine for which operation), so the baseline 3 applies.

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

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

The description enumerates the concrete operations (weekday, ISO week, date addition, day/weekday counts), which tells an agent what the tool computes and separates it from siblings like utcNow and timeInZones. It lacks a crisp verb+resource framing, but the feature list is specific enough to classify the 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 guidance on when to use this versus alternatives (e.g. utcNow, timeInZones), no preconditions, and no exclusions. The API URL reference is a spec pointer, not usage guidance, so the agent must infer when this tool applies.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value beyond them: deterministic output, the specific artifacts returned (subject, body, mailto, X intent URL, SHA-256), and confirmation that nothing is sent. It does not describe failure behavior when validation against contact.json fails, which is the main remaining 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?

Three tight sentences, all front-loaded with the core action first and constraints after. The opening sentence duplicates the title verbatim, which is minor redundancy, but nothing else 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 an 11-parameter, nested, no-output-schema tool, the description covers return values, determinism, validation, and permission scoping well. Missing only error/failure semantics, which keeps it from a 5.

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 64% schema coverage across 11 parameters (including a nested sender object and two enums), the schema carries most of the semantics. The description adds no parameter-level guidance beyond naming output fields, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Draft a correction or question... as an email and X post without sending it') and explicitly names the non-action (no sending). The title and description combine to make it unmistakable against siblings like verifyApprovedAction or fetch.

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

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

Explains the flow clearly: draft, validate, return artifacts, and 'Sending is up to the caller and requires its principal's permission.' It also equates the tool with the underlying endpoint. It stops short of naming when to prefer this over another sibling, but the surrounding context is sufficient for correct selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that — nothing about error behavior for malformed expressions, computation limits, or how non-terminating results 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 with the core capability front-loaded. The second sentence is marginal (endpoint equivalence rather than capability detail) but costs little and is not 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 only two well-documented parameters and annotations covering safety, most of what an agent needs is present. However, there is no output schema and the description does not describe the return shape (e.g., exact rational vs. rounded decimal string), which is the one remaining gap for a 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 100%, and the schema already documents the expression syntax, URL-encoding of '+', and the digits default/max, so the description carries no additional parameter meaning. Per the baseline rule for full coverage, 3 is appropriate.

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

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

The description states the resource and the distinguishing property ('exact rational arithmetic with no floating-point error'), which cleanly separates it from the math-adjacent siblings dateMath, countText and textStats. It is clear what the tool computes, though it never uses an explicit verb like 'evaluate' or says the input is a string expression.

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

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

There is no guidance on when to use this tool versus alternatives (e.g., dateMath for temporal arithmetic, or a floating-point path elsewhere), and no stated exclusions or prerequisites. The only usage-adjacent line points at an external HTTP endpoint rather than helping an agent decide to call this tool.

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

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

Annotations already cover read-only/idempotent/non-destructive semantics, so the bar is lower, and the description still adds real behavioral detail: what is returned (full text, Markdown or JSON), how fragment ids select a single record, and the caller obligation to cite the returned url. No permission, rate-limit, or truncation behavior is mentioned, so it stops short 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?

One dense sentence plus a short imperative ('Cite the returned url.'), with the core action front-loaded and no filler. Every clause carries usable information.

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

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

With no output schema, the description carries the return-value burden and does so adequately: it names the response content types and the single-record case. For a one-parameter idempotent fetch, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% and the id forms are already documented there, but the description adds meaning beyond the schema by explaining what each form yields — a whole dataset versus a single record via `#<record id>` or a permalink. That semantic distinction is not obvious from the schema alone.

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

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

States a specific verb and resource ('Return the full text of a BOZOS resource by id') and enumerates the payload types returned (Markdown guide/note, JSON dataset). It implicitly contrasts with the `search` sibling by naming it as the id source, so an agent can distinguish retrieval from discovery.

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

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

Explains where valid ids come from ('from `search`, or from https://bozos.si/content-index.json') and when to use the record-fragment form versus a plain dataset id. It does not state explicit exclusions or when to prefer `search`, but the routing 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 cover the safety profile (read-only, idempotent, non-destructive, closed-world), but the description adds real behavioral context: longest-token-first matching, and that it returns the crawler record with cite line, the operator's verification method, or an undocumented-token entry. With no output schema, this return-value disclosure is genuinely useful.

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

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

Front-loaded with the core purpose and kept to a few tight sentences; the API-equivalence note ('Same as GET ...') earns its place for routing. Slightly restates the title but not wastefully.

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 tool with no output schema, the description covers matching behavior, return shape, and the important caveat that a UA string is a claim, not proof. Only the caller's next step after identification is left implicit.

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 parameter 'ua' is already documented as the full User-Agent header value with a maxLength. The description adds no format or syntax guidance beyond the schema, so baseline 3 applies.

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

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

States a specific verb (identify) and resource (user-agent string matched against a crawler directory), and the title/description together make the operation unmistakable. No sibling tool does anything similar, so an agent can select it without confusion.

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

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

The description implies usage ('a user-agent string is a claim, not proof') and hints that the operator's verification method is the follow-up, but it never states when to prefer this over alternatives or what a caller should do with the result. Usage is inferable rather than explicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts beyond them: it makes no outbound network requests and retains no payload, and it identifies the equivalent REST endpoint. It still omits what the produced plan 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?

Four short sentences, front-loaded with the core action, then mechanism, then the key behavioral guarantee, then endpoint equivalence. No filler and nothing that could be cut without losing information.

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

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

With no output schema, the description should explain the shape or meaning of the returned plan, and it does not — an agent cannot tell what a 'retrieval plan' item contains. Combined with 0% parameter coverage and nested objects, the definition leaves meaningful gaps despite a solid core statement.

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 only partly meets it. It does map the three top-level inputs to plain language (resource manifest, cache validators, optional budgets), but nested fields such as etag, sha256, last_modified, max_items, accepted_types and max_total_bytes are never explained in either place.

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

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

States a specific verb and artifact ('Build a minimal conditional HTTP retrieval plan') and elaborates that it compares a caller-supplied manifest against cache validators and budgets. This clearly separates it from the sibling `fetch` by implication, though it never names `fetch` or any other 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?

Usage is only implied: the plan/cache-validator framing and the note that no network requests are made suggest this is a pre-flight dry-run step, but there is no explicit 'use this when you want X instead of fetching' or stated prerequisites. The endpoint-equivalence sentence ('Same as POST ...') tells an agent the transport but not when to choose it.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds genuinely new behavioral detail: what the call returns (resource ids) and that a canonical URL is included for citation, which tells the agent how to consume the result.

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

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

Two sentences, zero filler. The action and corpus are front-loaded, and the second sentence handles the return contract and next step in one clause.

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

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

With no output schema, the description carries the return-value burden and does so adequately: it names the returned artifact (resource ids) and the accompanying canonical URL. For a single-parameter read tool whose annotations cover safety, little else is needed; only matching behavior or result limits are 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?

There is a single parameter with 100% schema description coverage, so the schema already documents the query string and its 200-character cap. The description only restates 'by keyword' and adds no syntax, tokenization, or matching semantics 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 (search) and the full scope of the resource corpus (reference guides, datasets, notes, tools) plus the matching mode (by keyword). It also distinguishes itself from the sibling `fetch` by declaring that it returns ids meant to be passed there, so an agent can route between the two without opening schemas.

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

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

The description implies the intended two-step workflow (search, then hand ids to `fetch`), which is useful usage context. It gives no explicit when-to-use or when-not-to-use guidance versus siblings such as `textStats`, `exactCalc`, or `actionPreflight`, leaving the agent to infer the entry point.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds that results are deterministic and equates the tool to a specific POST endpoint, which is useful behavioral context, but it omits any return format or error behavior.

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

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

Two short sentences, front-loaded with the purpose and followed by the API equivalence. No filler, though the endpoint reference is of marginal value.

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

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

For a simple one-parameter deterministic measurement tool with strong safety annotations, this is minimally workable. However, without an output schema and with no description of what statistics are returned, the agent cannot know what to expect from the call.

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

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

The single required 'text' parameter has 0% schema description coverage, and the description does not compensate by explaining constraints such as max length, encoding, or accepted format. It merely implies that the text to measure is passed in.

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 verb ('measure') and resource ('text'), but 'deterministically' does not specify which statistics are computed (e.g., character count, word count). It does not distinguish from sibling countText, leaving the agent to infer scope from the name.

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

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

Provides no guidance on when to select this tool over siblings like countText or exactCalc, nor any prerequisites or exclusions. The only context is the underlying API endpoint, which does not help tool selection.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds only the 'Same as GET https://...' equivalence, disclosing that this is a stateless HTTP-backed lookup, but says nothing about output shape or error behavior.

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

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

Two short sentences, front-loaded with the primary purpose. The second sentence's HTTP-equivalence note is borderline filler but is compact and arguably useful for cross-referencing.

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

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

For a 3-param, no-required-arg tool with no output schema, the description does not explain what the response contains or how multiple comma-separated zones are returned. Annotations cover safety, but the return-value burden falls on nothing 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 description coverage is 100%, so the schema already documents at, tz and from_tz with their formats. The description adds no additional meaning about how these parameters interact (e.g. default UTC, comma-separated zone output), so the baseline 3 applies.

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

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

States a specific verb and resource ('Convert a time between IANA time zones') and covers the second mode ('give the current time anywhere'). It does not name or distinguish itself from close siblings like utcNow or dateMath, 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?

Usage is implied by the two described modes (conversion with a source zone, or current time with no arguments), which is enough for an agent to infer when it applies. There is no explicit when-not-to-use or routing to the sibling utcNow/dateMath tools that overlap with it.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the entire safety profile for a zero-parameter call. The description adds no behavioral context beyond that — nothing about caching, clock source, or freshness — so it does not earn credit for going beyond structured fields.

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

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

The core statement is front-loaded in the first sentence and the definition is very short. The second sentence mapping it to a REST endpoint adds marginal value for an agent that cannot call HTTP directly, but it is not noise.

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 zero-param read with full annotation coverage and no output schema, the description states both what it does and what it returns (UTC and Unix time), which is what an agent needs. It is complete for its complexity, though it does nothing to disambiguate from timeInZones.

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 tool takes no parameters, which is the baseline-4 case under the rubric; there is no parameter semantics to add. Schema coverage is 100% and the empty schema is consistent with the description.

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

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

States a specific verb and resource ('Get the current UTC and Unix time'), which is unambiguous and clearly distinct from converters like timeInZones or dateMath. It stops short of explicitly naming the sibling it differs from, so it lands at a clear-but-undifferentiated 4.

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

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

There is no when-to-use guidance, no exclusion against timeInZones (which is the nearest alternative for time queries), and no statement of when this tool is the wrong choice. The purpose implies a use case but nothing routes the agent between this and its siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and the description is consistent with them (no contradiction). It adds nothing beyond that, though: it does not say what happens on a mismatch, whether the call merely reports a boolean verdict, or whether a failed verification blocks downstream execution.

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 purpose. The second sentence (REST endpoint equivalence) is of marginal value to an MCP caller and slightly redundant with the title, but nothing is bloated.

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

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

There is no output schema, so the description should describe the verdict shape (match/no-match and any mismatch details), but it is silent on the return value. For a verification gate over a rich nested action object, the definition is under-specified 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?

With schema coverage at 50% and a fairly complex nested 'action' object, the description carries a compensation burden it does not meet. It never explains the 'approved_fingerprint' format beyond the regex, nor what fields of the action are actually re-fingerprinted for comparison.

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

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

States a precise verb+resource ('verify that an action still matches its approved fingerprint'), which is concrete and actionable. However, it does not differentiate itself from the sibling actionPreflight, which presumably produces or reviews that fingerprint — an agent must infer the ordering between the two.

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

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

No when-to-use guidance is given. The description never says this should be called after actionPreflight has produced a fingerprint, nor what to do when verification fails. Usage is only weakly implied by the word 'approved'.

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