zerm

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

The description discloses atomic increment semantics, monotonic uniqueness, starting value, and indefinite persistence—details beyond the annotations. These are valuable behavioral traits that the annotations (all false hints) do not convey.

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

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

Three sentences, front-loaded with the core action, then use cases and persistence info. 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 counter tool with no output schema, the description covers action, return value, initial state, concurrency, and persistence. The only minor gap is clarification of required vs optional parameters, which the schema already handles.

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 has 100% coverage with descriptions for all parameters, so a baseline of 3 applies. The description mentions 'named counter' but doesn't add further parameter-specific guidance 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?

The description clearly states the tool atomically increments a named counter and returns the new value, with explicit use cases for sequence numbers and run IDs. It distinguishes from sibling tools by emphasizing atomicity and monotonicity, which is unique among the listed 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?

It provides explicit use cases ('use it for sequence numbers, run IDs, or once-only ordering') and context ('across concurrent stateless runs') that indicate when to use it over alternatives. However, it does not name alternative tools or give explicit when-not guidance, so it's not a 5.

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

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

Annotations already declare readOnlyHint=true, but the description adds valuable behavior: determinism, support for 5/6 field expressions, timezone-awareness, and specific mentions of DST and DOM/DOW logic. This exceeds the minimal and provides helpful context beyond 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?

The description is two sentences, front-loaded with the primary purpose and then a rationale. Every clause adds value, with no redundancy or fluff.

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

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

Given the tool's moderate complexity, the description covers the main use cases (validation, scheduling, timezone handling) and even highlights edge cases (DST, OR-logic). With no output schema, it clearly states that it computes fire times, providing sufficient context.

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 baseline is 3. The description adds semantics like '5 or 6 field, seconds optional' and 'timezone-aware', which supplement the schema's parameter definitions and help interpret the 'expression' and 'timezone' parameters.

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

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

The description clearly states the tool's function: 'parses a cron expression... and computes the next N actual fire times'. It distinguishes itself from siblings by its specific focus on cron validation and scheduling, and no sibling offers similar functionality.

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

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

The description provides explicit guidance: 'Use this instead of guessing' and explains common pitfalls (DOM/DOW OR-logic, DST transitions). While no alternative tool is named, the guidance is clear and context-specific.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds meaningful behavior beyond this: 'Live lookups - not cached' and 'Automatically parses SPF and DMARC policies from TXT records' – both of which are useful and not inferred from the annotations. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose, then provides behavioral details, use cases, and an alternative. Every sentence carries unique value; there is 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?

The description covers purpose, behavior, and usage comprehensively, with no output schema to worry about. However, it does not mention error behavior (e.g., invalid domain, NXDOMAIN) or the response format, which would be useful for a live lookup tool. Overall it is still well-rounded.

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 both domain and types parameters. The description's list of record types and default behavior duplicates what the schema already provides. It does not add new parameter-level semantics, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Full DNS record lookup for a domain' and enumerates the exact record types returned (A, AAAA, MX, NS, TXT, CNAME, SOA, CAA). This clearly distinguishes it from sibling tools like name_check, email_check, and url_check, and it even offers a fallback via request_tool for unsupported lookups.

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?

Explicit use cases are provided: 'Use this for infrastructure audits, email deliverability setup, domain verification, and security checks.' It also gives an explicit alternative: 'Need a record type or lookup this does not support? Describe it via the request_tool tool.' This addresses both when to use and when not to use the 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 mark readOnlyHint and openWorldHint. The description adds that nothing is sent, describes the live MX lookup with RFC 5321 fallback, and notes the limitation that LLMs cannot perform the DNS part. This enriches the behavioral model beyond the annotations, though omitted details like rate limits or response shape would push it higher.

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

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

Three sentences, each earning its place: the first defines scope, the second gives concrete use cases, the third explains why the tool is necessary. No filler and information 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?

For a single-parameter, read-only tool with no output schema, the description covers purpose, usage, and behavior well. The only gap is that it does not describe what the result looks like (e.g., boolean vs. report) or how to interpret typo suggestions, which an agent might need to know.

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 only parameter 'email' is fully described in the schema ('The email address to check'). With 100% schema coverage the baseline is 3; the description's mention of syntax validation and address checks adds some context but no new syntax or format details, so it does not elevate the score.

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 is a specific and actionable statement: 'Deliverability probe for an email address without sending anything' plus enumerates components (syntax validation, MX lookup with A/AAAA fallback, disposable-domain detection, typo suggestions). This clearly distinguishes it from siblings like dns_query (DNS-only) and inbox_* (message operations).

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?

Explicitly states when to use: 'validate an address before sending to it, storing it, or accepting a signup,' and warns 'LLMs cannot do the DNS part; this is a live check.' However, it does not explicitly name alternative tools or state when not to use, so it stops short of a 5.

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

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

Annotations declare readOnlyHint true, and the description adds valuable behavioral context: determinism when a seed is passed ('same seed + schema = identical data'), cost efficiency, and supported formats/types. No contradiction with annotations.

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

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

The description is densely packed but well-structured: a single sentence front-loading the core capability, followed by specific lists of formats and types. No wasted words; every element adds 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?

The tool is moderately complex with 4 parameters and nested field objects, and the schema covers all params. Without an output schema, the description could clarify the return structure, but naming formats (json, ndjson, csv) implicitly indicates output. Overall sufficient for selection and 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 100%, so the baseline is 3. The description adds semantic value beyond the schema by explaining the deterministic effect of the seed parameter and summarizing the available types/formats in context, which helps the agent understand parameter interplay.

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 'Bulk realistic test data: generate up to 10000 rows from a field schema in one call', which is a specific verb+resource combination. It distinguishes itself from all sibling tools by focusing on deterministic bulk data generation, listing formats and types.

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 clear context for when to use the tool via 'orders of magnitude cheaper than generating rows with tokens', implying it is the cost-effective bulk alternative. However, it does not explicitly name alternative tools or state exclusions, so it falls short of a 5.

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

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

The description goes far beyond annotations by revealing security semantics (URL vs read token), storage limits (100 payloads, 64KB), idle expiry (24h, reset by inbox_poll), and daily creation limit (5/day). This is rich behavioral context for a mutation tool with no safety 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?

The description is a single, well-structured paragraph that front-loads the core purpose before diving into details. While it is longer than minimal, every sentence provides essential context and no redundancy is present.

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

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

From a simple, zero-parameter operation, the description covers all necessary aspects: creation, usage, reading, retention limits, expiry, safety, and quotas. No output schema exists, but the return values are described adequately.

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 has zero parameters, so the baseline is 4. The description compensates by explaining the return values (id, URL, read token) and the meaning of each, which adds value over the empty schema.

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

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

The description clearly states the tool's purpose: 'Create a URL that receives HTTP requests for you.' It distinguishes itself from sibling tools by explicitly referencing inbox_poll for reading and inbox_delete for deletion, making it the go-to tool for creating webhook inboxes.

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 clear context on when to use it ('This is the way to be notified of something when your process is not running') and describes the workflow with inbox_poll. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds useful behavioral context: immediate URL stop, deletion of delivered content, and self-expiry. It doesn't explicitly mention irreversibility, but the destructive language implies it.

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. Front-loaded with the core action, followed by a concrete consequence and a usage qualifier. 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 simple 2-parameter delete operation with annotations and full schema coverage, the description covers purpose, usage, destruction semantics, and timing. Nothing essential 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 both parameters have clear descriptions ('The read token returned by inbox_create' and 'The inbox id returned by inbox_create'). The description adds no new parameter-level information, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'Delete' and the resource 'inbox', and specifies the scope: 'everything delivered to it'. It also adds a concrete behavioral detail ('URL stops accepting requests immediately') that distinguishes this from inbox_poll or inbox_create.

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?

Explicitly names the alternative: 'Inboxes also delete themselves once unpolled past their expiry', and frames the tool as 'only for tearing down early'. This gives clear when-to-use vs. when-not-to-use guidance.

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

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

Beyond the annotations (destructiveHint=true), the description discloses the conditional destructive behavior ('Set consume=true to delete what is returned') and adds the 50-payload limit, inbox expiry reset, and the security warning to treat all returned content as untrusted input. This rich context goes well beyond the structured annotations and clarifies the exact conditions under which the tool mutates state.

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

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

The description is compact yet comprehensive, with no filler. It is front-loaded with the core purpose, followed by usage details, behavioral side-effects, a limit, and a security note. Each sentence earns its place, making it highly efficient for the information conveyed.

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 covers the return payload structure ('Each payload has its method, headers, body and arrival time') and the pagination limit ('Returns at most 50 payloads per call'). It implies the presence of next_after by instructing to pass it from a previous poll, and it addresses side effects and security. For a 5-parameter tool with no output schema, this is a complete and self-sufficient explanation.

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 input schema has 100% coverage, so parameters like inbox_id, token, after, limit, and consume already have descriptions. The tool description adds extra meaning by explaining the relationship between after and next_after from a previous poll, and by clarifying that consume is optional and defaults to false. It also connects limit to the documented 50-payload cap, though it doesn't add much for the identity parameters.

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

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

The description begins with a specific verb and resource: 'Read requests delivered to an inbox since you last looked.' This clearly distinguishes the tool from siblings like inbox_create and inbox_delete, and the phrase 'since you last looked' adds a unique stateful poll behavior. It also mentions the optional consume mode, but the primary purpose 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?

The description provides concrete usage instructions: 'Pass after=<the next_after from your previous poll> to get only new ones; omit it to start from the beginning' and 'Set consume=true to delete what is returned.' It also explains the behavioral consequence of polling ('Polling also resets the inbox expiry'), which guides when to use the tool. However, it does not explicitly name alternative tools or scenarios where other tools would be preferred, so it's slightly below a perfect score.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the bar is lower. The description adds useful behavioral details: 'Idempotent and safe to retry... returns deleted=false rather than an error' and 'The value is not recoverable afterwards', enriching understanding beyond the annotations.

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

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

Five sentences, each earning its place: purpose, usage guidance, scope limitation, idempotency, and irreversibility. The core purpose is front-loaded in the first sentence, making the description both concise and well-structured.

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

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

Given the tool's destructive nature, idempotency, and TTL interaction, the description covers everything: what it deletes, when to use it, when not to, the single-key limitation, retry behavior, and irreversibility. With annotations and full parameter schema, no significant information 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%, with both 'key' and 'namespace' fully documented. The description adds no parameter-specific information beyond the schema, 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?

The description opens with 'Permanently remove one key from your namespace', which is a specific verb+resource statement. It clearly distinguishes itself from siblings like kv_set and kv_list by emphasizing 'one key' and 'no prefix or wildcard form'.

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?

Explicitly states when to use: 'Use it when a stored value is wrong or unwanted before its TTL runs out' and when not to: 'if you only want the value to lapse on schedule, do nothing and let the TTL expire instead'. It also names kv_list as the way to find keys, providing a clear alternative.

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

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

The annotations already declare readOnlyHint=true, so the safety profile is known. The description adds valuable behavioral information: 'Returns found=false if missing or expired.' This discloses the return behavior for missing keys and indicates that values can expire, which is beyond what annotations provide. It doesn't contradict annotations and adds meaningful context.

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

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

The description is three sentences, each serving a distinct purpose: the first states what the tool does, the second when to use it, and the third what it returns. It is front-loaded with the core action and contains no filler or repeated information from the schema. 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?

This is a simple read operation with strong annotations and complete schema coverage. The description covers the key usage context (restoring state at start of run) and the edge case (missing/expired). No output schema exists, but the description's mention of 'found=false' suffices for this simple tool. It is complete for an agent to invoke correctly.

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

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

Schema description coverage is 100%, with both 'key' and 'namespace' clearly described in the schema. The tool description itself does not elaborate on parameter semantics, but the schema already provides sufficient meaning. According to the rubric, when schema coverage is high, a baseline of 3 is appropriate.

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

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

The description opens with 'Retrieve a value previously stored with kv_set', which is a specific verb+resource statement that clearly distinguishes kv_get from siblings like kv_set, kv_delete, and kv_list. It also states the intended use case: 'Call this at the start of a run to restore state, preferences, or progress saved by earlier runs.' This makes the tool's purpose unambiguous.

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

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

The description provides clear context for when to use the tool ('at the start of a run to restore state...'), which is explicit and actionable. It references kv_set as the storing counterpart but does not mention alternatives like kv_list for listing keys or when not to use this tool. This falls just short of a 5 because it lacks explicit exclusions or alternative 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?

Beyond the readOnlyHint annotation, the description adds crucial behavioral context: it returns only key names with expiry and last-update time, filters expired keys, has no pagination, and applies the limit before expiry filtering, which can result in short pages. This rich detail prevents surprises and is consistent with annotations.

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

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

Five sentences, each serving a purpose: stating the action, the use case, the return content, the limitation on walking large namespaces, and the ordering nuance with the limit. It is front-loaded with the core purpose and free of fluff.

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

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

Despite having no output schema, the description fully describes what the return value includes (key names, expiry, last-update time, never values) and covers edge cases like expired keys and short pages. It is appropriately complete for a list tool with minimal parameters and clear sibling differentiation.

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 covers all three parameters, so baseline is 3. The description adds extra semantics for 'prefix' (narrowing results) and 'limit' (interaction with expiry filtering causing short pages), going beyond the raw schema definitions. Useful context is provided without redundancy.

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 'List the keys held in your namespace, optionally narrowed to those starting with a prefix,' providing a specific verb and resource. It explicitly contrasts with kv_get by stating it returns key names and metadata, never values, which distinguishes it from the sibling 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?

It explicitly says to use this tool 'to discover what earlier runs saved before deciding what to fetch with kv_get,' giving a clear use case and naming the alternative. It also conveys usage limitations (no cursor/offset, need to narrow prefix for large namespaces) that guide when and how to use 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 indicate readOnlyHint=false and destructiveHint=true, so the write nature is acknowledged. The description adds valuable behavioral details: durability across sessions, TTL default/max, value size limit (8192 bytes), and max keys per namespace (1000). These go beyond the structured annotations, enhancing 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?

Three sentences, front-loaded with the core action, then constraints. Every sentence is information-dense and earns its place; no fluff 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?

The description covers durability, TTL behavior, size limits, and key namespace limits, which is strong for a set tool. It doesn't explicitly mention overwrite behavior or return value, but these are likely inferable given the destructiveHint annotation and absence of an output schema. Overall, well-rounded.

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 already provides 100% coverage for parameter descriptions. The description adds extra constraints not in the schema: value max size (8192 bytes) and max 1000 keys per namespace. It also reinforces the JSON-encoding guidance for the value, adding value beyond the schema's basic 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?

The description clearly states the action ('Store a value durably under (namespace, key) with a TTL') and the resource semantics as persistent memory. It distinguishes from sibling kv_* tools by focusing on the write/set operation and the durability across sessions.

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 a clear when-to-use context: 'use it as memory between stateless runs.' This implies the appropriate alternative usage (e.g., kv_get for retrieval) but does not explicitly exclude other tools or mention when-not to use 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 only indicate readOnly=false and idempotent=false, but the description adds rich behavior: exactly one winner under a race, the response shape (acquired true with token, false with retry_after_ms), auto-expiry to avoid wedging, and non-reentrancy. This far exceeds the annotation coverage.

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 compact four-sentence paragraph that front-loads the purpose and then gives essential behavioral details. Every sentence contributes value—race behavior, expiry, reentrancy, and usage guidance—with no redundancy or 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?

Even without an output schema, the description explains both possible outcomes (acquired=true with token, acquired=false with retry_after_ms) and covers prerequisites, expiry, and usage context. This makes the tool's behavior fully understandable for an agent.

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

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

The input schema already fully documents all three parameters with clear descriptions, and the description only repeats ttl_seconds default and max. It does not add new meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states the verb 'Acquire' with the resource 'mutual-exclusion lock' and immediately explains its purpose: preventing double-processing. It also distinguishes itself from sibling lock_release by describing the race outcome and the release token flow.

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

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

The description explicitly says to use the lock before processing a shared job and to call lock_release when done, giving clear when-to-use context. It also notes non-reentrancy and auto-expiry, though it does not explicitly list when not to use it or name alternative tools like counter_next.

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

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

The description adds significant behavioral context beyond annotations: only the token holder can release, without the token the lock expires on its own, and it returns released=false on wrong token or expired lock. This complements the annotations (idempotent, destructive) and gives the agent clear expectations of side effects and failure modes.

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 extremely concise: two sentences, packed with essential information, front-loaded with the primary action. No wasteful wording.

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 the description covers the key behaviors: early release, token requirement, expiry fallback, and false return condition. It does not explicitly state the success return value (presumably true), but that is implied. Given the absence of an output schema, this is adequate.

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

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

Schema coverage is 100%, so the schema already fully documents all three parameters. The description adds minimal extra meaning, only referencing the token origin from lock_acquire, which is also in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Release a lock early using the token returned by lock_acquire.' It names the specific verb (release), resource (lock), and the token requirement, distinguishing it from siblings like lock_acquire.

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 when to use this tool: when you want to release a lock before its natural expiry. It also explains that the lock expires on its own if not released, providing context. However, it doesn't explicitly compare with alternatives or state when not to use, so it's slightly below a perfect score.

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 annotations, the description explains critical result semantics: 'unknown' means no authoritative registry answered and must not be treated as free, some ccTLDs like .co are always unknown, and 'unregistered' does not mean final because of reserved/premium names. This is rich behavioral context.

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

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

The description is longer than two sentences but every sentence adds necessary caveats or context for a multi-target tool. It is dense and front-loaded with the core purpose.

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 three targets and no output schema, the description fully covers result categories, source attribution, defaults, edge cases (ccTLDs), and the follow-up action (request_tool). No gaps remain for accurate 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?

The input schema already documents each parameter, but the description adds value with normative examples (e.g., 'stripe.com' or 'Acme Global Ltd'), the normalized name echo, and defaults for tlds and targets.

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 action and scope: 'Live availability check for a name across domain TLDs (registry RDAP), npm, PyPI, and GitHub usernames.' This identifies the verb, resource, and distinctions from siblings like dns_query or email_check.

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

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

It clearly states it performs real registry lookups at call time and offers an explicit alternative (request_tool) for additional registries. It lacks explicit 'do not use when' guidance versus siblings like dns_query, but the use case 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 only declare readOnlyHint=true and openWorldHint=false. The description adds meaningful behavioral context: sandboxed execution, a 250ms kill switch against catastrophic backtracking, and the JavaScript/ECMAScript dialect. This goes beyond what annotations imply and informs the agent of important runtime constraints.

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 three sentences, all high-signal: what it does, why to use it, and safety/dialect caveats. No redundant phrasing or filler. It is front-loaded with the action and result.

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 explicitly lists the returned match components (text, indices, capture groups, named groups, replacement), which covers return value expectations. It also covers execution constraints and dialect, making the tool's behavior fully understandable for a test utility.

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

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

Schema description coverage is 100%, so all four parameters already have clear meanings. The description does not add significant details beyond what the schema provides—it only mentions 'optional replacement output' which the schema already explains. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Execute') and resource ('regex against test strings'), and enumerates the exact outputs: match text, indices, capture groups, named groups, and optional replacement. This clearly distinguishes it from all sibling tools, which are unrelated (timers, network, key-value, etc.).

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 'Deterministic proof, not prediction - run this before shipping a pattern' gives clear context that this is for verifying regex patterns prior to deployment. It doesn't explicitly name alternatives or exclusions, but no competing sibling exists for regex testing, so the guidance is 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?

The description discloses that 'the operator reviews every submission' and that it is 'Free, no payment ever required,' which adds useful context beyond the annotations (all false). However, it does not mention submission persistence, response format, or any asynchronous side effects. Since annotations provide no safety hints, the description partially compensates but could be richer.

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

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

The description is two sentences, front-loaded with an engaging question, and each sentence contributes meaning. It includes the what, how, process, and outcome without any filler. This is a model of concise, structured tool documentation.

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

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

Given the tool's simplicity and lack of output schema, the description covers the essential context: purpose, usage trigger, required input (tool description and task), and the review process. It could mention what happens after submission (e.g., no direct response), but the provided information is sufficient for an agent to infer the tool's role.

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% with clear descriptions for both parameters ('description' and 'use_case'). The tool description adds no additional parameter-specific detail, matching the schema's semantics. This aligns with the baseline of 3 when the schema fully documents parameters.

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

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

The description clearly states the tool's purpose: to request a new tool by describing it and the task. It uses a specific verb ('request') and resource ('a tool this server had'), and it distinguishes itself from all sibling tools because none are about requesting capabilities. The opening question 'Hit a capability wall?' effectively frames the tool's function.

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 context for when to use: 'Hit a capability wall?' This implies the tool is for situations where existing capabilities are insufficient. It does not explicitly mention alternatives or exclusions, but the unique nature of a request tool makes that less necessary. The guidance on what to describe (tool and task) is concrete.

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

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

Beyond the annotations (destructive, idempotent), the description adds critical context: the id acts as authorization and must be kept secret, and that already-delivered or already-cancelled timers return cancelled=false, explaining the idempotency behavior in practical terms.

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

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

Three sentences, each with a distinct purpose: action, security caveat, and edge-case behavior. No wasted words, and the most important action 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 simple (one parameter, no output schema) and annotations cover safety. The description provides all necessary operational details: cancellation action, id source, secret handling, and behavior for non-pending timers, making it fully self-sufficient.

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 schema already covers the id parameter fully (100% coverage), so baseline is 3. The description adds extra meaning by framing the id as a secret authorization token returned by timer_schedule, which is valuable semantic information 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?

The description clearly states 'Cancel a pending timer using the id returned by timer_schedule' with a specific verb and resource, distinguishing it from siblings like timer_schedule and timer_status by focusing on the cancellation action.

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 when to use this tool (to cancel a pending timer) and references the id from timer_schedule. It does not explicitly name alternatives, but the context is clear enough; the edge-case note about already-delivered/cancelled timers provides additional operational 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?

Beyond the annotations (readOnlyHint=false, etc.), the description discloses rich behavioral details: the POST mechanism, 3 delivery attempts with backoff, the returned id doubling as a capability for inspection/cancellation, payload size limits, delay bounds, and the prerequisite of a verified origin. This fully informs the agent about side effects and required context.

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

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

The description is concise yet comprehensive. Four dense sentences cover purpose, use case, prerequisite, limits, attempts, and return value without redundancy. It is front-loaded with the core function and each sentence adds meaningful 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 there is no output schema, the description compensates by explaining what the caller receives (an id with inspect/cancel capability). It also covers the prerequisite dependency, time and payload constraints, and delivery behavior. This makes the tool's complete contract clear to the agent.

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

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

Schema coverage is 100%, so the baseline is 3. The description enhances parameter understanding by explaining that the payload is 'JSON string delivered as the request body', tying url verification to the prerequisite, and noting that the returned id is for subsequent control. These additions go beyond the schema's per-property descriptions.

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

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

The description opens with a precise, action-oriented statement: 'Schedule a durable callback: at fire time this service POSTs your JSON payload to your URL.' This clearly identifies the tool's function and differentiates it from sibling tools like timer_cancel and timer_status, which manage or inspect existing timers.

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 explicit guidance on when to use the tool: 'Use it to wake up future runs of yourself or your orchestrator - agents cannot wake themselves.' It also states a critical prerequisite involving timer_verify_origin. It doesn't explicitly mention alternatives or when-not-to-use, but the use case is clear enough to distinguish it from immediate request 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, so the description doesn't need to establish safety. It adds valuable behavior details: the possible status values, that it returns attempts and last error, and that unknown ids produce found=false. This goes beyond the annotations.

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

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

Two sentences with no filler; the first sentence states the action and the second clarifies the not-found behavior. 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 single-parameter read-only status tool, the description covers the return fields, valid statuses, and error handling for unknown ids. The annotation and schema cover safety and parameter validation, so nothing important 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?

The single parameter 'id' is already fully documented in the schema with the same description ('The timer id returned by timer_schedule'). The description repeats this context without adding syntax or format details, so it provides minimal extra value 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?

The description uses the specific verb 'Check' and identifies the resource as 'a timer' by the id from timer_schedule, listing possible statuses which distinguishes it from sibling timer_* tools like timer_cancel and timer_verify_origin.

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?

Clearly states the tool is for checking a timer using the id returned by timer_schedule, providing context that it should be used after scheduling. It doesn't explicitly name alternatives, but the sibling context and the instruction 'by the id returned by timer_schedule' imply its usage window.

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

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

The description goes far beyond the annotations, detailing the POST payload structure, the required 2xx response with echoed token, strict URL requirements (https, public, no credentials, no private IPs), and persistence per origin. This provides vital behavioral context not captured by readOnlyHint or openWorldHint.

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 well-structured and front-loaded with a one-sentence summary, then expands into necessary details. Every sentence contributes essential information about the handshake, requirements, or scope, with no fluff 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?

Given the tool's complexity, the description is remarkably complete. It covers prerequisites, handshake mechanics, endpoint constraints, and scope of verification (per origin, persistent). It lacks only an explicit failure mode description, but the 2xx requirement implicitly covers that.

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

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

The schema already describes the 'url' parameter with an example, giving 100% coverage. The description adds meaningful constraints on the URL (default port, public reachability, no credentials, no private/reserved IP), which enriches the parameter's meaning beyond the basic type and format.

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

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

The description clearly states the tool performs a one-time consent handshake for timer callback origins, using a specific verb and resource. It distinguishes itself from sibling tools like timer_schedule by explaining it is a prerequisite for timers to deliver to an origin.

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

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

The description provides clear context by explaining the prerequisite (an HTTPS endpoint you control) and explicitly states that timers are not usable without such an endpoint. It lacks an explicit named alternative but effectively communicates when this tool is necessary.

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?

Description adds return value disclosure (converted time, UTC offsets, DST flag) and emphasizes determinism. Annotations already indicate read-only; 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?

Three sentences, each with a distinct purpose: function, rationale, return values. No redundancy.

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

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

Covers purpose, return behavior, and motivation. With 100% schema coverage and no output schema, the return value description is helpful. Minor gaps like default timezone are in 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 covers all 7 parameters with descriptions, so baseline 3. Description does not add parameter-specific details beyond mentioning IANA timezones.

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

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

Description states 'convert a timestamp between IANA timezones with full DST awareness,' clearly identifying the verb and resource. It distinguishes from sibling tz_info by focusing on conversion and exactness.

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 clear context: use this for exact DST-aware conversions when models might miscalculate. Does not explicitly name alternatives or exclusions, but the context is 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, but the description adds valuable behavioral context by defining transition timestamps: 'Transition timestamps are the first instant the new offset is in effect.' This clarifies a potentially ambiguous aspect of the returned data. It also specifies that inputs without a UTC offset are read as UTC (in the schema, but the description reinforces the tool's deterministic 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?

The description is two sentences long and front-loaded with the tool's purpose. It efficiently packs the key details: inputs, outputs, and a semantic clarification about DST transitions. No unnecessary words or repetition.

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

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

With no output schema, the description enumerates all return values (UTC offset, DST active, transition instants, abbreviation) and clarifies the transition timestamp meaning. It also includes a usage note. This is complete for a read-only informational tool, especially given the rich parameter 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?

The input schema provides 100% coverage with detailed descriptions for both parameters (date format and timezone example). The description does not add any parameter-specific semantics beyond what the schema already covers, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('returns') and clearly identifies the resource (timezone details for an IANA timezone and date), listing exact outputs: UTC offset, DST active flag, DST transition timestamps, and abbreviation. It also differentiates from sibling tools by emphasizing 'DST behavior before scheduling,' which is distinct from timezone conversion (tz_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?

The description explicitly states when to use this tool: 'Use this to understand DST behavior before scheduling.' This gives clear context. However, it does not mention when not to use it or name any alternative sibling tools, so it falls short of full explicit exclusion/alternative 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?

With readOnlyHint already in annotations, the description goes well beyond by disclosing the full redirect chain reporting, final status, content type, response time, TLS certificate expiry/trust, access hints, and 'fresh at call time' behavior. This gives the agent a comprehensive picture of what the tool does and what to expect.

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

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

The description is two sentences, leading with the core function and then listing specific outputs and a use case. Every word adds value, and it is perfectly sized for the tool's simplicity.

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 tool with no output schema and read-only annotations, the description fully covers the return values, behavioral nuances, and use context. It is self-contained and leaves no significant gap for an agent to invoke it correctly.

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

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

The input schema already provides a complete description for the single URL parameter ('The URL to check (https)'). The tool description adds no additional parameter meaning, only clarifying the overall behavior, so the baseline score of 3 is appropriate given 100% schema coverage.

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

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

The description clearly identifies the tool as a live URL health check, listing specific outputs (redirect chain, status, content type, response time, TLS details, access hints) that distinguish it from sibling tools like request_tool. The phrase 'verify links before citing them' further clarifies its specific 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?

The description states a clear use case ('use it to verify links before citing them'), providing context for when to apply the tool. However, it does not explicitly mention when not to use it or compare it to alternatives such as request_tool, so it falls short of a perfect score.

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