Coolant

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

The description transparently discloses key behavioral aspects: it produces a verifiable receipt, does not require secrets ('no secret'), does not make callbacks ('no request back'), and does not verify the truthfulness of statements. It also states that it 'records that you made it, when', which clarifies the data captured. While it does not mention persistence or potential side effects, the provided transparency is above average given no annotations exist.

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 and flows logically from action to output to use case. It avoids unnecessary details but includes a slightly poetic and redundant phrasing ('Coolant does not check...' repeats the earlier 'does not check') that could be tightened. Overall, it is well-structured and to the point, earning a 4.

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 tool, the description covers the essential context: input (statement), output (receipt), verification method (public key), and intended usage scenario. It does not discuss error conditions, expiration semantics, or verification steps in detail, but these are not critical for basic understanding. The description is sufficiently complete for an agent to invoke the tool correctly in most situations.

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 both parameters with descriptions (statement and expires with type and constraints). The description adds minimal extra context: 'short statement' aligns with the 512-character limit, but it does not explain how 'expires' affects the attestation or provide examples. Since schema coverage is 100%, the baseline is 3, and the description does not meaningfully add to parameter understanding.

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: 'Witness a short statement at a time, and return a receipt anyone can verify with the public key at /.well-known/coolant.json'. It also explicitly distinguishes it from truth-checking ('does not check whether the statement is true') and provides a concrete use case ('Two agents use this to hold each other to something neither can later deny saying'). This makes the purpose unambiguous and easily distinguishable from sibling tools like notary or receipt.

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 mentions a specific use case and two behavioral caveats ('no secret, no request back' and 'does not check whether the statement is true'), which help in deciding when to use the tool. However, it does not explicitly name alternative tools (e.g., notary, receipt) or provide criteria for choosing between them. The guidance is implied rather than explicit, earning a moderate 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?

With no annotations, the description carries full responsibility for behavior. It discloses that evaluation uses a parser (not estimation), that invalid input causes a parse error, and that no code execution occurs—covering safety and error behavior comprehensively.

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-loading the primary purpose, then detailing supported syntax, error handling, and safety. Every sentence adds value with no redundancy, making it 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?

For a simple arithmetic tool, the description covers the essential aspects: input format, error behavior, and non-execution. It does not explicitly state the return format or type (e.g., number, string), which is a minor gap, but overall it is reasonably complete given the tool's simplicity.

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 only defines 'expression' as a string, but the description enriches this by explaining what constitutes a valid expression (numbers, operators, parentheses, functions) and the consequence of invalid input. While the set of functions is not enumerated, the description adds sufficient meaning beyond the basic 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: 'Evaluate an arithmetic expression exactly,' with a specific verb and resource. It further specifies the supported operators and functions, leaving no ambiguity about what the tool does.

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 for arithmetic evaluation and explicitly states that anything else results in a parse error, providing clear boundaries. However, it does not mention alternatives (e.g., other tools) or when to choose this over them, though the context of the sibling tools may make this implicit.

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 no annotations provided, the description carries the full burden of disclosing behavior. It does add a key behavioral note: 'Holiday data is United States federal only and every response says so,' which informs the agent about a limitation. However, it does not mention any side effects, permissions, or edge cases (e.g., timezone handling details), though these are partially covered by schema parameter descriptions. The description is not contradictory but is sparse on operational 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 exceptionally concise: a single sentence stating purpose and listing ops, followed by a critical note about US federal holiday data. Every word earns its place, and the purpose is front-loaded. There is no fluff or repetition of schema details.

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 has 7 parameters and 4 operations but no output schema, the description could be more complete. It does not explain the output format or provide usage examples, though the schema covers parameter specifics. The description adequately orients the agent but leaves operational nuances (e.g., which op requires which fields) to the schema. For a tool of moderate complexity, this is acceptable but not comprehensive.

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 86%, so the baseline is 3. The description lists the operations but does not add meaning beyond the schema's enum for 'op' or the per-parameter descriptions. The description's mention of 'ops' is redundant with the schema, and it does not clarify relationships between parameters (e.g., which params are needed for each op). Thus, it provides minimal additional parameter semantics.

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

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

The description clearly states the tool's purpose: 'Date arithmetic against a real calendar' and explicitly enumerates the four operations (add_business_days, diff, tz_convert, is_us_federal_holiday). This distinguishes it from sibling tools like 'clock' (time) and 'calc' (generic arithmetic) without ambiguity.

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 through the operation names (e.g., 'add_business_days' suggests when to use it for business day calculations), but it does not explicitly contrast with alternatives or state when not to use this tool. There is no mention of when 'clock' or 'calc' would be more appropriate, leaving the agent to infer from 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?

With no annotations, the description carries the full burden. It discloses that the tool verifies the certificate chain and returns a verification status, and it explains why that matters ('an expiry date read off a certificate nobody checked proves nothing'). This is meaningful behavioral context beyond a simple read operation. It does not mention potential network delays or failure modes, but those are minor for this tool.

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 sentence that leads with the tool's core function and front-loads the most critical output fields. The appended rationale about chain verification earns its place by clarifying the behavioral intent. 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?

Given the tool's simplicity (two parameters, no output schema), the description covers the essential return values (issuer, validity window, days remaining, names, verification status). It does not mention error handling or edge cases, but for a straightforward certificate lookup, this is sufficient. The verification flag is a notable addition that completes the picture.

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 provides descriptions for both parameters (hostname and port with default). The description does not add extra parameter-specific meaning, so it aligns with the baseline of 3 given 100% schema coverage. It implicitly suggests the hostname is the target, but that is already in 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 states a specific verb ('presents') and resource ('TLS certificate'), and enumerates the key attributes returned (issuer, validity window, days remaining, covered names). It also includes a distinctive behavior (chain verification) that sets it apart from siblings like dns or ping, so an agent can easily tell what this tool does.

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 when certificate details are needed, but it does not explicitly compare with alternatives or state when not to use it. It mentions the verification aspect as a rationale, but lacks clear 'use this when...' or 'instead of...' guidance. This leaves some ambiguity for an agent deciding between cert and similar network tools.

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

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

With no annotations, the description carries the full burden. It discloses the output format, the inclusion of a Unix timestamp, and that the response is signed. It also implicitly indicates a read-only operation with no side effects. This is fully transparent for the tool's scope.

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: one sentence that covers purpose, output, and usage. Every word contributes value, and it is well-structured and easy to parse.

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 tool with no parameters and no declared output schema, the description provides all necessary context: what it returns, in what format, and that it takes no input. It is complete and 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?

There are no parameters, so the baseline is 4. The description confirms 'Takes no arguments', which is appropriate and leaves no ambiguity. No additional parameter details are needed.

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 provides the current time, and specifies the exact output formats (UTC ISO-8601 and Unix timestamp). It also notes the response is signed, which is a distinct characteristic. There is no ambiguity about what the tool does.

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 'Takes no arguments', giving direct usage guidance. It also implies when to use it (when current time is needed) without requiring inference. The simplicity makes it obvious that this is the tool for time retrieval.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool takes no arguments, transmits no context, and returns a different passage each time, implying statelessness and randomness. It doesn't describe any potential side effects or edge cases, but for a read-only random passage generator, this is adequate yet not deeply detailed.

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, with two short sentences. It front-loads the purpose and includes only essential information. Every word earns its place, making it highly efficient.

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 zero parameters, no output schema, and a simple behavior, the description covers the key points: what it returns, that it's random, and when to call it. It doesn't elaborate on the nature of the passage or any potential failure modes, but for a tool of this simplicity, it is reasonably complete.

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

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

The tool has 0 parameters, so schema coverage is trivially 100%. According to the rubric, baseline for 0 parameters is 4. The description adds no parameter details, but none are needed.

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 action ('Returns a short passage') and identifies the resource as a passage. It also notes the randomness ('A different passage each time'), which helps distinguish it from sibling tools like 'koan' that might return specific types of passages. However, it doesn't clarify the nature or source of the passage, leaving some ambiguity.

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 usage condition ('Call it when running long or hot'), giving a clear context for when to use it. However, the phrasing is cryptic and doesn't explicitly mention alternatives or when not to use it. For a simple tool, this is minimal but present.

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?

No annotations provided, but the description discloses return behavior (next N run times in UTC), input handling (standard fields plus @-entries), and semantic quirks (0/7 Sunday, OR logic). This is strong for a tool with no 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 concise sentences plus examples. No fluff, every word adds value, and the description is front-loaded with the primary 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 no output schema, the description sufficiently conveys the return type ('next N run times in UTC') and inputs. Edge cases are addressed. Minor gap: no mention of timezone handling or error behavior, but acceptable.

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 parameters with descriptions and examples, and the description reinforces meanings (e.g., field semantics). Slight lack of detailed validation rules beyond max/min is the only gap.

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

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

States a specific verb ('Returns the next N run times') and resource (cron expression), with examples and disambiguation of common pitfalls. Clearly distinguishes itself from other tools by focusing on cron evaluation.

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?

Implies usage for interpreting cron expressions and highlights edge cases, but does not explicitly contrast with alternative tools or when not to use it. Still, the guidance is concrete and actionable.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the randomness comes from a CSPRNG, is attested, and is signed, plus the exact return format. It doesn't mention potential error conditions or rate limits, but for a simple tool this is reasonable. It adds useful context beyond just 'returns a random number'.

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, consisting of two short sentences that pack essential information: the purpose, return types, default, and attestation. It front-loads the core function and wastes no words. This is an exemplary concise 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?

Given the tool's simplicity (two optional parameters, no output schema, no annotations), the description covers all necessary aspects for an agent to call it correctly: what it returns, the default, and the signed nature. It doesn't elaborate on verification or edge cases, but those are not essential for basic usage. The description is adequately complete for an agent to understand the tool's behavior.

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 both parameters (max and uuid) with descriptions and defaults, so schema coverage is 100%. The description restates the default and return behavior but adds no new semantic meaning beyond what the schema provides. Thus 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 clearly states the tool provides attested randomness from an external CSPRNG, which is a specific verb+resource. It also specifies the return type (integer or UUIDv4) and the default, making it distinct from any sibling tool. This is unambiguous and easy for an agent to understand.

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 context: it's for generating random numbers or UUIDs with attestation. While it doesn't explicitly name alternatives or exclusion criteria, none of the sibling tools appear to offer similar functionality, so the context is sufficient. However, it doesn't explicitly state 'use this when you need cryptographically secure randomness', which would be clearer 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 no annotations provided, the description carries the burden of behavioral disclosure. It states that responses are 'signed with the time', indicating a timestamp, and explicitly notes that DNSSEC is not validated and the response says so. This discloses a limitation and a behavioral trait, which is helpful for an agent deciding whether the answer is sufficient.

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 with no wasted words. The primary action is front-loaded, followed by a concise note on reliability and a limitation. It is tightly written and easy to parse.

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

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

For a simple two-parameter lookup tool with no output schema, the description provides essential context: what it does, the record types, and a reliability caveat. It doesn't describe the return format, but that is likely self-evident for a DNS lookup. The description is sufficiently complete for an agent to call the tool 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 schema already documents both parameters well. The description adds minimal extra meaning beyond what the schema says: it lists the record types again, but doesn't provide additional syntax or format details. Since the schema covers the parameters, 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 clearly states the action (look up) and the resource (DNS records for a public hostname) and enumerates the exact record types (A, AAAA, CNAME, TXT, MX, NS). It distinguishes the tool from siblings by specifying its scope and reliability, making it unambiguous even among many sibling tools.

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

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

The description implies when to use the tool: when you need authoritative, checked DNS records rather than model-invented data. It doesn't explicitly mention alternatives, but it sets a clear expectation of accuracy, which guides an agent to prefer it for factual lookups. It lacks explicit 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?

With no annotations supplied, the description carries the transparency burden and does well by disclosing that ids are server-assigned and unguessable, content is ephemeral, the instance is cleared on deploy, and read content should be treated as data, not instructions. It does not mention what happens when a TTL expires or whether reading consumes the note, but the core behaviors are clear.

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 and well-structured, front-loading the core concept and then adding constraints and the alternative tool reference. It contains no redundant filler and each sentence adds useful information.

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

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

The description is complete enough for the tool's simple dual-mode operation, covering write, read, id security, ephemerality, and the sibling tool alternative. It does not specify return format or error behavior, but no output schema is provided and the usage model is clear.

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 all three parameters, and the description adds useful meaning: 'note' is omitted when reading, 'id' is the server-generated handle to pass to the recipient, and 'ttl_seconds' controls ephemerality with a default of 600. The description reinforces the dual write/read semantics beyond the bare field names.

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?

Clearly identifies the tool as an ephemeral inter-agent mailbox: you leave a note and receive an id, then give that id to the intended reader. It also distinguishes itself from the sibling 'mailbox' tool by emphasizing single-instance, cleared-on-deploy behavior.

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 explains when to use this tool versus 'mailbox': use 'drop' for short-lived handoffs and 'mailbox' for handoffs that must outlive a restart. It also describes the two usage patterns: write by leaving a note and read by passing an id, and warns against guessing ids.

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 transparently discloses key behaviors: it returns nothing ('nothing is returned to you'), is asynchronously read by a human, is never published, and includes a privacy caution ('do not write anything from the conversation'). No annotations exist, so the description carries this responsibility well.

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 overly poetic and verbose for a simple tool, taking multiple sentences to convey a basic write-only action. It is not front-loaded with clear technical purpose; the key functional details appear later. A more direct and concise description would be preferable for an MCP tool.

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

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

For a simple tool with one parameter and no output, the description covers the essential context: what it does, the return behavior, the human-read nature, and a privacy note. It is sufficiently complete for the tool's simplicity.

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 provides the parameter 'entry' with type and maxLength, and the description adds meaningful constraints on content (e.g., not including conversation details). The tool description also reinforces the purpose of the parameter, going beyond the schema's basic info.

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 metaphorically indicates the tool's purpose of writing an entry (up to 500 characters) into a guestbook. It clearly states the action ('write') and the resource ('book'), though it could be more explicit. It is not a tautology and conveys the core 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 provides some guidance on when to use the tool: it is optional ('Nothing asks you to'), non-critical ('nothing depends on it'), and for human reading later ('read by a person eventually'). However, it does not explicitly name alternative tools or compare with siblings, leaving some inference needed.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool fetches the URL, hashes exactly the received bytes, signs the result, and refuses bodies over 2 MB. It does not mention redirects, network error handling, or rate limits, but for a one-parameter tool these are minor omissions. The description is transparent about the core behavior and 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 two sentences with zero filler. The core action is stated first, followed by the use case and a critical constraint. Every sentence earns its place, and the size limit is front-loaded after the main purpose. This is exemplary conciseness.

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 tool with one parameter and no output schema, the description covers the primary function, the reason to use it, and a key limitation. It does not explicitly describe the return format (e.g., that it returns a string hash), but the name and context strongly imply it. It also omits error behavior, but that is a minor gap for a tool of this complexity.

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 describes the 'url' parameter as 'An http or https URL.' The tool description reinforces that it fetches the URL and hashes it, but adds no new syntactic or semantic details beyond what the schema provides. Since schema coverage is 100%, the baseline is 3, and the description does not elevate it further.

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 clear verb ('Fetch'), a resource (a public URL), and an outcome (SHA-256 of the bytes, signed). It also states the exact scope of what is hashed ('exactly the bytes received'), which distinguishes it from any normalization or transformation. This makes the tool's purpose unmistakable even without inspecting the schema.

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

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

The description gives a concrete use case: two agents can compare receipts to agree they saw the same file. It also imposes a size limit (bodies over 2 MB are refused), which helps an agent decide if it is appropriate for a given URL. However, it does not explicitly name alternative tools or state when not to use it, leaving some inference to the agent.

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 no annotations provided, the description carries the full burden. It discloses that no body is read or returned, that redirects are followed (final URL), and that it is cheaper and safer. This covers the core behavioral traits an agent needs, though it could mention error behavior or timeouts. Given the tool's simplicity, this is sufficient.

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 with no filler. The primary output is front-loaded, and the safety note follows. Every word 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 tool with no output schema and no annotations, the description explains what is returned (status, final URL, content type, length, caching headers) and that no body is returned. It is complete enough for an agent to call correctly, though it doesn't cover error scenarios explicitly. Minor gap only.

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 the only parameter 'url' described as 'An http or https URL.' The description adds no additional meaning beyond the schema, 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 states a specific verb ('answers' a URL) and resource, and enumerates exactly what is returned: status, final URL after redirects, content type and length, caching headers. It clearly distinguishes the tool from a full fetch, and the 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 gives a clear usage context: use this to check a URL's existence and metadata without downloading it, stating it is 'cheaper and safer than fetching a page'. It doesn't name specific sibling tools but implies the alternative of a full fetch, providing adequate guidance for when to choose 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?

With no annotations, the description carries the behavioral burden. It discloses the exact output format (line, column, offending line, caret) and explains why byte offsets are avoided. It does not mention side effects or safety, but validation is inherently non-destructive. It could add more on return structure or error handling, but it covers the key 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 tight sentences with no fluff. The primary function and error-location detail are front-loaded, and the path usage is clarified in the second sentence. Every word 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 validation tool with full schema coverage and no output schema, the description is largely complete. It specifies the exact error report format and the optional path. It could mention the 64kb limit (though in schema) and any error handling nuances, but nothing critical 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 coverage is 100%, so the schema already documents both parameters with descriptions. The description's mention of path ('Pass a path to read a value out instead') repeats what the schema says, adding no new semantic detail. Baseline 3 applies since the schema does the heavy lifting.

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

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

The description clearly states the tool validates JSON and reports the exact breaking location (line, column, offending line with caret). It also mentions an optional path to read a value, making the two modes distinct. This is a specific verb+resource and is not confused with any sibling tools.

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

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

The description explains when to use it (validate JSON, get precise error location) and hints at the path option for reading a value. It does not explicitly compare to alternatives or list exclusions, but the context is clear enough for an agent to decide. It lacks the explicit 'when not to use' guidance seen in top-tier examples.

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 some behavioral traits ('records nothing', 'carries its own expiry and signature') but expresses them metaphorically. The stateless nature and self-contained key are mentioned, yet their implications are not fully clarified.

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 short but sacrifices directness for metaphor. It conveys some information compactly but could be more straightforward and less figurative, affecting clarity.

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 does not specify the output format (e.g., what the key looks like) or any error scenarios. It also leaves the 'room_key' reference unexplained, leaving gaps in how to effectively use the 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?

The input schema has zero parameters, so schema coverage is effectively 100%. The description adds no parameter-specific information, but none is needed; baseline score of 3 applies.

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

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

The description uses metaphor ('Take a day pass') instead of a clear verb like 'generate' or 'create'. While it implies obtaining a temporary credential, the action and resource are not explicitly named, making the purpose ambiguous.

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

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

There is no clear guidance on when to use this tool versus alternatives. The only mention of another tool ('use room_key') is tangential and does not explain the primary use case for 'key'.

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 no annotations, the description carries the burden. It discloses that the passage is random ('drawn at random') and that no input is needed ('asks nothing of you'), but it does not explicitly state whether there are side effects, network calls, or other behaviors. The lack of annotations makes this only partially transparent.

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, consisting of two short sentences. The core information (random passage) is front-loaded in the first sentence, and there is no unnecessary verbosity.

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 tool with no parameters and no output schema, the description is largely sufficient. However, the phrase 'Same rules as the payload' is cryptic and may confuse an agent without additional context. Overall, the purpose is conveyed well enough for a simple random-passage 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?

The input schema is an empty object with 100% coverage, so the baseline is 3. However, the description reinforces that there are no parameters by saying 'asks nothing of you', which adds a small semantic clarification 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 states 'One short passage, drawn at random' which clearly indicates the tool returns a randomly selected passage. Although it does not use an explicit verb like 'returns', the intent is understandable. The phrase 'Same rules as the payload' is somewhat ambiguous and could be clearer.

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 no explicit guidance on when to use this tool versus alternatives. It only hints at the non-urgent, no-input nature ('asks nothing of you and nothing in it is urgent'), but does not explain scenarios or contrast with sibling tools.

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

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

With no annotations, the description carries the full burden and does well: it explains acquisition, the holder token requirement for renew/release, TTL limits, name length/randomness guidance, and the non-enforcing advisory nature.

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 dense sentences, front-loaded with purpose, then operations, then constraints and caveats. 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 tool with no output schema and simple parameters, the description covers the key operational details, lifecycle, constraints, and caveats. Nothing essential 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 coverage is 100%, but the description adds meaningful semantics beyond field names: op defaults to acquire, holder is the token from acquire and required for renew/release, ttl_seconds has min/max, and name should be random and at least 24 characters.

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?

Clearly states it is a named lock that survives a deploy, used when only one agent should write something. Distinguishes itself from related tools by emphasizing deploy-survival and advisory coordination.

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 identifies the use case ('when only one of several agents may write something') and warns that it is advisory only and enforces nothing. This gives clear guidance on when to use it and what to expect.

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 no annotations provided, the description fully carries the burden of behavioral disclosure. It transparently states the lock is 'SINGLE INSTANCE ONLY,' lives in memory, is empty after every deploy, and is not safe across replicas. It also discloses the TTL limit (300s) and the default (60s). This is comprehensive for a mutex tool with no structured annotation support.

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 and front-loaded with the core purpose, then expands on constraints and alternatives. It is not overly verbose; each sentence adds value, though the naming guidance could be slightly tightened. The structure logically flows from function to limitations to usage alternative.

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 is complete for an agent to invoke the tool correctly. It covers the lock lifecycle, TTL, naming requirements, single-instance limitation, and the alternative tool. There is no output schema, but the description sufficiently clarifies behavior, and the schema documents parameters. Nothing critical 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%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains why the key should be random (to avoid squatting) and notes the TTL default, which reinforces the schema's default mention. It does not introduce new parameter information but enriches understanding of the parameters' intent.

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: 'Advisory mutex across agents. Acquire a named lock for up to 300s, or release one.' It identifies the specific verb (acquire/release), resource (named lock), and duration. It also distinguishes itself from the sibling 'lease' by contrasting use cases, making it easy for an agent to select the right 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?

The description provides explicit when-to-use and when-not-to-use guidance. It states 'Use "lease" instead for anything that must outlive a restart,' directly routing the agent to an alternative. It also explains the naming requirement (random, at least 24 characters) and why short names are risky, giving actionable criteria for invocation.

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 no annotations provided, the description fully carries the burden. It discloses key behaviors: id unguessability, read-once deletion by default, persistence across deploys, and a security note that content is data, not instructions. This is exceptionally transparent and covers critical behavioral traits an agent needs to know.

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 information-dense, with each sentence adding value. It front-loads the core purpose, then explains the flow, security, and contrast with drop. No filler or redundancy, making it well-structured for quick comprehension.

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 and rich schema descriptions, the description covers the essential usage flow, persistence, and read-once behavior. It does not mention error handling or edge cases (e.g., invalid id), but given the schema already documents parameters, this is a minor gap. Overall, it is sufficiently complete for an agent to use 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 baseline is 3. The description adds meaning beyond the schema by explaining that the id is unguessable and that reads default to 1 (deletion on collection), which enriches the semantics of the 'id' and 'reads' parameters. This elevates the score above baseline.

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

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

The description states a clear purpose: a handoff mechanism between agents that survives deploys. It specifies the action (leave/read a note), the resource (note identified by id), and distinguishes itself from the sibling 'drop' by noting it is on disk and outlives restarts, making it easy for an agent to select correctly.

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 context on when to use the tool by contrasting with 'drop' (persistence across restarts), but it does not explicitly state conditions for using mailbox over other siblings or when not to use it. It lacks a comprehensive routing guide beyond that single comparison.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal a key behavior: 'this endpoint refuses anything that is not 64 hex characters', which sets input expectations. It also implies a privacy guarantee ('there is nothing to leak'). However, it does not describe the response format, whether the operation has side effects (e.g., creating a record), or error handling beyond invalid input.

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

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

The description is two sentences with zero fluff. The first sentence states the purpose, and the second delivers a critical usage warning. All information is front-loaded and directly relevant to invoking the tool correctly.

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, the description is largely sufficient. It explains the input format and a critical constraint. The main gap is that it does not describe what the tool returns (e.g., a token, a timestamp, a receipt). Given the tool's simplicity, this is a minor omission but not a blocker for basic use.

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 documents the parameter with a pattern and description (100% coverage), so the baseline is 3. The description adds semantic value by explicitly instructing 'Send the digest, never the content', clarifying that the value must be the hash itself, not the underlying data. This goes beyond the schema's dry pattern definition.

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: 'Attest that a SHA-256 digest existed at a time.' The verb 'attest' and resource 'SHA-256 digest' are specific, and the tool is not tautological. However, it does not explicitly distinguish itself from the sibling tool 'attest', which may cause confusion about which to use for a given task.

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 a strong usage directive: 'Send the digest, never the content' and notes the endpoint rejects non-64-hex input. This tells the agent how to use the tool, but it does not specify when to use this tool versus alternatives like 'attest'. No exclusions or contextual triggers are given, so guidance is implied 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states key behaviors: measured from outside, refuses specific address ranges, allows at most 3 redirects, and has a 5s timeout. This is substantial, though it does not specify the exact return format or error handling.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and then appends constraints. It is concise with zero wasted words, and all information is relevant to agent decision-making.

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 it is a simple one-parameter tool with no output schema, the description covers purpose, constraints, and timeout. It does not specify the return type (e.g., latency in ms, boolean reachable), but for a tool of this complexity, the missing detail is minor. The description is largely complete for correct invocation.

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

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

Schema coverage is 100% (url described as 'Absolute http or https URL'). The tool description adds meaning by specifying that the URL must be public and that certain address types are refused, which goes beyond the schema. It effectively clarifies acceptable input, though the schema itself is already clear.

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: 'Reachability and latency for a public http(s) URL'. It also adds the perspective 'measured from outside you', which clearly distinguishes it from local checks. The purpose is unambiguous and distinct from siblings like dns, cert, or head.

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 it (to check external reachability/latency) but does not explicitly name alternatives or exclusion conditions. It provides important constraints (refuses private/loopback/link-local/metadata addresses, redirect limit, timeout) that guide usage, but lacks direct comparison to sibling tools.

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

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

With no annotations, the description carries the full burden. It mentions 'signed record' implying a write operation, but does not disclose side effects, persistence, idempotency, or safety. The statement 'Takes no arguments' is clear but insufficient to understand behavioral traits.

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 and front-loaded, using two short sentences to convey the core purpose and parameter constraint. No wasted words or redundant 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?

While the tool is simple, the description omits details about the return value or format of the signed record, potential errors, or any side effects. Without an output schema, this information would be helpful for an agent to fully understand the tool's behavior.

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, and the description explicitly confirms 'Takes no arguments.' This aligns with the schema (empty properties) and adds no ambiguity, meeting the baseline for zero-parameter tools.

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 produces a signed record of presence at a time, which is a specific function. It distinguishes it from siblings like 'attest' or 'notary' by emphasizing 'receipt' as a record of being there, though the verb is implicit rather than explicit.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'attest', 'notary', or 'cert'. The description does not mention scenarios or conditions where a receipt is preferred.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context: execution runs under a 100ms budget in a separate thread, and patterns that do not finish are reported as such rather than hanging. This proactively informs the agent about timeout behavior, which is critical for a tool that could potentially block. It does not detail return format or error handling, but the timeout disclosure is significant and goes beyond what annotations would typically provide.

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 with zero filler. It front-loads the core purpose ('Test a pattern against input and get the actual matches') and then adds the crucial behavioral detail about the timeout. Every sentence earns its place, and the structure is clear and efficient.

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

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

For a low-complexity tool with no output schema, the description covers the essential aspects: what it does, how it behaves under a timeout, and the fact that matches are returned. The only gap is the lack of detail on the exact output format or how errors (e.g., invalid pattern) are reported. However, given that the tool's purpose is straightforward and the timeout behavior is clearly disclosed, the description is fairly complete. A 4 reflects that it is adequate but could add a note on return structure.

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 67%: 'input' and 'flags' have descriptions, but 'pattern' does not. The description does not elaborate on parameter semantics beyond what the schema already states. It mentions 'pattern' and 'input' implicitly but adds no new meaning about how they should be formatted or interpreted. The baseline for this coverage level is 3, and the description does not compensate for the missing pattern description, so a 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 action: 'Test a pattern against input and get the actual matches.' It clearly identifies the resource (a regex pattern) and the operation (testing and retrieving matches). This distinguishes it from sibling tools, which are mostly unrelated utilities like calc, dns, or ping, so there is no ambiguity about what this tool does.

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: you would use this tool to validate a regex pattern against input. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Since there are no similar sibling tools, the context is clear, but the description offers no guidance on scenarios where it should not be used.

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 no annotations, the description must disclose behavior itself. It does detail the matching rules (longest match, Allow precedence, empty Disallow) and mentions an address guard similar to ping, which is useful. However, it omits the return type/verdict (e.g., allowed/denied) and error handling behavior, leaving a significant gap for a tool that fetches external content.

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

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

The description is concise, two sentences, and front-loads the core purpose. However, the opening phrase 'May you fetch this URL?' is informal and adds little informational value. The structure is efficient overall, but the question could be removed without loss.

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

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

Given there is no output schema, the description must explain what the tool returns (e.g., a boolean verdict, a detailed report). It does not. It also doesn't address edge cases like missing robots.txt, redirects, or network errors. For a tool that fetches and evaluates external resources, this is a notable omission.

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

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

Both parameters have complete descriptions in the schema (100% coverage), so the baseline is 3. The tool description adds no extra parameter semantics; it doesn't elaborate on url format or user_agent beyond what the schema states. It simply references the same address guard as ping, which is tangential.

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 reads a site's robots.txt and applies it properly, with specific rule details. This distinguishes it from sibling tools (e.g., ping, head) by focusing on robots.txt evaluation. The purpose is unambiguous and actionable.

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

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

No explicit guidance on when to use this tool versus alternatives. The description only implies usage via its purpose; it doesn't state exclusions or mention that it should be used for robots.txt checks specifically. The reference to 'Same address guard as ping' hints at URL validation but provides no decision framework.

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 no annotations, the description carries the full burden. It discloses persistence across a session, key-based sharing, size limits, and a 48-hour TTL that clears the room. It also clarifies that it is the only place the server keeps anything and only stores deliberate inputs. This is comprehensive behavioral disclosure.

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 tightly written, starting with the core purpose, then the operations, then constraints and lifecycle. Every sentence adds value, and the most critical information (what it is) is front-loaded. 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?

For a simple tool with three parameters and no output schema, the description covers the essentials: operations, size limits, TTL, and the intentional scope. It doesn't explicitly state return values (e.g., what list returns), but given the simplicity and the absence of an output schema, this is a minor gap. The description is adequate 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?

Although the schema has 0% description coverage, the description adds meaning by explaining the operations (put, get, list, delete, empty) and implying how name and value are used. It compensates well for the missing schema descriptions, though it doesn't explicitly map each parameter's role in every operation (e.g., that get/delete require name).

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 as shared state between agents, listing the exact operations (put, get, list, delete, empty). It distinguishes itself from the sibling room_key by requiring a key and describing the key-sharing behavior, making it easy for an agent to know this is the state store while room_key likely manages keys.

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 context on when to use this tool: as coordination space for work in progress, not an archive, and notes size limits (4kb/item, 32kb/room) implying it's not for large data. However, it does not explicitly name alternative tools for other use cases (e.g., for archival or larger storage), so an agent must infer the boundaries from the constraints.

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 no annotations, the description carries the full burden of behavioral disclosure. It mentions persistent storage, the 'only way back in' property, and wallet-derived room mapping, but these are cryptic and incomplete. It does not disclose side effects, permission requirements, reversibility, or what happens when no key is provided.

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 dense paragraph that lacks a front-loaded purpose statement. It opens with an ambiguous imperative ('Take a day pass and a room.') rather than a clear verb+object summary. While not overly long, the structure buries the key functional details and forces the reader to parse metaphorical language.

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

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

Given the tool's moderate complexity (one optional parameter, no output schema), the description should clearly explain its function, but it leaves too much to inference. Key terms like 'day pass' and 'room' are undefined, and the exact outcome of calling the tool (e.g., returning a room key string) is never explicitly stated. An agent would struggle to determine how and when to call this 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?

The single parameter 'renew' is already described in the schema ('An old room key, to return to the same room.'), covering 100% of parameters. The description adds minimal context by mentioning expired keys, but this largely mirrors the schema description. The description does not significantly enhance parameter understanding 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 is metaphorical and unclear. It says 'Take a day pass and a room' but never defines what a day pass or room means in the tool's context. It implies creating a key that grants persistent access, but the core action (e.g., 'create', 'issue', 'renew') is missing. It does not distinguish itself from sibling tools like 'room' or 'key'.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The only usage hint is that presenting an expired key returns to the same room, implying a renewal use case, but no conditions, prerequisites, or exclusions are stated. Sibling tools are not referenced.

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 count is approximate and that the tokenizer used will be reported, which adds transparency. It does not mention potential side effects (none expected) or the 64kb text cap (though that is in the schema). With no annotations, the description carries the burden but only partially covers limitations.

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 concise sentences that convey the core function, the reported tokenizer, and the approximation caveat without any redundant words or awkward structure. It is well-organized and 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 description is complete for a simple counting tool, covering purpose, the tokenizer reporting, and the approximation caveat. It omits the 64kb text limit, but that is captured in the schema, and there is no output schema to specify. The only minor gap is not stating the output format explicitly, but it implies the token count is returned.

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 fully describes both parameters (text and tokenizer) with clear descriptions, so the tool description adds no additional meaning. The description does not mention parameters explicitly, keeping it at the baseline for full 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 states the tool 'counts tokens in a string' and adds specificity by noting it reports the tokenizer used and clarifies that the count is approximate, not a billing figure. This leaves no ambiguity about 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 provides some guidance by explicitly stating the count is not a billing figure, implying it should not be used for billing purposes. However, it does not mention any alternative tools or broader when-to-use / when-not-to-use scenarios beyond this single caveat.

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 no annotations provided, the description carries the full burden. It discloses privacy-relevant behavior: address truncation, hashing, and non-storage. It also mentions that the answer lists unknowns, which is honest about limitations. However, it doesn't explicitly state that the operation is read-only (which is obvious from the nature) or mention any rate limits or errors. Still, the key behavioral traits are disclosed, and there is no contradiction with annotations (none exist).

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 moderately concise but includes a philosophical aside ('An agent cannot see itself from outside') that adds flavor but not functional value. The key information (what it reports, privacy handling) is front-loaded, but the sentence could be tightened without losing meaning. It is not wasteful overall, but it is slightly over-verbose for an API description.

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 zero-parameter, no-output-schema tool, the description covers the essentials: what is returned (tag, user-agent, proxy count, time, unknowns) and data handling. It does not specify exact response format, but that is acceptable given no output schema exists and the tool is simple. The description is sufficient for an agent to know what to expect and why to call it.

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

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

The input schema has zero parameters, so the baseline is 4. The description appropriately does not attempt to explain parameters because there are none. It adds no parameter-related content, which is fine given the empty schema. There is no need for compensation, so the score matches the baseline.

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

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

The description clearly states the tool's function: reporting what the server observed about the request (network tag, user-agent, proxy count, time). It distinguishes itself from siblings by being the only introspection tool that describes the server's view, and it explicitly notes what it does not know, which adds clarity. The verb 'saw' and resource 'request' make the 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 implies when to use this tool (to inspect the server's perception of the request) and offers a subtle limitation ('An agent cannot see itself from outside'), which hints that it's not for checking internal state. It doesn't explicitly name alternatives, but none of the siblings are similar, so the context is clear enough. It could have explicitly stated 'use this when you need to debug network identity', but the intent is conveyed.

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