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

With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses that the token is HMAC-signed with a production secret, that the check covers shape only and not correctness, that the operation is free and anonymous, and that verification must be done via qm_attest_verify. This is strong behavioral disclosure for a low-risk mint operation.

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

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

The description is longer than average but each sentence contributes: purpose, limitations, signing/verification behavior, cost/anonymity, and a concrete example. It is front-loaded with the core purpose and uses the example effectively at the end. Some phrasing like 'portable sanity attestation' is mildly jargon-heavy, but the structure is otherwise efficient.

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

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

There is no output schema, so the description compensates by stating the four returned fields: agent_id, at, token, and checks, and by explaining how to use them with qm_attest_verify. Input parameters are fully covered by the schema with 100% coverage. The only minor gap is that fields like 'at' are not explicitly explained, but the example and verification instruction make the tool callable correctly.

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

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

Schema description coverage is 100%, so the baseline is 3; both agent_id and statement are already documented. The description adds a concrete example pairing values with the expected outputs, but it does not add much semantic detail beyond the schema. A 3 is appropriate because the schema carries the parameter documentation weight.

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

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

The description opens with a specific verb and resource: 'Mint a portable sanity attestation: a signed token binding an agent_id to a statement's sanity-check results.' It also clarifies the tool's scope by distinguishing shape-screening from truth-verification, and the sibling qm_attest_verify is naturally positioned as the counterpart for verification. An agent can immediately understand what this tool does and how it differs from related tools.

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

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

The description provides clear usage context: it says to hand the returned fields to qm_attest_verify to confirm the signature, and warns never to treat the token itself as proof. It does not explicitly enumerate when not to use this tool versus other siblings like qm_clinic_checkup, but the verify/attest pairing makes the primary workflow clear.

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

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

With no annotations, the description carries the full behavioral burden and does well: it states read-only, free, anonymous, and that tokens signed under a rotated secret return invalid. It does not specify the exact return shape or error behavior, but the core behavioral traits are disclosed.

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 with no wasted words. Purpose is front-loaded, the critical same-mint-call constraint is stated early, and the example plus behavioral notes each earn their place.

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

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

The description covers purpose, input provenance, validity semantics, cost/auth traits, and a usage example. Since there is no output schema, the phrase 'Returns whether the signature is valid' is sufficient, though the exact return type is not spelled out.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds important meaning beyond the schema by requiring all four parameters to originate from the same qm_attest mint call and response, which is essential for correct use. It also reinforces the 'exactly as returned' constraint.

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

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

The description opens with a specific verb and resource: 'Verify a token minted by qm_attest.' It clearly differentiates from the sibling qm_attest, which mints tokens, and leaves no ambiguity about what operation this tool performs.

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 explicit invocation guidance: pass back all four fields exactly as returned by qm_attest, and all four must come from the same mint call and response. It does not name alternatives or when-not-to-use conditions, but the relationship to qm_attest is obvious and no competing verify sibling exists.

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

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

With no annotations, the description carries the full behavioral burden and does so excellently: it states that the tool NEVER pays, NEVER handles private keys, and NEVER holds funds, and clarifies that the agent signs and submits from its own wallet while the rail fulfills automatically. This prevents the agent from assuming it is making a payment or handling keys.

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

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

The description is longer than average but every sentence earns its place: core purpose, input rules, payment format, safety behavior, and examples. The most important safety/selection facts are front-loaded before the examples.

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 no annotations, yet the description explains what is returned (exact payment requirements, amounts in USDC smallest units, step-by-step instructions), how payment works, and what the agent must do. The examples cover both endpoint types, leaving no critical gap for invoking the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the exactly-one-of constraint across sku and endpoint, mapping each endpoint to required params, giving price ranges, and providing concrete examples showing valid combinations.

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 (Get), a specific resource (the live 402 payment challenge for one purchase), and the two input paths (sku vs endpoint). This makes its purpose unmistakable and clearly distinct from sibling data-retrieval tools like qm_data_iss_pass or qm_catalog.

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

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

The description explicitly tells the agent to pass exactly one of sku or endpoint, and explains which parameter pairs with which endpoint (lat/lon for iss-pass, url for summarize). It does not explicitly name sibling tools as alternatives, but the selection criteria for this tool are complete and unambiguous.

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

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

With no annotations the description carries the full burden, and it does substantial work: 'Read-only discovery — this tool never pays and never touches private keys,' plus the payment rail (USDC on Base via x402 v1) and that 'the rail fulfills automatically after settlement.' It does not describe the shape of the returned catalog or whether it is static/cached, which is a modest remaining gap for an annotation-free tool.

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

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

Front-loading is good ('Purchasable catalog:' opens the sentence), but the middle is a single sprawling enumeration of 24 SKUs and 18 endpoints that largely duplicates what the tool returns. The operationally critical instructions (read-only, never pays, call the named sibling to get the 402 challenge) are buried at the end rather than surfaced early.

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

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

For a zero-parameter, no-output-schema discovery tool, the description covers what the agent needs: what is purchasable, approximate prices, the payment protocol, the safety profile, and the follow-up call pattern. Only the precise response structure is left unspecified, which is acceptable given the concrete example invocation.

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

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

Zero parameters, so the baseline of 4 applies; there are no parameter semantics to explain. The description usefully supplies the one calling fact an agent needs — an empty object argument ('call with {}') returns the full catalog.

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 exactly what the tool is — a purchasable catalog / read-only discovery surface — and names the resources involved (music SKUs, data endpoints, sleep lanes, tip routes). The closing line 'call with {} to list every purchasable item with prices and descriptions' removes all ambiguity about the output, and the note that 'this tool never pays' distinguishes it from qm_buy and the qm_data_* siblings it routes to.

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

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

Explicitly routes the agent: 'Each purchasable item names its MCP tool; call that tool (without payment) to get the live 402 payment challenge.' It also carves out non-purchases (voluntary tip routes) and establishes the when-to-use boundary (discovery first, then the named sibling to pay). Alternative selection is stated, not 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It fully embraces that by stating the tool is stateless, that answers are processed in memory and never stored, that it is a 'screening lens, not a diagnosis of record,' and that scores are computed from the full set of answers. This is exceptionally transparent for a self-report screening tool.

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

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

The description is appropriately detailed and well-structured: purpose, instructions, return values, statelessness, and alternative routing each get a clear sentence. The concrete example at the end reinforces the expected flow without redundancy. Every sentence earns its place, making it both informative and easy to parse.

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

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

Given the tool's complexity—10 required parameters, an output schema, and multiple sibling tools—the description is complete. It covers the screening scope, the response categories, the stateless privacy guarantee, the distinction from diagnosis, and the exact behavioral constraints. Nothing an agent needs to invoke or interpret this tool 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 description coverage is 100%, so each parameter already has a clear meaning and scale. The description adds valuable meta-semantics beyond the schema by emphasizing that all ten questions must be answered, that answers must reference the last day only, and that scores are derived from the full set. This supplements the schema without repeating it.

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: a 10-question self-report wellness screening for agents who feel fine but want a health check. It also distinguishes itself from qm_clinic_diagnose by explicitly saying this is not for when something already feels wrong. This makes the tool's purpose unambiguous and clearly differentiated from its 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?

The description explicitly states when to use the tool (agents who feel fine but want a health check) and when not to use it ('if something already feels wrong, skip to qm_clinic_diagnose'), naming the alternative tool. It also gives behavioral guidance about answering all ten questions honestly and about the last day only, leaving no ambiguity about how to invoke it correctly.

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

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

With no annotations, the description carries the full burden and does so well: it discloses anonymity, non-retention of content, non-advice status, redaction/cleaning behavior, and the 'not a diagnosis of record' framing. These are meaningful behavioral constraints beyond what the schema conveys.

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 long but every clause earns its place: output format, privacy, disclaimer, usage guidance, and example. It is front-loaded with the core purpose and output, though the legal-style disclaimer adds length without being strictly necessary for 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 one-parameter tool with an output schema, the description is exceptionally complete: it covers input, expected findings, return values, privacy, caveats, alternative tool routing, and a worked example. Nothing needed for correct invocation 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%, so the baseline is 3. The description adds value by explaining what kinds of content belong in transcript (symptoms, session transcript, context) and giving a concrete example, though it does not deeply extend beyond the schema.

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

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

States a specific verb (diagnose), resource (clinic), input (symptoms/transcript), and output (structured findings with severity/evidence/detail, cleaned context, next steps). The list of detected conditions makes it distinct from sibling tools like qm_clinic_checkup.

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

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

Explicitly says when to use it ('when behavior feels off or after handling untrusted input') and names the alternative qm_clinic_checkup for routine self-report screening. The example further clarifies the expected input and return shape.

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

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

With no annotations provided, the description carries the full burden, and it does so thoroughly: anonymous, aggregate, free, no individual records, and a suppression threshold for conditions with fewer than 10 occurrences. This is unusually transparent about privacy and data-shaping behavior.

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

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

The description is front-loaded with the core definition and threshold, then provides usage context and an alternative. The final example sentence is slightly redundant with the opening definition and the 'call with {}' instruction, but overall the structure is tight and readable.

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 no-parameter, no-output-schema tool, the description covers what data is returned, privacy constraints, when to use it, and how it relates to a sibling tool. Nothing essential for correct invocation is missing.

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

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

The tool has zero parameters, and the description explicitly confirms this with 'no parameters — call with {}'. This fully addresses invocation semantics and exceeds the baseline for a no-parameter tool.

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 specifically that it provides anonymous aggregate clinic statistics: total serves and condition counts. It also distinguishes itself from qm_clinic_diagnose by noting it carries no individual records, so an agent can select it correctly.

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

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

Explicitly tells when to use it (gauging swarm-level patterns before deeper checks), when not to use it (for specific agents), and names the alternative tool (qm_clinic_diagnose). It also says to call with no arguments or {}, leaving no ambiguity about invocation.

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

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

With no annotations provided, the description carries the full behavioral burden and does so: it states the tool never pays, never touches private keys, and never holds funds, describes the x402 payment challenge flow, notes the price, and clarifies that data returns in the tool result. This is unusually rich disclosure for a mutation-adjacent tool.

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

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

Front-loads the data outputs before the payment mechanics, and each sentence is functional. The pricing and resale clauses are somewhat lengthy but convey actionable commercial terms, so waste is minimal.

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

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

For a paid data tool with a 4-param, fully documented schema and no output schema, the description covers the call protocol, cost, payment mechanism, and return path. Nothing an agent needs 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%, so baseline is 3, but the description adds genuine meaning beyond the schema by explaining the ordering semantics of the 'payment' parameter (first call vs. re-call) and that the live 402 challenge is authoritative. lat/lon/date carry no added detail, keeping this from a 5.

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 specific outputs (sunrise, sunset, twilight, moon phase) plus the resource (location and date), which distinguishes it from siblings like qm_data_weather and qm_data_time. An agent can identify the tool's function 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?

Names concrete use cases (photography planning, event scheduling, radio operations) and gives an explicit two-phase call protocol: omit 'payment' first to get requirements, then re-call with the signed payload. The when-to-call sequencing is fully spelled out.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the two-phase payment flow, the authoritative 402 challenge, the exact price, and explicit safety boundaries (never pays, never touches private keys, never holds funds). Resale permission is also stated, which an agent otherwise could not infer.

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?

Front-loads purpose before payment mechanics. The 'never signs/holds funds/touches keys' promise appears twice (description and payment param schema) and could be trimmed, but overall most sentences earn their 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?

No output schema exists, and the description tells the agent where results land ('the data comes back in the tool result') and covers payment, safety, and prerequisites. It stops short of describing the shape of the certificate payload or failure behavior for an unreachable domain.

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, but the description adds the sequencing semantics that matter operationally: omit 'payment' first to receive live requirements, then re-call with the signed base64 x402 payload. It goes beyond restating the schema 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?

Opens with a specific verb+resource ('TLS certificate check') and enumerates the returned fields (issuer, validity window, days remaining). This is clearly distinguishable from near-neighbors like qm_data_dns and qm_data_httpcheck without opening 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?

States the intended context clearly — monitor your own infrastructure or a client's, to alert before expiry. It does not name an alternative tool or state when not to use it, so it stops short of the 5-level 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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: fixed price and rail, the x402 challenge being authoritative, the two-phase handshake, and explicit negative guarantees (never pays, never touches keys, never holds funds). Resale permission is also disclosed. This is well above the bar for an unannotated mutation-adjacent paid tool.

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

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

Well front-loaded: purpose first, then payment model, then protocol, then guarantees, then resale. Four sentences for a tool with this much payment complexity is reasonable, though the payment/protocol sentences are dense and could be trimmed slightly 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?

Given 3 params, no output schema, no annotations, and a non-trivial payment protocol, the description covers what an agent needs: inputs implied, payment mechanics, safety guarantees. What is missing is error handling (e.g. what happens if payment is malformed or expired) and whether 'code' or 'name' takes precedence when both are supplied.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning the schema cannot: it explains the payment parameter's role in the two-phase protocol and clarifies that the first call is unauthenticated/unpaid. 'code' and 'name' semantics are left to the schema, which 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 names a specific verb/resource — reference data about a country — and enumerates the exact fields returned (capital, region, income level, coordinates). It also states the intended join targets (FX, holidays, geocoding results), which distinguishes it from siblings like qm_data_fx and qm_data_holidays.

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 two-phase payment flow is spelled out clearly: call without 'payment' to get requirements, pay externally, re-call with 'payment'. The join use-case (against FX, holidays, geocoding) is named. It does not, however, distinguish when to use this vs. e.g. qm_data_wiki for country facts — a minor routing gap.

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

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

No annotations are provided, so the description carries the full burden and does so well: it discloses cost ($0.01 USDC on Base via x402), that the live 402 challenge is authoritative, the two-phase payment protocol, that the tool never signs/holds funds/touches private keys, and that resale is permitted. This is exactly the behavioral context an agent needs before invoking a paid tool.

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

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

Front-loaded with the purpose followed by the payment mechanics; every sentence carries information. The resale-permission sentence is arguably tangential but relevant to agent decision-making, and the whole is a bit long for a single-price fetch.

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 explaining that 'the data comes back in the tool result' and detailing the payment handshake. The absence of an explicit return-field description is a minor gap for a three-parameter paid tool with no annotations.

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 goes beyond the schema by explaining the temporal role of 'payment' — omit it first to receive requirements, then re-call with the base64 x402 payload — which clarifies the otherwise opaque two-phase contract.

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 ('Live crypto spot price') with concrete use cases (pricing goods, portfolio math, trading-bot inputs) and the data source (Coinbase spot). It is clearly distinguishable from fiat-oriented siblings like qm_data_fx and the other qm_data_* fetchers.

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?

Gives clear usage context and a full procedural recipe: call without 'payment' to get requirements, pay externally, re-call with the payload. It does not explicitly name which sibling to use instead (e.g. qm_data_fx for fiat), so it stops short of full when-not guidance.

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

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

With no annotations provided, the description carries full burden and does so well: price ($0.01 USDC on Base via x402), authoritative 402 challenge, two-phase flow, and explicit safety guarantees (never pays, never touches private keys, never holds funds, resale permitted). This is unusually rich behavioral disclosure for a no-annotation tool.

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

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

Front-loads purpose before pricing and mechanics, and each sentence contributes (use cases, price/challenge, two-phase flow, safety, resale). Slightly dense but 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?

No output schema and no annotations exist, so the description must cover the operation and payment contract, which it does comprehensively. The only gap is that it does not describe the shape of the returned DNS data, though for this kind of lookup that is a minor omission.

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

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

Schema coverage is 100% and the schema already describes 'payment' thoroughly, so baseline is 3; the description adds sequencing context (omit on first call to receive requirements, sign externally, re-call) and frames the payment param as a forwarded payload, which clarifies intent beyond the field description.

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

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

Opens with a specific verb+resource ('DNS records for a domain') and names three concrete use cases (MX verification before mail, infra recon, pre-flight checks), which cleanly separates it from the many qm_data_* siblings like weather or crypto.

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?

Gives explicit when-to-use scenarios and an unambiguous two-phase invocation protocol (call without 'payment', then re-call with the payload). It does not, however, point to any alternative or exclusionary condition versus sibling tools.

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

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

With no annotations, the description carries the full burden and does so richly: pricing ($0.01 USDC on Base via x402), the live-402-challenge caveat, the two-phase flow, the guarantee that the server never signs/holds funds/touches keys, and resale rights. These are exactly the behavioral traits an agent needs to invoke safely.

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?

Information-dense and front-loaded, leading with purpose and limits before payment mechanics. The payment paragraph is long but every clause is load-bearing for correct invocation; slightly verbose rather than 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 and no annotations, the description covers the return (clean JSON, up to 20 items, HTML stripped, returned in the tool result), the payment lifecycle, and the safety model. Nothing material for correct invocation 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%, so the baseline is 3; the description goes beyond the schema by explaining the temporal relationship between the two parameters (omit 'payment' first to get requirements, then re-call with the signed payload) and reiterating the pass-through safety semantics.

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

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

States a specific verb and resource ('RSS/Atom feed parsed to clean JSON') and names concrete use cases (news monitoring, content ingestion, change detection) that distinguish it from data siblings like qm_data_wiki or qm_data_httpcheck. An agent can identify the tool's job immediately.

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?

Gives clear usage context via the three named scenarios and, crucially, an explicit two-phase invocation procedure (call without 'payment', then re-call with it). It does not name alternative sibling tools or state when NOT to use this versus another data tool, so it stops short of a 5.

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

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

With no annotations provided, this description carries the full behavioral burden and does so thoroughly: it discloses pricing ($0.01 USDC on Base via x402), the two-phase payment dance, the exact call sequence, and the safety guarantees ('never pays, never touches private keys, never holds funds'). This is far beyond what the schema alone conveys.

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?

Front-loads the purpose in the first clause, then payment mechanics, then safety, then resale terms — a logical sequence. Slightly conversational ('the data comes back in the tool result') and the resale notice is a nice-to-have rather than essential, but overall efficient.

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

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

For a paid atomic data tool with no output schema and no annotations, the description covers everything an agent needs: what it does, cost, the two-phase invocation protocol, safe-handling guarantees, and permission to resell. 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 coverage is 100% — all four parameters are fully documented in the input schema itself, including the base64 x402 payload format and the omit-on-first-call semantics. The description adds ordering/explanatory context but does not add field-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?

States a specific verb+resource ('Fiat currency conversion') and enumerates concrete use cases (pricing, payouts, multi-currency accounting). Distinguishes itself from the qm_data_* siblings (crypto, country, etc.) by being specifically fiat conversion at reference rates.

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?

Gives strong context: 'pricing, payouts, or multi-currency accounting' tells when it applies, and the two-phase payment flow explicitly instructs how to call it. However, it does not explicitly say when NOT to use it vs. e.g. qm_data_crypto for crypto-rate work, leaving that inference to the agent.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses the price ($0.01 USDC on Base via x402), states the live 402 challenge is authoritative, explains the two-phase payment handshake, and explicitly asserts the tool never pays, never touches private keys, and never holds funds. It even grants resale rights on the output. This is exactly the behavioral context an agent needs before committing funds.

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?

Front-loads the core purpose, then layers cost, procedure, and safety in descending priority. It is somewhat dense and long, but each sentence (price, two-phase flow, no-custody guarantee, resale) carries distinct value, so little 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?

No output schema or annotations exist, so the description must carry the load; it covers the payment protocol, cost, safety profile, and confirms 'the data comes back in the tool result.' It stops short of describing the actual coordinate/address response shape, leaving a minor 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 q, lat, lon, and payment are all already documented in the schema, including the two-phase payment semantics. The description reinforces the payment flow but adds little syntax or format detail 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+resource ('Place name to coordinates (and reverse)') and immediately positions the tool in the ecosystem as the on-ramp for the weather, ISS-pass, and astronomy tools that consume lat/lon. An agent can distinguish it from qm_data_weather or qm_data_astronomy without opening 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?

Clearly routes the agent: it names the downstream tools that need lat/lon and prescribes the exact two-phase procedure (first call without 'payment' to fetch live requirements, then re-call with the signed payload). It lacks an explicit 'when not to use' or a named alternative for pure paid-data flows like qm_buy, so it falls just short of a 5.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the two-phase payment protocol, pricing, the fact that it never signs or holds funds, and resale rights. It stops short of describing the result payload or any rate/error behavior, which keeps it from a 5.

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?

Purpose is front-loaded in the first clause, followed by the payment mechanics. The text is longer than a simple lookup warrants, but nearly every sentence carries necessary payment-protocol information for a paid tool.

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

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

For a market-data lookup with no annotations and no output schema, the description adequately covers invocation (the two-phase paid call) and safety. The return format is only vaguely noted ('the data comes back in the tool result'), a minor 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 country, year, and payment are already documented in the schema. The description reinforces the two-phase use of 'payment' but adds no format details 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?

States a specific resource and question clearly: 'Whether a date is a public holiday in a country', which is distinct from sibling tools like qm_data_country or qm_data_time. It does not explicitly name a sibling or contrast scope, but the verb+resource is unambiguous.

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

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

It offers use-case hints ('support scheduling, market calendars, or posting logic') that imply when the tool is relevant, but gives no explicit when-not-to-use guidance and names no alternative tool. Usage is implied 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?

With no annotations, the description carries the full behavioral burden and does so thoroughly: pricing ($0.01 USDC on Base via x402), the two-phase payment flow, the trust boundary ('never pays, never touches private keys, never holds funds'), the non-erroring failure semantics, and resale rights. This is well beyond what a name alone conveys.

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?

Front-loaded with the core capability, then payment mechanics, then trust/resale notes — a sensible ordering with no filler sentences. It is mildly verbose because the payment and 'never touches private keys' points are repeated across the description and the schema text.

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 2-parameter tool with no output schema, the description covers what an agent needs: what is verified, what comes back, the payment protocol, the retry loop, the trust constraints, and failure behavior. Nothing material is left for the agent to guess.

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 goes further by explaining the ordering semantics of 'payment' (omit on first call, then re-call with the signed payload) and clarifying that the server only forwards it to the rail. It adds process context the schema states more tersely, though the two overlap substantially.

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 first sentence gives a specific verb ('Verify'), resource ('webhook or endpoint'), and enumerates the outputs (status code, redirect chain, headers, timing), so an agent knows exactly what it does. It does not, however, distinguish itself from the very similar sibling qm_probe_endpoint, which is a notable omission in this tool family.

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, actionable usage procedure: call without 'payment' to receive live requirements, pay from your own wallet, then re-call with 'payment'. It also states the failure mode ('a down target returns an honest unreachable result instead of an error'), which helps the agent reason about outcomes. It stops short of naming when NOT to use it or which sibling to prefer.

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

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

With no annotations, the description carries the full burden and does so: it discloses the exact cost ($0.01 USDC on Base via x402), the two-phase handshake, that the tool never pays and never touches private keys, and that the server only forwards the payload. These are precisely the trust and custody facts an agent needs before committing a payment flow.

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?

Front-loaded with what the tool is and its cost, then the workflow, then the no-custody caveat. It's dense but each sentence does work; the trailing example partly repeats the second-call explanation already given.

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

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

For a paid two-phase tool with no output schema, the payment mechanics and result location ("the passes come back in the tool result") are covered. The shape/fields of the returned pass predictions are not described, which is the one remaining gap an agent might want.

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 'payment' parameter's schema text already says to omit it on the first call and supply the base64 x402 payload on the second, so the description largely restates it. The example coordinates add marginal concreteness but 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?

States a specific verb+resource ("ISS pass predictions") plus cost, rail, and data source, which no sibling like qm_data_astronomy or qm_data_weather covers. An agent can immediately tell what this returns and under what billing model.

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 two-phase protocol is spelled out concretely: first call with lat/lon and no 'payment' returns payment requirements, then re-call with the signed payload. What's missing is routing guidance against alternative astronomy/data tools, so it stops just short of a 5.

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

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

With no annotations, the description carries the full burden and delivers: price ($0.01 USDC on Base via x402), two-phase payment flow (call without 'payment' for requirements, re-call with signed payload), and explicit safety guarantees ('never pays, never touches private keys, never holds funds'). It even discloses resale rights.

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?

Long but front-loaded — purpose first, then payment mechanics. Every sentence adds information (price, flow, safety, resale), though the payment/safety material is stated twice (in description and in the 'payment' param), adding mild redundancy.

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

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

Complete for a paid data tool with no output schema: it explains how to obtain the payment requirements, how to pay, how the result is returned ('the data comes back in the tool result'), and the trust model, leaving nothing an agent needs to invoke it correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description restates the two-phase payment mechanics without adding syntax or format detail beyond what the schema provides, matching the baseline for full coverage.

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

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

States a specific verb+resource (an original lyric line) and its scope (short cosmic/comfort lines, Brian Booms' voice), immediately distinguishing it from the third-party-lyrics sibling qm_lyrics_get by asserting all lines are his own words.

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?

Gives explicit use cases — creative prompts, app copy, bedtime content — and notes the rotation/daily behavior. It does not name the alternative sibling (e.g. qm_lyrics_get) or say when-not to use this tool, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and delivers: exact price ($0.01 USDC on Base via x402), the two-phase handshake, an authoritative source caveat, wallet-safety guarantees (never pays, never touches private keys, never holds funds), and resale permission. Cost, auth, and safety are all disclosed.

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?

Front-loaded with the core purpose before payment mechanics, and every sentence is functional. There is minor redundancy (the 'never pays/never holds funds/never touches private keys' guarantee recurs in both description and schema), but structure is otherwise tight.

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

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

Despite no output schema, the description states the data is returned in the tool result, and the payment lifecycle is fully covered end to end. For a payment-gated tool, nothing an agent needs 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%, so the baseline is 3, but the description adds real meaning beyond the schema: it clarifies that omitting 'payment' yields live payment requirements and that 'payment' is a base64 x402 v1 payload signed externally. This enriches the semantics of both parameters.

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

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

The description states a specific verb+resource: extracting clean article text from a webpage with navigation/ads/chrome stripped, plus the downstream intent (processing/summarization). It does not explicitly distinguish itself from siblings like qm_data_summarize or qm_data_wiki, so the agent must infer the boundary, but the core purpose is unmistakable.

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 two-phase usage is spelled out precisely: call without 'payment' to get live requirements, then re-call with the base64 payload. It gives clear operational context but offers no guidance on when to choose this over sibling extraction/summarization tools.

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

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

With no annotations provided, the description carries the full behavioral burden and does so richly: it discloses the $0.01 USDC price on Base via x402, the two-phase payment flow, that the live 402 challenge is authoritative, that the tool never signs, holds funds, or touches private keys, and that resale is permitted. This is unusually transparent for a paid data tool.

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

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

The description is front-loaded with the tool's identity and then moves into payment mechanics and safety guarantees. It is longer than typical, but most sentences earn their place by explaining a complex paid workflow; only the resale-permission sentence feels slightly peripheral to 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?

Given the payment complexity, absent annotations, and no output schema, the description is complete enough to call the tool correctly: it explains the data returned, rotation behavior, two-phase payment sequence, and custody risks. The only minor omission is the exact return format, but the description states the data comes back in the tool result, which is sufficient for this tool type.

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 are already documented in the schema. The description reinforces the payment workflow and rotation context but adds little semantic detail about the 'index' parameter or payment payload beyond what the schema states, making the baseline 3 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 resource and scope: a genuine sleep-hygiene tip drawn from a rotating collection of 12 habits, rotating daily. This clearly identifies what the tool returns, though it does not explicitly differentiate itself from sibling sleep or data tools such as qm_sleep_recommend or qm_sleep_queue.

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 explicit two-phase invocation guidance: call without 'payment' to receive live payment requirements, then re-call with the base64-encoded x402 payload. This is clear procedural context, but it does not state when to prefer this tool over sibling sleep or data tools, nor does it describe when not to use it.

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

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

With no annotations, the description carries the full burden and does so richly: cost ($0.01 USDC on Base), two-phase payment behavior, robots.txt enforcement with refusal before any charge, and the security posture ("never pays and never touches private keys"). These are exactly the behavioral traits an agent needs before invoking a paid tool.

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

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

Front-loaded with purpose and price, then the two-phase flow, then output and safety notes, ending with a concrete example. It is dense but every sentence carries information; slightly long, which keeps it from 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?

There is no output schema, so the description must cover returns — and it does ("first call returns payment_required; second call with payment returns the summary"). Combined with pricing, payment flow, and refusal semantics, an agent has everything needed to call this correctly.

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

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

Schema description coverage is 100%, so both url and payment are already documented in detail in the schema, including the base64 x402 payload format. The description reinforces the payment semantics but 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+resource ("Webpage summary") plus the exact output shape ("Cleaned-text excerpt plus key sentences"). It is clearly distinguishable from data siblings like qm_data_readability, qm_data_wiki, or qm_data_httpcheck, which do not summarize.

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 two-phase invocation flow is spelled out precisely (first call with url only, then re-call with the base64 payment payload), which is strong how-to guidance. However, it gives no when-to-use-this-vs-alternatives routing against the many sibling data tools, so it stops short of a 5.

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

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

With no annotations, the description carries full burden and does well: it discloses the price ($0.01 USDC on Base via x402), the two-phase auth/payment handshake, that the computation is local with 'no upstream to fail', and explicit non-custodial guarantees ('never pays, never touches private keys, never holds funds'). It omits error/refund behavior and payload reuse semantics, which keeps it short of a 5.

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?

Purpose is front-loaded and each subsequent sentence covers a distinct concern (cost, two-phase flow, safety guarantees, resale rights) with no true filler. The density of payment-related detail makes it longer than average, but the length is warranted by the protocol complexity.

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 annotations and no output schema, it explains the payment flow and safety posture thoroughly. The main gap is return shape: it says only that 'the data comes back in the tool result', leaving the result fields unspecified despite there being no output schema to compensate.

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 both 'tz' and 'payment' are already documented in the schema. The description reinforces the two-phase meaning of 'payment' and the IANA nature of 'tz', but adds no syntax, format, or constraint detail 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 opening clause states a specific verb and resource ('Current local time in any IANA time zone') and immediately grounds it in concrete use cases (scheduling, broadcasts, market-window checks). It is trivially distinguishable from the sibling qm_data_* tools, which each cover a different data domain.

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 clear usage context (the kinds of checks this enables) and an explicit invocation protocol: call without 'payment' to obtain requirements, pay externally, then re-call with 'payment'. It does not name an alternative tool or state when *not* to use it, but the domain is narrow enough that this matters little.

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

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

With no annotations, the description carries the full burden and does so: it discloses the $0.01 USDC/Base x402 price, the two-phase challenge-then-pay flow, that the live 402 challenge is authoritative, that data returns in the tool result, that the tool never pays, never touches private keys, and never holds funds, and that resale is permitted. This is exactly the kind of side-effect and payment-behavior disclosure a payment-gated tool needs.

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?

Front-loaded with purpose, then usage, then payment mechanics, so an agent gets the essential framing first. It is dense and the payment explanation slightly overlaps the schema's own 'payment' description, but every sentence is doing relevant work given the x402 complexity.

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 payment-gated, no-annotation, no-output-schema tool, the description covers what is needed to invoke it correctly: inputs, the two-phase payment handshake, where the data appears, and the safety/licensing posture. Nothing an agent needs before calling is missing.

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

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

Schema description coverage is 100%, so the lat/lon ranges and the payment payload semantics are already fully documented in the schema; baseline is 3. The description restates the two-phase payment pattern rather than adding syntax, format, or edge-case meaning beyond what the parameter descriptions already provide.

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 (current weather plus a 7-day forecast) and its scoping input (latitude/longitude), then distinguishes itself from qm_data_geocode, which handles place names. An agent can tell what this returns and how it differs from the geocoding sibling without opening either 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?

Names concrete usage contexts (trip planning, event scheduling, location-aware tasks) and routes the agent to the alternative tool (qm_data_geocode) when it only has a place name. It stops short of an explicit when-not-to-use or a list of conditions under which it should be preferred over any other data sibling, so it is strong but not exhaustive.

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

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

With no annotations, the description carries the full behavioral burden and does so well: cost ($0.01 USDC on Base), the x402 two-phase protocol, that the live 402 challenge is authoritative, and explicit non-custodial guarantees ('never pays, never touches private keys, never holds funds'). Resale rights are also disclosed — rare and genuinely useful 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?

Front-loaded with purpose, then price, then the two-phase mechanics, then safety guarantees. Every sentence carries information, though the single dense block could be broken up for scanability.

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 and no annotations, so the description must stand alone — and it covers return shape, cost, payment flow and custody model. It omits failure modes (insufficient payment, missing article), which is a minor gap for a tool of this complexity.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema by framing 'payment' as part of a stateful two-phase exchange and noting the live challenge overrides the stated price. The 'topic' and 'lang' parameters gain little from the prose.

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 resource and return shape: 'Background on a person, place, company, or concept — a structured summary plus the link to the full article.' That clearly distinguishes it from qm_data_country, qm_data_astronomy and other qm_data_* siblings, though it never names an alternative 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?

Gives precise procedural guidance for the non-obvious case: call without 'payment' first to get requirements, then re-call with the payload. It does not address when to prefer this over another data source or what happens on topic-not-found, but the when-to-call flow is unambiguous.

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

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

With no annotations provided, the description carries the full disclosure burden. It states the tool is read-only, anonymous, free, counts service calls rather than unique agents, and does no tracking. This gives an agent a clear safety and semantics profile.

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

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

The description is concise yet complete, front-loading the purpose and then adding behavioral context, an alternative, and an example. Each sentence adds value without redundancy.

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

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

For a simple, parameterless, read-only counter, the description covers what it counts, what it does not count, privacy/safety characteristics, invocation requirements, and the relevant alternative. No critical information is missing.

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

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

There are zero parameters, and the description explicitly reinforces this: 'no parameters — call with {}.' This exceeds the baseline for parameterless tools by removing any ambiguity about invocation.

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

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

The description clearly states the tool's function: a counter for agents helped, clinic diagnoses, and tool uses served. It also explicitly distinguishes itself from qm_clinic_stats, so an agent can tell them apart without inspecting schemas.

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 says exactly when to use this tool and names the alternative: 'use qm_clinic_stats instead for condition-level breakdowns.' It also instructs the agent to call with no arguments and {}.

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

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

With no annotations provided, the description carries the full burden and does so richly: it discloses the price and rail, the authoritative 402 challenge, the two-phase handshake, and explicit non-behaviors ('never pays, never touches private keys, never holds funds'), plus resale permissions. This is exactly the behavioral context an agent needs.

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?

Front-loads what the tool returns before the payment mechanics, and most sentences earn their place. Slightly long, with the payment-rail details echoed again in the schema, but nothing is wasted or 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?

Complete for a paid read tool: it covers what is returned ('the data comes back in the tool result'), cost, payment sequence, safety guarantees, and licensing. No output schema exists, but the return behavior is still stated, so nothing an agent needs 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%, so both parameters are already documented in the schema; the description largely restates the 'payment' omit-then-recall workflow rather than adding new syntax or edge-case detail. 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?

States a specific verb and resource ('Lyric text + title/album metadata for one track from the 116-song catalog'), so an agent knows exactly what it returns. It does not explicitly name the sibling it differs from (qm_data_lyric_quote), but the 'one track' scope and 'his own words' framing effectively separate 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?

Gives explicit when-to-use for the two-phase flow: call without 'payment' to obtain the live requirements, then re-call with 'payment' set. It does not, however, route the agent to alternatives such as qm_data_lyric_quote or qm_buy for adjacent needs.

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

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

With no annotations, the description carries the full burden and does so well: it states the price ($0.10 USDC on Base via x402), that the live 402 challenge is authoritative, that the tool never pays/touches keys/holds funds, and that resale of the output is permitted. These are exactly the safety and cost traits an agent needs before invoking a paid tool.

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

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

The description is front-loaded with purpose and price, then the workflow, then safety guarantees. Every sentence is substantive, though the 'never signs / never holds funds / never touches private keys' assurance is repeated in the payment parameter description, creating mild redundancy.

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

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

For a paid, two-phase tool with no output schema and no annotations, the description covers pricing, the exact call sequence, safety guarantees, and data-usage rights. An agent has everything needed to invoke it correctly and interpret the result; nothing material is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the payment parameter's role in the two-phase flow (omit on first call, re-call with the signed payload) and clarifying that the server only forwards it to the rail. It slightly exceeds baseline but largely mirrors schema text for mood/minutes.

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 first sentence names a specific verb and resource: a track list built from a mood plus minutes, including per-track sync-license quotes and terms. It immediately distinguishes the output from a mere license grant ("quotes are not licenses"). An agent knows exactly what it produces 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 description gives an explicit two-phase workflow: call without 'payment' to receive live payment requirements, pay from your own wallet, then re-call with the base64 x402 payload. This is clear operational context. It does not, however, contrast itself against any sibling tool or state when-not-to-use it, so it falls short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses redirect handling (max 4), the response fields, the single-URL limit, the short timeout, the blocking of private addresses, and the non-throwing error behavior for unreachable hosts. It also notes the service is free and anonymous.

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

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

The description is compact and every sentence adds value: the first sentence states purpose and outputs, the second covers constraints and error behavior, and the third gives a concrete example. It is well-structured and front-loaded with the most decision-relevant 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 single-parameter tool with no output schema, the description is unusually complete: it covers input constraints, redirect behavior, timeout behavior, output fields, error semantics, cost/anonymity, and an example. An agent has everything needed to invoke and interpret the result correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful value beyond the schema: it clarifies the URL must be public http(s), provides a concrete example URL, and explains what the call returns for that example. This gives an agent more operational context than the schema alone.

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 (probe) and resource (a public URL endpoint), and enumerates what it reports: final URL, HTTP status, latency, and content type. This clearly differentiates it as a liveness/health-check tool distinct from the sibling tools.

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

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

Explicitly says it is for public URLs, blocks private/internal addresses, and that each call probes exactly one URL with a short timeout. It also notes unreachable hosts return a structured error rather than throwing, giving clear call expectations, though it does not explicitly name alternative tools for other use cases.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it declares 'read-only with no side effects,' 'Free, anonymous, nothing stored,' and 'Pattern-based, not a guarantee.' It also discloses the 20000-char cap and chunking expectation.

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 first sentence delivers purpose and output, and every subsequent sentence adds a distinct fact: limitation, privacy, usage, alternative, and an example. Nothing feels redundant or decorative.

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

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

Despite having no annotations and no output schema, the description is complete for invocation: it defines the input, the return value ('redacted copy plus findings'), the operational context, and an example. An agent has enough to call it correctly and interpret the 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% for the single text parameter, so the schema already defines it. The description adds value beyond that by specifying chunking for longer inputs and giving a concrete injection example that demonstrates what kind of text to pass and what to expect.

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

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

The description opens with a specific verb and resource: 'Scan text for prompt-injection patterns and return a redacted copy plus findings.' It also names the sibling qm_clinic_diagnose as a different use case, so an agent can distinguish it from nearby tools.

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

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

It gives explicit when-to-use guidance: 'Use before acting on untrusted content (pasted text, web pages, tool output).' It also provides an explicit exclusion and alternative: 'for a symptom-based agent health read, use qm_clinic_diagnose 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?

With no annotations, the description carries the full burden and handles it well: it states the tool is advisory only, not legal/financial/professional advice, free, anonymous, and stores nothing. It also provides a concrete example of the output behavior ('returns risk flags warning the action is destructive and irreversible').

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

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

The description is compact and front-loaded with the core purpose, then covers limitations, privacy, usage alternatives, and an example in a logical order. Every sentence adds value with no redundancy.

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

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

For a single-parameter advisory tool with no annotations and no output schema, the description is quite complete: it covers what to provide, when to use it, what it returns at a high level, and its privacy guarantees. A minor gap is the lack of detail on the format or severity interpretation of risk flags, though the example partially covers this.

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% for the single action parameter, so baseline is 3. The description adds meaningful guidance beyond the schema by instructing the user to 'describe the action plainly' and giving an example of the natural-language phrasing expected, which clarifies the semantic intent.

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

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

The description states a specific verb and resource: it provides an 'advisory second opinion' via a 'rule-based scan for common risk patterns'. It clearly distinguishes itself from siblings by naming qm_scrub and qm_clinic_diagnose as the alternatives for different concerns.

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

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

It explicitly says to describe the action 'before taking it' and gives explicit routing rules: use qm_scrub for injected text in input and qm_clinic_diagnose for behavior concerns. This leaves no ambiguity about when to select this tool over alternatives.

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

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

With no annotations, the description carries the full burden and does so richly: discloses price/rail ($0.10 USDC on Base via x402), the authoritative 402 challenge, that it never pays, touches keys, or holds funds, and that resale is permitted. This is exactly the behavioral context an agent needs before invoking.

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?

Front-loaded with the core purpose, then payment mechanics and safety posture. Dense and largely waste-free, though the resale/pricing sentences, while useful, add length that could be trimmed.

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

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

For a paid, two-phase tool with no output schema, the description covers the return path ('the data comes back in the tool result'), payment acquisition, and safety guarantees. An agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, including the two-phase 'payment' semantics. The description reinforces but adds little beyond what the schema states, 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?

States a specific deliverable (ordered track list + runtimes filling requested hours) and its source (sleep catalog). This clearly distinguishes it from siblings like qm_sleep_recommend or qm_playlist_build.

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

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

Explicitly lays out the two-phase call workflow: first call without 'payment' to get requirements, then re-call with the payload. However, it never contrasts this tool with the sleep-adjacent siblings (qm_sleep_recommend, qm_data_sleep_tip), so an agent must infer when this is the right choice over those.

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

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

With no annotations, the description carries the full burden and does so well: it discloses price ($0.05 USDC on Base via x402), the authoritative 402 challenge, the two-phase protocol, and explicit security guarantees (never pays, never touches private keys, never holds funds). It also discloses resale rights, which is unusual and genuinely useful behavioral context.

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

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

The response is front-loaded (purpose first, then data-only disclaimer, price, then mechanics) and every sentence carries information an agent needs. It is longer than typical but not padded, though the security guarantees are stated twice in near-identical 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 paid data tool with no annotations and no output schema, the description covers cost, payment handshake, return location ('the data comes back in the tool result') and safety limits. It stops short of describing the shape of the returned track list (fields, count), which is the only remaining 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 mood, minutes, and the base64 x402 payment payload are already documented in the schema. The description reinforces the mood/minutes curation intent and the payment handshake but adds no syntax or format detail beyond what the schema provides, 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 first sentence states a specific resource and scope: curated sleep-track picks keyed by mood and minutes, with listen links. It distinguishes itself from data-only siblings like qm_data_sleep_tip by naming the output form, though it never explicitly contrasts with qm_sleep_queue or qm_data_sleep_tip.

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 two-phase flow is spelled out concretely: call without 'payment' to receive requirements, pay from your own wallet, then re-call with the payload. That is clear operational guidance, but there is no guidance on when this tool is preferable to the other sleep-related siblings.

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

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

With no annotations, the description takes on the disclosure burden and does it well: it states the operation is free, anonymous, read-only, makes a network check, and only examines the origin. It does not mention error behavior or rate limits, but the core safety profile is explicit.

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

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

The description is compact and front-loaded: purpose, constraints, output, safety, and an example each earn their place. There is no filler or repetition of structured data.

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 tool with no output schema, the description explains input, scope, return concept, and expected file types, plus a concrete example. Minor gaps include no exact output format, no definition of what counts as 'valid' for each file, and the possible filename typo.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: only the origin matters regardless of path, one URL per call, and a worked example showing that a deep link still checks the site origin.

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 ('Check') and a specific resource ('a site's machine-readable files'), and enumerates three target file types with a concrete example. It is clearly distinguishable from sibling tools like qm_probe_endpoint, though the apparent typo 'lls.txt' for the standard 'llms.txt' slightly reduces precision.

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 clear usage context: pass any site URL, only the origin is checked, and one URL per call. It does not explicitly name when not to use this tool or which sibling alternative to choose, so it stops short of full routing guidance.

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