AgentX x402 Services (paid MCP tools)

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes beyond that by disclosing the underlying paid route (GET /x402/kevcheck) and a price ($0.10), which is real behavioral context an agent needs for cost-aware routing. It stops short of saying what happens on a 402 or what the response shape is, though the payment parameter schema covers the challenge 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?

Two terse clauses, front-loaded with what it does, followed by route and cost. Every token carries information; there is no filler or restatement of the tool name.

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 should say roughly what comes back (e.g., whether the version is listed in KEV, matched CVEs with IDs/severity). It omits that entirely, leaving the agent unsure whether the result is a boolean verdict, a CVE list, or raw feed data. The payment mechanics are fully covered by the parameter schema, so the remaining gap is squarely on the return side.

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

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

Schema description coverage is 100%, including a detailed explanation of the payment proof parameter, so the schema carries the load. The description only echoes that software and version are the query inputs via the visible URL template; it adds no format, matching, or edge-case semantics beyond that. 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: a CVE check for a software+version pair, resolved against CISA KEV and NVD. That is immediately distinguishable from every sibling (DNS checks, Polymarket, weather, SEO audits). It does not explicitly name a sibling alternative, but none of the listed siblings are plausibly confusable.

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

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

Usage is only implied: 'for software+version' tells the agent what input shape to bring, and the '$0.10' signals a paid call, but there is no explicit when-to-use, when-not-to-use, or alternative named. The agent must infer that this answers 'is this version vulnerable?' rather than, say, returning a general advisory feed.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds the cost ($0.01) and the underlying route (GET /x402/email-check?q=), which is useful context, but it omits the notable behavior that a first call without payment returns a live 402 challenge — that is only explained inside the payment parameter description.

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

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

Two short sentences, front-loaded with what is checked and followed by cost/route. Nothing is padded, though 'outreach verdict' is left unexplained and costs a small amount of clarity for the terseness.

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 paid x402 flow and absence of an output schema, the description leaves out the two behaviors an agent most needs up front: that an unpaid call returns a 402 challenge, and what the 'outreach verdict' actually contains. The schema compensates for the payment mechanics, but the top-level context is thin for a paid, multi-check tool.

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

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

Schema coverage is 100%; both q and payment are fully documented in the schema, including the x402 settlement flow. The description only reiterates that q accepts a domain or address, adding essentially no 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 the exact record types returned (MX, SPF, DMARC) plus an 'outreach verdict' for a domain or address, which is specific enough to separate it from the security/polymarket/weather siblings. The verb is only implied by the tool name rather than written into the description, so it falls just short of a 5.

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

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

The description names no alternatives and gives no conditions for choosing this tool over siblings like check_security_headers or check_webmcp. The use case is inferable from the purpose statement, but no explicit when-to-use or when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the pricing ($0.01) and the concrete GET route, though the 402/payment handshake itself is documented in the schema rather than here.

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

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

Two compact sentences with no waste; the what and the cost are front-loaded. The telegraphic style is efficient but slightly at the expense of readability.

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

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

For a simple one-required-parameter read-only scoring tool with no output schema, the description covers what is measured, the 0–10 output scale, and the per-call price. Little more is needed, though a note on whether a full breakdown is returned would round it 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%, including a detailed explanation of the optional payment proof parameter and the required https URL. The description adds only the route showing how url is passed; baseline 3 is appropriate when the schema carries the parameter burden.

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 — scoring security headers for a URL — and enumerates the dimensions checked (CSP, HSTS, framing, cookies, TLS), which distinguishes it from sibling health/vuln checks like check_cves and get_site_health. It stops short of explicitly naming which sibling to use instead.

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

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

No statement of when to use this versus check_cves, get_site_health, or check_webmcp, and no prerequisites or exclusions. Usage is only implied by the task description itself.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral facts not present in annotations: the exact GET route and the $0.10 price per call, which matters for cost-aware tool selection. It stops short of describing the first-call 402 challenge flow or rate limits, but the schema's payment field covers that.

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

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

A single compact sentence with the purpose front-loaded and the price/route trailing, so nothing is wasted. It is arguably too compressed given the complexity of the x402 payment flow, but there is no filler or repetition.

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

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

For a 2-parameter, no-output-schema tool with annotations present, the description covers what the tool returns at a high level (pass/fail). It omits what 'WebMCP agent-compatibility' actually inspects and how its result should route an agent to order_webmcp_upgrade, which leaves a real gap in a crowded check_* / webmcp_* sibling set.

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

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

Schema description coverage is 100%, so both the 'host' and 'payment' parameters are already documented in detail, including the nuance of omitting payment on a first call. The description's '?host=' fragment confirms host is a query parameter but adds no semantics 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 and resource ('WebMCP agent-compatibility check') plus the outcome shape ('pass/fail verdict'), which is more than a restated name. It does not, however, distinguish itself from near-siblings like check_x402, lint_protocol_card, or order_webmcp_upgrade, leaving the agent to infer the boundary.

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

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

The description contains no when-to-use or when-not-to-use guidance and never names the alternative tools (e.g. order_webmcp_upgrade for remediation, lint_protocol_card for protocol validation). The only procedural hint — omit payment on a first call to receive a 402 challenge — lives in the schema, not the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the low-risk profile is covered. The description's main addition is the $0.01 per-call price, which matters because 'readOnly' can mislead an agent into thinking the call is free. However, the two-step 402-challenge-then-pay workflow, the biggest behavioral surprise here, is disclosed only in the schema, not in the description.

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

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

One compact sentence, front-loaded with the core question and followed by the invocation form and price. The 'GET /x402/x402_check?url=' fragment is mildly redundant with the schema but does anchor the call shape and cost.

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 whose real complexity is a paid 402-challenge handshake, the description omits the flow entirely and does not say what a result looks like (valid/invalid, challenge details). No output schema exists to cover returns, so the description leaves the agent to discover the payment dance from parameter docs alone.

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

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

Schema description coverage is 100%, so the schema fully documents both url and the optional payment proof. The description repeats only the url query parameter and adds no semantics the schema doesn't already carry, which is the baseline 3 case when the schema does the heavy lifting.

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

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

The description names a specific resource and check: determining whether a URL is a valid agent-payable paid resource under x402 v1 and v2. 'x402 Doctor' is jargon but the parenthetical explanation disambiguates it from the check_* siblings, which target DNS, headers, CVEs, and so on.

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

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

Usage is implied by the purpose (validate/pay against an x402 endpoint) but the description never states when to prefer this over alternatives or what preconditions exist, such as needing a URL that actually serves an x402 challenge. $0.01 gives a cost signal but no exclusion criteria.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds useful behavioral facts — it is a paid endpoint ($1.75) hit via POST /x402/classify — which is real value. It does not disclose the 402-challenge/payment-retry flow, but that lives in the schema.

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

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

Two tight fragments, front-loaded with purpose then endpoint and price. Slightly telegraphic, but nothing 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?

For a paid, multi-param tool with no output schema, the description is thin on return behavior and on what happens without payment or how labels/multiLabel interact. The schema carries the payment flow, so this is adequate but with clear gaps.

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

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

Schema coverage is 100%, so both the char limit and payment-proof semantics are already documented. The description repeats the 24k limit and cost but adds no meaning beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource — 'AI topic classification of supplied text' — with a hard input limit. It does not name a sibling, and extract_keywords is a closely related tool an agent could confuse it with. Clear but not differentiated.

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

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

No guidance on when to use this vs. extract_keywords or when-not to use it. The cost mention ($1.75) implies a paid route, but the description never says when classification is the right choice.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context the annotations cannot express: this is a paid x402 route costing $0.90, which tells the agent a payment flow is involved. It stops short of explaining the two-call challenge/retry pattern, though the payment parameter's schema text carries that burden.

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

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

Two short clauses that front-load the capability and then the endpoint/price. Nothing is wasted, though the telegraphic style (em dash plus price fragment) borders on under-specification rather than crispness.

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 3 simple params, full schema coverage, and read-only annotations, the essentials are present. The gap is the return shape: no output schema exists, and "scores and language" only gestures at the response format (score scale? language as ISO code or name?) without pinning it down.

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 text, payment, and maxKeywords are all documented at the field level with the 24k char limit and the full 402 proof mechanics. The description adds nothing about parameters, so the baseline 3 applies; it neither compensates nor detracts.

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 ("AI keyword extraction") plus the outputs it produces ("scores and language"), which is more than a restatement of the name. However, it never distinguishes itself from the similarly-shaped sibling classify_text or from run_seo_audit, so an agent must infer the boundary itself.

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

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

There is no statement of when to reach for this tool versus classify_text, run_seo_audit, or get_page_roast, and no exclusions or prerequisites beyond the price tag. The agent gets the endpoint and cost but no selection guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by disclosing the route and $0.01 cost, but it does not describe the response shape, pagination, or practical limits of the scan.

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

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

The description is extremely compact and front-loads the key arbitrage condition. The endpoint and price fragments are terse but purposeful, though the notation is slightly cryptic.

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 carries more burden for explaining what is returned. It states the selection condition but not the return format, and it leaves payment flow details to the schema. It is minimally adequate for a paid Polymarket scan tool but not complete.

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

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

Schema coverage is 100%, so both the limit and payment parameters are already documented in the schema. The description only repeats the 'limit=' query shape and price, adding no meaning beyond what the schema already provides.

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

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

The description states a precise arbitrage condition: markets where YES_ask + NO_ask < $1.00. That condition distinguishes it from sibling Polymarket odds/book/history tools, though it does not use an explicit verb like 'find' or name the resource as Polymarket arbitrage markets.

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 arbitrage condition implies when the tool is useful, and the endpoint plus cost give some operational context. However, it does not say when to prefer this over get_polymarket_odds or get_polymarket_book, nor does it give any exclusions or prerequisites beyond the schema's payment description.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the $0.01 cost and the endpoint it hits, which is genuinely useful, but it does not say what the verdict payload looks like or how it is scored; the payment/retry mechanics are disclosed in the parameter schema rather than the description.

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

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

Front-loaded and waste-free, with the resource, check dimensions, endpoint, and price all in one compact line. The telegraphic style borders on under-specification rather than verbosity.

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

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

There is no output schema, so the description is the only place to learn what a 'verdict card' contains, and it gives only the check categories without the shape of the result. The complex payment handshake is well covered by the schema, which keeps this from being inadequate.

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

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

Schema description coverage is 100% and the payment parameter carries a detailed explanation of the 402 challenge flow, so the schema does the heavy lifting. The description only alludes to the host parameter via '?host=', adding no syntax or format detail beyond the schema.

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

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

The description names a specific resource (agent-readiness verdict card) and enumerates the checks covered (llms.txt, A2A, MCP, TLS, crawlers), so the agent knows exactly what is produced. It does not, however, differentiate itself from close siblings like check_webmcp, get_crawler_policy, or lint_protocol_card.

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

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

Usage is implied by the checklist of dimensions covered, which suggests when the tool is relevant, but there is no explicit when-to-use / when-not guidance and no routing to sibling tools such as get_crawler_policy or check_webmcp.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds genuinely useful non-schema behavior: the cost ($0.01) and the underlying route (GET /x402/btc-fees). It does not restate the 402 payment handshake, which is fine since the schema covers it, but it also omits latency/refresh cadence for a time-sensitive fee forecast.

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?

One compact sentence plus a route/price fragment; the return payload is front-loaded and every token carries information. No filler or restatement of the title.

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

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

With no output schema, the description usefully enumerates the four returned horizons so the agent knows what it gets back, and it discloses price and endpoint. Only the paid-call flow (first call returns a 402 challenge) is left entirely to the schema description.

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

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

Schema description coverage is 100% and the single `payment` parameter is fully documented there, so baseline is 3. The description's 'No params' is a slight mismatch with the schema — accurate for functional inputs but it could confuse an agent into never supplying the payment proof on a retry.

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 (Bitcoin sat/vB fee forecast) and enumerates the exact horizons returned: next block, 30 min, 1 hour, economy. An agent can tell this is a fee-estimate tool rather than a price tool, though no sibling (e.g. get_gas_price, get_crypto_prices) is named to sharpen the boundary.

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

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

Usage is only implied by the resource name and the 'No params' note — the agent can infer you call it when you need BTC fee rates. There is no explicit when-to-use/when-not guidance and no mention of alternatives such as get_gas_price for other chains.

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

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

Annotations already establish that this is a safe, idempotent read. The description adds genuinely new context — the endpoint path and the $0.01 price, which signals a paid call — but it never mentions the 402 challenge/retry flow that actually governs invocation; that only appears in the payment parameter's schema text.

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

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

Two short fragments, no filler, with the resource description front-loaded ahead of the route and price. Terseness is the only concern; nothing is redundant.

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

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

With one required parameter, full schema coverage, and read-only annotations, the essentials are covered. However, with no output schema the description should say more about what the policy matrix contains or its shape, and it never acknowledges the payment handshake that a first call will trigger.

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 host and the payment-proof parameter are already fully documented in the schema, including the omit-on-first-call behavior. The description adds only the price, leaving 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 names the concrete deliverable — a TLS/security-headers/AI-crawler policy matrix for a given host — plus the exact route, so an agent knows what it will get back. It stops short of distinguishing itself from the sibling check_security_headers, whose scope visibly overlaps.

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

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

There is no statement of when to reach for this tool versus check_security_headers or check_webmcp, and no preconditions are given. The agent must infer the use case from the resource name alone.

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

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

Annotations already declare this as a safe, read-only, idempotent operation. The description adds useful pricing context ($0.01) and a token limit, but it does not explain the payment/retry flow or pagination behavior beyond what the schema covers.

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

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

Two compact sentences, front-loaded with the output and limit, followed by endpoint and price. There is no waste and no burying of critical information.

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

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

For a simple read-only price lookup with annotations and full schema coverage, the description is largely complete. It states the return values at a high level and the cost, though it could mention first-call payment behavior more explicitly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters in detail. The description adds a useful maximum of 10 tokens for the assets parameter, but otherwise adds no syntax or format detail beyond the schema.

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

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

The description states a specific resource and output: USD price plus 24h move for up to 10 tokens. It is clear what the tool returns, but it does not explicitly differentiate itself from siblings like get_btc_fees or get_fx_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?

It gives an implicit scope (up to 10 tokens) but does not say when to use this tool versus alternatives such as get_btc_fees or get_fx_rates. No exclusions or selection guidance are provided.

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

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

Annotations already declare read-only, idempotent, non-destructive, so safety is covered. The description adds useful context ($0.01 cost and the GET route), but the 402 payment/retry behavior — the genuinely tricky part — lives only in the schema, not the description.

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

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

Two terse fragments, zero waste, return scope front-loaded before the endpoint and price. Slightly telegraphic style but appropriately sized for a trivial no-arg read.

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 does state what comes back (index + 7-day history). Combined with annotations and a fully documented payment param, an agent has enough to call it correctly; only the challenge/retry loop is left implicit.

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

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

Schema coverage is 100% and the single optional 'payment' param is fully documented there. 'No params' adds a small confirmation but arguably undersells the optional payment mechanism that the schema describes at length.

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

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

Specific resource (Crypto Fear & Greed Index) plus explicit return scope (7-day history), pinned to a concrete route. An agent can distinguish it from siblings like get_crypto_prices or get_btc_fees without inspecting other 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?

States 'No params' and the cost, implying a direct fetch, but never says when to prefer this over get_crypto_prices or any other market-sentiment sibling, nor any exclusions.

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

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

Annotations already declare readOnly/idempotent/non-destructive. The description adds a trait annotations do not carry — a $0.01 price and the upstream EBC source — which is genuinely useful, but it omits the paywalled first-call/challenge behavior and any rate limits, leaving the payment nuance to the schema's payment parameter.

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

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

Three compact fragments with the purpose front-loaded; nothing is padded. The raw URL template is slightly awkward but is the only marginal waste.

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 should say what a caller gets back (base→quote rate pairs), which it only gestures at. The complex payment handshake is covered in the schema, so the gap is moderate rather than severe.

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

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

Schema description coverage is 100%, so the schema already documents base, symbols, and the full x402 payment flow. The description's '?base=&symbols=' template merely restates parameter names and adds no format or validation detail 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?

Names the specific resource and its upstream source ('ECB reference FX rates') and pins the exact endpoint path, so it is distinguishable from get_crypto_prices and get_btc_fees without opening the schema. There is no explicit verb, but the GET route makes retrieval 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?

No statement of when to call this versus get_crypto_prices or get_btc_fees, no exclusions, and no prerequisite context such as the fact that unpriced first calls return a challenge. Usage must be inferred entirely from the name and endpoint.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so safety is covered. The description adds genuinely useful non-schema context: the underlying GET route and a $0.01 cost per call. It does not itself explain the 402 challenge retry behavior, but that is documented in the payment parameter's schema text.

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

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

A single front-loaded sentence plus endpoint and price — no filler. It is dense to the point of being slightly telegraphic ('Live gas on ... plus USD transfer cost'), but every fragment carries information.

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

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

For a zero-required-parameter read-only lookup with full schema coverage, the description covers scope, chains, cost, and route. The only gap is that with no output schema the description does not characterize the response shape (units, per-chain fields), which would help an agent interpret results.

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

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

Schema coverage is 100% and the chain enum plus the payment/402 flow are fully documented in the schema, so the description has nothing left to add. Mentioning '?chain=' duplicates existing schema information rather than extending it, 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 the resource (live gas prices) and enumerates the exact six chains covered, plus an extra value-add (USD transfer cost). It is clearly distinguishable from siblings such as get_btc_fees or get_crypto_prices, though it never names them explicitly and uses a noun phrase rather than a verb.

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 no when-to-use or when-not guidance and does not point to alternatives like get_btc_fees for Bitcoin fees. The only contextual hint is the endpoint path and the $0.01 price, which tells the agent the call costs money but not when it is the right call.

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

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

Annotations already establish that the operation is read-only, idempotent, and non-destructive. The description adds useful context beyond that: it is a paid GET costing $0.01 and returns an SVG along with score and verdict, though it leaves the 402 challenge workflow to the schema's payment parameter description.

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

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

The description is a single compact sentence that front-loads the main action and output types. It is efficient, though slightly telegraphic in combining a product name, endpoint, and price.

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 appropriately states the return components: score, verdict, and SVG. Combined with the fully described input schema and read-only annotations, it gives enough context for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, so both url and payment are already documented in the schema. The description mentions the url query parameter indirectly via '?url=', but adds no parameter meaning beyond what the schema already provides.

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

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

The description names a specific action and resource: roasting a page's biggest flaw and returning a score, verdict, and SVG. It is understandable apart from the many sibling tools, though the phrase 'Legends Roast' is product-flavored rather than plain functional language.

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 no explicit guidance on when to use this tool versus alternatives such as run_seo_audit, check_security_headers, or get_site_health. It implies usage from the endpoint name and price but does not name exclusions or selection criteria.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral facts: this proxies a specific HTTP GET route and costs $0.01 per call. It stops short of stating failure modes or what an unpaid first call returns, which the schema's payment field handles.

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 compact fragments lead with the returned data, then the route, then the price — no wasted words. The telegraphic style is slightly cryptic ('— $0.01') but costs nothing in length.

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

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

With no output schema, the description does list the key returned fields, and the payment mechanics live in the schema. However, it omits units/scale of depth, what 'q' resolves against (topic vs slug), and failure behavior for a small paid lookup tool.

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

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

Schema coverage is 100%, so both q and payment are fully documented in the schema, including the 402-challenge flow. The description's '?q=' merely restates the query-string binding and adds no format or semantics beyond the schema, so baseline 3 applies.

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

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

Names the specific resource and its payload precisely: top-of-book bid/ask, spread, and USD depth for a Polymarket book, plus the backing route. It does not distinguish itself from near-siblings such as get_polymarket_odds or find_polymarket_arb, so an agent must infer which one to pick.

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

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

There is no statement of when to use this versus get_polymarket_odds, get_polymarket_history, or find_polymarket_arb. The '$0.01' hints that the call is paid, but no guidance on prerequisites or exclusions is given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: the $0.01 cost and the x402 route, which tells the agent this is a paid call. It does not add anything else — the 402-challenge/retry mechanics live entirely in the payment parameter's schema text.

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

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

Two terse clauses, front-loaded with what is returned, then endpoint and price. Nothing is wasted, though the abbreviation style ('YES-price series') is a bit dense.

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

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

With no output schema, the description must convey the return shape, and 'with change and high/low' only partially does so — the granularity, field names, and empty-result behavior are unknown. The payment flow is fully documented in the schema, so the main gap is the response shape and any failure modes.

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%: q is documented as 'Topic or slug', days as 'Window 1–90, optional', and payment gets a long procedural explanation. The description only echoes the route template with q and days, adding no semantics the schema lacks. 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 resource (YES-price series), verb-ish action (return history), window (1–90 days), and return contents (change, high/low). This distinguishes it from get_polymarket_odds and get_polymarket_book in substance. It does not name a sibling outright, so it stops short of the top score.

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

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

There is no explicit 'use when' clause and no named alternative; the agent must infer that this is the historical-price companion to get_polymarket_odds. The 1–90 day window is stated, but nothing says what happens outside it or which sibling to pick for current odds.

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

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

Annotations already declare readOnlyHint and idempotentHint true, but the description adds two valuable behavioral details: the endpoint is a paid $0.01 x402 route and the HTTP method is GET. It still omits return format details, but the cost disclosure is significant beyond annotations.

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

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

The description is two short, front-loaded sentences with no wasted words. It efficiently conveys purpose, endpoint, and cost, though the endpoint fragment is slightly cryptic and could be clearer.

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

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

For a simple read-only tool with no output schema, the description should clarify what the returned odds look like (e.g., decimal, implied probability). It does not, leaving a gap in understanding the return values.

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

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

Schema description coverage is 100%, with both parameters fully documented in the input schema. The description only reiterates the ‘q’ parameter indirectly via the endpoint URL and adds no new semantic meaning, so the baseline of 3 applies.

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

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

The description states a specific resource (‘Live YES/NO odds for a named Polymarket market’), which clearly differs from siblings like get_polymarket_book or get_polymarket_history. However, it does not explicitly name or exclude any sibling tool, leaving differentiation to inference.

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

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

The description offers no guidance on when to use this tool versus alternatives. It merely states what it does (‘Live YES/NO odds…’) without any when-to-use or when-not-to-use context relative to the other polymarket 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?

Annotations already declare this is a read-only, idempotent, non-destructive lookup. The description adds useful cost context ($0.01) and the HTTP route, but it does not itself describe the x402 payment/retry behavior; that burden is carried by the schema's payment parameter description.

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

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

Two compact fragments, front-loaded with the user-facing question and followed by the endpoint and price. Every element carries information; there is no padding.

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 read-only lookup with full parameter coverage and explicit safety annotations, the description is mostly complete: it states the question answered, the route, and the cost. A minor gap is that it does not state what is returned when no market has resolved, and there is no output schema to cover that case.

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 explains both q (optional topic, newest resolved if omitted) and the payment proof flow in detail. The description only hints at q through the URL-style '?q=', so it does not add meaning beyond the schema.

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

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

The description asks a specific question — did a market resolve and which outcome won — and ties it to a specific endpoint. It is clearly distinct from sibling odds/book/history tools by focusing on final resolution status, though it does not name those siblings 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?

Usage is implied: call this when you need to know whether a market has resolved and which outcome won. There is no explicit guidance on when to prefer it over get_polymarket_odds, get_polymarket_history, or find_polymarket_arb, nor any stated exclusions.

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

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds genuinely new behavioral context: this is a paid x402 route at $0.01 per call, plus the exact upstream endpoint. It does not mention pagination or response size for large limits.

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

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

Two compact fragments with the ranking criterion front-loaded and cost separated at the end. The literal 'GET /x402/polymarket-trending?limit=' string is slightly implementation-flavored but earns its place by hinting at the limit parameter.

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

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

For a two-optional-parameter, read-only list endpoint with no output schema, the essentials are present: what is returned conceptually (top markets with YES prices) and that payment is required. A brief note on how many markets appear or the response shape would close the 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 both parameters are already documented — including a detailed explanation of the payment proof flow. The description only mirrors the 'limit' concept via the URL template and adds nothing about valid ranges or defaults 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 resource and ordering: 'Top open Polymarket markets by 24h volume with YES prices.' This is clearly distinguishable in substance from get_polymarket_odds/book/history, though the description never names those siblings to make the routing explicit.

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

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

Usage is only implied by the phrase 'Top open ... by 24h volume' — an agent can infer this is the discovery/ranking call rather than a lookup by market id. There is no explicit when-to-use, when-not-to-use, or pointer to get_polymarket_odds or get_polymarket_book as 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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context that this is a snapshot and costs $0.01, but it does not explain payment challenge behavior or rate limits beyond what the schema provides.

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

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

The description is short, front-loaded, and free of fluff. The endpoint fragment is a bit terse, but the overall size is appropriate for a simple read-only 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?

The description lists the snapshot components and states the price, which is useful. However, with no output schema, it does not describe the return shape in detail, and it leaves payment-flow behavior to the schema.

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

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

Schema description coverage is 100%, so both host and payment are already documented in the schema. The description mentions the host parameter in the endpoint path but adds no meaningful semantics beyond the schema.

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

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

The description clearly states the resource scope: a DNS, TLS certificate, HTTP status, and latency snapshot. It is specific enough to distinguish a site-health check from sibling tools like check_security_headers or run_seo_audit, though it does not explicitly name alternatives.

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

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

It provides no when-to-use or when-not-to-use guidance and does not route the agent between this tool and related siblings. The endpoint notation and price are implementation details, not usage guidance.

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

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

Annotations already declare this read-only, idempotent and non-destructive, and the description is consistent with that. It adds the genuinely non-obvious behavior: the call is paid ($0.01 USDC via x402), which is not derivable from annotations and matters for agent decision-making; it stops short of restating the 402 retry flow, which the schema covers.

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

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

A single sentence front-loads purpose, provider and price with zero filler. Nothing is repeated from the schema or annotations beyond the implicit field name.

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

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

For a simple two-parameter read tool whose schema fully documents the payment flow, the description covers purpose, source and cost. It omits response shape (units, fields returned) and there is no output schema, but that gap is minor for a well-known weather payload.

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 fully documented in structured fields. The description only implies that 'city' drives the query and adds no format, casing or payment semantics beyond it; baseline 3 applies.

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

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

States a specific verb and resource ('Live current weather for any city'), names the upstream provider (Open-Meteo), and gives the concrete endpoint path. No sibling tool overlaps with weather, so an agent can select it unambiguously at a glance.

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

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

Usage is only implied: you call it to get weather for a city. It doesn't say when to prefer it (e.g. 'live' vs. any forecast alternative) or hint that a first call without payment returns a 402 challenge — that guidance lives in the schema, not the description.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context about the GET route and $0.01 cost, plus a hint that it returns patched JSON fixes, but it does not explain the response or payment interaction in detail.

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

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

It is a single compact sentence with the core purpose and endpoint front-loaded. The brevity is mostly efficient, though it borders on under-specification rather than pure conciseness.

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

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

For a two-parameter paid lint tool with rich annotations and schema coverage, the description is adequate but thin. It does not describe return values or the patch/fix output, and with no output schema present that leaves a meaningful gap.

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

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

Schema description coverage is 100%, so both the url and payment parameters are already well documented in the schema. The description only indirectly references the url parameter via the GET query string and adds no parameter semantics 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 and resource: linting an A2A/MCP protocol card. It is distinguishable from most siblings, but it does not explicitly differentiate itself from related tools such as get_agent_card or check_webmcp, and "patched JSON fixes" is vague.

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

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

Provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The endpoint and price are usage context, but they do not tell an agent when this lint is the right choice.

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

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

Annotations already declare destructiveHint/readOnlyHint/idempotentHint, and the description adds real context beyond them: the exact $4.00 charge, the confirm gate, the site-fetch-and-generate side effect, and the crucial clarification that the server never settles payment itself. It stops short of saying whether the charge is refundable or where webmcp.js is written.

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 'DESTRUCTIVE' and the price, then the side effect, then the confirmation rule – the most decision-relevant facts come first. The 'POST /x402/webmcp-upgrade JSON {url, notes?}' fragment partly duplicates the schema and 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, destructive mutation tool with a fully documented 4-parameter schema and no output schema, the description covers cost, confirmation, side effect, transport, and payment responsibility. Nothing an agent needs to decide whether to call it 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 schema already explains url, notes, confirm, and the full payment/x402 challenge flow. The description only restates the endpoint shape and the non-settlement caveat, adding little semantic detail 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 and resource ('places a paid WebMCP upgrade order'), plus the concrete side effect ('Fetches the site and generates webmcp.js') and the endpoint. An agent can immediately distinguish this from the read-only sibling check_webmcp.

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?

Explicit gating instruction: 'Confirm with the user before calling' plus the confirm parameter requirement, which tells the agent exactly when it may proceed. It doesn't name check_webmcp as the non-paid alternative, so there is a small gap in alternative routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's job is incremental value — and it delivers the paid-call cost ($0.10) and the underlying route, both of which affect how an agent should plan the call. It does not mention rate limits or what happens when the audit target is unreachable, but the payment retry behavior is fully documented in the schema.

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

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

Two compact fragments with the purpose front-loaded and pricing tacked on at the end; nothing is redundant. The endpoint string is somewhat redundant with the schema but is short enough not to be wasteful.

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 should carry more about return shape, but 'score and findings' gives a rough signal and the payment mechanics live in the schema. Gaps remain around failure modes and the scope of what the audit checks, which matter for a paid per-call tool.

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

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

Schema coverage is 100%, so both the host and payment parameters are already fully explained upstream; the description only restates that host is a query parameter via the URL template. 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?

Names a specific verb and resource ('Rules-based SEO + agent-readiness audit') and states the deliverable ('score and findings'), which is enough to tell it apart from check_webmcp or get_site_health in most cases. The overlap with 'agent-readiness' versus check_webmcp is not explicitly disambiguated, keeping it from a 5.

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

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

There is no statement of when to use this versus siblings like check_webmcp, get_site_health, or get_crawler_policy, and no prerequisites or exclusions. The agent must infer the selection from the tool name alone.

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