Outcome-first x402 services led by AveDaris Company Intelligence with free task routing on Base.
Scored across 14 tools
Several clusters overlap: search_utilities and network_capabilities both act as catalog discovery for the same paid utilities, and domain_trust_score is a superset of domain_rdap_lookup, email_auth_check and vendor_watch_recheck. vendor_watch_recheck vs vendor_what_changed is also a near-boundary (snapshot vs diff). Descriptions do cross-reference each other explicitly, which keeps most selections recoverable.
Everything is snake_case and consistently domain-prefixed (domain_*, vendor_*, get_*, text_*, web_*), so the family of a tool is obvious. Minor deviation: some are domain_noun ('domain_trust_score', 'vendor_intelligence') while others are noun_verb ('entity_normalize', 'json_repair', 'text_extract_signals'), so the action is not always in the same position.
At 14 tools it sits comfortably in the well-scoped band and each tool maps to a real utility. There is mild redundancy in the meta layer (search_utilities plus network_capabilities, get_utility_details plus get_call_snippet), which keeps it just under a 5.
The surface covers discovery, domain/email vetting, vendor research, change tracking, text extraction and web reading, but the advertised catalog includes many $0.001 primitives (url.parse, uuid.validate, base64, text.slugify) reachable only over raw HTTP, not as MCP tools. There is also no tool to establish or clear the stored baseline that vendor_watch_recheck/vendor_what_changed depend on, and no batch path for domain vetting.
Domain age and registration from public RDAP: registration, expiry and last-changed dates, age in days, registrar, status flags and nameservers. Uncharged if a data source is down. Paid: $0.003 USDC per call via x402 on Base. Calling without payment returns the payment requirement; invalid input is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. example.com. An email address or URL is reduced to its domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that failed data sources are not charged, that the call costs $0.003 USDC via x402 on Base, that an unpaid call returns the payment requirement rather than an error, and that invalid input is free. These billing and failure-path semantics are exactly the kind of context annotations cannot convey and are critical for an agent deciding whether to spend.
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 dense sentences, front-loaded with the returned data, then cost, then edge-case billing. No filler and no repetition of the title or schema.
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?
Although there is no output schema, the description enumerates the return payload fields, the price, the payment-required path, and the free-failure conditions. An agent has everything needed to decide and invoke 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% and the single `domain` parameter is fully documented in the schema, including the email/URL normalization behavior. The description adds no parameter-level detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (look up) and resource (domain age and registration via public RDAP) and enumerates exactly what is returned: registration/expiry/last-changed dates, age in days, registrar, status flags, nameservers. This clearly separates it from the sibling domain_trust_score, which implies a reputation judgment rather than raw registry data.
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 establishes context (public RDAP data) and the billing model, which implicitly frames when the call is worthwhile, but it never states when to prefer this over domain_trust_score or when a lookup is unnecessary. Usage is implied by the returned-field list rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call domain vetting: RDAP age and status, DNS, MX, SPF, DMARC, DKIM and an HTTPS probe combined into a 0-100 score, a low_risk/review/high_risk verdict and reason codes. Uncharged if a data source is down. Paid: $0.01 USDC per call via x402 on Base. Calling without payment returns the payment requirement; invalid input is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. example.com. An email address or URL is reduced to its domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, openWorld, non-destructive), the description discloses pricing ($0.01 USDC via x402 on Base), no-charge failure modes (data source down, invalid input), and the payment-required response when unpaid. These are exactly the auth/cost behaviors 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?
Two sentences, front-loaded with what the tool does and followed by commercial/failure terms. Dense but every clause carries operational value; the enumerations are long but necessary for scope.
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 carries most of that burden by naming the score range, verdict levels, and reason codes, plus pricing and error semantics. Only gap is that the reason codes themselves are not illustrated or enumerated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and the schema description fully documents it (accepts domain, email, or URL and normalizes to domain). The description adds no parameter-level detail beyond the schema, so the 100%-coverage 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?
States a specific verb ('vetting/scoring') and resource (domain) and enumerates exactly what is combined (RDAP age/status, DNS, MX, SPF, DMARC, DKIM, HTTPS probe) into named outputs (0-100 score, verdict, reason codes). The phrase 'one-call' distinguishes it from single-source siblings such as domain_rdap_lookup or email_auth_check.
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?
'One-call domain vetting' implies this is the aggregate alternative to calling individual lookups, and the cost/payment clauses tell the agent what to expect. There is no explicit 'use this instead of X when Y' routing statement, but the context is clear enough to select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a sending domain's MX, SPF, DMARC and DKIM (common selectors) over public DNS and get pass/weak/missing per check, findings and a 0-100 score. No mail is sent. Uncharged if a data source is down. Paid: $0.003 USDC per call via x402 on Base. Calling without payment returns the payment requirement; invalid input is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. example.com. An email address or URL is reduced to its domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world behavior, and the description adds substantial context beyond that: no mail is actually sent, results are uncharged if a data source is down, payment is $0.003 USDC per call via x402 on Base, an unpaid call returns the payment requirement, and invalid input is not billed. That is exactly the billing and failure-mode transparency an agent needs before invoking a metered 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?
Two dense sentences that are front-loaded with the core action and output, followed by behavioral and pricing caveats. Every clause carries information, though the billing details make it slightly packed for a single-parameter 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?
There is no output schema, but the description compensates by naming the per-check verdicts, findings, and 0-100 score. Combined with annotations covering the safety profile and explicit payment/failure semantics, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'domain' parameter is fully described in the schema, including the reduction of an email address or URL to its domain. The description only echoes this via 'a sending domain', adding 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?
States a specific verb (Check) plus the exact resource dimensions (MX, SPF, DMARC, DKIM over public DNS) and the output shape (pass/weak/missing per check, findings, 0-100 score). This is clearly distinct from siblings like domain_rdap_lookup or domain_trust_score, which cover registry data and reputation rather than DNS mail authentication.
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 framing context — checks are performed over public DNS, no mail is sent, and it works on a domain derived from an email or URL. It does not, however, explicitly say when to prefer this over sibling tools like domain_trust_score, so the routing guidance is implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalize an organization or entity name into a deterministic canonical form and tokens for matching and dedupe. Paid: $0.005 USDC per call via x402 on Base. Calling without payment returns the payment requirement; invalid input is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Organization or entity name, e.g. Acme, Inc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them by disclosing the paid model ($0.005 USDC per call via x402 on Base) and the failure semantics: an unpaid call returns the payment requirement, and invalid input is not charged. It stops short of describing the exact response shape (e.g. how tokens are returned), which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what the tool does, then cost, then edge-case billing behavior. Every sentence adds information an agent needs and nothing is repeated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema tool, the description covers purpose, cost, and error/charging behavior — enough to invoke it correctly. The only shortfall is the absence of any indication of the returned structure beyond the words 'canonical form and tokens'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter with 100% schema description coverage, so the schema already carries the burden; the description adds no syntax detail but its wording ('organization or entity name') is consistent with the schema example. Baseline 4 applies for a one-parameter tool with full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (normalize an organization/entity name) plus the concrete output intent (deterministic canonical form and tokens for matching/dedupe). None of the sibling tools overlap with this, so an agent can select it unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for matching and dedupe' implies the intended use case but never states when to use this versus an alternative or any prerequisite conditions. No sibling covers normalization, so the missing routing guidance is a mild rather than fatal gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free and read-only; never charges or sends a request. Returns the x402 payment steps plus curl and JavaScript that call the chosen utility with a working example body over HTTP.
| Name | Required | Description | Default |
|---|---|---|---|
| utility | Yes | Utility id, route key, path or full URL, e.g. vendor.intelligence, json-repair, /v1/paid/dns-lookup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and non-destructive, but the description adds genuinely important context: it never charges and never sends a request, which disambiguates the otherwise alarming 'paid request' framing. Saying it uses a working example body over HTTP also shapes expectations about output. No auth or rate-limit detail, but the key behavioral risk is addressed.
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 sentence, front-loaded with the safety-critical caveat ('Free and read-only; never charges or sends a request') before the return description. No wasted words.
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 describing the return value, and it does so: payment steps, curl, JavaScript, example body. Minor gap around error behavior for an unrecognized utility id, but everything needed to call it correctly 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 100% and the single `utility` parameter is fully documented with examples in the schema. The description only refers to 'the chosen utility' without adding accepted-format guidance beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: it returns x402 payment steps plus curl and JavaScript snippets for a chosen utility. The 'ready-to-run / working example body' framing makes the output concrete. It doesn't explicitly differentiate itself from get_utility_details or search_utilities, but the deliverable (runnable code) is distinctive enough to be recognizable.
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 executable code for a paid utility rather than metadata. There is no explicit statement of when to prefer this over get_utility_details or how to follow up after obtaining the snippet, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free and read-only; never charges. Use after search_utilities to see everything needed before paying: method, URL, price, payment terms, input fields, a valid example body and an example output.
| Name | Required | Description | Default |
|---|---|---|---|
| utility | Yes | Utility id, route key, path or full URL, e.g. vendor.intelligence, json-repair, /v1/paid/dns-lookup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, and the description adds that the call is free and never charges. It also lists the information returned, though it does not discuss auth or rate limits, so it is meaningfully additive but not exhaustive.
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 key safety and cost traits, then usage and returned content. There is no padding 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 one-parameter read-only details tool, the description covers cost, safety, relationship to search_utilities, and the returned contract fields. With no output schema, listing those returned fields is especially useful and sufficient.
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 utility parameter already documents ids, route keys, paths, and full URLs with examples. The description adds no further parameter semantics beyond the schema baseline.
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 gives a specific verb and resource: get a utility's full contract, including method, URL, price, payment terms, input fields, and examples. It also distinguishes this details call from search_utilities, so an agent can tell what this tool is for without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this after search_utilities and explains the condition: to see everything needed before paying. That names the relevant alternative and gives a clear selection context for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repair common malformed JSON (single quotes, trailing commas, unquoted keys) and return valid structured JSON. Paid: $0.005 USDC per call via x402 on Base. Calling without payment returns the payment requirement; invalid input is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Malformed JSON text to repair, e.g. {'hello':'world',} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: pricing ($0.005 USDC per call via x402 on Base), what an unpaid call returns (the payment requirement rather than an error), and that invalid input is not charged. These are exactly the operational facts an agent needs and none are expressed in 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?
Three short sentences: capability first, payment second, error semantics third. No filler, no repetition of the title, and the most decision-relevant clause (price) is front-loaded in sentence two.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers purpose, return shape ('valid structured JSON'), cost, and failure-billing behavior, which together answer every question an agent would have before invoking it.
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 parameter already carries an example of malformed input, so the schema does the explanatory work. The description adds no further constraint or format detail about the input string, which is the baseline case.
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 ('Repair ... JSON') and enumerates the concrete malformation classes it handles (single quotes, trailing commas, unquoted keys), which no sibling tool touches. An agent can identify the capability without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples of malformations give clear context for when this applies, and the input example reinforces it. It does not name an alternative or an exclusion (e.g., when to use a general parser instead), 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.
Free. Find the right paid AUN utility for a task and get its x402 HTTP path and price. Covers all public utilities, including vendor.intelligence (company research, company lookup, vendor checks, supplier and KYB pre-screening from public web evidence, $0.04; also a paid MCP tool, vendor_intelligence) and $0.001 primitives (json.validate, url.parse, text.slugify, email.normalize, uuid.validate, base64, querystring). Example: {"task":"research a vendor company website"}. Omit task for the full catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | Plain-language job to do, e.g. repair this JSON or research a supplier company. Omit to list all utilities. | |
| budgetUsd | No | Optional maximum price per call in USD, e.g. 0.01. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: it is free to call, it returns routing data (x402 path) plus per-call price, and it enumerates catalog contents including price points. It stops short of describing the response shape or whether results are ranked.
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 'Free. Find the right paid AUN utility…' is well front-loaded. But the long parenthetical enumerating eight $0.001 primitives (json.validate, url.parse, text.slugify, …) is catalog inventory that doesn't help an agent select or invoke the tool and crowds out more useful routing 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?
With no output schema, the description must carry the return-value burden and does so partially: it says you get an x402 HTTP path and a price. It doesn't say what the response container looks like (single match vs ranked list, field names), though for a two-param, no-required-param lookup that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both params are self-documented, so baseline is 3. The description earns an extra point by supplying a worked example value ({"task":"research a vendor company website"}) that shows the expected phrasing of a plain-language task, which the schema only gestures at.
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 — find a paid AUN utility and return its x402 HTTP path and price — which is more concrete than a generic search. However, it never distinguishes itself from the sibling search_utilities or get_utility_details, which look like direct competitors for the same job, so an agent can't tell from the text alone which to 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?
Gives one concrete usage rule — 'Omit task for the full catalog' — and an example task phrasing, which helps. It offers no guidance on when to choose this over search_utilities or get_utility_details, and no exclusion criteria, leaving sibling selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free and read-only; never charges. Start here to pick one of the public paid utilities for a job. Returns ranked matches with id, method, URL, price and a one-line summary. Leave task empty to list every utility.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | Plain-language job, e.g. check a supplier company or fix broken JSON. Empty lists all. | |
| limit | No | Maximum results, default 10. | |
| maxPriceUsd | No | Only return utilities at or below this price per call, e.g. 0.005. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description could coast; instead it adds non-obvious context — the search is free/never charged while the utilities it returns are paid per call. It also previews the response fields (id, method, URL, price, summary), which annotations cannot convey. No contradiction with the read-only annotation.
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 short sentences, front-loaded with the free/read-only guarantee and the 'start here' routing cue, then the return shape, then the empty-task special case. Nothing is 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?
There is no output schema, and the description compensates by listing the returned fields, so an agent knows what comes back. Remaining gaps are minor: no statement about ranking semantics or the default result count (both partly covered by the schema's limit 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%, so task/limit/maxPriceUsd are already documented with examples and defaults. The description's only parameter-related sentence ('Leave task empty to list every utility') restates what the schema's task description already says. Baseline 3 is correct.
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 ('search/rank utilities') and states its role in the flow: 'Start here to pick one of the public paid utilities for a job.' That phrasing cleanly separates it from siblings like get_utility_details, which is the follow-up, and from the various lookup/check 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 an explicit entry-point instruction ('Start here') plus one concrete usage rule ('Leave task empty to list every utility'). It stops short of naming an alternative or a 'do not use for X' exclusion, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract URLs, emails, money amounts, and ISO dates from free text as structured lists. Paid: $0.008 USDC per call via x402 on Base. Calling without payment returns the payment requirement; invalid input is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to scan, e.g. Email ops@example.com on 2026-08-30 about $25. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely non-schema information: the $0.008 USDC x402 payment flow on Base, the unpaid-call response, and the no-charge-on-invalid-input policy. It stops short of describing output list structure or limits on extracted item counts.
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, zero filler. The functional statement comes first and the payment/error behavior second, which is the right priority order for an agent deciding whether to call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, non-destructive extraction tool with no output schema, the definition covers purpose, cost, and failure modes adequately. A brief note on the returned list shape (e.g. whether matches keep positions or context) 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?
With a single parameter at 100% schema description coverage, the schema already carries the meaning and even includes an illustrative example. The description adds only that the text is scanned for the four entity types, which is marginal value over 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 ('Extract') and enumerates the exact resources produced (URLs, emails, money amounts, ISO dates) from free text, plus the output shape ('structured lists'). It is clearly distinguishable in practice from siblings like entity_normalize or json_repair, though it never names a sibling 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?
Gives useful operational context about payment: cost per call, that unpaid calls return the payment requirement, and that invalid input is free. However, it offers no guidance on when to choose this over related siblings (entity_normalize, email_auth_check) or what input shape works best; usage is only implied by the resource list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Company research and vendor due diligence: send a company name and official website, get a sourced profile (summary, official-site facts, public contact emails, recent mentions, evidence score, sources, limitations) for company lookup, supplier checks and KYB pre-screens from public web evidence. Not legal identity, credit or registry data. Paid: $0.04 USDC per call via x402 on Base. Calling without payment returns the payment requirement; invalid input is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Company name, e.g. Example, Inc. | |
| objective | No | Optional research question, e.g. Is this a legitimate supplier of industrial pumps? | |
| websiteUrl | Yes | Official http(s) website, e.g. https://example.com/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing pricing ($0.04 USDC via x402 on Base), the no-payment behavior (returns payment requirement, no charge), and the invalid-input billing exemption. It also frames the evidence basis ('public web evidence') and its limitations, which annotations alone cannot 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?
Two dense sentences, front-loaded with purpose and output contents before payment mechanics. Every clause carries information an agent needs and none is redundant with the schema.
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 supplies the return shape (summary, official-site facts, emails, mentions, evidence score, sources, limitations), the evidence basis, the exclusions, and the paid-call mechanics. Nothing material for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents name, websiteUrl and the optional objective. The description only echoes that name and website are the inputs sent, without adding format or usage detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Company research and vendor due diligence: send a company name and official website, get a sourced profile') and enumerates the returned artifacts. The line 'Not legal identity, credit or registry data' cleanly separates it from registry-oriented siblings such as domain_rdap_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names concrete use cases (company lookup, supplier checks, KYB pre-screens) and explicit exclusions (not legal identity, credit or registry data). It does not name a specific alternative tool to use instead, which keeps it just below the top mark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fresh public snapshot of a supplier domain (site up/down and redirect host, registrar, registry status, DNS, MX/SPF/DMARC, trust verdict) plus whether anything changed since the last stored check. Use vendor_what_changed for the full diff. Uncharged if a data source is down. Paid: $0.005 USDC per call via x402 on Base. Calling without payment returns the payment requirement; invalid input is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Supplier domain, e.g. example.com. An email address or URL is reduced to its domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description adds what they cannot: pay-per-call pricing, the payment protocol, a no-charge guarantee when a data source is down, and the behavior of an unpaid or invalid call. This is exactly the billing/failure context an agent needs before invoking a paid endpoint.
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 return payload is front-loaded and the alternative-routing and pricing details follow in short sentences. The parenthetical enumeration is dense but every item is informational; only minor tightening is possible.
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 full burden of describing returns and does so by listing the snapshot fields and the changed-since-last-check flag. Combined with pricing and failure-charging behavior, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema itself documents the normalization behavior ('An email address or URL is reduced to its domain'). The description adds nothing about the domain parameter, so it neither compensates nor detracts; 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 ('fresh public snapshot of a supplier domain') and enumerates exactly what the snapshot covers (site status, registrar, DNS, MX/SPF/DMARC, trust verdict) plus a change flag. It also explicitly distinguishes itself from the sibling vendor_what_changed, so an agent can route 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 names the alternative explicitly ('Use vendor_what_changed for the full diff'), giving a clear conditional for choosing between the two. It does not address the other nearby siblings (vendor_trust_score, domain_rdap_lookup, email_auth_check) that overlap in coverage, so the routing guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every field that changed at a supplier domain since the previous stored check, with before/after values and high/medium/low severity, a one-line summary, recent change history and a fresh snapshot. Public signals only. Uncharged if a data source is down. Paid: $0.01 USDC per call via x402 on Base. Calling without payment returns the payment requirement; invalid input is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Supplier domain, e.g. example.com. An email address or URL is reduced to its domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: scope limited to public signals, no charge when a data source is down, $0.01 USDC per call via x402 on Base, unpaid calls return the payment requirement, and invalid input is free. These are exactly the billing and failure-mode facts an agent needs before invoking a paid endpoint, and nothing contradicts readOnlyHint/destructiveHint.
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?
Four tight sentences with the payload described up front and pricing pushed to the end where it belongs. The opening sentence is a long noun phrase without a main verb, which slightly slows parsing, but no sentence is 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?
With no output schema, the description does the work of enumerating return fields, and it fully covers the payment path. The remaining gap is the baseline dependency: it never says what happens on a first call with no prior stored snapshot, which is material for a diff-style 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?
Single parameter with 100% schema description coverage, and the schema already explains domain normalization (email address or URL reduced to its domain). The description adds no additional meaning about the domain argument, 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?
Concrete verb-and-resource: reports every field that changed at a supplier domain since the previous stored check, and enumerates the payload (before/after values, severity, summary, history, snapshot). It implicitly separates itself from vendor_watch_recheck and vendor_intelligence via the 'previous stored check' framing, though it never names the sibling that produces that stored baseline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase 'since the previous stored check' hints that a prior check must exist, but the description never states that prerequisite or says when to use this versus vendor_watch_recheck or vendor_intelligence. No exclusions or alternatives are given, so the agent must infer routing from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read up to 5 public URLs in one call. Each URL returns its own status, final URL, title, main content as Markdown, truncated flag, byte and char counts and error code; one failing URL never fails the rest. Not charged if no URL can be read. Paid: $0.015 USDC per call via x402 on Base. Calling without payment returns the payment requirement; invalid input is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | 1 to 5 public http(s) URLs, e.g. ["https://example.com/"]. | |
| maxCharsPerUrl | No | Optional Markdown cap per URL, default 8,000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it enumerates per-URL return fields (status, final URL, title, Markdown, truncated flag, byte/char counts, error code), states partial-failure isolation, and details the x402 payment model, price, and the two no-charge cases. That is exactly the kind of operational context annotations cannot carry.
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 batch capability is front-loaded in the first clause, followed by return shape, failure semantics, and billing in descending order of importance. No sentence is redundant with another.
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 supplies the return structure itself, plus billing and partial-failure behavior. An agent has everything needed to call it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including the 1-5 URL range and the 8,000 default char cap. The description only restates the 5-URL ceiling and does not add format or interaction guidance for maxCharsPerUrl.
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 (Read), resource (public URLs), and a hard scope limit (up to 5 in one call). No sibling tool in the list performs page fetching, so the batch-read identity is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'public URLs' wording implicitly excludes authenticated/intranet targets and the batch framing implies multi-URL use, but the description never says when to prefer this over a single-URL read or names an alternative. Usage context is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
vendor_watch_recheckvendor_what_changedweb_read_batchdomain_rdap_lookupdomain_trust_scoreemail_auth_checkvendor_intelligenceentity_normalize1 field changedInput schema / properties / name / descriptionAdded value: +"Organization or entity name, e.g. Acme, Inc."get_call_snippetget_utility_detailsjson_repair1 field changedInput schema / properties / input / descriptionAdded value: +"Malformed JSON text to repair, e.g. {'hello':'world',}"network_capabilities2 fields changedInput schema / properties / budgetUsd / descriptionAdded value: +"Optional maximum price per call in USD, e.g. 0.01."Input schema / properties / task / descriptionAdded value: +"Plain-language job to do, e.g. repair this JSON or research a supplier company. Omit to list all utilities."search_utilitiestext_extract_signals1 field changedInput schema / properties / text / descriptionAdded value: +"Text to scan, e.g. Email ops@example.com on 2026-08-30 about $25."entity_normalizejson_repairnetwork_capabilitiestext_extract_signalsMade-to-order data for AI agents: company intel, B2B contacts, scraping. Pay per call via x402.
x402-paid analytics, market intelligence, research, and LLM inference for AI agents.
Machine-paid revenue intelligence, recovery decisions, and x402 routing for AI agents.
Agent trust, pre-purchase risk, deliverable checks, data and SEO tools. Pay per call via x402.
Add one secure layer between your agents and this server.