loop-mcp

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is partly covered. The description adds meaningful context by fixing the encoding assumption (UTF-8 input) and implying decode validates its input ('safely') rather than silently producing garbage. It omits the L402 paid-call flow entirely, which is the most consequential behavior of this tool, though that is documented in the l402_proof parameter.

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

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

A single sentence with no padding; the two operations are front-loaded and the qualifier about alphabets is the only trailing detail. Nothing could be removed without losing information.

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

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

For a four-parameter utility with no output schema, the description covers the core operation but says nothing about what encode/decode returns or how decode failures surface, and it is silent on the payment-required flow. The schema fills those gaps, so the definition is workable but not 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?

Schema coverage is 75%, so the schema carries most of the load, but the description still adds interpretation: 'UTF-8 text' clarifies what the data parameter accepts on encode, and 'standard and URL-safe alphabets' frames the url_safe flag as an alphabet choice rather than a separate mode. It does not restate the 100 KB limit or the padding behavior, which live 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 pairs two specific verbs (encode, decode) with the exact resource (UTF-8 text / Base64) and states the alphabet variants, so its function is unmistakable. It does not name or contrast any sibling (e.g. hash_generate, jwt_decode), but the operation is distinct enough that confusion is unlikely.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives or when not to use it. The only hint is the adverb 'safely' for decode, which implies input validation but is not spelled out as a condition for choosing 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?

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, and the description usefully adds provenance details (source URL, fetched_at in RFC 3339, source_sha256 of the upstream body). However, it omits the most consequential behavior: an unpaid first call returns a 0-sat Lightning invoice and macaroon rather than a price, a fact that appears only inside the parameter 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?

Three short sentences, front-loaded with the core capability, followed by source and freshness, then the provenance fields. No filler or repetition.

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

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

With no output schema, the description must convey the return shape: it lists the provenance fields and mentions USD plus other currencies, but does not describe the price field structure or currency keys. It also fails to surface the payment-gated first-call behavior, which is essential to calling the tool successfully.

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

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

Schema description coverage is 100% and the l402_proof parameter's description fully documents the invoice-then-retry flow, so the schema carries the parameter burden. The tool description itself says nothing about l402_proof, so it adds no meaning beyond the schema; baseline 3 applies.

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

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

The description states a specific verb and resource ('Get the current Bitcoin price in USD and other major currencies') plus the upstream source (mempool.space), so an agent can immediately tell it apart from sibling utilities like btc_send_decision. It stops short of naming which 'other major currencies' are supported, leaving the return shape partially open.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no routing to or away from siblings such as btc_send_decision or optimal_send_window. 'Real-time' implies it is for fresh quotes, but that is inference rather than stated guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered; the description adds that it performs live fetching of mempool and fee data and returns a machine-actionable verdict plus pressure level and savings estimate. It omits one material behavior: this is a paid endpoint whose first call returns a Lightning invoice rather than a verdict, which an agent only discovers from 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?

Three sentences, front-loaded with the outcome and followed by mechanics and fit, so an agent gets the gist from the first line. Minor redundancy between "composited send-or-wait recommendation" and "machine-actionable verdict" keeps it off a 5.

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

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

With no output schema, the description does the necessary work of naming the return fields (verdict, sat/vB fee rates, mempool pressure, estimated savings), which is the key gap it had to fill. The missing piece is the pay-per-call gating on the first invocation, though that is recoverable from 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?

Schema description coverage is 100%, and the enum for urgency plus the L402 proof flow are fully documented there, so the schema carries the parameter burden. The description adds no meaning beyond it, not even referencing urgency as the lever that shapes the verdict, so baseline 3 applies.

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

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

"Returns a composited send-or-wait recommendation for a Bitcoin transaction" names a specific verb and artifact, and the enumeration of verdicts (SEND_NOW, WAIT, URGENT_ONLY) pins down exactly what comes back. An agent can distinguish this from btc_price or optimal_send_window without opening 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?

"Ideal for agents that need a single decision call instead of parsing multiple raw mempool endpoints" gives a clear situational fit. However, it never names or excludes the closest sibling, optimal_send_window, which plausibly overlaps in intent, and gives no when-not-to-use condition.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds 'bounded row output', hinting at truncation behavior, but omits other notable behavior such as the pay-per-call requirement and whether output is truncated silently or with a marker.

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

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

A single sentence with the format list and the output constraint front-loaded, zero filler. Nothing could be removed without losing information.

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

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

There is no output schema, so the description should clarify the return shape — object-per-row keyed by header versus arrays — and it only says 'structured JSON'. The L402 behavior and error paths are documented in the schema rather than the description, leaving moderate gaps for a caller reasoning from the description alone.

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 still reinforces the capped-row semantics ('bounded row output') and the delimiter formats it accepts, which map to the max_rows and delimiter parameters. It adds no contradicting or redundant detail.

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

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

The description uses a specific verb ('Convert') and names the source resource (CSV, TSV, semicolon, pipe-delimited text) and output ('structured JSON with bounded row output'). It's easy to distinguish from siblings like json_extract or json_validate, though it never explicitly states that distinction.

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

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

Usage is implied by the narrow purpose — parse delimited text into JSON — but there is no explicit 'use when' or 'do not use when' guidance, and no mention of the L402 payment retry flow that a first-time caller will encounter. The schema carries the payment instructions instead.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only that output is a hexadecimal or Base64 digest; it says nothing about the L402 payment flow, which is the most consequential behavioral trait of this tool and appears only in the schema's l402_proof parameter.

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

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

A single front-loaded sentence with zero filler; the resource and both option families are stated up front.

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 deterministic hash tool this is nearly adequate, and there is no output schema to explain. However, the description omits the paid-call/L402 flow that will surprise an agent on first invocation, and does not state that output is a single digest string.

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

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

Schema description coverage is 100%, including enum values for encoding and algorithm and the detailed L402 payment instructions, so the schema does the heavy lifting. The description merely restates the algorithm and encoding choices already enumerated in the schema, adding no new meaning.

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

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

The description names a specific verb+resource (generate a SHA-256/SHA-512 digest) plus the output representations, which distinguishes it from siblings like base64_convert and uuid_generate without needing to name them. It doesn't explicitly contrast with siblings, so it falls short of a 5.

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

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

There is no when-to-use guidance, no mention of alternatives such as base64_convert, and no note of prerequisites. The agent must infer usage entirely from the name and schema.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful constraint that only a single value is returned, but says nothing about the L402 payment retry flow or failure behavior, which live only in the schema's l402_proof text.

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

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

A single sentence that front-loads the operation, states the scope (one value), and ends with a concrete example. No wasted wording.

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

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

For a simple two-parameter read tool with full schema coverage and no output schema, the description conveys scope and return shape (one value) adequately. The only shortfall is that the non-obvious Lightning payment retry behavior is never surfaced outside the parameter text.

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 both required parameters and the payment proof are already documented, including path syntax examples. The description's example path duplicates the schema's "path" description and adds no format or edge-case detail beyond it; baseline 3 applies.

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

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

The description gives a specific verb and resource ("Extract one value from JSON") plus the mechanism (dot path with array indexes) and a concrete example. This clearly separates it from siblings like json_validate (validation) and csv_to_json (format conversion) without the agent needing to open any schema.

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

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

The extraction use case is implied by the description and example, but there is no explicit when-to-use guidance, no mention of pairing with json_validate, and no statement of when this tool is the wrong choice (e.g. needing multiple values at once). Usage must be inferred.

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

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

Annotations mark it read-only and non-destructive. The description adds useful output details: normalized JSON, root type and SHA-256 hash. It does not explain what happens with invalid JSON, what 'normalized' means (key sorting? whitespace?), or the L402 payment gating, which the schema documents but the description omits.

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?

It is a single front-loaded sentence with no wasted words. Every clause states an output or action.

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

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

There is no output schema, and the description only partly covers returns. It omits error behavior for invalid input and the normalization rules. The payment flow lives only in the schema, a notable gap for a tool whose first call returns an invoice instead of a result.

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

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

Schema coverage is 100% and well documented, including the 100 KB limit and the L402 flow. The description adds nothing about parameters beyond the schema, so the baseline of 3 applies.

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

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

It gives specific verbs and outputs: validate, identify the root type, and return normalized JSON plus a SHA-256 hash. It does not separate itself from siblings like json_extract or hash_generate, though the purpose is distinct enough to infer.

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

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

It gives no guidance on when to use this tool over json_extract (querying), hash_generate (hashing arbitrary text) or csv_to_json. It also says nothing about the two-step payment flow as a usage prerequisite; only the schema covers that.

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

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

Annotations declare the safety profile (readOnly, non-destructive, open-world), so the description's job is to add operational context. It does: processing happens 'locally' and the response 'always marks verification as false', which is a meaningful caveat an agent could otherwise misread as a validation result. It stays silent on malformed-token behavior and on the paid L402 retry flow, but that flow is documented in the schema.

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

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

Two tight sentences, with the non-verification caveat front-loaded in the first sentence and the output guarantee in the second. Nothing is redundant or padded.

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

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

With no output schema, the description supplies the single most important return-value fact (verification always false) and the local-processing guarantee, which is enough to call the tool correctly. It could go slightly further by noting behavior on malformed tokens or that the decoded claims are returned as an object, but the critical risk is covered.

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%, including the 20 KB token limit and the full L402 payment-proof workflow, so the schema carries parameter meaning. The description adds nothing about either parameter; 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 and resource ('Decode JWT header and payload claims') and adds the essential scope qualifier 'without verifying the signature', which distinguishes it from any verifying or signature-checking alternative. An agent knows exactly what it gets without opening 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 'without verifying the signature' phrase implies when this tool is appropriate (inspection only) versus when signature validation is needed, but it never names an alternative or states an explicit exclusion. Usage is inferable rather than prescribed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety and external-network reach are covered. The description adds that the LNURL-pay protocol is handled internally and that min/max sendable amounts come back for validation, which is genuine extra context. However, it omits the L402 gating behavior (the first call returns a 0-sat invoice and macaroon), leaving that disclosure entirely to 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?

Three short sentences, front-loaded with the core verb and resource, then the protocol behavior, then the return payload. Each sentence carries distinct information with no filler or restated title.

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

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

With no output schema, the description usefully states what comes back (invoice plus min/max amounts), and the annotations cover the safety profile. It is a simple two-required-parameter lookup, so little more is needed; the main gap is error behavior for malformed addresses or unreachable domains.

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: address format, the 1–100,000,000 sat bounds, and the l402_proof flow are all fully documented in the schema. The description only reinforces that amount is what the caller wants to send and that min/max should be checked against it, adding little beyond the structured fields.

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 gives a specific verb and resource: 'Resolve a Lightning Address (user@domain.com) to a payable BOLT11 invoice', including the exact input format and output type. No sibling tool in the list overlaps with Lightning payments, so there is nothing to disambiguate against, which keeps this just short of a 5.

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

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

Usage is implied by the phrasing 'for a given amount' — an agent infers this is the tool for turning a Lightning Address into a payable invoice. There is no explicit when-to-use or when-not guidance, no prerequisites, and no mention of what to do when the address is invalid or the domain is unreachable.

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

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

The annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so safety behavior is covered. The description adds useful behavioral context about the returned forecast components, confidence calibration, RBF flag, and data source, though it does not mention the L402 payment flow in the description itself.

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

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

The description is front-loaded and information-dense, with each major clause describing a relevant output or behavior. The opening phrase is somewhat vague, and the long list is dense, but it generally earns its length.

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

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

For a tool with no output schema, the description does a good job enumerating return values and the source of the data. Parameters and safety annotations are well covered, though the omission of sibling differentiation and the L402 flow in the description leaves a small gap.

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

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

Schema description coverage is 100%, so all three parameters are already well documented in the input schema. The description reinforces the target fee and forecast window concepts but adds little parameter syntax or meaning 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 that the tool returns a Bitcoin fee/congestion forecast, recommended send window, fee trajectory, confirmation targets, and RBF viability. It distinguishes itself as a synthesis layer above raw fee data, but it does not explicitly differentiate itself from the sibling btc_send_decision 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 implies usage by saying this is the decision an autonomous payment agent needs before broadcasting. However, it gives no explicit when-to-use guidance, exclusions, or comparison with alternatives such as btc_send_decision.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds the meaningful trait that results are deterministic, i.e. reproducible for identical input. It does not, however, surface the paid-call/L402 flow or any rate limiting in the description itself, leaving that entirely to 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?

A single front-loaded sentence that enumerates the outputs with zero filler. Every clause contributes information an agent would use to select the 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?

With no output schema, the description usefully lists what comes back (statistics, token estimate, reading time, content hash), which is the key information for selection. It could say more about the shape of the statistics object, but the L402 payment mechanics are handled by 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?

Schema coverage is 100%, with both `text` (size limit) and `l402_proof` (payment retry flow) fully documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb (return) and resource (text statistics) and enumerates the outputs: token estimate, reading time, SHA-256 hash. This differentiates it from siblings like hash_generate, which produce hashes but no text metrics, though the description never names a sibling explicitly.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as hash_generate for pure hashing. Usage is only inferable from the tool name and the enumerated outputs.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered and the bar is lower. Beyond that, the description adds no behavioral context: it does not mention the L402 payment gating implied by the l402_proof parameter (unpaid calls return an invoice), does not say what output form 'normalized UTC timestamp forms' actually is, and gives no error behavior for unparseable 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?

A single front-loaded sentence with zero filler; the verb and the input formats come first and the output goal last. It is slightly under-sized for a tool that carries a payment flow, but nothing in the sentence is wasted.

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

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

The tool is a simple 3-parameter converter with full schema coverage and no output schema, so the burden is modest and the description is adequate at a minimum-viable level. However, 'normalized UTC timestamp forms' is left undefined (RFC3339 string? epoch seconds?) and the L402 payment prerequisite, which an agent must know to succeed on the paid path, appears only in the schema rather than being surfaced in the description.

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 baseline is 3. The description's format list does mirror and reinforce the 'from' enum values (unix, unix_ms, rfc3339, date), but it adds no meaning about the 'auto' inference behavior, the expected string shape of 'value' per format, or the payment flow for l402_proof beyond what the schema text already says.

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

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

The description names a specific verb (convert) and resource (timestamps) and enumerates the exact accepted input formats: Unix seconds, Unix milliseconds, RFC3339, and ISO dates. It also states the output direction (normalized UTC), so an agent can immediately tell this is a format-normalization utility and no sibling (base64_convert, hash_generate, url_parse, etc.) overlaps with it.

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

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

Usage is only implied: the listed formats suggest callers pass any of them, and the schema's 'auto' default implies inference. There is no explicit statement of when to use this versus siblings, no guidance on when to set 'from' explicitly rather than relying on 'auto', and no guidance on ambiguous inputs.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description goes beyond that by disclosing the exact shape of the response and the token-savings rationale, which is genuinely useful behavioral context. It stops short of covering the L402 payment behavior, but that is documented in the schema's parameter description.

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

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

A single dense sentence with the core action front-loaded and the return fields listed after. The field enumeration is long but each item carries real information for an agent; the closing token-savings claim is mild marketing but still justifies using this tool over raw parsing.

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

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

There is no output schema, so the description must carry the return-value burden, and it does so by enumerating every field returned. The payment flow lives in the schema, and error conditions for invalid or unknown txids are the only notable gap.

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

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

Schema description coverage is 100%, so both the txid format and the L402 payment flow are fully documented structurally. The prose adds no syntax, format, or constraint detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb (fetch) and resource (Bitcoin transaction by txid) and enumerates the returned fields: type, input/output counts, fees, fee rate, confirmation status, RBF, SegWit/Taproot flags, and agent_summary. No sibling in the list performs transaction decoding, so the differentiation gap is irrelevant here.

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

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

Usage is only implied: an agent infers it should call this when it has a txid and wants a decoded summary. There is no explicit when-to-use versus alternatives (e.g. when to prefer this over raw hex parsing) and no exclusions or prerequisites stated in the description itself.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so safety is covered. The description usefully adds that no fetch occurs and that output is normalized, but it does not mention the L402 payment flow, error behavior, or rate limits. Some value beyond annotations, but not rich behavioral context.

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

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

A single front-loaded sentence that states the operation, input domain, outputs, and a key non-behavior ('without fetching it') with zero wasted words.

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

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

For a simple two-parameter parsing tool with full schema coverage and no output schema, the description is nearly complete: it names the input types and all output fields. It could be stronger by briefly acknowledging the L402 payment requirement, but that is already fully 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?

Schema description coverage is 100%, so the schema already documents both parameters, including the L402 proof flow. The description adds no parameter-level meaning beyond what the schema provides, which is the expected baseline when schema coverage is complete.

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

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

The description uses a specific verb ('Parse') and resource ('HTTP or HTTPS URL') and enumerates the exact output fields (scheme, host, port, path, query, fragment). It is immediately distinguishable from every sibling tool, none of which parse URLs.

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

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

The phrase 'without fetching it' implies the tool is for structural parsing rather than retrieval, but the description gives no explicit when-to-use guidance, prerequisites, or alternatives. Usage is inferable from the purpose but not stated.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds meaningful detail about cryptographic randomness and UUID version 4. It omits the L402 paid-call flow entirely, which is the one non-obvious behavior an agent would want flagged.

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

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

A single front-loaded sentence with no filler; every clause (quantity, randomness, standard, version) carries distinct information.

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

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

For a two-parameter tool this is mostly sufficient, but a description-only reader would be blindsided by the paywalled first call returning a Lightning invoice instead of UUIDs. The schema covers it, so the gap is not fatal, but the description could have warned about the two-step payment flow.

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 earns a 4 by restating the count range (one to one hundred) in the call's own intent language and confirming the default of a single identifier is the minimum. It says nothing about l402_proof, though the schema documents that thoroughly.

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

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

States a specific verb (generate), resource (RFC 4122 UUID version 4 identifiers), quantity range (one to one hundred), and quality guarantee (cryptographically random). An agent knows exactly what it gets and cannot confuse it with hash_generate, which produces digests rather than identifiers.

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

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

Usage is only implied by the nature of a UUID generator; there is no explicit when-to-use or when-not, and no pointer to alternatives such as hash_generate for cases where a digest is actually wanted. Acceptable for a narrow utility, but nothing steers the agent.

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