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

With no annotations provided, the description carries the transparency burden. It discloses 'FREE' (no cost), 'Deterministic' (pure function, no side effects), and the 400 error response for invalid conversions. These are meaningful behavioral traits beyond what schema alone would 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?

The description is compact: two informative sentences plus two clarifying examples. Every sentence contributes to the agent's understanding, with no filler or redundant restating of the schema.

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

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

Given the tool's simplicity and the rich schema coverage, the description adequately covers purpose, parameter semantics, examples, and error behavior. It stops short of specifying the exact return value shape, but for a straightforward converter the output is highly inferable.

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 descriptions cover all three parameters (value, from, to), providing a baseline of 3. The description adds semantic value with concrete examples like {value:100, from:'c', to:'f'} and unit abbreviations ('GiB', 'MB'), clarifying accepted formats that the schema does not fully illustrate.

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

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

The description opens with a specific verb and resource: 'Convert a value between units in the same dimension' and enumerates a clear list of dimensions (length, mass, temperature, etc.). This directly distinguishes it from sibling tools like currency and timezone, which handle different conversion 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?

The tool explicitly limits usage to same-dimension conversions and states 'Different-dimension conversions 400', effectively signaling when not to use it. It does not explicitly point to alternative tools by name, but the boundary is clearly communicated.

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 disclosing non-obvious behavior. It explicitly reveals the paid nature ($0.001), the x402 challenge when payment is omitted, and how to settle via x_payment. This goes beyond the schema and covers critical 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 compact and well-structured. It front-loads the cost warning, then explains the core functionality, summarizes arguments, and closes with the payment challenge behavior. Every sentence adds a distinct piece of information with no filler.

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

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

The description covers key contextual aspects: accepted cron format, default values, payment requirement, and the high-level result (run times plus description). While the exact return structure isn't detailed, the tool is relatively simple and the absence of an output schema is partially compensated by this clear summary.

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 description coverage is 100%, so the input schema already documents all parameters. The description repeats argument names and defaults (timezone, count, from) without adding new semantic meaning or clarifications beyond what the schema provides.

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: 'Parse a 5- or 6-field cron expression and return the next N run times plus a plain-English description.' This uses a specific verb and identifies both the input and output, distinguishing it from sibling tools like rrule.

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 clear context of what the tool does, so the agent can infer when to use it, but it does not explicitly mention alternative tools (e.g., rrule) or provide 'when not to use' guidance. Usage is implied rather than stated.

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

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

Discloses the paid nature ($0.001), cached feed, keyless ECB source, informational-only caveat, and the 402 challenge / x_payment flow. This is extensive behavioral transparency beyond annotations (which are absent).

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?

Dense yet compact: three sentences communicate cost, source, use case, payment flow, and argument list. Front-loaded with the PAID flag and no filler.

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

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

Despite no output schema or annotations, the description covers price, data source, caching, limitations, and payment mechanics. The result (converted amount) is implied and sufficient for a simple converter.

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 100% coverage. The description briefly mentions amount, from, to (ISO-4217) and x_payment behavior, but this largely mirrors the schema, adding little new semantic value.

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 converts amounts between currencies using reference/mid-market rates from the ECB. The verb 'Convert' plus the specific resource (currencies) differentiates it from generic siblings like '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?

Provides clear context: it's for informational reference rates, not dealable quotes, and explains the x402 payment flow. However, it doesn't explicitly mention when to use this tool over a sibling like 'convert'.

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 transparency burden. It discloses the paywall behavior (x402 challenge) and that x_payment is required to settle the $0.001 fee, along with configurable weekend/holiday handling. It doesn't describe output format or edge cases, but the key behavioral traits are covered.

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 front-loaded, starting with the payment notice and operation list. Every sentence adds functional information, and the structure maps cleanly to the schema's op property. 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?

Given the tool has 11 parameters and no output schema, the description covers all operations, parameter roles, and the payment challenge. It lacks explicit mention of return shape, but for a multi-mode calculation tool the core usage context is sufficiently 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?

Schema coverage is 100%, so baseline is 3. The description adds semantic value by grouping parameters per operation (duration/date for add/subtract, from/to/units for diff, days/weekend/holidays for business-add/diff). This explains how parameters interplay beyond individual schema 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 clearly states the tool performs calendar date math with four explicit operation modes: add/subtract durations, diff datetimes, and business-day add/diff. It distinguishes itself from sibling tools like timezone and cron by specifically enumerating date-math operations and the ISO-8601 duration format.

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 concrete usage patterns per operation (e.g., 'op='add'/'subtract' an ISO-8601 duration...'), and mentions the payment requirement and challenge flow. It does not explicitly compare to sibling tools or state when not to use it, but the self-contained usage guidance 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?

With no annotations, the description carries the full burden and does well by disclosing the payment requirement, the 402 challenge behavior, and the types of results returned. It doesn't cover edge-case errors, but the most important non-obvious behavior is transparently explained.

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 covering purpose, arguments, outputs, and payment flow. It is efficient overall, though it repeats the $0.001 fee already in the title, which is a minor 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?

Despite lacking an output schema, the description names the three output forms (unified patch, op-list, stats), giving a sufficient expectation of results. It also fully explains the payment challenge flow, which is essential for a paid tool. Some internal structure of the op-list/stats is unspecified but tolerable.

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 71%, and the description largely restates default values and mode choices already present in the schema (e.g., 'default lines', 'context default 3'). It adds little new meaning for label_a/label_b, 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 opens with 'Diff two texts' and lists specific outputs (unified patch, structured op-list, stats), clearly identifying the verb and resource. It distinguishes itself from sibling tools like encode/convert/hash, which are unrelated transformations.

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 tool's purpose implicitly defines when to use it, and the description provides concrete context about the paid workflow (x402 challenge and x_payment settlement). It doesn't explicitly contrast with alternatives, but no sibling tool performs diffs, so exclusions aren't 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?

With no annotations, the description carries the full burden. It only mentions 'FREE' and the operation list, but does not disclose error behavior, return format, or any side effects. This is insufficient for a tool with no structured 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 brief and front-loaded with 'FREE' and the core action. The second sentence is a compact list of operations. While 'FREE.' is unnecessary, the structure is efficient and to the point.

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, but there is no output schema, so the description should explain return values. It does not explicitly state that the result is the encoded/decoded text. Error handling is also unaddressed, leaving the description adequate but incomplete.

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 'op' and 'text' documented. The description adds no additional semantics beyond the schema—it merely lists the valid operations, which are already present 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 clearly states 'Encode or decode text' and lists all supported operations (base64, hex, url, html) with specific verbs. This distinguishes it from sibling tools like hash or convert, which serve different purposes.

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

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

Usage is implied: the user needs text encoding/decoding in one of the listed formats. However, there is no explicit guidance on when to use this versus alternatives, nor any exclusions.

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

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

With no annotations, the description carries the full burden. It discloses output encodings (hex/base64/base64url), HMAC support, and a special 0x-form for keccak256, adding value beyond the schema. It omits the HMAC restriction for keccak256/sha3-256, but that is present in the schema.

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

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

The description is concise and front-loaded, with the core purpose and algorithm list in the first sentence. The 'Args' summary at the end is slightly redundant given the schema, but it serves as a quick reference without bloating the overall length.

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

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

The description covers the essential aspects: algorithms, HMAC, encodings, and the special 0x-form. Minor details like base64url input encoding and HMAC restrictions are missing but are captured in the schema. For a moderate-complexity tool with no output schema, this is sufficiently 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?

Schema coverage is 100%, so the baseline is 3. The description repeats parameter names and some values but adds little semantic detail beyond the schema. It even omits 'base64url' from input_encoding in the summary, relying on the schema for full details.

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

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

The description clearly states the tool's function: 'Compute a cryptographic digest' with a specific list of algorithms (sha256, md5, etc.). This distinguishes it from siblings like encode/convert, which focus on other transformations. The title 'Hash / HMAC' reinforces the 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 gives clear context for when to use the tool—for cryptographic hashing and HMAC—and lists input/output encoding options. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough for an agent to select it appropriately.

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 useful context by stating 'Uses a CSPRNG' and noting kind-specific parameter usage (size for nanoid, bytes for hex/base64url). However, it does not describe the response format, error behavior, or any side effects beyond generation, which leaves some gaps for an unauthenticated 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 short and front-loaded with the core purpose. However, 'FREE.' is cryptic and likely a wasted token, and the trailing 'Args: kind, count.' duplicates what the schema already communicates. It remains compact and readable, but not 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?

The tool has four optional parameters and no output schema, so the description needs to cover parameter behavior and invocation constraints, which it does (kind enumeration, count cap, size/bytes mapping, CSPRNG). It omits the return value shape, but for a simple ID generator this is likely inferable. Overall, it is sufficient for an agent to select and use this tool correctly among siblings.

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 covers all four parameters, so the baseline is 3. The description adds value by clarifying how parameters relate to the 'kind' selector (e.g., nanoid uses size, hex/base64url use bytes) and setting the count limit at 1000. This goes beyond the schema's individual descriptions and helps the agent construct valid invocations.

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 'Generate identifiers' and enumerates all supported kinds (uuidv4/uuidv7, ulid, nanoid, hex, base64url, int), which directly matches the title. This is a specific verb+resource statement that distinguishes the tool from unrelated siblings like encode or regex.

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 ('Generate identifiers') and provides constraints like 'count up to 1000', but it does not explicitly name alternatives or state when not to use it. The sibling tools are clearly different domains, so usage context is somewhat self-evident, but no explicit guidance or exclusions are given.

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

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

With no annotations provided, the description carries the full burden. It discloses the payment requirement ($0.001), the challenge behavior ('Without payment returns the x402 challenge'), and the detail level of error explanations ('which property, what was wrong, allowed values'). This is transparent about cost, failure mode, and output quality.

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 two-sentence structure that front-loads the paid nature and then states the core functionality. It avoids unnecessary words and every clause delivers useful information, including the appeal to pass x_payment.

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 the main workflow: validation, error explanation, payment challenge, and settlement. Since there is no output schema, it adequately describes return behavior (errors in plain English, challenge response). It falls slightly short of a 5 by not explicitly describing the successful validation result, but the overall context is sufficient for a simple 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 schema description coverage is 100%, so each parameter already has a description. The tool description only lists the args ('schema (object), data (any)') without adding extra meaning beyond the schema. It does clarify x_payment's purpose, but that is already well-described in the schema. Thus, it meets the baseline for high 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 verb 'Validate' and the resource 'a JSON Schema (draft 2020-12)', with the added benefit of explaining errors in plain English. This distinguishes it from sibling utility tools like regex or convert. The purpose is specific and 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 implicitly indicates when to use the tool (for JSON Schema validation against draft 2020-12) and provides practical context about the payment prerequisite and x_payment parameter. It lacks explicit exclusions or named alternatives, but the usage context is clear enough for an agent to decide.

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 the catastrophic-backtracking protection, killable worker, hard timeout, and the fact that pathological patterns return a 400 instead of hanging. This adds meaningful behavioral context beyond the raw schema.

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

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

The entire description is one concise sentence that leads with 'FREE' and the safety guarantee, then immediately notes op types and relevant args. Not a wasted word, and the structure is 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?

The schema covers all parameters and the description adds safety context, but there is no output schema and the description does not explain what each op returns (e.g., boolean for test, match list, replacement string). For an AI agent, this leaves some ambiguity about expected return values.

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

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

The schema already covers 100% of parameters with descriptions, so the baseline is 3. The description's 'Args' summary restates op, flags, and replacement but does not add deeper semantics beyond what the schema already provides. It omits the limit parameter entirely, though that is also 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 opens with 'Run a regular expression against input' and the title enumerates 'test / match / extract / replace', giving a specific verb+resource. This clearly distinguishes it from sibling tools like encode, convert, and text, which handle other text 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?

The description conveys usage through the op parameter (test|match|extract|replace) and the safety note, but it never explicitly states when to prefer this tool or what alternatives exist. Usage is implied by the tool's function rather than stated as 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, the description carries the full burden of behavioral disclosure. It explicitly states the $0.001 cost, the x402 challenge when unpaid, and the role of x_payment. It also provides a tip about DTSTART, adding practical behavioral context beyond bare parameter listings.

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 with a front-loaded payment notice, a precise function statement, and a compact argument list. The tip and payment warning are integrated without redundancy. 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?

Despite lacking an output schema, the description conveys the core return concept (next N occurrences) and all operational prerequisites such as payment and DTSTART anchoring. It does not elaborate on timezone rendering or error handling, but for a paid tool with five parameters, coverage is solid.

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 100% parameter coverage, so the description only needs to add value. It offers an example RRULE string and clarifies the payment behavior connected to x_payment. The DTSTART tip enriches the rrule parameter semantics, going beyond the schema's generic 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 tool's specific action: expanding an iCal RRULE into its next N occurrences, citing RFC 5545. This distinguishes it from sibling tools like cron or datemath which handle other time-based operations. The title reinforces the 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 explains the payment model—pass x_payment to avoid the 402 challenge—and advises including DTSTART for anchored series. It does not explicitly name alternatives or exclusions, but the specialized scope makes the intended use 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?

With no annotations provided, the description carries the full burden. It discloses that the tool is free, describes each op's behavior (e.g., slugify -> URL slug), and specifies required argument combinations. However, it omits return format, error behavior (though strict is in schema), and any side effects.

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, starts with the core purpose ('FREE. Text transforms.'), and every sentence provides necessary detail. It avoids redundancy with the schema.

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

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

While the description covers the main operations and argument combinations, it lacks a statement about return values, which is important given there is no output schema. It also does not address potential error cases, though strict behavior is documented in the 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 schema has 100% coverage, so the baseline is 3. The description adds value by explaining which parameters are used together for different ops, and elaborates on the 'op' parameter semantics beyond the schema's list enumeration.

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 explicitly identifies the tool as 'Text transforms' and enumerates all operations (slugify, case conversions, template filling), making its purpose unambiguous and distinct from sibling tools like encode or hash.

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 clear context by specifying which op requires which arguments (op + text for slugify/case, template + data for template), and implies when to use each op. However, it does not explicitly mention when NOT to use this tool or point to alternatives.

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

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

With no annotations, the description carries the full burden. It discloses the paid nature, the x402 payment flow (challenge vs. settlement), and the output fields (converted datetime, UTC offsets, tz abbreviations, DST flags, offset difference). It does not detail all error cases, but the key behavioral traits are transparently stated.

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 well-structured, leading with the crucial paid warning, then the core purpose, return fields, arguments, and payment flow. Every sentence is functional, though the density of information in one paragraph slightly reduces readability.

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 paid tool with no output schema, the description covers the essential context: payment mechanism, return values, required arguments, and a free alternative. It lacks explicit edge-case behavior (e.g., invalid zone handling) but is otherwise sufficiently complete 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 100% descriptive coverage for all four parameters, including formats and payment payload details. The description merely reiterates the args list and payment behavior without adding meaningful new semantics beyond what the schema already says, so 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 clearly states the tool's function: 'Convert an instant between IANA time zones with historically-correct DST.' This is a specific verb+resource that distinguishes it from generic siblings like 'convert' or 'datemath', and it also lists the return fields.

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: it is a paid timezone conversion tool. It explains the payment prerequisite ('Without payment returns the x402 challenge') and mentions an alternative ('Free teaser exists on the HTTP API'). However, it does not explicitly contrast with sibling tools or state 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.