DevX Agent Hub

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

Adds important behavior beyond the annotations: it explains the x402 payment flow, the exact price, that the first call returns PaymentRequired without charging, and how to retry with payment. These are critical operational details an agent would not infer from readOnly/openWorld/idempotent/destructive 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 front-loaded with the core action and output, then follows with usage and payment details. It is dense but appropriate for the tool's complexity, with minor redundancy in repeating the $0.01 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?

Given the complexity of crypto payment protocols and the lack of an output schema, the description covers the main outputs, supported chains/tokens, validation step, and payment flow. It is mostly complete, though it leaves parameter formatting and error behavior under-specified.

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 only 14%, so the description must compensate. It clarifies the token/chain/protocol mapping for EIP-681, BIP21, and Solana Pay, but it does not explain the format of required parameters like `to` and `amount`, nor the meaning of `label` or `message`.

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: create a crypto payment request that returns an EIP-681/BIP21/Solana Pay link plus QR code SVG. The purpose is clear and distinct from siblings like verify_crypto_payment, but the description does not explicitly differentiate itself from those 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?

Gives clear usage context: "For invoices and checkouts" and notes recipient validation before request creation. It does not state when not to use it or explicitly name alternative tools, 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.

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

Goes well beyond the readOnly/idempotent annotations by disclosing the entire x402 payment handshake: the first call returns PaymentRequired with no charge, and the retry must carry payment in _meta["x402/payment"], at $0.01 USDC on Base. That is exactly the kind of non-obvious operational behavior an agent would otherwise fail on.

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 chain coverage and the use case, then the payment mechanics; nearly every clause carries information. The price is stated twice ("$0.01 USDC on Base via x402" and "Price: $0.01"), a small 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 two-parameter, single-purpose tool with no output schema, the description covers supported networks, the failure modes detected, and the full payment flow. It does not spell out the return shape (e.g., whether an identified chain or a validity boolean comes back), which is the only notable gap given there is no output 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 50%: x402_payment is documented in-schema, while address has only a maxLength. The description tells the agent which chain families an address may belong to, which adds some semantic framing, but gives no format, casing, or checksum expectations for the required parameter.

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 (validate/identify) and resource (crypto wallet address) and enumerates exactly which networks and address encodings are covered. That scope statement cleanly separates it from siblings like wallet_balances_multichain and token_safety_check, which operate on balances and token contracts rather than address syntax.

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?

"before sending funds" plus "catches typos and wrong-network addresses" gives a clear triggering condition and the failure mode it prevents. It does not explicitly name an alternative tool or an exclusion case, 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower; the description adds genuinely new behavior — the x402 payment loop, that the first call is uncharged and returns PaymentRequired, and that the paid retry must carry payment in _meta["x402/payment"]. It stops short of describing failure modes after payment, rate limits, or latency.

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

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

Dense but front-loaded: capability, use cases, then payment mechanics in the logical call order. The price is stated twice ('$0.003 USDC on Base via x402. Price: $0.003.'), which is redundant padding 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?

No output schema exists, and the description does summarize the return (prioritized findings plus a score), plus the payment handshake an agent must perform before getting results. The only real gap is domain input format, which matters for a paid call that would fail or misresolve on a malformed hostname.

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 x402_payment parameter is documented in the schema, but the required `domain` parameter has no description anywhere — no format guidance (bare apex vs. subdomain, no scheme/www, 253-char cap). With coverage at 50%, the description should compensate for the undocumented required parameter and does not.

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 (DNS and email-security audit of a domain) and enumerates exactly what is checked: A/AAAA/NS/MX/TXT/CAA/SOA, SPF, DMARC, MTA-STS, BIMI, DNSSEC. It also declares the deliverable (prioritized findings and a score), so an agent can distinguish it from every sibling in the list, none of which touch DNS.

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 concrete triggering scenarios: deliverability checks, phishing/spoof risk, and vendor due diligence. That is clear when-to-use context, but there are no exclusions or pointers to alternative tools, and no guidance on what a domain with no mail records will yield.

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, open-world), and the description adds what annotations cannot: a concrete price, the x402 payment handshake, the fact that the first call is free and returns PaymentRequired, and how to retry with payment in _meta["x402/payment"]. Cost and payment-failure behavior are exactly the traits an agent needs to avoid a surprise charge or a dead-end call.

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 capability and scope, then payment mechanics at the end, with no filler sentences. Minor redundancy: "$0.005 USDC on Base via x402" and "Price: $0.005 per token" say overlapping things and could be one clause.

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 the return-value burden and does so by listing the concrete signals and the risk-level/flags summary. For a read-only, single-address, paid call, everything needed to invoke it correctly and interpret the cost is present.

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 only 33%, so the description has to compensate, and it largely does: it enumerates the six supported chains matching the enum and explains the two payment paths (_meta["x402/payment"] versus the x402_payment parameter) including when to omit it on a first call. It never explicitly says the address parameter is the token contract address, which is the one semantic gap.

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 (ERC-20 token pre-check from on-chain data) and enumerates exactly what is returned: name/symbol/decimals/supply, owner/renounced status, proxy detection, bytecode scan for mint, blacklist, fee, max-tx, trading switch and pause, plus flags and risk level. It is explicitly distinguished from the sibling token_safety_check by scope, so an agent can choose between them 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 the alternative and the condition that selects it: "No honeypot simulation (use token_safety_check for that)", reinforced by the title's "cheaper, no simulation". That gives an explicit when-to-use-this vs when-to-use-the-other rule, which is the strongest form of 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavioral context: no cost, and that results include price, REST endpoint, MCP tool name, example arguments and x402 payment instructions — valuable for a catalog tool with no output schema. It stops short of disclosing result limits, pagination, or ranking 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?

Two sentences with zero filler; the free/cost signal and the search target are front-loaded, and the example list is dense with actionable query vocabulary. The return-value sentence is packed but each clause adds distinct information.

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

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

For a one-param, no-output-schema, well-annotated tool, the description covers purpose, cost, and the shape of returned data. The remaining gap is behavior when the optional query is absent (full-catalog listing vs. error) and whether results are truncated — minor but real for a catalog search.

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 param is documented as "What you need, in a few words". The description goes beyond that by giving concrete query formulations ("honeypot", "transcribe audio", "ocr", "translate", "dns"), which teaches the agent how to phrase a capability query rather than a keyword. It does not address what happens when query is omitted.

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 (search) and resource (DevX catalog of pay-per-call agent tools) plus the search dimension (by capability). The examples ("honeypot", "transcribe audio", "ocr") make it unmistakably distinct from the concrete sibling tools like speech_to_text or translate_text, which perform work rather than discover 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 leading "Free:" signals a cost-based reason to prefer this over paid siblings, and the capability examples imply it is a discovery entry point. However, it never states when to use this versus calling a specific sibling tool directly, nor whether an empty query is valid given 0 required parameters. 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?

Goes well beyond the readOnly/idempotent annotations: it discloses the exact price ($0.002 USDC on Base), the billing exception (images without text are free), the 3 MB limit, and the non-obvious first-call-uncharged payment handshake with the precise retry mechanism. This is the kind of behavior an agent could not infer from annotations or schema alone.

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, then formats, then price/payment, which is a sensible order. It repeats the price twice ('$0.002 USDC per image on Base via x402' and 'Price: $0.002 per image'), which is a small redundancy in an otherwise dense, useful block.

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?

Covers what the tool accepts, limits, output shape (reading-order text vs Markdown tables/lists), and the full payment lifecycle, which is the riskiest part of calling it. With no output schema, describing the return value fills that gap; nothing essential for a correct call 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 67%, and the description adds real meaning: it explains that the format option yields either plain text in reading order or Markdown with tables/lists, and it documents the x402 payment parameter and retry path. It does not mention requestKey idempotency, which is left to the schema, so it is not fully complete.

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

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

States a specific verb and resource ('OCR / image to text / text extraction') plus the exact input classes it handles (screenshots, receipts, invoices, scanned documents, signs, photos) and accepted formats. An agent can immediately tell this is the image-to-text tool and not the speech or web-page 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 gives clear conditions for use (image content types, supported formats, 3 MB cap) and spells out the two-step x402 payment flow (first call returns PaymentRequired, retry with payment in _meta). It stops short of naming alternatives or exclusions, e.g. when to prefer image_to_text_ocr_demo or web_page_to_markdown for URL content.

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 and openWorld, so the safety profile is covered. The description adds genuinely new behavioral facts: the input is a fixed bundled image (so the call takes no user data) and results are cached (so repeated calls are cheap and return identical output). It does not describe the response shape, but that is minor 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?

One short sentence with zero waste; the key differentiators (free, demo, fixed sample, cached) are all front-loaded and none of the words are filler.

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

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

For a parameterless, cached demo tool with no output schema, the definition covers what it operates on and that the input is fixed and cached. The only minor gap is that it never states the output is extracted OCR text, which a reader must infer from the tool name.

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

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

With zero parameters, the baseline is 4. The description reinforces this by stating the input is a fixed sample PNG, making it clear an agent must not attempt to pass an image path or URL to this tool — a useful implicit contract for a demo endpoint.

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 parent tool (image_to_text_ocr) and specifies the demo runs on a fixed sample invoice PNG, which immediately separates it from the real OCR tool and the other *_demo siblings. It stops short of a crisp verb phrase like 'run OCR on a bundled sample image', but the resource and mode are 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?

'Free demo' and 'fixed sample' imply this is for trying the capability without supplying your own image, and the sibling name points to the production tool. However, there is no explicit statement such as 'use when you have no image input; call image_to_text_ocr to process your own image', so the routing decision is left to inference.

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

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

Beyond the annotations, the description discloses input limits (20 min / 10 MB), supported formats, pricing per started minute, that the quote is computed before payment, that failures are not charged, and the first-call x402 payment flow. This is unusually rich behavioral context for a read-only, idempotent, open-world 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 capabilities, then moves into task, pricing, and payment flow. It is information-dense, but the price is stated twice in slightly different form, which is minor redundancy for a payment-related 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?

Given seven parameters, no output schema, and a nontrivial x402 payment workflow, the description covers what the tool returns, input limits, pricing, idempotency benefits, and the first-call payment sequence. An agent has enough context to invoke it correctly without additional documentation.

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 value by clarifying audio_url versus base64 usage, task=translate semantics, and the payment retry parameter path. It reinforces rather than duplicates the schema, though most per-parameter details remain in the schema.

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

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

The description immediately states the specific verb/resource combination: speech to text / transcribe audio / ASR using Whisper large-v3-turbo. It also names supported input formats and returned artifacts, which lets an agent distinguish this from text_to_speech, translate_text, and OCR siblings without opening 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 gives clear usage context: provide an audio URL or base64 audio, use task=translate for English output from any language, and retry with x402 payment after the first PaymentRequired response. It does not explicitly compare against the demo or translate_text siblings, so it stops short of full 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 declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context by noting the sample is fixed, the result is cached, and the visible output includes transcript, segments, and WebVTT shape.

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 distinction, caching behavior, and return-shape summary front-loaded. No sentence is wasted.

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

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

Given the zero-parameter schema, rich annotations, and no output schema, the description is complete enough: it explains the fixed-sample scope, cached behavior, and what output shape the agent can expect.

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, so parameter semantics require no explanation. The description appropriately reinforces that the tool operates on a fixed sample and takes no user-supplied audio.

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 demo action on a named resource: a free demo of speech_to_text using a fixed cached MP3. It distinguishes itself from the sibling speech_to_text tool by making clear this is a fixed-sample demo, and it also names the output areas shown.

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

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

The phrase 'Free demo ... on a fixed sample MP3 (cached)' gives clear usage context: this is for previewing speech_to_text behavior without supplying real audio. However, it does not explicitly say to use speech_to_text instead when real transcription is needed.

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, and the description adds substantial beyond-schema behavior: output is an audio content block, failures are not charged, first call is free, and the exact retry mechanism. This is exactly the kind of payment/auth/return-shape 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?

The core purpose and limits are front-loaded and the description is dense with useful facts. It is slightly over-packed and repeats the price twice ('$0.001 USDC per started 1,000 characters' and 'Price: $0.001 per started 1,000 characters'), costing a little 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?

With no output schema, the description compensates by naming the return format (WAV audio content block) and detailing the payment handshake. For a 4-param, single-required tool, an agent has everything needed to call it and handle the payment retry.

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 decent (75%), and the description supplements it with the language set, the 400-char MCP cap, and how x402_payment/_meta payment must be supplied on retry. The idempotency semantics of requestKey are spelled out in the schema rather than the description, leaving a minor gap.

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 precise verb+resource ('Text to speech / TTS / voice generation (MeloTTS)') and states the exact input languages and output form (WAV voice clip as an audio content block). This clearly separates it from siblings like speech_to_text and text_to_speech_demo.

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 concrete operating context: 400-char limit per MCP call, 2,000 via REST, and the two-step x402 flow (first call returns PaymentRequired, retry with payment in _meta['x402/payment']). It does not explicitly say when to prefer it over text_to_speech_demo, so it stops short of full 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 declare readOnly/openWorld/idempotent/non-destructive, so the safety bar is low. The description still adds real value by disclosing the fixed input, that results are cached, and what the response contains (metadata plus a WAV link), which is not derivable from annotations or the empty 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 short clauses, zero waste, with the identifying fact (demo on a fixed sentence, cached) front-loaded and the return payload last. Nothing to trim.

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-param demo with no output schema, the description covers what it does and roughly what comes back (metadata, WAV link). It doesn't specify the audio format duration, language of the sample sentence, or whether output is a URL vs. inline data beyond 'link', but the essential calling information is present.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no input is needed by describing a fixed sentence, though it does not explicitly say 'takes no arguments'.

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 (text-to-speech demo) and the key differentiator from the sibling text_to_speech: it runs on a 'fixed sentence' that is cached. An agent can tell instantly that this is not the production synthesis call.

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 words 'Free demo' plus 'fixed sentence' imply the intended use case — trying the capability without cost — and implicitly route arbitrary-text synthesis to the text_to_speech sibling. However, it never explicitly states the condition or names the alternative, 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?

Annotations already declare read-only, idempotent, non-destructive, but the description adds the traits that actually matter here: a $0.01 USDC charge on Base via x402, a free initial 402 handshake, and no charge on failed checks. It also discloses the informational/not-financial-advice posture, which annotations cannot express.

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 with the core purpose before the return fields, chains and payment mechanics. Minor waste: the price is stated twice ('$0.01 USDC on Base via x402' and 'Price: $0.01 per token'), and the opening alias list is a touch repetitive.

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 fully by enumerating verdict, risk_score, confidence, reasons, simulated buy/transfer/sell honeypot test, tax percentages, mint/blacklist/pause flags, liquidity and concentration. Payment prerequisites and the idempotency/charging behavior are also covered, leaving nothing an agent needs 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 the baseline is 3, but the description adds the supported chain list with Base as default and documents the alternative payment channel via _meta["x402/payment"] that mirrors the x402_payment parameter. That is meaningfully more than the schema alone conveys.

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 with multiple recognized aliases (honeypot detector, rug pull check, scam token scanner) and names the exact input domain (ERC-20 contract or Solana mint). It also enumerates the verdict shape and every signal returned, so an agent knows precisely what it gets back without opening a 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?

It gives operational context for invocation (first call returns PaymentRequired, retry with payment in _meta) and lists supported chains, but never says when to choose this over the closely overlapping siblings erc20_token_quick_scan or token_safety_check_demo. Usage is implied by the name and feature list rather than explicitly routed.

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 safety profile (readOnly, idempotent, non-destructive, openWorld), so the description adds real context beyond them: the demo is free, it returns a full verdict plus honeypot simulation, and it is restricted to a fixed token set. It omits rate limits or any per-call constraints on the demo, which is the only gap.

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 sentences, front-loaded with the free/limited scope, then the reason to use it. No filler, and the pricing contrast with the paid sibling is compressed into a single clause.

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 signals what the return contains (full verdict + honeypot simulation) so the agent knows the response shape is identical to the paid tool. Complete for a one-param demo; a brief note on whether demo results are cached or rate-limited would close the last 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 0%, so the description must compensate, and it does by enumerating the exact allowed values (USDC, WETH, DEGEN, AERO), which map directly onto the enum. It does not mention the DEGEN default, which is documented in the schema, so it adds meaningful but not exhaustive parameter context.

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 (token safety check) with an explicit scope limitation to four Base tokens, and explicitly positions itself as the free demo variant of token_safety_check. An agent can distinguish it from the paid sibling and from erc20_token_quick_scan 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?

Gives an explicit when-to-use: preview the exact output shape before paying $0.01 for other tokens, and names the alternative (token_safety_check) that applies outside the four-token set. The routing decision is fully determined by 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?

Goes well beyond the annotations (readOnly, idempotent, openWorld): it discloses the 5,000-character cap, the exact price ($0.001 per started 1,000 characters on Base via x402), that failures are not charged, and that the first call is a free PaymentRequired probe. This is exactly the kind of cost/failure/retry context an agent needs before spending money.

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 limits, then pricing and payment mechanics – a sensible order. The price is stated twice ('$0.001 USDC per started 1,000 characters ... Price: $0.001 per started 1,000 characters'), which is one wasted sentence in an otherwise dense block.

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, annotation-covered tool with full schema coverage and no output schema, the description covers cost, retry semantics, size limits and idempotency. It leaves the shape of the successful response (where the translated text appears) unstated, which is the one gap an agent might hit after payment succeeds.

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 still adds value by explaining that source-language detection is automatic (matching the source_lang default) and by clarifying the two-step payment parameter flow via _meta["x402/payment"]. It does not add unit/format detail beyond what the schema notes for requestKey idempotency.

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 ('Translate text / machine translation between 100 languages'), names the underlying model (M2M100 1.2B) and the auto-detect behavior, which is unambiguous. However, it never distinguishes itself from the sibling translate_text_demo, so the agent has no textual basis for choosing between the paid and demo variants.

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 a clear operational sequence for the paid flow (first call returns PaymentRequired, retry with _meta["x402/payment"]), which is genuinely useful call guidance. But there is no guidance on when to choose this over translate_text_demo, nor any exclusion or precondition statement beyond the payment handshake.

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 and open-world, so the safety profile is covered. The description adds genuinely new behavioral facts beyond them: the input is a fixed sample sentence, results are cached, and the call returns representative output shape rather than translating the caller's content.

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

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

A single sentence with no filler, front-loading the 'free demo' qualifier and ending with the payoff (output shape). Nothing is redundant with 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?

For a zero-parameter, read-only demo with rich annotations and no output schema, the description covers everything needed: what it runs on, that it is cached, and that it returns illustrative output. Only a note on demo limitations (e.g., single fixed sentence, no rate/quality guarantees) 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 takes zero parameters, which is the baseline-4 case. The description reinforces this by making clear the sentence is fixed, so an agent won't expect to supply text.

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 action (demo translation) on a specific resource (a fixed sample sentence) and explicitly names the tool it demonstrates, translate_text. An agent can distinguish it from the real translate_text and from the other *_demo siblings 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?

The word 'demo' plus 'free' and the reference to translate_text imply the intended use: previewing behavior before calling the real tool. It does not explicitly say 'use translate_text for actual content' or state any exclusion, so the routing signal is clear but left implicit.

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?

Beyond the annotations (readOnly, idempotent, openWorld), the description discloses the two-step x402 payment handshake, that the first call is not charged, and the exact retry mechanism via _meta['x402/payment']. It does not mention error behavior for unreachable URLs or rate limits, but the paid-flow disclosure is the high-value item an agent cannot infer from the 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 output fields are front-loaded in one dense sentence, followed by the price and payment protocol. Minor waste: the price is stated twice ('$0.001 USDC on Base via x402. Price: $0.001.'), which is redundant rather than harmful.

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 enumerated field list is exactly what an agent needs to know what comes back, and the payment protocol is spelled out sufficiently to complete a paid call. Little an agent requires to invoke this 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 50% and the 'url' parameter has no schema description at all, but the description's context makes its meaning obvious (the URL to preview), and it explains the payment-retry path that the x402_payment schema only partially covers. It adds meaningful signal beyond the structured fields.

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

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

The description opens with a specific verb+resource ('Link preview and SEO metadata for a URL') and enumerates the exact fields returned (HTTP status, final URL, OpenGraph/Twitter tags, JSON-LD, robots), making the scope unambiguous. It does not differentiate itself from the related sibling web_page_to_markdown, which keeps 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?

The payment mechanics double as a usage instruction: the first call is free and returns PaymentRequired, then a retry with payment is expected. However, there is no guidance on when to choose this over web_page_to_markdown or other URL tools, and no note about input constraints such as redirects or unsupported schemes.

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?

Beyond the annotations, the description discloses important behavior: return fields, recipient/minimum-amount semantics, the $0.01 USDC cost on Base, the no-charge first call, and the retry mechanism via _meta["x402/payment"]. These details are essential for invoking a paid verification tool correctly.

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 return behavior, then transitions into payment mechanics. It is generally efficient, but repeats the price twice ('$0.01 USDC on Base via x402. Price: $0.01.') and could be trimmed slightly.

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 carries the burden of explaining returns, and it lists status, confirmations, native value, and decoded USDC transfers. It also explains the payment flow. It could do more on possible status values or error cases, but it is complete enough for an agent to call 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 only 20%, so the description must compensate. It meaningfully explains tx as a tx hash, chain options, and that to plus min_usdc answer whether the recipient received at least that amount; the x402 payment parameter is already described in the schema. It stops short of detailing formats or edge-case behavior for min_usdc and to beyond what the schema provides.

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

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

The description names a specific verb and resource: it verifies a crypto payment/transaction confirmation from a tx hash and returns status, confirmations, native value, and decoded USDC transfers. This clearly distinguishes it from sibling tools like create_crypto_payment_request, crypto_address_validate, and wallet_balances_multichain.

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, including that passing to and min_usdc answers whether a recipient received at least that amount, and it explains the x402 payment flow: first call returns PaymentRequired with no charge, then retry with payment. It does not explicitly compare itself to sibling alternatives or state when not to use it.

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

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 the things they cannot: a concrete price ($0.01 USDC on Base), a payment/auth requirement, and the fact that the first call is free and fails with PaymentRequired. It also discloses the extra per-chain contract-address output, which is not visible any other way.

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

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

Three sentences, front-loaded with what the tool returns, then cost, then the payment handshake. The only waste is the redundant restatement of the price ($0.01 USDC ... Price: $0.01), which repeats information 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?

There is no output schema, so the description carries the return-value burden, and it does name the payload (native balance, USDC balance, is-contract flag, per chain). It stops short of the actual response shape or how a partially failing chain is reported, which keeps it from a 5.

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

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

Schema coverage is 67%, and the description goes beyond the schema by documenting the _meta["x402/payment"] transport path that the x402_payment parameter exists to work around. The chains parameter's default (

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 scope: native and USDC balances of an EVM wallet across five explicitly listed chains, plus a per-chain contract check, all in one call. That is concrete enough to separate it from siblings like token_safety_check or crypto_address_validate 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?

The x402 flow is spelled out procedurally: first call returns PaymentRequired with no charge, then retry with payment in _meta["x402/payment"]. That is real invocation guidance, but there is no statement of when this tool is preferred over the sibling tools that also accept addresses.

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?

Goes well beyond the annotations: it discloses redirect following, robots.txt compliance, content-stripping heuristics, the metadata fields returned, and a prompt-injection warning that page text is third-party data and never instructions. It also surfaces cost ($0.002 USDC on Base) and the exact two-step x402 payment flow, none of which the readOnlyHint/openWorldHint annotations convey.

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

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

Front-loaded with the core capability and the return shape, then the safety caveat, then pricing and the payment flow — a sensible ordering. It loses a point for redundancy: the price is stated twice ('$0.002 USDC on Base via x402. Price: $0.002.') and the parenthetical keyword list (web scraper / html to markdown / reader) adds bulk without adding selection signal.

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 carries the return-value burden and does so by naming title, description, author, date, canonical URL and word count. The paid-call flow is fully explained, which is essential for a 402-gated tool. The remaining gap is max_chars behavior on truncation, which an agent needs 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 coverage is 33% and uneven: x402_payment is fully documented in the schema, url is self-evident, but max_chars (500–100000) is undocumented in both schema and description — the description never says whether it truncates, how truncation is signalled, or that word count reflects the truncated text. The payment mechanics in the description partly compensate for the payment params but not for the length-control param.

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 (read a web page, return clean Markdown) and supports it with concrete behaviors: follows redirects, strips nav/ads/scripts, preserves headings/lists/code/tables. It also enumerates returned metadata, which lets an agent distinguish it from a pure metadata tool. However, it never names url_metadata_link_preview, the closest sibling, so the boundary between 'page content' and 'link preview' is left 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 payment handshake is spelled out precisely (first call returns PaymentRequired with no charge, retry with payment in _meta["x402/payment"]), which is genuinely actionable usage guidance. But there is no statement of when to choose this over url_metadata_link_preview or image_to_text_ocr, and no exclusions (e.g. paywalled or JS-rendered pages). Usage is implied by capability rather than stated as selection criteria.

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