loop-mcp

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a non-mutating local transformation. The description adds that decoding is handled "safely" and that URL-safe output omits padding, which is useful, but it says nothing about behavior on malformed input or the size ceiling (left 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 with no filler and the scope stated up front. The qualifier "safely" is slightly vague and earns less than the rest of the sentence, keeping it just short of a 5.

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

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

For a three-parameter, no-nested, stateless converter this is nearly enough. However, with no output schema the description should state that the result is a string (and whether decode returns text), and it is silent on the 100 KB limit and error behavior — small but real gaps.

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%: data and url_safe are documented, while action is a bare enum. The description partially compensates by tying 'standard and URL-safe alphabets' to url_safe and 'encode/decode' to action, but with no syntax or format detail beyond the schema, baseline 3 is appropriate.

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

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

States a specific verb pair (encode/decode) and resource (Base64) plus the supported alphabets, so an agent immediately grasps the operation. It doesn't name or differentiate from siblings, but none of the siblings (hash_generate, jwt_decode, uuid_generate) could be confused with this operation.

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 encode/decode framing, but there is no explicit guidance on when to pick this tool over neighbors that also emit encoded strings, nor any stated prerequisites. The word "safely" hints at tolerant decoding but is never explained or contrasted with an unsafe alternative.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds real value beyond them by disclosing data provenance ('Source: mempool.space') and freshness ('Real-time'), which an agent needs to judge trustworthiness and staleness. It stops short of stating caching behavior, update cadence, or which currencies are actually returned.

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

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

Three tight sentences with the core capability front-loaded, followed by provenance and freshness. No filler or repetition; every clause carries 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 simple read-only tool with no parameters and no output schema, the description covers what is returned (price in USD and other major currencies), the source, and the freshness. The only gap is that 'other major currencies' is unspecified, leaving the exact return shape slightly ambiguous.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. No parameter syntax or defaults are needed, and the description correctly spends no words on inputs.

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

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

States a specific verb and resource ('Get the current Bitcoin price') plus scope ('in USD and other major currencies'). No sibling tool overlaps with price lookup, so an agent can distinguish it immediately from btc_send_decision or optimal_send_window.

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

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

The description implies usage (a live price lookup) but never states when to reach for this versus related Bitcoin tools like optimal_send_window or btc_send_decision. Since it is a zero-parameter, single-purpose tool the implied context is largely sufficient, but no explicit routing guidance is 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the fetch-and-composite behavior (live mempool + fee data) and the concrete output shape (verdict, sat/vB rates, mempool pressure, estimated savings).

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

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

Three sentences, front-loaded with the core purpose, then behavior, then audience fit. No filler; every sentence carries information.

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

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

With readOnly annotations and no output schema, the description adequately explains what the agent receives (verdict values, fee rates, mempool pressure, savings). The one missing element is routing guidance against the sibling `optimal_send_window`.

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 single `urgency` enum is fully documented with per-value meanings in the schema. The description adds nothing about the parameter, so the baseline 3 for schema-driven params 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+resource: returns a composited send-or-wait recommendation for a Bitcoin transaction, and enumerates the verdict outputs. It is clear on its own, but it never distinguishes itself from the sibling `optimal_send_window`, which sounds like an overlapping recommendation 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?

"Ideal for agents that need a single decision call instead of parsing multiple raw mempool endpoints" gives an implied use context. But there is no explicit when-to-use vs. when-not guidance, and the closely related sibling `optimal_send_window` is never named as an alternative.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The only behavioral note, 'bounded row output', merely restates the max_rows constraint already in the schema; nothing is said about malformed-row handling, truncation signaling, or the 100 KB input cap 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?

A single front-loaded sentence with no filler; the scope of accepted formats and the bounded-output constraint both appear immediately.

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 never indicates the return shape (array of objects vs. wrapper with metadata) or how row truncation is surfaced to the caller. For a simple 4-parameter utility with full parameter coverage this is a modest but real 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 four parameters (csv size limit, header default, max_rows range, delimiter enum) are already documented in structured form. The description's delimiter list adds no syntax or semantics beyond the enum values.

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

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

States a specific verb (convert) and resource (CSV/TSV/semicolon/pipe-delimited text) plus the output form (structured JSON), so the tool's function is unambiguous. It does not explicitly differentiate itself from siblings like json_extract or json_validate, but no sibling overlap is plausible.

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 from the purpose; there is no statement of when to prefer this over json_extract/json_validate or any precondition (e.g., input must be text, not a file path). Adequate for a self-evident utility but leaves routing to inference.

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 the algorithm/encoding surface and says nothing about local vs remote computation, idempotency, or the 100 KB input ceiling (which lives 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?

A single sentence with zero waste, front-loading the core action and immediately qualifying it with the supported algorithms and encodings. Nothing is padded or restated.

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 three-parameter, no-output-schema utility with full schema coverage and annotations covering safety, the description is close to sufficient. It could add one clause on input limits or the fact that hashing is deterministic/local, but 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% and both optional parameters carry enums with explicit defaults in the schema, so the description merely restates the algorithm and encoding options. Baseline 3 applies when the schema fully documents the parameters.

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

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

States a specific verb (generate) and resource (SHA-256/SHA-512 digest), plus the two output encodings. An agent can tell it produces a hash rather than decoding/encoding existing data, though it never explicitly distinguishes itself from the nearby base64_convert or jwt_decode siblings.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. Usage is only implied by the obvious purpose (you need a digest), so an agent must infer that base64_convert is the right sibling for pure encoding rather than hashing.

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 is covered by structured data. The description adds genuine value by disclosing the single-value scope and the simple-path/array-index syntax, but it says nothing about behavior on a missing path or malformed JSON.

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 an inline example, no filler, and the key limitation ('one value') placed before the syntax 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?

For a two-parameter, read-only tool with no output schema, the description is close to sufficient, but it omits the failure contract (error vs null on a non-existent path) and any note on return typing, which an agent needs to interpret results.

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

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

Schema description coverage is 100% and both parameters are documented with their own examples, including the 100 KB size limit on 'json'. The description's path example duplicates the schema, so it adds no semantics beyond structured data; 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 (Extract) and resource (a value from JSON) with a concrete example path, so the core function is unambiguous. It does not, however, position itself against the adjacent json_validate or csv_to_json siblings, so the agent must infer the boundary.

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

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

Usage is implied by the constraint 'one value' and 'simple dot path', which hints at when this is the right tool versus a fuller query language, but there is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative.

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

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

Annotations already declare the read-only, non-destructive, open-world safety profile, so the description's added value is its disclosure of return shape (normalized JSON, root type, SHA-256 hash). That output disclosure matters because no output schema exists. It stops short of clarifying what the hash is computed over or determinism guarantees.

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 that leads with the primary action before listing secondary outputs. Every clause earns its place.

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

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

For a one-parameter tool with full schema coverage and no output schema, the description adequately covers both operation and return payload. Only minor gaps remain (determinism, normalization rules) that an agent could want but not strictly need.

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 single 'json' parameter is fully documented in the schema (including the 100 KB cap). The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb ("Validate") and resource ("JSON") and even enumerates the outputs: root type, normalized JSON, and SHA-256 hash. It clearly distinguishes itself from a pure extractor or hasher, though it never names a sibling tool to sharpen the boundary.

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

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

There is no guidance on when to choose this over json_extract or hash_generate, no prerequisites, and no exclusions. The agent must infer applicability purely from the verb, which is not enough given the overlapping sibling set.

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 and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: decoding is local and the signature is deliberately not verified, and the response always reports verification=false — a non-obvious output trait that prevents misuse.

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 zero waste. The key constraint (no signature verification) is front-loaded rather than buried.

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?

No output schema exists, and the description compensates by explaining the salient return characteristic (verification always false). For a one-parameter decode tool this is nearly complete, though it omits any note on error handling for malformed tokens.

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

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

With a single parameter at 100% schema coverage, the schema already documents the token format (compact serialization, 20 KB limit). The description adds no syntax or format detail beyond what the schema 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 (decode) and resource (JWT header and payload claims), with scope qualifier 'locally without verifying the signature'. This clearly distinguishes it from siblings like base64_convert and tx_decode_explain, which handle different artifacts.

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

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

The description implies the use case (inspecting a JWT's claims) and adds the important caveat that no signature verification happens, but it never states when to reach for this tool versus alternatives, nor any exclusions such as 'use a verification tool when authenticity matters'.

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 a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds genuinely useful behaviour beyond that: it handles the full LNURL-pay protocol internally and returns the invoice plus min/max sendable amounts for validation. It doesn't mention auth or rate-limit behaviour, but with a low annotation bar this is solid added 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?

Three tight sentences, front-loaded with the verb and resource, and every clause earns its place (output type, protocol handling, return contents). 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?

For a simple two-parameter resolve with no output schema, the description covers what the tool does, that it performs the protocol exchange, and what it returns. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100% and both parameters (address format, amount in sats) are fully documented in the schema. The description restates 'user@domain.com' and 'given amount' but adds no syntax or constraint detail beyond the schema, so baseline 3 applies.

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

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

Specific verb (Resolve) plus resource (Lightning Address user@domain.com) plus concrete output (payable BOLT11 invoice). An agent immediately knows what this does and what it produces.

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 the use case (converting an address to a payable invoice for a given amount), and no sibling overlaps with Lightning functionality. However it states no explicit when-to-use/when-not conditions, prerequisites, or alternatives, so guidance is only implied.

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, openWorldHint and destructiveHint=false, so safety is covered structurally. The description adds meaningful context beyond that: the forecast horizon (1-4h), the presence of a calibrated confidence score, an RBF-viability flag, and the external data source (mempool.space), which explains the openWorldHint. It does not discuss failure modes or rate limits.

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 definition is front-loaded with the tool's identity and then lists its outputs in a single dense sentence, with the positioning line last. Every clause carries information, though the output enumeration is long enough that some trimming is conceivable.

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 compensates by enumerating the return fields, and annotations cover the read-only/open-world safety profile. Both parameters are documented in the schema, and the external data source is disclosed. Only the absence of any guidance on data freshness or failure handling keeps it from being fully 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 description coverage is 100%, so both parameters (hours_ahead, target_sat_vb) are already fully documented with ranges, defaults and semantics. The description adds no syntax or behavioral detail about them, and its "next 1-4h" phrasing is slightly narrower than the schema's 1-6h range, though not contradictory. Baseline 3 is appropriate when 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 opens with a specific domain and resource ("Bitcoin transaction timing intelligence") and enumerates exactly what it returns — congestion forecast, send window, fee trajectory, confirmation targets, RBF flag — so an agent knows precisely what this tool produces. It implicitly positions itself against raw fee tools ("a synthesis layer above raw fee data") but never names the closest sibling, btc_send_decision, leaving that distinction to inference.

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

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

It gives a clear use context — "the decision an autonomous payment agent needs before broadcasting" — which tells the agent when this tool fits in a payment workflow. It stops short of explicit exclusions or naming alternatives (e.g. when to prefer btc_send_decision or btc_price instead), so the routing guidance is contextual rather than directive.

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, openWorldHint=true), so the bar is lower. The description nevertheless adds a real behavioral trait — 'deterministic' — signaling a pure, side-effect-free, reproducible computation, and it enumerates exactly what the call yields despite there being no output schema. It says nothing about behavior on input over the 100 KB limit or error cases.

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 names a distinct returned artifact. 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 one-parameter, read-only computation tool with annotations and no output schema, the description sufficiently covers what comes back (statistics, tokens, reading time, SHA-256 hash). It is slightly thin on what 'text statistics' concretely includes and on behavior for oversized input.

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

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

There is a single parameter with 100% schema description coverage, and the schema already documents it as the text to analyze with a 100 KB cap. The description adds no syntax, encoding, or formatting guidance for the input, 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 enumerates the concrete resource it produces: text statistics, token estimates, reading time, and a content hash. It is clear what the tool computes, but it does not differentiate itself from the overlapping sibling hash_generate, which also produces hashes.

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 only lists outputs; it never says when to reach for this tool rather than hash_generate or json_extract, nor does it state prerequisites or exclusions. An agent must infer the use case purely from the output list.

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 the safe/read-only profile, so the bar is lower. The description adds value by naming the accepted input formats and, importantly for a tool with no output schema, disclosing that output is 'normalized UTC timestamp forms.' Error handling and ambiguity resolution for 'auto' remain undisclosed.

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 packs the input formats and the output form with zero filler. Every clause earns its place.

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

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

For a two-parameter, single-purpose conversion tool with full schema coverage, this is nearly complete. Since there is no output schema, the description carries the output-form explanation, but it leaves 'auto' detection and invalid-input behavior unspecified.

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 'from' enum values and 'value' already documented in the schema. The description restates the input formats but adds no syntax, defaults, or examples beyond what the schema provides, so the baseline 3 is appropriate.

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

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

States a specific verb (Convert) and resource (timestamps) and enumerates the accepted input formats (Unix seconds/milliseconds, RFC3339, ISO). This clearly distinguishes it from siblings like base64_convert or url_parse, though it does not explicitly name an alternative.

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 description and the 'from' enum, but there is no explicit when-to-use, no mention of the 'auto' default behavior, and no exclusion against adjacent tools. An agent can infer this converts timestamps but gets no routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered; the description goes further by disclosing the exact fields returned, including an 'agent_summary' string intended for LLM context injection. It stops short of describing failure behavior for an unknown txid or any network/rate-limit 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 definition is front-loaded with the core action, and the field enumeration is dense but earns its place by pre-announcing the return shape in the absence of an output schema. The trailing token-savings sentence is mildly promotional but brief.

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 one required parameter and no output schema, the description compensates well by enumerating the returned fields, letting the agent know exactly what it gets back. The missing piece is error/edge-case behavior (invalid or not-yet-confirmed txids) and any pagination or response-size caveats.

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?

Only one parameter, and the schema description coverage is 100% — the schema already documents txid as a 64-character hex transaction ID with min/max length enforced. The description adds nothing about txid format beyond restating 'by txid', so the baseline 3 applies while the schema carries the load.

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

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

States a specific verb and resource ('Fetch a Bitcoin transaction by txid') and precisely enumerates what the returned summary contains (type, counts, fees, fee rate, confirmation/RBF/SegWit/Taproot flags). No sibling tool overlaps with transaction decoding, so the agent can select it unambiguously.

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

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

It gives a clear use rationale — an agent-ready summary that 'saves 500-2000 tokens vs parsing raw TX JSON' — which implicitly routes the agent away from raw-JSON post-processing. However, it states no explicit when-not conditions, prerequisites, or error cases (e.g., unknown txid, unconfirmed tx handling).

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 is covered. The description adds genuinely new behavioral context: the operation is purely local ('without fetching it') despite the open-world hint, and output is 'normalized', both of which affect how an agent should interpret results.

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, front-loaded with verb and resource, with no redundant or filler content. Every clause (protocol restriction, field list, no-fetch caveat) carries information.

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

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

With no output schema, the description usefully enumerates the returned fields, so the agent knows what to expect. It omits error behavior (e.g., what happens with a malformed or non-HTTP URL), which is the only notable gap for a one-parameter parse 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?

Only one parameter, and the schema documents it fully (absolute HTTP/HTTPS URL, 4,096 char cap) at 100% coverage. The description's field list describes the return shape rather than adding syntax or format meaning to the parameter itself, 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 (parse) plus the exact resource (HTTP/HTTPS URL) and enumerates the resulting fields (scheme, host, port, path, query, fragment). The 'without fetching it' clause further sharpens what the tool does versus a network call, which cleanly separates it from the unrelated utility siblings.

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

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

Usage is implied by the tool's nature: use it when you have a URL string and need its components. There is no explicit when-to-use statement, no stated preconditions, and no named alternative (the siblings are unrelated utilities, so there is little to differentiate against, but the description still leaves routing to inference).

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, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuine behavioral value by specifying 'cryptographically random' and 'RFC 4122 version 4', telling the agent the quality and format guarantees of the output, which the annotations do not convey.

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

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

A single tight sentence that front-loads the verb and resource with zero filler. Every clause (range, randomness, RFC 4122, version 4) contributes to correct invocation.

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-required-parameter utility with no output schema, the description covers everything needed to call it correctly. The only minor omission is how multiple UUIDs are returned (array vs. delimited string), which an agent must infer.

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

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

Schema coverage is 100% and the single 'count' parameter is fully documented with min 1, max 100, and default 1. The description's 'one to one hundred' merely restates the schema bounds, adding no new semantic detail, 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?

The description states a specific verb (Generate), resource (UUID version 4 identifiers), and even the standard and range, so an agent immediately knows what it produces. It does not need to name a sibling since no other tool in the list generates UUIDs, but it also makes no explicit differentiation attempt.

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 tool obviously generates identifiers, but the description never states when to reach for it versus hash_generate or timestamp_convert, nor any prerequisites. With a trivially scoped utility and no true alternatives, implied usage is adequate but nothing is spelled out.

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