MoneyTools x402 agent toolkit

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), so the description earns credit for disclosing what those annotations cannot: the three-tier verdict valid|risky|invalid, the paid HTTP endpoint /v1/email-check, the requirement to send an X-API-Key header, and the cost of 1 credit per successful call. The bulk of payment and referral prose dilutes but does not contradict this useful context.

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

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

The first sentence is tight and front-loaded, but the remainder is dominated by monetization material: x402 credit pack pricing, API-key plumbing, and a long referral program clause with revenue-share, settlement timing, and an earnings lookup URL. Most of that does not help an agent decide to call or call the tool correctly, and the referral paragraph is entirely irrelevant to invocation.

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

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

For a single-parameter validation tool with an output schema present, the definition covers purpose, method (no SMTP), and verdict semantics adequately; return fields need not be restated. The gaps are around failure modes and whether credits are required for the MCP call specifically versus the paid HTTP route, which the mixed framing leaves ambiguous.

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

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

Only one parameter exists and its schema description coverage is 100%, so the baseline is 4. The description adds nothing about the email parameter's expected format beyond the schema, but nothing is lost either.

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 (validate an email address) and enumerates exactly what is checked: syntax, domain existence, MX/null-MX, SPF, DMARC, disposable domains, role accounts, free providers, typo suggestion. The explicit 'without sending mail or SMTP probing' clause further pins down what the tool is and is not, and no sibling tool overlaps this function.

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

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

The 'without sending mail or SMTP probing' phrasing implies the appropriate use case (address verification rather than delivery testing), but there is no explicit when-to-use, when-not-to-use, or alternative named. Given the sibling list contains unrelated payment/mint/web tools, that omission is minor, yet the guidance remains implied rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely non-obvious operational context: it is a paid HTTP endpoint (/v1/sol-mint), requires an X-API-Key header on the MCP POST, and costs 1 credit per successful call with no demo limit for prepaid credits. The referral-earnings paragraph adds nothing an agent needs to invoke the tool and dilutes this.

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

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

The first two sentences are well front-loaded and contain everything needed to select and call the tool. The remainder is promotional bulk: x402 pack pricing, credit mechanics, and a long referral clause with revenue-share percentages, settlement cadence, and a separate endpoint — content that does not help an agent decide to invoke this 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?

An output schema exists, so return values need not be re-explained, and for a one-parameter read-only check the description covers purpose, scope, cost, and auth. It is sufficiently complete to call correctly; the only surplus is referral material that adds no operational completeness.

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

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

There is a single required parameter with 100% schema description coverage ('Solana mint address (base58)'), so the schema already carries the semantics. The description mentions mint authorities but does not clarify the input format, whether Token-2022 mints are accepted identically, or how to obtain the address — baseline 3 applies when the schema does the work.

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 ('Rule-based safety check of a Solana SPL / Token-2022 mint') and enumerates exactly what is examined: mint & freeze authority, permanent delegate, transfer hook/fee, pausable, default-frozen, largest-holder concentration. The returned riskScore and verdict are named, and the subject matter is unmistakably distinct from siblings like email_check or web_read_markdown.

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 domain — an agent inspecting a Solana mint knows this is the relevant tool — and the paid-endpoint details suggest the context is programmatic risk screening. But there is no explicit 'use this when X, not Y' guidance, no statement of when a check is unnecessary, and no comparison to the x402_* siblings that also gate payment flows.

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 the safety profile is covered. The description adds genuinely useful behavior: robots.txt compliance, public-page restriction, a 1h cache, sha256 of content, and that it costs 1 credit per successful call with an X-API-Key requirement. However, these signals are buried inside a large block of payment/referral prose, which dilutes their utility.

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

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

The first sentence is well front-loaded, but the remainder is a run-on block of pricing packs, x402 purchase URLs, credit accounting, and a referral program with settlement terms—content that does not help an agent invoke this MCP tool and actively obscures the operationally relevant facts.

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?

An output schema exists, so return-value explanation is unnecessary, and the two parameters are documented in the schema. The core operation plus auth and robots constraints make the definition functionally complete, but the heavy promotional noise and absent failure-mode guidance (e.g., non-public URLs, credit exhaustion) leave real gaps.

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

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

Schema description coverage is 100%, so both `url` and `maxChars` (with its 500-100000 range and default) are already fully documented in the schema. The description adds no additional semantics about parameter behavior, 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 opening sentence names a specific verb and resource ('Fetch a public web page and return clean Markdown') and even enumerates the structural elements preserved (title, headings, links, lists, code) plus a sha256 of the content. Siblings are all unrelated (email, solana, x402 payment utilities), so no differentiation is needed, but the scope qualifiers 'public pages only' and 'Respects robots.txt' sharpen purpose further.

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 states a constraint ('public pages only') but never says when an agent should choose this over any alternative, nor what to do when a page is non-public or robots-disallowed. The rest of the text describes billing mechanics rather than usage selection, leaving only an implied 'use this to read a web page'.

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 readOnly/idempotent annotations, the description discloses critical behavior: non-custodial funds, seller OFAC screening, gateway fee formula, charging only on seller 2xx responses, prepaid-credit requirements, and API-key header usage. These details materially affect whether and how an agent should use the 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 main purpose and critical payment behavior are front-loaded, but the description is dense and includes lengthy credit-pack and referral-program details that are not essential for selecting or invoking this tool. It would benefit from trimming operational/marketing details into referenced docs.

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

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

Given the tool has an output schema, the description does not need to fully explain return values, yet it still summarizes gatewayUrl, price, and fee. It also covers the non-custodial model, prepaid credits, API-key requirement, and charging conditions, leaving little ambiguity for invocation.

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

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

Schema coverage is 100%, and the schema already documents both url and method. The description adds context about the seller endpoint being prechecked, but does not add syntax or semantics for the method parameter beyond what the schema provides.

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

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

The description clearly states the tool prechecks an x402 seller and returns the gatewayUrl, price, and gateway fee. However, its overlap with the sibling x402_precheck is not explicitly addressed, so an agent may not immediately see why it should choose this tool over the raw precheck.

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: call this before paying an x402 seller through the MoneyTools Pay Gateway, then call the returned gatewayUrl with X-API-Key. It does not explicitly exclude alternatives or explain when to use x402_precheck or x402_recommend instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds useful behavioral context beyond that: it performs a network fetch, validates five specific 402 fields, screens against an OFAC list, and returns one of four verdicts. It also discloses the credit/auth model, though the referral details are not relevant to invoking the 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 purpose is front-loaded effectively in the first sentence, but a large portion of the description is promotional content about prepaid credits, pricing packs, and a referral program. That material does not help an agent select or invoke the tool and dilutes an otherwise clear definition.

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?

An output schema exists, so return values do not need full explanation, and the annotations cover the safety profile. The description is functionally complete for a simple two-parameter pre-check tool, but it spends space on pricing and referrals while omitting more relevant details such as behavior on unreachable endpoints or caching.

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

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

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description clarifies that the URL is the endpoint the user plans to pay and that payment fields like scheme, network, payTo, amount, and asset are checked, but it adds little parameter-level 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 verb and resource: fetch an x402 endpoint, validate its HTTP 402 payment requirements, and screen payTo against OFAC SDN. The pre-payment framing distinguishes it implicitly from x402_verify_settlement, though no sibling is named explicitly. The core purpose is clear despite the later promotional material.

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 opening phrase 'Before paying an x402 endpoint' gives a clear triggering condition for when to use this tool. It does not state when not to use it or name alternatives such as x402_verify_settlement, so it falls 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?

Annotations already declare readOnly, idempotent, openWorld, so the safety profile is covered; the description adds real behavioral context beyond that — live unpaid probes returning valid x402 terms, OFAC screening of payTo, top-3 pre-checking, and a 1-credit-per-successful-call cost model. The credit/header paragraph is genuinely useful operational detail, though the referral program text is monetization marketing rather than behavior of this 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?

The purpose is correctly front-loaded in sentence one, but the majority of the text is a prepaid-credit pitch and a referral revenue-share program (20% of net revenue, off-chain ledger, monthly settlement, manual review, min 1 USDC, earnings endpoint) that does not help an agent select or invoke this tool. That material belongs in docs, not the tool definition.

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 an output schema present and full parameter coverage, the return values need not be explained, and the ranking/credit behavior is covered. However, the description leaves the non-prepaid path ambiguous ('No demo limit with prepaid credits' implies a limit exists without them, but never states what it is or what happens on 402/credit exhaustion), while spending space on referral details.

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 task, limit, network, and maxPrice, establishing a baseline of 3. The description adds nothing about parameter meaning — it never clarifies accepted CAIP-2 network formats, how maxPrice interacts with ranking, or what a higher limit costs in credits.

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

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

The opening sentence gives a specific verb and resource: 'Find which x402 paid service to call for a task', and the second sentence names the ranking signals (relevance, liveness, latency, price). It stops short of differentiating from siblings such as x402_precheck and x402_gateway_plan, even though 'top 3 freshly pre-checked' gestures at the relationship without explaining it.

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

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

Usage is only implied: an agent can infer this is the discovery step before paying a service, but there is no explicit when-to-use versus x402_precheck, x402_verify_settlement, or x402_gateway_plan. No exclusions or prerequisites for calling it are stated beyond the credit/header mechanics.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description usefully adds that one credit is charged per successful call and that an X-API-Key header is required on the MCP POST. However, the long referral-program paragraph is unrelated to how the tool behaves on invocation.

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 opening sentence is well front-loaded, but roughly half the description is billing and referral-program marketing (credit pack endpoints, 20% revenue share, monthly settlement, minimum payout). That material does not help an agent decide to call or correctly invoke the tool and crowds out genuinely useful guidance.

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 verification intent, inputs, and verdict values are covered, and an output schema exists so return shapes need not be explained. What is missing is sibling differentiation and any note on confirmation depth beyond the schema default, which matters for a pending-state verification 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 description coverage is 100%, so all seven parameters are already documented in the schema, including the network enum and the exact/atLeast match mode. The description restates the network list and the amount/payTo check but adds no syntax or edge-case detail beyond the schema, so the baseline of 3 applies.

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

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

The first sentence gives a specific verb and resource ("Verify an on-chain USDC settlement") plus the conditions checked (tx hash, network, paid amount to payTo) and the return values (valid|invalid|pending|not_found). It does not distinguish this tool from the sibling verification tools (x402_precheck, x402_gateway_plan), so it falls short of a 5.

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

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

There is no guidance on when to use this versus x402_precheck or x402_gateway_plan, which are plausible alternatives for an agent checking payments. The only contextual information is commercial (prepaid credits, API key header), which is an access prerequisite rather than usage guidance.

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