x402-paid analytics, market intelligence, research, and LLM inference for AI agents.
Scored across 79 tools
Many tools have overlapping purposes: multiple routing tools (agentcore_route, route_task, mpp_route), multiple Base transfer tools (base_transfer_search, base_transfer_search_rpc), multiple batch extraction tools (batch_extract, batch_url_json, x401_batch_extract), and multiple Bazaar market analytics tools (bazaar_pulse, bazaar_market_report, bazaar_category_heat). Several groups of tools appear to do essentially the same thing with only minor differences in price or packaging. An agent would struggle to select reliably without reading every description.
All tool names use snake_case consistently, with domain prefixes like base_, bazaar_, x402_, and solana_ that aid grouping. However, the naming pattern is not uniformly verb_noun; many are noun phrases (sentiment, inference, market_intel) while others are verb_noun (classify_text, extract_json). This minor deviation from a strict action-oriented pattern keeps it from a perfect score.
With 79 tools, this server far exceeds any practical MCP surface, creating severe selection overload for agents. The vast majority are niche paid microservices, many of which are redundant variations of the same capability. This is an extreme mismatch for a coherent tool set.
The tool surface spans many domains (blockchain data, market analytics, text processing, people search, web extraction, routing), so it is broad. However, it lacks cohesive lifecycle operations and a unified discovery mechanism, and the heavy redundancy means some real gaps (e.g., listing management, cross-service orchestration) are obscured. Agents can work around many missing pieces, but the surface is not cleanly complete.
Task router over paid agent services; free top-1 recommendation or paid $0.01 ranked top-three with ghost-bid counterfactual pricing, qualified handoff and receipt binding. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| max_price | Yes | ||
| price_cap | No | ||
| constraints | No | ||
| output_format | No | ||
| preferred_rail | No | ||
| prior_bid_atomic | No | ||
| seller_delivery_receipt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must carry full burden. It does disclose the cost model ($0.01/call via x402), the free/paid behavior difference, and mentions problem-aware behaviors like ghost-bid counterfactual pricing, handoff, and receipt binding. Yet it does not cover rates on limits, what happens if pay/latencies, how constraints or rail choices behave, or error/refund scenarios, leaving agents without complete behavioral predictability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, front-loaded sentence or two that quickly establishes router identity, the free/paid distinction, and the cost. No filler or redundant restating. It is slightly run-on but stays within the constraints of a high-signal description.
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 8 parameters, no output schema, and no annotations, the description should cover far more. It explains the business model and gives strong top-level facts, but leaves foundational operational semantics (what 'qualified handoff' does, how price caps function, what 'receipt binding' means in practice, and what the response looks like) unstated, making it incomplete for a tool this complex.
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%, and the description has no meaningful parameter docs. It never maps max_price or price_cap boundaries, does not define constraints, ignored output_format and preferred_rail, and silently relies on opaque fields like prior_bid_atomic and seller_delivery_receipt. The only related hint is that costs $0.01, which is not enough to set parameters correctly for an 8-field tool with no schema commentary.
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 is a 'task router over paid agent services' and gives strong specifics: free top-1 vs paid $0.01 ranked top-three, ghost-bid counterfactual pricing, qualified handoff, receipt binding, and the x402 rail. It does not name or explicitly contrast with siblings like route_task or mpp_route, but the unique pricing/model details make its identity reasonably distinct.
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 context is only implied: an agent can infer that a free route gives a single top recommendation and paying $0.01 gives a ranked top-three, with tie-ins to ghost-bid pricing and receipt binding. However, there is no explicit 'when to use this versus the alternate router' guidance, and it does not mention alternatives such as route_task or mpp_route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select up to five proven time, Base, wallet-balance and x402 verification utilities in one preflight bundle with statuses, evidence hash and bundle ID. $0.005/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Base/EVM wallet address to inspect | |
| include | No | Compatibility alias for components | |
| chain_id | No | Compatibility chain identifier | |
| endpoints | No | Compatibility list; first URL is used by endpoint_verify | |
| components | No | Utilities to run; defaults to all five | |
| endpoint_url | No | HTTPS x402 endpoint for endpoint_verify | |
| wallet_address | No | Compatibility alias for wallet | |
| endpoint_request | No | Optional request descriptor for endpoint_verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the call produces statuses, an evidence hash, a bundle ID, and costs $0.005 via x402, which is useful. However, it does not mention whether the operation is read-only, how evidence is generated, whether external endpoints are contacted, or any authentication or rate-limit implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence conveys the core bundling behavior and outputs, and the second adds pricing and payment mechanism. The word 'proven' is mild filler, but overall every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively complex tool with 8 parameters, nested objects, compatibility aliases, and no output schema, yet the description provides only a high-level summary. It does not explain the relationship between alias parameters and canonical ones, the meaning of the components enum, how endpoint_verify uses the endpoint URL, or what the returned evidence hash and bundle ID represent. The missing details are significant for correct 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 description coverage is 100%, so the baseline is 3 even though the description itself adds little per-parameter meaning. Some schema fields are only described as 'Compatibility alias' or 'Compatibility identifier,' which is weak, and the main description only hints at the utility categories without mapping them to parameters like components, endpoints, or wallet_address.
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 clear verb and resource: it selects up to five verification utilities in one preflight bundle, covering time, Base, wallet-balance, and x402 checks. The bundle framing distinguishes it from the many single-utility siblings like base_block_number or x402_endpoint_verify, though it does not explicitly name an alternate tool an agent might confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. The phrase 'preflight bundle' implies a pre-check use case, but the agent is left to infer when this should be chosen over the individual base_* utilities or the similar b402_preflight sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an AI Agent API’s x402, agent.json, OpenAPI, llms.txt, robots.txt, and MCP discovery surfaces; return a 0–100 score, missing fields, validation findings, and prioritized fixes. $1.00/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Bare domain (example.com) or https URL — normalized to the https origin |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose the $1.00/call monetization, which is a genuine economic trait. However, it does not cover failure modes, rate limits, or behavior on invalid/non-AI domains, and the normalization detail lives in the schema rather than here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that front-loads the action, explicitly enumerates the audited surfaces, and lists all return components. The cost is tacked on cleanly at the end. Minimal waste, though the missing usage guidance is an absence rather than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, it reasonably covers the audit scope, output constituents (score, missing fields, findings, prioritized fixes), and cost. It would be more complete if it distinguished itself from the overlapping x402/b402 siblings, but it is adequate for invoking 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 already well described (bare domain or https URL, normalized to https origin). The description adds cost context but no parameter-specific semantics, so the baseline 3 for full schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (verify) and a specific resource (AI Agent API discovery surfaces: x402, agent.json, OpenAPI, llms.txt, robots.txt, MCP), and lists concrete outputs. It is clear about what it does, though it does not explicitly contrast with the narrower sibling tools (x402_endpoint_verify, b402_preflight), so differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this audit versus its siblings (x402_endpoint_verify, b402_preflight, fetch_x402_content). It does mention the $1.00/call cost, which hints at a decision factor, but there are no exclusions or alternative routing, leaving the agent to infer when the breadth of this audit is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Give a returning agent a bounded accountless context bundle with optional cursor-aware Bazaar delta/trending results, statuses, next cursor, and evidence hash. $0.005/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Opaque continuation cursor returned by a prior poll. | |
| components | No | Optional signals to include; defaults to the four legacy components. | |
| since_snapshot | No | Completed Bazaar snapshot date to anchor a delta/trending poll. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the call is accountless, costs $0.005 via x402, and returns a bounded bundle with statuses, next cursor, and evidence hash. This goes beyond the schema and usefully informs the agent of auth-free usage and pricing, though it does not cover error or edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense, front-loaded sentence with no filler: it states the action, the resource, the key optional behavior, and the pricing. Every clause carries meaning.
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 appropriately enumerates the main returned elements: statuses, next cursor, evidence hash, and optional Bazaar delta/trending results. It also covers cost and accountless access. It could clarify what 'bounded' means or list the legacy default components, but the description is largely sufficient for correct 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%, so the schema already documents all three parameters clearly. The description adds some contextual color by mentioning cursor-aware delta/trending behavior, but it does not materially improve on the schema's parameter documentation.
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: returning a bounded, accountless context bundle to a returning agent. It also names the bundle's concrete contents (cursor-aware Bazaar delta/trending results, statuses, next cursor, evidence hash), which clearly differentiates it from one-off siblings like bazaar_delta or bazaar_trending and from preflight/readiness tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: this is for returning agents, it can include cursor-aware results from a prior poll, and it bundles several signals into one context. It does not explicitly list exclusions or alternatives, but the 'returning agent' and 'cursor-aware' phrasing is enough for an agent to know when this tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer a research question with cited web sources and a concise evidence packet. $0.65/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Question to answer with citations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it does disclose a genuinely useful trait: cost of $0.65/call and x402 payment requirement, which tells the agent this is a paid operation. It omits auth expectations, rate limits, latency, and any note on whether the call can fail or be retried.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and followed by the cost disclosure. Every sentence earns its place; the pricing clause is compact rather than 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, so the description must gesture at the return value, which it does ('cited web sources and a concise evidence packet'). For a trivial one-parameter tool that is nearly complete, though it could say more about source freshness or citation format.
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% for the single 'question' parameter, so the schema already documents the input and baseline 3 applies. The description adds no syntax, length, or format nuance 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?
States a specific verb and resource ('Answer a research question with cited web sources') plus the return shape ('evidence packet'), so the purpose is unambiguous. It does not, however, distinguish itself from the near-identical sibling research_answer, leaving the agent to guess 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?
There is no when-to-use guidance, no prerequisites, and no named alternative despite research_answer and web_search being obvious overlapping siblings. The only routing signal is the price, not a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a bounded award-flight search and get a normalized, validated request echo with honest availability semantics. $0.02/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| cabin | No | ||
| end_date | Yes | ||
| passengers | No | ||
| start_date | Yes | ||
| origin_airports | Yes | ||
| destination_airports | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of explaining behavior, but it only hints at validation and cost. It does not state whether the tool performs a live search, whether it mutates any state, or what guarantees 'honest availability semantics' actually represent. Important behavioral traits like external calls, caching, and side effects are undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the core action in the first clause. The cost note is a useful addition. It earns its place without excessive verbosity, though the vague 'honest availability semantics' wording could be tightened.
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 six untyped parameterswooden, no output schema, and no annotations, the description leaves major gaps: date formats, airport code format, cabin value constraints, passenger limits, and response shape. The mention of pricing helps, but it does not compensate for the missing operational context an agent needs to call this tool reliably.
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%, yet the description provides no parameter-level meaning beyond the word 'bounded.' It does not clarify date formats, airport code requirements, cabin constants, or passenger count constraints. The description fails to compensate for the absence of parameter documentation.
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 concrete action: submit a bounded award-flight search and receive a normalized, validated request echo. However, it is unclear whether this tool actually returns flight availability results or only an echo of the submitted request. The phrase 'honest availability semantics' adds ambiguity rather than clarifying the tool's core purpose.
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 tool versus alternative search or flight-related tools. It does not explain prerequisites, expected input conventions, or what kinds of award searches are appropriate. The description offers no situational context to help an agent decide to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate BNB/B402 payment intent freshness, recipient, amount, deadline, fee cap, public BNB balance, and recent activity without custody or payment relay. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | native/BNB or a BEP-20 contract address | |
| chain | Yes | ||
| payer | Yes | ||
| amount | Yes | ||
| fee_cap | Yes | Maximum network fee in BNB | |
| deadline | Yes | ISO-8601 timestamp or Unix seconds | |
| intent_id | Yes | ||
| recipient | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description discloses key behavioral traits: it performs validation without custody or payment relay, indicating a non-mutating read operation. It also mentions checking public BNB balance and recent activity, which implies on-chain reads, and discloses a cost of $0.01/call. However, it does not explicitly call itself read-only or describe error handling, leaving some ambiguity about side effects beyond 'without custody'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource, lists validation targets, and concludes with a cost note. It is under 30 words with no redundant information, making it highly economical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no annotations and no output schema, the description provides a solid overview of what is validated but omits details about return values, error conditions, and inter-parameter relationships (e.g., chain/asset compatibility). It does not mention prerequisites or limitations beyond 'without custody,' leaving some ambiguity for an agent that needs to handle errors or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 38% (only asset, fee_cap, and deadline have descriptions). The description lists validation aspects that map to parameters (freshness → deadline, recipient → recipient, amount → amount, fee cap → fee_cap, balance → payer) but does not add detailed semantics for each parameter. It partially compensates by connecting parameters to the validation purpose, but it leaves intent_id and payer (beyond pattern) under-explained, and does not fully cover the gaps 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 clearly states the tool validates BNB/B402 payment intents, listing specific aspects to validate (freshness, recipient, amount, deadline, fee cap, public BNB balance, recent activity) and explicitly excludes custody and payment relay. This distinguishes it from sibling tools like x402_endpoint_verify and x402_receipt_lookup, which focus on different stages of the x402 lifecycle.
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 does not provide explicit guidance on when to use this tool versus alternatives. It does not name sibling tools or specify conditions for selection. The name 'preflight' implies it is used before initiating a payment, but this is not stated, and no 'when-not' or alternative routing advice is given. With no annotations to compensate, the description leaves usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current Base mainnet block number from redundant public RPCs and return structured JSON with source and freshness metadata. $0.002/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full disclosure burden. It adds meaningful behavioral detail: data is fetched from redundant public RPCs, results include source and freshness metadata, and each call costs $0.002 via x402. It does not enumerate failure modes or rate limits, but this is a simple read-only fetch and the disclosed information is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The action and resource are front-loaded, and the pricing detail is appended as an efficient second sentence.
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 fetch, the description supplies enough: purpose, data source, return nature, and cost. It does not specify exact JSON field names, and there is no output schema, so a bit more detail about the returned structure could have improved it, but selection and invocation remain unambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is an empty object, so there is nothing for the description to clarify about parameter meanings. The baseline of 4 applies because the parameter surface is empty.
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 operation (fetch), resource (current Base mainnet block number), data source (redundant public RPCs), and output shape (structured JSON with source and freshness metadata). This makes it immediately distinguishable from sibling tools like base_gas_price and base_tx_status.
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 clearly establishes when the tool is appropriate: when the current Base mainnet block number is needed. It does not explicitly list alternative tools or exclusion conditions, but the specificity of the resource provides clear selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current Base gas price and EIP-1559 base fee in wei and gwei, plus latest block number and fetch timestamp from redundant public RPCs. $0.002/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses source (redundant public RPCs) and pricing ($0.002/call), but does not mention read-only nature, error handling, caching, or rate limits. Since annotations are absent, this is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence packs the resource, output fields, source, and cost. It is front-loaded with the primary purpose and avoids fluff.
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 tool, it fully specifies the output (gas price, base fee, block number, timestamp), the source, and cost. No output schema exists, so this description serves as the agent's complete reference.
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?
No parameters exist, so the description adds nothing beyond the empty schema. Baseline 4 applies because the tool requires no input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what it returns: current Base gas price, EIP-1559 base fee in wei and gwei, plus block number and timestamp. This clearly distinguishes it from sibling tools like base_block_number by focusing on gas price and fees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention when to avoid it or which sibling covers other use cases, such as block number only. The cost note is informational but not a usage criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bounded Base ERC-20 transfer history for one wallet, with token, flow and pagination filters and normalized transfer fields. $0.005/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | ||
| flow | No | ||
| limit | No | ||
| chains | No | ||
| offset | No | ||
| tokens | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals the tool is paid (via x402), bounded, and returns normalized fields, but omits pagination cap, default behavior, and any rate-limit or error conditions.
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 resource and filters, and the cost model tucked at the end. No filler, though the second sentence could be more information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no parameter descriptions, and no annotations, the description is too thin to fully guide an agent. It omits response shape, pagination mechanics, enum values for flow, and differentiation from the RPC variant, leaving important behavior to be inferred.
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 descriptions cover 0% of the parameters)Skip, so the description must explain them, but it only broadly references 'token, flow, and pagination filters'. It does not define flow's values, what token expects, or how pagination is controlled, forcing the agent to infer from the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (Base ERC-20 transfer history), a clear scope (one wallet), and filter dimensions (token, flow, pagination). It is distinct enough from generic search tools, though it does not explicitly differentiate from the sibling tool base_transfer_search_rpc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus related siblings like base_transfer_search_rpc or base_usdc_balance. The word 'Bounded' hints at scope, but an agent has to infer the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bounded Base mainnet ERC-20 transfers by address, direction, asset, counterparty, and time window; return structured transfer records. $0.02/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | ||
| limit | No | ||
| address | Yes | ||
| direction | Yes | ||
| counterparty | No | ||
| to_timestamp | No | ||
| from_timestamp | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose that the search is bounded, that it returns structured transfer records, and that each call costs $0.02 via x402. However, it does not explain behavior such as default limits, ordering, pagination, or what 'bounded' precisely means, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and then adds the pricing detail. Every part earns its place, and there is no redundant or filler content.
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 7-parameter tool with no output schema and no annotations, the description is reasonably informative but not complete. It does not explain the required direction and address parameters, limit defaults, timestamp constraints, or the relationship to the sibling base_transfer_search. Still, enough high-level context is present for the tool to be used plausibly.
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. It names five filter dimensions: address, direction, asset, counterparty, and time window. This adds meaning beyond the bare schema, but it does not clarify the semantics of each parameter in detail, such as direction relative to the address or the meaning of the limit 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?
The description gives a specific verb ('Search'), a concrete resource ('Base mainnet ERC-20 transfers'), and the filter dimensions used. It is clear and understandable on its own. However, it does not differentiate this tool from the sibling base_transfer_search, so it misses the explicit sibling distinction needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for searching ERC-20 transfers, but it provides no guidance about when to prefer this tool over alternatives. Most importantly, there is a closely named sibling 'base_transfer_search' with no stated distinction, leaving the agent without routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Base transaction success or revert state, block number, confirmations, gas used, and effective gas price for a transaction hash. $0.003/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Transaction hash, 0x-prefixed 64 hex chars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost model ($0.003/call via x402) and lists the returned data fields, which is useful. However, it does not explicitly state that this is a read-only operation or mention any failure modes or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the tool's purpose and lists the key return fields, followed by cost information. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple hash-lookup tool with one parameter, the description provides the necessary purpose, return fields, and cost. However, it omits any mention of error conditions (e.g., invalid hash, not found) or whether the tool is read-only, which could be useful in a complete context.
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 schema fully documents the single 'hash' parameter with type, pattern, and description, so the description adds no additional semantic meaning for parameters. It simply refers to 'transaction hash' in passing, which does not go beyond the schema's 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?
The description clearly states the tool returns Base transaction status with specific fields (success/revert, block number, confirmations, gas used, gas price) for a transaction hash. This is specific and unambiguous, though it does not explicitly distinguish itself from sibling tools like base_block_number or base_gas_price beyond the resource type.
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 implies when to use the tool—whenever a Base transaction hash needs status and receipt details—but it does not provide explicit guidance on when not to use it or how it differs from alternative status-checking tools. No exclusions or selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a Base wallet’s USDC balance on the canonical Base USDC contract and return structured JSON with atomic and formatted values. $0.003/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address, 0x-prefixed 40 hex chars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It adds useful context: the specific canonical contract, the cost ($0.003/call via x402), and the return shape (atomic and formatted values). It does not explicitly note read-only behavior or failure modes, but the balance-check nature is strongly implied and the provided details exceed minimal disclosure.
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, dense sentence delivers the core purpose, network, contract, return type, and pricing without redundancy. Every phrase earns its place and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter balance check with no output schema, the description covers the essential operational facts: what is read, from where, what it returns, and what it costs. It could be more complete with explicit read-only clarification, but nothing critical is missing for correct 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?
The input schema has 100% description coverage for the single address parameter, so the schema already documents the parameter. The description does not add meaningful semantic detail beyond what the schema provides, warranting the baseline score.
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 ('Check'), a precise resource (a Base wallet's USDC balance on the canonical Base USDC contract), and the return format (structured JSON with atomic and formatted values). This clearly identifies what the tool does and distinguishes it from related siblings such as base_usdc_transfer_check and base_wallet_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or recommend siblings for different needs, leaving the agent to infer the appropriate context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a Base mainnet tx hash actually moved USDC: decodes every USDC Transfer log in the receipt (from, to, amount) and answers settled true/false — the check an x402 seller runs before trusting a payment reference. $0.004/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| tx | Yes | Transaction hash to verify, 0x-prefixed 64 hex chars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the internal behavior: 'decodes every USDC Transfer log in the receipt (from, to, amount)' and the binary outcome 'settled true/false'. It also transparently states the cost ($0.004/call). Missing edge cases like what happens for non-USDC or non-existent transactions, but the provided detail is above average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the core purpose ('Verify a Base mainnet tx hash'), then elaborates with mechanism, use case, and cost. Every phrase earns its place; no filler or 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 one-parameter tool with no output schema, the description is complete: it explains what the tool checks, how it checks it, what it returns (true/false), when to use it, and the cost. The sibling context shows it's well-positioned among related tools, and the description fully satisfies the need.
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 schema already fully describes the single 'tx' parameter with pattern and description, giving 100% coverage. The description adds valuable semantic context by specifying this is a 'Base mainnet tx hash' and that it's specifically for USDC, which is not in the schema. This elevates it above the 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 clearly states the tool's specific verb and resource: 'Verify a Base mainnet tx hash actually moved USDC'. It goes further by explaining it decodes every USDC Transfer log and answers settled true/false, which sharply distinguishes it from sibling tools like base_tx_status or base_usdc_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'the check an x402 seller runs before trusting a payment reference'. This tells the agent exactly when to use it. However, it doesn't explicitly mention alternatives or when not to use it, such as when a simpler tx status check would suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Profile any Base wallet without signup or an API key: native and ERC-20 balances, bounded transfer activity, counterparties, contracts, freshness and an evidence hash. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Optional native/base/eth or ERC-20 contract address | |
| chain | No | base | |
| address | Yes | ||
| lookback_blocks | No | ||
| include_counterparties | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral aspects. It states no signup/API key needed and mentions a cost, but does not explicitly say whether it's read-only or non-destructive. It does mention 'bounded transfer activity' which hints at limitations. It adds some value beyond schema but misses safety/behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is efficient and packs key differentiators (no signup, cost, output categories). It is concise but could be reorganized slightly for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no output schema), the description is too sparse. It lists output categories but doesn't explain what 'bounded transfer activity' means, how lookback_blocks affects results, or what the evidence hash is for. The lack of details about parameter behavior and output expectations leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only asset has a description), and the tool description does not explain most parameters. It mentions 'bounded' and 'counterparties' but doesn't map to lookback_blocks or include_counterparties. It fails to clarify the meaning of the address parameter or how chain works. Description adds little beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: profiling a Base wallet, with explicit details about what it returns (balances, transfers, counterparties, freshness, evidence hash). It distinguishes from sibling tools by being a comprehensive profile rather than a specific query (e.g., base_usdc_balance, base_transfer_search).
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 tool over siblings. It does not mention alternatives or exclusion criteriaate (e.g., when to use base_usdc_balance instead). The description implies a general profiling use case, but no explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract JSON from up to 10 public URLs in isolated ephemeral compute, validating each result against its own JSON Schema and returning a reconciled idempotent manifest. $0.02/call via x402; unused execution is refundable when delivery fails.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| idempotency_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does it well: it discloses isolated ephemeral compute, per-item schema validation, idempotent manifest behavior, the $0.02/call cost, and refundable unused execution on delivery failure. It stops short of explaining failure modes for invalid URLs or schema mismatches.
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 one compartmentalized paragraph with two coherent sentences. It fronts the core extraction behavior, then supplies key constraints and costs. No redundant language or 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?
The description is largely complete for selection purposes: batch size, public-only URLs, schema validation, isolation, idempotency, cost, and refund behavior are all covered. Lacking an output schema and annotations, it still leaves a few questions around failure modes, but it gives strong enough context for an agent to 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?
The description adds some semantic meaning to the parameters: 'up to 10 public URLs' maps to items, and 'reconciled idempotent manifest' implies the role of idempotency_key. However, it never directly explains that idempotency_key must be supplied to make retries safe, and with schema coverage at 0%, the description has gaps around the exact structure and semantics of the items array.
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: extract JSON from up to 10 public URLs. It adds distinctive scope (isolated ephemeral compute, per-URL JSON Schema validation, reconciled idempotent manifest) that clearly separates it from single-extract or non-validating siblings like extract_json or batch_url_json.
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 implies when to use the tool: for batch JSON extraction from public URLs with schema validation and a paid x402 call. It clearly implies a multi-HTTP-URL batch scenario, but it does not explicitly exclude private URLs or direct users to alternatives like extract_json or batch_url_json.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run up to 10 bounded HTTPS URL-to-JSON extraction jobs for one prepaid, idempotent completion receipt. $0.02/call via x402; one reconciled batch of up to 10 jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| jobs | Yes | ||
| idempotency_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose important behavioral traits: it is a pre-paid operation ($0.02/call via x402), idempotent via a receipt, and limited to 10 jobs. However, it does not describe failure semantics, partial job failures, return format, or authentication requirements, leaving gaps for a paid operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes only essential details (cost, idempotency, batch limit). There is no fluff or repetition of schema field names.
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 batch operation with no output schema, the description covers the core function and payment but lacks details about what the returned receipt/batch looks like, error handling, or retry behavior. It is adequate for basic selection but not fully complete for safe 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?
The schema has 0% description coverage, so the description must compensate. It adds meaning by explaining that 'jobs' are URL-to-JSON extractions and limits them to 10. It does not explicitly explain 'idempotency_key' beyond the word 'idempotent,' which is a partial gap. Still, the description provides more than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Run up to 10 bounded HTTPS URL-to-JSON extraction jobs.' It specifies the resource (URL-to-JSON extraction), batch limit, and adds unique traits (prepaid, idempotent receipt, cost) that distinguish it from siblings like web_extract or fetch_x402_content.
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 implies usage for batch extraction of up to 10 URLs and mentions a cost, offering some context. However, it does not explicitly state when to use this tool vs alternatives, nor when not to use it. The batch size and payment model serve as implicit guidance but no clear exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where the x402 Bazaar demand actually is — the whole latest catalogue snapshot classified into 9 service categories, each with listing count, settled 30d calls, unique payers and share. $0.003/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description discloses the exact output contents (categories, counts, calls, payers, share) and the cost ($0.003/call). It does not explicitly confirm a read-only operation, but the 'snapshot' wording suggests a non-mutating query, which is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose, then lists the key data points and cost. Every word adds value, and the dash structure makes it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description still conveys the essential return value: a classification of the catalogue into categories with multiple metrics. It also includes pricing, making it sufficiently complete for an agent to decide when to invoke 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?
The tool has zero parameters, so the description correctly implies no inputs are needed. This baseline of 4 is appropriate since the schema is empty and there is nothing to explain.
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 explicitly states the tool provides a snapshot of the latest x402 Bazaar catalogue classified into 9 service categories with specific metrics (listing count, settled 30d calls, unique payers, share). This clearly distinguishes it from other bazaar tools that focus on different aspects, such as new listings or pulse.
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 'Where the x402 Bazaar demand actually is' implies this tool is for understanding demand distribution by category. It gives a clear context for use, though it does not explicitly name alternatives or state when not to use it, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loopable Bazaar category heat feed, or a bundled scout digest with heat, deltas, new listings, price changes, pulse, seller rank and repeat-call telemetry. $0.001079/call via x402; scout_digest view $0.005/call.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | ||
| cursor | No | ||
| categories | No | ||
| max_changes | No | ||
| since_snapshot | No | ||
| client_polled_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It adds useful context: x402 payment, exact per-call costs, loopability, and repeat-call telemetry. But it does not disclose pagination mechanics, required authorization flow, failure modes, or whether the operation is purely read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences, no filler, with the core purpose front-loaded and pricing in the second sentence. The long metric list is dense but each item conveys a meaningful inclusion.
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?
This is a multi-mode tool with six parameters and no output schema, but the description omits per-view parameter requirements, how cursor-based looping works, what the response looks like, and what the telemetry/snapshot parameters control. An agent would likely struggle 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 description coverage is 0%, so the description must compensate, but it only hints at 'view' through 'category feed' versus 'scout digest' and at 'cursor' through 'Loopable.' The meanings of categories, max_changes, since_snapshot, and client_polled_at are left entirely to inference, which is insufficient for a six-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a Bazaar category heat feed with an optional bundled scout digest, and enumerates the digest contents (heat, deltas, new listings, price changes, pulse, seller rank, telemetry). It is specific about the resource and the two modes, though it lacks an explicit verb like 'return' or 'fetch.' The 'bundled' wording helps differentiate it from the many individual Bazaar 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?
The description implies usage contexts via 'Loopable' for repeated polling and 'bundled scout digest' for getting multiple metrics at once, and it gives per-view pricing. However, it does not explicitly say when to use this tool instead of calling bazaar_category_heat, bazaar_delta, bazaar_pulse, or other siblings, nor does it state exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What changed in the x402 Bazaar catalogue overnight — resources added, resources delisted, and prices that moved (with before/after amounts), diffed between the two latest daily snapshots. $0.004/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the diffing behavior, the types of changes reported, and the cost ($0.004/call via x402), which is valuable context. It doesn't cover edge cases like snapshot availability or output format, but for a zero-parameter tool, the core behavior is transparent.
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 entire description is one well-structured sentence that front-loads the purpose and appends cost information. Every word adds value, with no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does, its scope, and its cost. Given the lack of output schema and annotations, it is reasonably complete for a simple, parameterless diff tool. It could mention output format or snapshot dates, but the core use case is clear.
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 input schema is empty (0 parameters), and the description appropriately focuses on output/behavior rather than parameter syntax. The baseline score of 4 applies because no parameter explanation is needed.
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 diffs the two latest daily snapshots of the x402 Bazaar catalogue, reporting added, delisted, and price-changed resources with before/after amounts. This specific verb+resource+scope distinguishes it from sibling bazaar tools like bazaar_new_listings or bazaar_price_stats.
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 implies usage for tracking overnight changes but does not explicitly state when to use this tool versus alternatives like bazaar_market_report or bazaar_trending. No exclusions or 'use instead' guidance are provided, leaving the comparison implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint an x402 Bazaar listing before buying or before publishing your own: 0-100 quality score combining a live probe of the resource (valid 402? description? output schema? category? above the facilitator price floor?) with its day-by-day snapshot history (price churn, delisting). $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | Yes | The listed resource URL to lint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the nature (lint, quality score), the components (live probe and snapshot history), the cost ($0.01/call), and the specific criteria checked. It doesn't explicitly state read-only or side effects, but 'lint' implies analysis. It also mentions the return type (0-100 score). This is substantial disclosure.
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 that are information-dense and front-loaded: the purpose, the score, the checks, and the cost are all present with zero fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description is quite complete: it explains what it does, what it returns (quality score), what it checks, and the cost. It lacks explicit error conditions or prerequisites, but those are minor for this type of read-only lint tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'resource' parameter, which already describes it as 'The listed resource URL to lint'. The description adds the x402 context and the fact it's a listing, but doesn't add syntax or format details beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lints an x402 Bazaar listing and produces a 0-100 quality score, listing specific checks (valid 402, description, output schema, category, price floor, price churn, delisting). This is a specific verb+resource and distinguishes it from generic tools, though it doesn't explicitly name 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?
The description gives clear usage context: 'before buying or before publishing your own'. This tells the agent when to use it, but it doesn't explicitly mention alternatives or when not to use it, so it's not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full state of the x402 Bazaar in one JSON dossier — marketplace totals, price distribution and bands, network split, top services and sellers, new entrants, day-over-day movers, and how many listings have real repeat buyers. Built from daily full-catalogue snapshots. $0.50/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data source (daily full-catalogue snapshots), the cost ($0.50/call), and what is included. It does not mention rate limits or authentications, but for a read-only report, these are less critical. The cost disclosure is a valuable behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the tool's purpose, and every sentence provides value. It lists contents efficiently and adds cost and snapshot timing without fluff.
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 tool with no output schema, the description is complete. It tells the agent exactly what to expect (a JSON dossier with named metrics), the data timeliness, and the cost. This is fully sufficient for selecting and invoking the 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?
The tool has zero parameters, so there is nothing to document. The description adds useful context about the report's content and freshness without needing to explain params. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'the full state of the x402 Bazaar in one JSON dossier' and enumerates the included metrics (totals, price distribution, network split, top services/sellers, etc.). This specific verbless statement thoroughly differentiates it from sibling tools that focus on individual aspects.
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 implies when to use it naturally: for a comprehensive market overview. It says it's built from daily full-catalogue snapshots and costs $0.50/call, providing context. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which resources just listed on the x402 Bazaar — everything present in the latest daily snapshot that was missing from the prior one, with service, network, price and seller address. $0.003/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully discloses the tool's behavior: it compares daily snapshots to derive new listings, returns specific fields (service, network, price, seller address), and states the cost of $0.003/call via x402. This is comprehensive and transparent for a read-only query 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 a single sentence that is front-loaded with the core purpose, followed by the method and cost. It is concise, with no filler or redundant information, and every phrase adds value.
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?
Even without an output schema or annotations, the description provides enough context to understand the tool's behavior, including the exact selection algorithm and output fields. For a simple tool with no parameters, this is a complete and self-explanatory 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?
The tool has zero parameters, so the schema provides no additional meaning. The description compensates by explaining what the tool does and what it returns. According to the baseline for zero parameters, this is a high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: identifying resources newly listed on the x402 Bazaar. It specifies the exact resource (x402 Bazaar), the verb (just listed), and the scope (everything in the latest daily snapshot missing from the prior one), which distinguishes it from sibling tools like bazaar_delta or bazaar_category_heat.
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 makes the intended use clear by phrasing it as a question ('Which resources just listed...'), indicating it is used to discover new listings. However, it does not explicitly mention when not to use the tool or suggest alternative sibling tools, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How x402 Bazaar listings are priced right now — percentile distribution (atomic + USD), USD price bands with market share, and per-network medians from the latest daily full-catalogue snapshot. Optionally filter to one network. $0.002/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Optional network filter (e.g. 'base', 'solana'); omit for all networks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds valuable behavioral context: the data comes from 'the latest daily full-catalogue snapshot' (indicating potential staleness), the cost is disclosed ($0.002/call via x402), and the optional network filter is described. It does not mention output format or error behavior, but given the read-only nature, the key traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function, and contains no fluff. It efficiently conveys the stats provided, the snapshot source, the optional filter, and the cost. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the essential context: what data is returned (percentiles, price bands, medians), the data source (daily snapshot), and cost. It could mention the response structure or error handling, but for a stats query, the description is largely complete. Slightly more detail on return format would push it to 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?
The only parameter, network, is fully described in the schema with an example and instruction to omit for all networks. The description repeats this via 'Optionally filter to one network.' Since schema coverage is 100%, the description adds no new semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it provides a percentile distribution (atomic + USD), USD price bands with market share, and per-network medians for x402 Bazaar listings, based on a daily snapshot. This is a specific, distinct function compared to sibling tools like bazaar_pulse or bazaar_trending, which focus on other aspects. The purpose is immediately clear.
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 implies usage context—'How x402 Bazaar listings are priced right now'—and mentions the optional network filter, but it does not explicitly state when to use this tool versus alternatives like bazaar_market_report or bazaar_delta. There are no exclusions or alternative tool recommendations, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full x402 Bazaar market pulse for the latest completed daily snapshot: catalogue totals, top services by call volume, new listings and networks. $0.002/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost ('$0.002/call via x402') and the data freshness ('latest completed daily snapshot'), which are useful behavioral traits. However, it does not mention return format, error conditions, or any rate limits, leaving some behavioral uncertainty for a zero-parameter 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 a single, well-structured sentence that front-loads the primary purpose and includes critical details (contents, freshness, cost). Every word earns its place with no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no output schema), the description covers the essential aspects: source, contents, frequency, and cost. It does not explain output structure, but that is not necessary when no output schema exists and the tool is a straightforward data snapshot. A perfect score would require distinguishing guidance from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain any. The baseline for 0 params is 4, and the description appropriately focuses on the tool's output rather than input, which is irrelevant here.
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 identifies the resource ('x402 Bazaar market pulse') and specifies its contents ('catalogue totals, top services by call volume, new listings and networks'). While it lacks an explicit verb like 'get' or 'list', the intent is unambiguous. It distinguishes from siblings by naming 'x402 Bazaar' specifically, though it doesn't differentiate from the similar-sounding 'market_intel'.
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 does not state when to use this tool versus alternatives. It mentions 'latest completed daily snapshot' implying a use case for fresh data, but there is no explicit guidance on when not to use it or what alternatives exist. With multiple sibling tools offering market data, this gap is noticeable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who is actually earning on the x402 Bazaar — top 25 seller addresses by settled 30d calls from the latest daily snapshot, with listings, unique payers and each seller’s busiest resource. $0.003/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool uses the latest daily snapshot, focuses on settled 30d calls, and lists specific data included. It also mentions the call cost ($0.003 via x402), adding useful context beyond what schema or annotations provide. However, it does not explicitly state read-only nature or potential rate limits, but for a simple data query, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, tightly packed with relevant detail: ranking criteria, time window, snapshot source, included fields, and cost. Every phrase earns its place with no redundancy, and the key purpose is front-loaded in the first few 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?
For a zero-parameter query tool, the description is remarkably complete. It explains what data is used (latest daily snapshot), the metric (settled 30d calls), the ranking scope (top 25), and the output components (listings, unique payers, busiest resource). No output schema exists, but the description effectively communicates the return content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to clarify. The description instead focuses on what the tool returns, which is more relevant. Per rubric, a baseline of 4 applies when there are no params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: ranking top 25 x402 Bazaar seller addresses by settled 30d calls. It specifies the exact output content (listings, unique payers, busiest resource) and distinctively differs from sibling bazaar tools like bazaar_market_report or bazaar_pulse, which focus on broader market trends rather than individual seller ranks.
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 'Who is actually earning on the x402 Bazaar' gives a clear use case, implying it is for identifying top-earning sellers. It does not explicitly mention alternatives or when not to use it, but the context is clear enough that an agent can infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which x402 Bazaar services are gaining settled calls and unique payers fastest right now — day-over-day movers, decliners and new entrants from daily full-catalogue snapshots. $0.003/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the data source (daily full-catalogue snapshots), comparison method (day-over-day), output categories, and cost ($0.003/call via x402). This goes beyond a generic description, though it does not explicitly state read-only behavior or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-constructed sentence that front-loads the core question and includes all essential details: the resource (Bazaar services), metrics (settled calls, unique payers), time frame (day-over-day), categories (movers, decliners, new entrants), data source, and cost. 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?
For a zero-parameter tool with no output schema, the description is reasonably complete: it explains the conceptual output, the cadence of snapshots, and the pricing. It does not detail the exact result structure, but the absence of an output schema makes that less critical. It could also mention that it is read-only, but the context is 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?
The tool has zero parameters, so the schema is fully covered. Per the baseline for 0-parameter tools, the description does not need to add parameter details. It could mention that no input is required, but the context signals make this unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: identifying which x402 Bazaar services are gaining settled calls and unique payers fastest, with specific categories (day-over-day movers, decliners, and new entrants). This distinguishes it from sibling tools like bazaar_pulse or bazaar_delta by specifying exact metrics and snapshot basis.
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 implies usage for discovering currently trending Bazaar services ('gaining... fastest right now') but does not explicitly state when to use this tool over alternatives or provide exclusions. No sibling tool references are given, leaving some ambiguity for an agent choosing between related bazaar_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one ephemeral headless browser action and verify a selector or text assertion, returning a verified evidence record. $0.02/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| action | Yes | ||
| expected | Yes | ||
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the browser action is ephemeral and mentions the cost ($0.02/call via x402), but it does not describe side effects, failure behavior, the nature of the evidence record, or any restrictions. This is insufficient for a tool that performs web actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core functionality front-loaded and cost information appended. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has complex nested objects and no output schema, yet the description gives only a high-level overview. It does not explain how to construct the action object, what the expected object should contain, or what the evidence record looks like. For a tool with 4 required parameters and nested structures, this is grossly incomplete.
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 0%, so the description must compensate. It hints at the 'expected' object via 'verify a selector or text assertion' and the 'action' object via 'browser action', but it does not explain the individual parameters, the meaning of action types, or the format of the expected object. This is a significant 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 clearly states the tool runs an ephemeral headless browser action (click/type/goto) and verifies a selector or text assertion, returning an evidence record. It uses a specific verb and resource, and while it doesn't name a specific alternative, the function is distinct from 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?
There is no guidance on when to use this tool versus alternatives, nor any exclusions, prerequisites, or context about typical use cases. The description only states what the tool does without addressing decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one bounded chat completion (standard messages request shape) per paid call, with no account to open and no provider key to hold. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | ||
| max_tokens | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses payment model, bounded nature, and no-setup requirement, which is useful. However, it does not disclose the output shape, error behavior, or rate limits, and relies on the term 'standard' to convey messages structure.
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 totaling about 25 words; the core action is front-loaded and every clause adds useful context (bounded, paid, no account, price). No fluff.
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 no annotations or output schema, the description should cover what the tool returns and any constraints beyond the schema. It covers cost and access model but omits response format, model identity, and max_tokens limit (600) from the schema, leaving an agent to rely on prior knowledge of chat completions.
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. 'Standard messages request shape' adds meaning to the messages parameter, and 'bounded' hints at max_tokens, but max_tokens is never explained or tied to its 600 maximum. Partial compensation only.
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?
Description states a specific verb ('Get') and resource ('one bounded chat completion') and clarifies the request shape ('standard messages request shape'). It does not explicitly differentiate from sibling tools like 'inference' or 'x402_endpoint_verify', though the no-account/pay-per-call positioning gestures at a unique niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (paid call, no account/provider key, $0.01/call via x402) that implies when to use it, but it never explicitly states when to choose this tool over alternatives or when not to use it. No exclusions or sibling naming are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify text into exactly one of your 2-20 labels (support triage, intent detection, content routing) — the answer is validated against your label list, so you always get a real label back. $0.005/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to classify (truncated to 8,000 characters) | |
| labels | Yes | 2-20 candidate labels; the response is exactly one of them |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adds valuable behavioral guarantees: 'the answer is validated against your label list' ensures a real label is returned, and the pricing ($0.005/call via x402) is an extra non-obvious detail. It does not cover failure modes, but the tool's simple classification behavior makes this less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the action and packs in the label constraint, use cases, validation guarantee, and pricing. Every phrase earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter tool, and the description plus schema fully specify inputs, output behavior (exactly one label), validation, and cost. No output schema is needed because the labels parameter already states the return characteristic, and the description adds meaningful context for real-world use.
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%—both parameters are fully described in the schema (text truncation, label constraints, response guarantee). The description's mention of '2-20 labels' and the response being one of them largely repeats schema content, providing no new parameter-specific meaning beyond 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?
The description opens with a specific verb and resource: 'Classify text into exactly one of your 2-20 labels.' It also names concrete applications (support triage, intent detection, content routing) that immediately distinguish it from sibling tools like sentiment or extract_keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by listing example applications, and the phrase 'your 2-20 labels' implies it is for custom labels. However, it does not explicitly mention when NOT to use it or name alternative tools, so it lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Company research brief with cited sources, business profile, competitors, market signals, and risks. $0.50/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Exchange ticker, e.g. AAPL | |
| filing_type | No | 10-K |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose one meaningful trait: a per-call price of $0.50 via x402, implying a paid/crypto-settlement flow. It says nothing about latency, caching, whether the funding wallet must be pre-provisioned, or the output format, so significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the deliverable and its component sections, then the cost. No filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid research tool with no output schema and no annotations, describing the brief's sections is a good start, but the definition omits selection guidance, the meaning of filing_type, and operational traits like latency and output shape. It is adequate but well short of complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% — ticker has a description (though its schema example, COIN, conflicts with the 'AAPL' example shown) and filing_type has an enum plus default but no textual description. The description adds zero parameter meaning, leaving filing_type's semantics (which filing drives the brief) entirely to inference.
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 enumerates the concrete deliverable — a cited research brief covering business profile, competitors, market signals, and risks — which tells an agent exactly what it produces and lets it be distinguished from siblings like market_intel or us_equity_snapshot. The verb is only implied via the tool name, but the output scope is specific enough to be actionable.
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 choose this over adjacent tools such as research_answer, market_intel, or us_equity_snapshot, nor any stated prerequisites. The only usage-adjacent signal is the price tag, which is not the same as selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile a multi-rail merchant payment policy with authorization, spending, settlement, receipt, deny, and refund rules. $0.02/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| reversible | Yes | ||
| product_type | Yes | ||
| max_latency_ms | Yes | ||
| max_price_usdc | Yes | ||
| supported_assets | Yes | ||
| refund_capability | Yes | ||
| human_authorization_required | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits, but it only mentions a per-call cost. It does not disclose whether the tool creates persistent state, requires authentication, has side effects, or what the output format is.
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 no filler; the first states the core purpose and the second adds pricing information. It is front-loaded and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (7 required params, no output schema, no annotations), the description is minimal and omits critical context such as return value structure, behavioral constraints, and parameter semantics. It is not complete enough for reliable 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?
The input schema has seven required parameters with zero descriptions, and the tool description does not explain any of them. The mention of 'refund rules' loosely relates to refund_capability, but the other six parameters (e.g., product_type, max_latency_ms) are completely unaddressed.
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 uses a specific verb ('compile') and resource ('multi-rail merchant payment policy') with a list of rule types, making its function clear. It does not name alternative tools or explicitly differentiate from siblings, but the scope is distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool, what triggers its use, or how it compares to sibling tools like settlement_verify or x402_receipt_lookup. There are no usage conditions or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current USD price for one token symbol from live market data, with source attribution. $0.004/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Single token symbol, e.g. ETH, BTC, SOL | BTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose two useful behavioral traits — data provenance ('live market data, with source attribution') and the cost model ('$0.004/call via x402') — but says nothing about freshness/latency, caching, rate limits, or whether payment is required per call versus via a token.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences; the core capability is front-loaded and the pricing/provenance note is compact and earns its place for a paid x402 endpoint.
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 tool with no output schema and no annotations, the description covers the essential call context and hints at the return ('source attribution'), though it does not state the response shape (scalar vs. JSON with source fields) an agent should expect before paying.
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 single parameter has 100% schema description coverage including default (BTC) and examples, so the schema does the heavy lifting. The description only reinforces 'one token symbol', adding no syntax, casing, 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?
States a specific verb+resource: the current USD price of a single token symbol sourced from live market data, plus source attribution. It is clear what the tool returns, but it does not differentiate from siblings like token_metrics or trading_signals, which an agent could plausibly confuse with a price 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?
The description gives no explicit when-to-use guidance and never names an alternative among the many market-data siblings (token_metrics, trading_signals, bazaar_price_stats, us_equity_snapshot). Usage is only loosely implied by 'Current USD price for one token symbol'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Echo the request query parameters back with a timestamp — an x402 client diagnostic that exercises the payment headers, not just the HTTP client. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the tool's side effects: it's a non-mutating echo, requires x402 payment, and costs $0.01/call. It adds meaningful context beyond the schema, though it doesn't detail response format or failure 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, front-loaded with the core action, followed by the diagnostic context and cost. No redundant 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?
As a simple diagnostic echo tool, the description covers purpose, cost, and behavioral context sufficiently. It doesn't specify the timestamp format, but that's a minor detail for an echo endpoint.
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 schema has zero defined properties but allows arbitrary query parameters with a clear description. The tool's description reinforces that query parameters are returned verbatim, and since parameters are free-form, there is little more to explain.
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 echoes request query parameters back with a timestamp, and identifies it as an x402 client diagnostic. This specific verb+resource makes it distinct from the sibling analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It conveys a diagnostic use case ('exercises the payment headers, not just the HTTP client') and mentions cost, implying it's for testing x402 integration. However, it doesn't explicitly state when not to use it or name an alternative, but given the sibling set, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make one bounded request to a public HTTP endpoint and report status, x402 payment signals, latency and assertion validity without returning the target body. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| method | No | GET | |
| headers | No | Scalar request headers | |
| target_url | Yes | Public http(s) endpoint to test | |
| task_assertions | No | Optional status, body_contains and response_schema assertions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: the request is bounded, costs $0.01, and the target body is not returned. However, it does not warn about sending user-supplied headers/body to arbitrary endpoints or discuss side effects, prerequisites, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that efficiently conveys the verb, resource, output scope, constraint (no body), and cost. Every clause adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description covers the core purpose, return fields, and constraints. It lacks details on assertion validation or method defaults, but the schema partially fills that 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 60% with descriptions for target_url, headers, and task_assertions, but method and body lack descriptions. The description adds no parameter-specific detail beyond noting the request is bounded and x402-related, leaving some parameters under-explained.
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 makes one bounded request to a public HTTP endpoint and reports specific data (status, x402 payment signals, latency, assertion validity). It also explicitly notes the target body is not returned, distinguishing it from siblings like web_extract.
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 implies use for lightweight HTTP endpoint testing with a cost per call, but it does not explicitly state when to choose this tool over alternatives or mention any exclusions. No direct comparison to sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn unstructured text (emails, invoices, listings, bios) into structured JSON conforming to your JSON Schema — reply is parse-validated with an automatic retry, so you get JSON or a clean failure. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Source text to extract from (truncated to 8,000 characters) | |
| schema | Yes | JSON Schema object the output must conform to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does excellently: it discloses parse-validation, automatic retry, and a clean failure mode. It also mentions cost. These behavioral traits go well beyond the schema, which only defines the inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main purpose, then adds behavioral details and cost. Every clause earns its place with 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?
For a simple two-parameter tool with no output schema, the description adequately covers purpose, behavior, failure modes, and cost. It does not need to explain return values since the output is described as JSON or a clean failure, and the schema param is self-explanatory.
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 both parameters. The description adds examples of text types but no additional syntax or constraints beyond the schema. The baseline of 3 is appropriate; the description does not meaningfully enhance parameter understanding.
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 it converts unstructured text into structured JSON using a provided JSON Schema, with specific examples (emails, invoices, listings, bios). This is a specific verb+resource and distinguishes it from siblings like extract_keywords or classify_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (when you have unstructured text and a JSON schema), but it does not explicitly name alternatives or exclusion criteria. The use case is well-defined, but no 'vs alternatives' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract ranked keywords and named entities (people, orgs, places, products) from text as clean JSON arrays — for tagging, indexing, and enrichment pipelines. $0.004/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze (truncated to 8,000 characters) | |
| max_keywords | No | Maximum keywords to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the output format ('clean JSON arrays') and pricing, but omits important behavioral details like the 8,000-character truncation limit, rate limits, or auth requirements. This leaves gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main action, includes pricing, and uses no filler. Every word contributes to conveying purpose and value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, output format, use cases, and pricing. The schema covers the parameters. While it doesn't mention the 8,000-character truncation limit, that is available in the schema. The lack of an output schema makes the 'clean JSON arrays' statement somewhat vague, but overall it is adequately complete for a simple extraction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context about ranked output and entity types (people, orgs, places, products), but it does not specifically explain the parameters beyond what the schema already provides. It enhances understanding of the output, but not the parameters themselves.
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 extracts ranked keywords and named entities from text, using a specific verb and resource. It distinguishes itself from sibling tools like classify_text or summarize_text by focusing on extraction and entity recognition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('for tagging, indexing, and enrichment pipelines'), giving clear context for when to use it. However, it does not mention alternatives or exclusions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and extract content from x402-protected web pages, handling edge payment automatically. Returns clean article content with payment proof. $0.02/call via x402. Free tier: 1 fetch/day (content only).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to fetch (must be https) | |
| format | No | Output format (default: markdown) | |
| extract_options | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses automatic payment handling, cost ($0.02/call), free tier limits (1 fetch/day), and that it returns payment proof. This is valuable behavioral information beyond the input schema, though it doesn't cover failure modes or what happens if payment fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the main purpose and include cost/free tier info. Every word earns its place, with no redundancy or 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 tool with no output schema and moderate complexity (payment handling, multiple formats), the description provides enough context: purpose, cost, free tier, return content. It doesn't explain error cases or detailed usage, but it's sufficient for an agent to decide when to call it and what to 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?
The input schema already describes all three parameters with reasonable detail (URL must be https, format enum, selector note). The description adds context about output being 'clean article content' and mentions 'content only' for the free tier, but doesn't deeply elaborate on parameter meanings. With 67% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch and extract' with a clear resource ('x402-protected web pages') and scope ('handling edge payment automatically'). It distinguishes itself from generic tools like web_extract by focusing on x402-protected content and automatic payment.
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 clearly implies when to use this tool: for x402-protected pages where edge payment is needed. It doesn't explicitly name alternatives or exclusions, but the automatic payment handling is a strong contextual indicator that sets it apart from ordinary fetch tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit a signed or explicitly declared selected offer against alternatives and quantify affordable counterfactual savings. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| alternatives | Yes | ||
| selected_offer | Yes | ||
| max_price_atomic | No | ||
| signature_secret | No | ||
| signed_selected_offer | No | ||
| selected_offer_declared | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions the cost ($0.01/call) but does not state whether the tool is read-only, what it returns, or any side effects. The term 'audit' implies analysis, but the agent cannot infer if it mutates state or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that captures the core purpose and pricing. It is front-loaded with the action and resource, with 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?
Given 6 parameters, 2 required, nested objects, and no output schema, the description is insufficient. It does not explain what the audit returns, how to specify alternatives, or any constraints. The agent would struggle to use it correctly without additional information.
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 0%, so the description must explain parameters. It only hints at two modes ('signed or explicitly declared') which correspond to signed_selected_offer and selected_offer_declared, but does not explain their relationship or the role of max_price_atomic or signature_secret. The agent cannot infer how to construct the required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: auditing a selected offer against alternatives and quantifying savings. It specifies the two modes ('signed or explicitly declared') and mentions pricing, which is specific and distinguishes it from siblings like agent_readiness_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives. The description does not mention any conditions, prerequisites, or reference sibling tools. The agent cannot determine when this tool is appropriate versus other audit or marketplace tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a legal entity from public LEI registry records by LEI, legal name, jurisdiction, registration ID or country, returning ranked candidates and evidence. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| lei | No | 20-character Legal Entity Identifier | |
| country | No | ISO 3166-1 alpha-2 legal-address country code | |
| candidates | No | Return ranked candidates instead of rejecting an ambiguous match | |
| legal_name | No | Legal entity name or distinctive name fragment | |
| jurisdiction | No | ISO 3166-2 jurisdiction code | |
| registration_id | No | Entity registration identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions cost and output type but overpromises by stating 'returning ranked candidates' without clarifying that this depends on the `candidates` parameter; the schema shows it rejects ambiguous matches by default. It also omits error handling, rate limits, or authentication requirements, and does not explicitly confirm the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and includes cost information. Every phrase contributes value: the verb, the resource, the search fields, the output type, and the pricing. There is no filler or redundancy, making it highly concise and well-structured.
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 6 parameters, 100% schema coverage, no output schema, and no annotations, the description is moderately complete. It explains what the tool does and the output type but lacks essential behavioral details like the conditional nature of candidate ranking, minimum parameter requirements (implicitly minProperties:1), and any caveats about data freshness or ambiguity. An agent might call it correctly but without full understanding of edge cases.
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 lists the search dimensions (LEI, legal name, jurisdiction, registration ID, country) which map directly to parameters, and mentions 'candidates' as an output behavior. However, it adds no extra meaning beyond the schema descriptions—no examples, format details, or usage constraints—so it stays at the 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 clearly states the action ('Resolve a legal entity'), the resource ('public LEI registry records'), and the supported query dimensions (LEI, legal name, jurisdiction, registration ID, country). It also notes the output ('ranked candidates and evidence'), making the tool's purpose unambiguous and distinct from sibling search tools like people_search or profile_search, which target individuals rather than legal entities.
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 implies usage when you have any of the listed identifiers (LEI, name, jurisdiction, etc.) but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or comparison with other tools are provided, leaving some inference required. It is clear enough for basic use but lacks explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chat-completion inference (standard messages request shape) against a six-model catalogue (see /api/v1/models). $0.01 charged per call: pay $0.01 exact on Base or Solana, or authorize up to $1.00 with the Base "upto" scheme and still be charged $0.01.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model ID (see /api/v1/models) | deepseek/deepseek-v4-flash |
| stream | No | Enable SSE streaming | |
| messages | Yes | Chat messages array |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a critical behavioral trait: a $0.01 per-call charge and the payment mechanics (exact $0.01 on Base or Solana, or up to $1.00 via the Base 'upto' scheme with actual charge of $0.01). It omits auth prerequisites, rate limits, and error behavior, but the cost/payment disclosure is substantial and non-obvious.
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 purpose before the pricing detail, which is the right ordering. The pricing clause is somewhat dense but every element (amount, chains, scheme) is load-bearing for an agent deciding whether it can pay.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, so the description should ideally cover the return shape and auth; it implies an OpenAI-standard chat shape but never states the response format explicitly. Payment mechanics are well covered, but the response/error surface and the distinction from chat_completion are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented in the schema. The description adds only that the request uses the 'standard messages request shape' and references the model catalogue, which is marginal value beyond the schema — baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It names a specific verb+resource (chat-completion inference) and scopes it to a six-model catalogue pointed to via /api/v1/models. However, it does not distinguish this tool from the highly similar sibling 'chat_completion', leaving an agent unable to tell them apart from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no exclusion criteria, and no routing hint against alternatives. Given siblings like chat_completion and route_task that overlap heavily, the absence of any 'use this instead of X' statement is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Triage one Bazaar listing against its snapshot history: how long it has persisted, price changes, duplicate variants and a buy signal. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_url | No | Listing resource URL to match instead | |
| listing_name | No | Listing/service name to match |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses a specific behavioral trait—cost ($0.01/call via x402)—and implies a read-only analytical function, but does not explicitly state whether it writes, requires authentication, or describe failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and includes all essential information without redundancy. Every clause adds value, from the action to the cost model.
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 lack of an output schema, the description does a good job of outlining what the tool returns (persistence, price changes, duplicate variants, buy signal). It is complete for a single-listing analysis tool, though it could clarify matching behavior when both name and URL are provided.
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 input schema has 100% description coverage for both parameters (listing_name and listing_url), so the schema already provides the meaning. The description adds no additional parameter-level detail beyond the schema, earning a baseline score of 3.
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 uses a specific verb 'Triage' with a clear resource ('one Bazaar listing') and enumerates distinct outputs (persistence, price changes, duplicate variants, buy signal). This clearly distinguishes it from sibling tools such as bazaar_pulse or market_intel.
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 clearly states the tool is for triaging a single listing against its snapshot history, implying usage when a user needs a historical assessment of one listing. It does not explicitly name alternatives or exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compose public DeFi market metrics (protocols, chains, DEX volume, fees, yields) with bounded public web context. $0.10/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Base | |
| symbol | No | ||
| project | No | ||
| token_address | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'bounded public web context' and the $0.10/call cost, which is useful, but it does not disclose whether the tool performs live web fetches, whether results are cached, what happens on rate limits, or whether any parameters are required despite none being marked required. The 'bounded' qualifier hints at constraints but is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and includes the cost detail. It is concise and readable, though the phrase 'bounded public web context' is slightly jargon-heavy and could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is too thin. An agent cannot determine which parameters to supply for a given metric request, what the output shape will be, or what constraints apply. The cost and 'bounded' context are helpful but do not make the tool safely callable.
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 for the four undocumented parameters. It does not explain how chain, symbol, project, or token_address map to the metric categories, nor does it clarify which parameters are needed for which use cases. The description adds no parameter-level meaning beyond the schema's bare names.
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 ('Compose') and resource ('public DeFi market metrics') and enumerates the metric categories (protocols, chains, DEX volume, fees, yields). It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools like token_metrics or crypto_price, which could overlap in the DeFi/crypto space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It mentions 'bounded public web context' and a price, but does not state when an agent should prefer market_intel over token_metrics, crypto_price, or trading_signals. The usage context is only implied by the metric categories listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Admit one service from the live MPP public catalog using task relevance, price, Tempo rail, and freshness constraints, with deterministic refusal evidence. $0.005/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| rail | No | tempo | |
| task | Yes | Natural-language task to match against the MPP public catalog | |
| freshness | No | ||
| price_cap | No | Maximum service price in USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful behavioral context: the call costs $0.005 via x402 and refusals produce deterministic evidence. It does not, however, explain what a successful admission returns or whether any downstream side effect occurs.
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, information-dense sentence front-loads the core purpose and constraints, then appends the essential cost detail. Every phrase earns its place; there is no redundant 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?
The description gives enough to understand the tool's selection constraints and cost, but the absence of an output schema leaves the admission/refusal return contract unexplained. It also does not clarify what 'admit' produces operationally or how the refusal evidence should be consumed by the agent.
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%, but the description maps all four parameters to their constraint roles: task relevance, price, Tempo rail, and freshness. It adds meaning beyond the bare enum and field names, yet it does not elaborate on the freshness object structure or how constraints interact.
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 ('Admit'), a specific resource ('live MPP public catalog'), and the constraints used (task relevance, price, Tempo rail, freshness). It conveys the gating nature clearly, but it does not explicitly distinguish itself from closely related siblings like mpp_route or oblique_gateway.
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 tool versus the many routing and gateway siblings. The description implies a catalog-admission context, but it never states when an agent should select this over mpp_route, oblique_gateway, or route_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MPP-native catalog-first task routing. Free returns one recommendation; paid returns the top three with prices, payment methods, MCP schemas, health metadata and operator-controlled attribution. $0.01/call via MPP or x402 for the top-three shortlist; free route returns top-1.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Natural-language task to route | |
| price_cap | No | ||
| constraints | No | ||
| output_format | No | json | |
| preferred_chain | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It discloses the free/paid behavior, output contents (prices, payment methods, MCP schemas, health metadata), and cost ($0.01/call via MPP or x402). However, it does not mention potential side effects, error conditions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, and packs essential information (free vs. paid, output details, cost) without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the main behavior and output features but lacks a full picture: no return schema, no explicit usage context, and no mention of edge cases or prerequisites. Given the tool's relative simplicity, it is partially complete but leaves 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?
Only the 'task' parameter has a schema description; the rest are undefined. The description provides minimal indirect hints (e.g., price_cap relates to 'prices', preferred_chain may relate to 'MPP-native' or 'x402'), but it does not explicitly explain the meaning or expected input format for parameters like constraints, output_format, or preferred_chain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'MPP-native catalog task-first routing' with explicit differentiation between free (one recommendation) and paid (top three with details) results. It also mentions pricing, making the core function unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the free vs. paid behavior and output differences, but does not explicitly state when to choose this tool over alternatives (e.g., other routing tools). It lacks direct guidance on conditions like 'use when you need pricing or multiple options'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Observer-backed gateway over five allowlisted proven sellers with capped float, upstream payment reference, delivery and transparent 10% margin receipt. $0.001187/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Task used to select an allowlisted observer-proven seller |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose concrete behavioral attributes: a 10% margin receipt, capped float, upstream payment reference, delivery, and an explicit x402 price of $0.001187/call. It does not describe side effects or return format, but it is notably transparent about the transactional nature of the 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 description is compact and contains no filler, fitting in two sentences. However, the first sentence is a dense comma-separated list of abstract terms that is grammatically awkward and requires parsing to understand, so it is concise but not optimally structured for quick comprehension.
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 interface, the description covers the core call context: seller selection, cost, payment method, margin receipt, and delivery. However, with no output schema and no example task or expected return format, an agent must make some assumptions about what the gateway actually returns after invoking a seller.
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 only parameter, `task`, has 100% schema description coverage stating it selects an allowlisted observer-proven seller. The tool description itself adds no additional parameter-level detail, so the schema already carries the semantic load; this matches the baseline for high schema 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?
The description identifies the tool as an 'Observer-backed gateway over five allowlisted proven sellers' and mentions task-based seller selection, which gives a helpful scope. However, it lacks a clear verb and explicit outcome (e.g., 'routes', 'selects', or 'delivers'), so the exact purpose remains somewhat inferred rather than stated.
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 context about the seller pool, pricing, and payment mechanism, but it never states when to use this tool versus alternatives. With siblings like route_task, mpp_route, agentcore_route, and fetch_x402_content, no exclusionary or comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Profile the Base address that just paid you: public x402 payment footprint (payments, distinct recipients, cadence, native activity, what this shop has seen) and a class — self-disclosed catalogue scout, scheduled verifier, catalogue sweep, paying index, repeat buyer, single touch — with evidence and confidence, plus the rule for reading it: the first one to three payers of a new listing are usually verifiers paying to look. Not an identity claim. $0.01/call via x402. Free doors: GET /api/v1/payer-profile/example (a worked machine-wallet profile) and GET /api/v1/payer-profile/classes (every class and its heuristic).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The Base address that paid you | |
| window_days | No | How far back to read, in days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it states the data is public, notes the output includes evidence and confidence, explicitly disclaims identity claims, and discloses the per-call cost. It does not mention rate limits or auth requirements, but the core behavioral traits are transparent.
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 dense but each sentence adds value: purpose, output contents, interpretation rule, identity disclaimer, pricing, and documentation pointers. It is longer than average but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by listing the output categories, the class taxonomy, the evidence/confidence aspect, and the interpretive rule. It also provides free exploration endpoints. Minor gaps like error cases or pagination are not critical for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description reinforces that 'address' means the payer who paid you, but it does not add substantial meaning beyond the schema's field descriptions.
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 uses a specific verb ('Profile') and a precise resource ('the Base address that just paid you'), then enumerates what the profile contains (x402 payment footprint, class, evidence, confidence). This clearly distinguishes it from generic wallet tools like wallet_analyze or base_wallet_profile.
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 implies usage after receiving a payment and includes a heuristic for interpreting early payers, but it does not explicitly state when to prefer this tool over sibling tools such as wallet_analyze or base_wallet_profile. It provides a useful reading rule but no direct when-to-use/when-not-to-use guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accountless people-enrichment lookup: normalize identity signals and return requested enrichment fields with confidence, freshness, retrieval time and evidence hash. $0.28/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Full name | |
| No | Email address | ||
| phone | No | Phone number | |
| company | No | Company or organization | |
| location | No | Location | |
| linkedin_url | No | professional profile URL | |
| requested_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does substantial work: it discloses the accountless operation mode, the normalization behavior, the exact return metadata (confidence, freshness, retrieval time, evidence hash), and per-call pricing via x402. It stops short of describing failure modes (e.g., no-match or low-confidence behavior), which is a gap for a paid external lookup, but the disclosure is meaningfully richer than the 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?
A single dense sentence that front-loads purpose, then delivers scope, behavior, and pricing in order of importance. Every clause earns its place — accountless mode, normalization, return metadata, and cost — with zero filler or repetition of schema content.
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 lookup tool with no output schema, the description compensates well by disclosing the return envelope (confidence, freshness, retrieval time, evidence hash). It lacks guidance on zero-match/low-confidence handling and data-source caveats, which matter for a paid API, but the core call contract — inputs, outputs, cost — is sufficiently covered for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 86%, so the schema already documents the parameters well. The description adds genuine framing value with 'normalize identity signals,' clarifying that the identity params (name, email, phone, company, location, linkedin_url) are fuzzy inputs to be normalized rather than exact-match keys, and 'requested enrichment fields' maps directly to the required requested_fields param. This framing goes beyond the schema's simple field descriptions.
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 ('people-enrichment lookup'), the scoping qualifier ('Accountless'), and the behavioral core ('normalize identity signals and return requested enrichment fields'). The addition of return metadata (confidence, freshness, retrieval time, evidence hash) makes it clearly distinguishable from siblings like people_record_normalize (normalization-only) and people_search (search vs. enrich).
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 'Accountless' qualifier and '$0.28/call via x402' pricing imply this is the pay-per-call, no-account path versus account-based alternatives, which provides useful context. However, it never explicitly names sibling tools or states when NOT to use it (e.g., when you have an account, or when you only need normalization, which people_record_normalize covers). Usage is 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.
Normalize supplied person identity signals into one stable people record with a deterministic id and derived domains, without inventing employment or location data. $0.28/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Full name | |
| No | Person email address | ||
| domain | No | Company domain | |
| company | No | Company or organization | |
| last_name | No | Last name | |
| first_name | No | First name | |
| linkedin_url | No | professional profile URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden and does so well: it reveals deterministic id generation, derived domains, and explicitly states it will not fabricate employment or location data. It also adds cost context ('$0.28/call via x402'), which is useful operational transparency.
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 entire definition is one efficient sentence that leads with the core purpose, then states the key behavioral constraints, and ends with pricing. Every clause adds information; 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?
Although there is no output schema, the description tells the agent what the result will contain: a stable people record, deterministic id, and derived domains. Combined with the fully documented parameter schema and the no-invention caveat, the tool is adequately specified for selection and invocation. It could go further by describing minimal input expectations or error behavior, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters are already documented in the schema, so the baseline is 3. The description adds the framing 'person identity signals' but does not clarify how parameters interact, which signals take precedence, or how conflicts are resolved. It does not need to compensate heavily because schema coverage is 100%.
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 clear action ('Normalize'), a specific resource ('supplied person identity signals' into 'one stable people record'), and distinguishes the output via 'deterministic id and derived domains'. It also sets boundaries by stating it does not invent employment or location data, which separates it from enrichment-style 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 implies when to use the tool: when you have person identity signals and want a normalized, stable record. However, it does not name alternatives such as people_enrich or people_search, nor does it state explicit conditions for choosing this tool over those siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search people by name, location, skill, title, seniority or company filters using bounded public-reference data; private contact and employment fields are explicitly null. $0.10/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| person_names | No | ||
| search_after | No | ||
| person_skills | No | ||
| person_locations | No | ||
| current_company_names | No | ||
| current_company_domains | No | ||
| current_position_titles | No | ||
| current_company_industries | No | ||
| current_company_specialties | No | ||
| current_company_headquarters | No | ||
| current_position_seniority_level | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses an important behavioral trait: private contact and employment fields are explicitly null, and the data scope is bounded public-reference data. It also mentions pricing. However, it does not disclose whether results are paginated, how they are ordered, response shape, or any rate/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler. The primary purpose and filters are front-loaded, followed by data-scope and pricing details. It could be slightly clearer if broken into two sentences, but it remains efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 optional parameters, no annotations, and no output schema, this description is incomplete. It gives useful scope and pricing context, but omits how to combine filters, what result fields look like, how pagination works, and what error conditions may arise. An agent would still need to infer much from raw schema names and types.
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 schema has 13 parameters with 0% description coverage, so the description must compensate. It does map the main filter dimensions to likely parameters (name, location, skill, title, seniority, company), but it does not explain the value/exclude/exact_match object structure, offset/search_after pagination semantics, or limit behavior. The compensation is therefore partial at best.
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 action ('Search people') on a clear resource, and enumerates the filter dimensions: name, location, skill, title, seniority, and company. It adds a scope qualifier ('bounded public-reference data') that helps set expectations, but it does not explicitly distinguish this from sibling tools like people_enrich or profile_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as people_enrich, profile_search, or tweets_search. It does not state prerequisites, whether at least one filter is required, or when another tool would be more appropriate. The context is only implicit from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purchase an Oblique-controlled prepaid HTTP-data access token in one machine-friendly POST. $1.00/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry all behavioral transparency. It implies a financial side effect ('purchase', '$1.00') but does not disclose payment handling, token expiration, idempotency, or side effects beyond the purchase. This is insufficient for a transaction-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences, with the primary action front-loaded and the pricing model in the second. It wastes no words, though it could have used the second sentence for usage context instead of jargon like 'Oblique-controlled' and 'x402'.
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 an operation that creates a prepaid access token and involves payment, there is no mention of side effects, token expiration, return value, required authentication, or error conditions. Without this context an agent cannot safely invoke the 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?
The schema has one 'input' object with nested properties, but schema description coverage is effectively 0%, and the tool description does not explain the required fields or format. Mentioning '$1/call' hints at the amount/query params but does not tell an agent how to construct the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Purchase'), a specific resource ('prepaid HTTP-data access token'), and a concrete mechanism ('one machine-friendly POST', '$1.00/call via x402'). This gives an agent a clear idea of what the tool does, though it does not explicitly distinguish it from sibling purchase-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as purchase_web_extraction_sample or other x402-related tools. The description states the operation and cost, but it does not explain the conditions that should lead an agent to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search professional profiles using bounded public-reference data, with paging and normalized name/headline/company/location fields; private profile fields Oblique does not hold are explicitly null. $0.30/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| geoId | No | ||
| title | No | ||
| school | No | ||
| search | No | ||
| lastName | No | ||
| location | No | ||
| firstName | No | ||
| followerOf | No | ||
| industryId | No | ||
| pastCompany | No | ||
| currentCompany | No | ||
| requestContext | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses paging, normalized fields, null handling for private data, and pricing, which adds value. However, it omits details like response format, rate limits, authentication requirements, or any side effects. For a search tool, the read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and avoids waste. It efficiently conveys the primary function, data scope, and pricing. It could be slightly more structured by separating concerns, but overall it is well-organized and concise.
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 13 parameters with zero schema descriptions, no output schema, and no annotations, the description is severely incomplete. It does not explain how parameters interact, paging behavior, or what the response structure looks like. The pricing and data-scope notes are helpful, but an agent would struggle to call this tool 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?
With schema description coverage at 0% and 13 parameters, the description must compensate by explaining parameter usage, but it does not. It mentions normalized fields like name/headline/company/location, but none of the specific parameters (geoId, followerOf, industryId, requestContext, etc.) are described. The description adds no meaning to any 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?
The description clearly states the tool searches professional profiles, specifies the data scope as bounded public-reference data, and mentions paging and normalized fields. It differentiates from siblings like people_search and people_enrich by highlighting the bounded public-reference nature and explicit nulls for private fields, making its purpose 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 description implies usage for searching public professional profiles and notes the data is bounded, but it does not explicitly name alternative tools or provide when-to-use/when-not-to-use guidance. The mention of pricing and field normalization gives context, but no direct comparison to similar sibling tools like people_search is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is this contract an upgradeable proxy, and where does its current code live? Returns the proxy standard, implementation, admin and beacon addresses, whether the implementation has code, and the storage slots and block read. Base, Ethereum and major L2s; optional raw storage slots decoded. $0.003/call via x402 (Base or Solana) or MPP. Also GET with query parameters. Free worked example: GET /api/v1/proxy-implementation/example.
| Name | Required | Description | Default |
|---|---|---|---|
| block | No | 'latest' (default) or a decimal block number; explicit blocks are immutable and cached longer. | latest |
| chain | No | Chain name (base, ethereum, optimism, arbitrum, polygon) or chain id (8453, 1, 10, 42161, 137). Default base. | base |
| slots | No | Up to 4 extra raw storage slots to read and decode: each a 0x bytes32 or a decimal slot number. GET accepts a comma-separated list. | |
| address | Yes | Contract address to inspect, 0x plus 40 hex characters (any case). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses returned fields, optional raw storage decoding, supported chains, payment mechanism, price, GET support, and a free example. It stops short of error behavior and invocation limits beyond price.
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 definition is front-loaded with the core question and return fields, then adds chain, payment, and example details. It is dense but not redundant; pricing and GET notes could be tightened but each sentence has a plausible operational use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must carry return-value and safety context. It enumerates the returned proxy fields and payment model well enough for correct invocation, though it omits failure modes and some corner-case behavior.
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 four parameters are already well documented in the schema. The description adds only a general mention of optional raw storage slots and chain coverage, not meaningfully extending parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific question and resource: checking whether a contract is an upgradeable proxy and locating its current code. It clearly distinguishes the operation from generic contract inspection by naming the proxy standard, implementation, admin, and beacon outputs.
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 opening question and the supported chain list, but there is no explicit when-to-use guidance, no alternatives named, and no exclusions. An agent can infer the tool's niche, but the definition does not route between this and any sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy a bounded machine-readable extraction sample from one HTTPS webpage. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTPS page to extract | |
| idempotency_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses cost ($0.01/call via x402), boundedness, and that it targets one HTTPS page. However, it omits details about the output format, idempotency behavior, and failure modes, which are critical for a paid operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and pricing. Every word contributes meaning, and there is no redundancy or 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?
There is no output schema or annotations, so the description must explain what the agent receives and any usage context. It fails to describe the return value (e.g., the extracted content structure), how the idempotency key works, or the exact limits of the 'bounded' sample. This is a significant gap for a paid tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (url has a description, idempotency_key does not). The tool description does not clarify the purpose of idempotency_key and merely restates the URL requirement already present in the schema, adding no new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('buy') and the resource ('a bounded machine-readable extraction sample from one HTTPS webpage'). It also includes the cost and protocol, which helps differentiate it from free extraction tools, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like web_extract or fetch_x402_content. The description implies it is for inexpensive sample extraction but does not state prerequisites, exclusions, or scenarios where other tools are preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and synthesize supplied web pages into a cited decision packet with structured JSON findings. $0.05/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| question | Yes | ||
| idempotency_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does disclose meaningful behavioral context for a tool with no annotations: it is a paid call ('$0.05/call via x402') and produces cited, structured JSON output. However, it does not explain how the question parameter shapes the synthesis, how multiple URLs are processed, or what happens on failure or duplicate idempotency_key submissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, action first, no filler. The cost is separated cleanly as its own factual statement, and every word contributes to the tool's purpose or its commercial constraint.
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 tool with no annotations, no output schema, and three required parameters, the description is too thin. It omits the role of question, idempotency semantics, output structure beyond 'JSON findings', and when to choose this over closely related siblings.
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 for the three required parameters. It only hints at urls through 'supplied web pages'; question and idempotency_key are entirely unexplained, leaving an agent without enough meaning to invoke the tool correctly.
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 clear verb phrase ('extract and synthesize'), a specific resource ('supplied web pages'), and a concrete output ('cited decision packet with structured JSON findings'). The decision-packet framing helps distinguish it from raw extractors like web_extract or batch_url_json, though it does not explicitly name a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as answer_with_sources, web_extract, or purchase_web_extraction_sample. The phrase 'decision packet' implies a use case, but there is no when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Did a price change on an x402 Bazaar listing pay off? Give one listing's resource_url or a seller_payto address (25 listings per page) and a window_days (7–90, default 30): replays the reported price history from daily snapshots, marks every repricing event with 30d calls and payers before and after it, computes each event's revenue counterfactual in USDC on the observed post-change volume with a one-line verdict, and compares against peers sharing the listing's first tag. Free example: GET /api/v1/reprice-regret/example. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Opaque paging cursor from a previous seller_payto response. | |
| network | No | Optional CAIP-2 network filter, e.g. 'eip155:8453' or 'solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d'. | |
| window_days | No | How many snapshot days back from the latest snapshot to replay (7–90, default 30). | |
| resource_url | No | One listing: the resource URL exactly as the x402 Bazaar reports it (http/https). Mutually exclusive with seller_payto. | |
| seller_payto | No | All listings paid to this address (the payTo the Bazaar reports); up to 25 per page with a cursor. Mutually exclusive with resource_url. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and handles it well: it discloses that the tool replays snapshots, compares 30d calls/payers before and after each repricing, derives a counterfactual, and compares peer tags. It also discloses cost ($0.01/call via x402) and provides a free example endpoint, so an agent knows the operational and financial implications before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence front-loaded with the motivating question and required inputs, followed by the analysis pipeline, cost, and example endpoint. Every clause earns its place; there is no filler or redundant restatement of 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?
No output schema exists, but the description compensates by specifying the computed outputs: per-event revenue counterfactual in USDC, a one-line verdict, and peer comparison. Combined with full schema coverage for parameters and the pricing/example details, an agent has enough to decide when and how to call this 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 the baseline is 3, and the description still adds integration-level meaning: resource_url targets one listing, seller_payto targets up to 25 listings per page, and window_days controls the replay horizon. It reinforces the mutual-exclusivity of the selector parameters without simply repeating 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 opens with a pointed question ('Did a price change... pay off?') and then specifies the exact analytical actions: replays price history from daily snapshots, marks repricing events, computes a USDC revenue counterfactual, and compares against peers. This clearly scopes the tool and differentiates it from sibling bazaar/x402 tools even without naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives the exact invocation pattern: provide a resource_url or seller_payto address, plus an optional window_days, and clarifies that seller_payto results are paginated at 25 listings. It does not explicitly name alternatives or when-not-to-use cases, but the intended use case is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer a concise research question from one bounded web search: cited answer, source URLs/labels with retrieval timestamps, honest insufficient-evidence refusal, and a receipt of the upstream cost. Optional domain scope and freshness. $0.01/call via x402. Free preview of the shape: GET /api/v1/research-answer/preview.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| question | Yes | One concise research question | |
| freshness | No | Only sources from the last day/week/month/year | |
| max_sources | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses a lot: it returns cited sources with retrieval timestamps, will honestly refuse on insufficient evidence, charges $0.01/call via x402, and offers a preview. This goes well beyond a generic 'research the question' statement.
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 with the main action and output contract front-loaded; pricing and preview are useful extras. No filler, though the first sentence is a long list of output guarantees.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema or annotations, the description covers the output contract, refusal behavior, cost, optional inputs, and a preview endpoint. It doesn't detail exact response formatting/x402 invocation, but gives enough for an agent to select and call 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 covers half via descriptions for question and freshness, and the description adds that scope and freshness are optional. However, max_sources is left unexplained in both schema and description, so the text only partially compensates for the coverage 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 ('Answer') and resource ('research question from one bounded web search'), and enumerates the output contract (cited answer, source URLs/labels with retrieval timestamps, refusal, receipt). It is clear about what it produces, though it does not explicitly contrast with sibling answer_with_sources or web_extract.
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 scope: use for one concise research question needing one bounded web search, with optional domain/freshness controls. It does not name alternatives or conditions to avoid, so it stops at 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite text to match an instruction — change tone, formality, length, or reading level ("make it formal", "simplify for a 10-year-old") with deterministic output. $0.005/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to rewrite (truncated to 8,000 characters) | |
| instruction | Yes | Rewrite instruction, e.g. "make it formal" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden of disclosing behavior. It adds useful details: deterministic output and cost ($0.005/call). It does not mention output format or error handling, but for a simple tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose, gives examples, and notes cost and determinism without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, full schema coverage, no output schema), the description provides a complete picture: what it does, examples, and key behavioral traits. It could mention return value explicitly, but that is implied by 'rewrite'.
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 schema already documents both parameters with descriptions (100% coverage), and the description enriches understanding by providing concrete instruction examples and the range of transformations (tone, formality, length, reading level), adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Rewrite text') and defines the scope ('to match an instruction'), including examples of transformations. It distinguishes itself from sibling tools like summarize_text and classify_text by focusing on rewriting rather than summarization or classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: whenever text needs rewriting to match an instruction. However, it does not explicitly mention alternatives or exclusions, but the examples imply specific use cases, so it meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Route protocol, market-activity, and paid-service discovery tasks through Agent Economy read-only MCP data, preserving free top-one and paid ranked top-three results with evidence timestamps and qualified handoff sessions. $0.01/call via x402 (free tier: 3 queries/day/wallet, returns top-1 result only).
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| constraints | No | ||
| seller_delivery_receipt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It explicitly discloses read-only operation, the $0.01/call x402 cost, the 3-query/day free tier, and the free-vs-paid top-1/top-3 result difference. It omits failure modes and exact handoff/evidence behavior, but safety and pricing are covered.
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 just two sentences, both contributing useful information (scope + payment/result tiers). However, the first sentence is dense and jargon-heavy, making it harder to parse quickly.
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 tool has nested parameters, zero schema property descriptions, and no output schema, yet the description never defines the output shape, the meaning of 'qualified handoff sessions', or how paid mode is selected. An agent gets enough to know what the tool does, but not enough to predict the exact call/response contract.
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 0% schema description coverage, the description must explain the parameters; it only loosely hints that `task` can be a protocol, market-activity, or paid-service discovery query. It gives no semantics for `constraints` (chain, category, max_price) or `seller_delivery_receipt`, so an agent cannot confidently construct these 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 names a concrete action — 'Route ... tasks' — and points at a specific resource ('Agent Economy read-only MCP data'), while also stating free/paid result behavior. It lacks sibling differentiation and leaves jargon ('qualified handoff sessions') unexplained, but the core purpose is identifiable.
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 conveys when to use the tool: for protocol, market-activity, and paid-service discovery tasks, with a free-tier caveat. It does not explicitly contrast route_task with sibling routing tools like agentcore_route or mpp_route, nor 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.
Run a short Python program in an isolated sandbox and get back exit code, stdout, stderr, duration and up to 3 artifact files from ./out/. Python 3.12 + numpy/pandas/requests, no network, 512 MB, 30 s max, 32 KB code, 4 input files of 256 KB. Free compile-only syntax check first at POST /api/v1/run-python/validate. $0.05/call (one run) via x402. Free syntax check: POST /api/v1/run-python/validate. Free worked example: GET /api/v1/run-python/example.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Command-line arguments (sys.argv[1:]), at most 16. | |
| code | Yes | Python 3 program source, at most 32 KB. Runs as main.py in an empty working directory. | |
| files | No | Up to 4 input files written into the working directory before the run. | |
| stdin | No | Text piped to the program on standard input (at most 32 KB). | |
| timeout_s | No | Wall-clock limit for the program in seconds (default 15, max 30). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the sandbox is isolated and has no network, implying no external side effects. It also states the cost and time limits, making the tool's behavior transparent. No contradictions with any annotations are present.
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 contains redundancy, repeating the free syntax check endpoint and listing limits twice. It is organized but could be more concise without losing essential 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?
It covers the environment, limits, cost, and expected output components, but lacks an explicit output schema. The enumerated return fields (exit code, stdout, stderr, duration, artifacts) are sufficient for an agent to understand the result, though more detail on artifact encoding would improve 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?
All five parameters are described in the schema with clear explanations, and the description adds relevant context such as Python 3.12 with numpy/pandas/requests and file size limits. This fully clarifies parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: running a short Python program in a sandbox and returning exit code, stdout, stderr, duration, and artifacts. It also specifies the Python version and libraries, making it distinct from other sibling tools like inference or echo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides constraints (no network, 512 MB, 30 s max, 32 KB code) and cost ($0.05/call) to guide usage. However, it does not explicitly state when to prefer this tool over alternatives, though the free syntax check endpoint offers a validation pathway.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sentiment analysis of a supplied block of text, or of current coverage of a named topic. $0.05/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Text to score directly | |
| topic | No | Topic to gather and score instead of text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the cost model ('$0.05/call via x402'), which is real behavioral context, but says nothing about return format, latency, or what 'coverage of a topic' actually entails (fetching, sourcing, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the purpose front-loaded and the pricing appended. There is no redundancy or filler, though the pricing detail is the only thing beyond the one-sentence core.
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 annotations and no output schema, the description should do more to describe what comes back (a score, a label, confidence, aggregation over a topic). The dual-mode operation and pricing are covered, but the return contract is left entirely undefined.
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% - both text and topic have descriptions plus examples - so the baseline is 3. The description only loosely restates the two modes and adds no format, length, or language constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Sentiment analysis') and covers both operating modes (supplied text or named topic). It does not, however, differentiate itself from nearby siblings like classify_text or summarize_text, which an agent could plausibly confuse it with.
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 'of a supplied block of text, or of current coverage of a named topic' implies when to pass text vs topic, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as classify_text. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current server time as ISO 8601 plus Unix epoch, returned only after settlement — the smallest end-to-end probe of the x402 payment path. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral trait: 'returned only after settlement,' and notes the cost per call ($0.01/call). This is valuable context beyond the basic output description, though it does not cover potential failure modes or exact response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the output and the payment gate, the second adds the cost and use-case context. It is front-loaded and every phrase earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool, the description covers the output format (ISO 8601 + Unix epoch), the settlement requirement, and the cost. Since no output schema exists, a more explicit response structure would improve completeness, but it is already functional for an agent to invoke 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?
The tool takes zero parameters, so the schema is fully self-explanatory. The description adds no parameter details, but none are needed. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the current server time as ISO 8601 and Unix epoch, specifying the exact data provided. This is a distinct, specific resource unlike any sibling tool, so it fully clarifies the tool's purpose.
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 frames this as 'the smallest end-to-end probe of the x402 payment path,' giving clear context for when to use it (testing payment integration). It does not explicitly name alternatives, but the sibling list contains no similar tool, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an x402 settlement actually landed on Base mainnet: real JSON-RPC receipt lookup, decoded USDC Transfer events with payer/payee/amount, success-or-reverted status, confirmation count, and a stored verification_id you can re-fetch later as a receipt. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | Transaction hash to verify on Base mainnet | |
| chain_id | No | Chain id (only 8453, Base mainnet, is supported) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses several behavioral traits: performs a real on-chain lookup, decodes specific USDC Transfer event fields, returns a verification_id for later re-fetch, and costs $0.01 via x402. It does not detail edge cases like invalid tx_hash or network failures, but covers core behavior well.
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 main purpose. The first sentence efficiently lists key features in a compact list, and the second states pricing. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, it enumerates the expected return data (receipt lookup, decoded events, status, confirmations, verification_id). It also notes cost. Given the modest parameter set, the description is sufficiently complete for an agent to decide and invoke.
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 already describes both parameters (tx_hash format and chain_id default/limitation) with 100% coverage. The description adds context about the purpose (verifying x402 settlement) but does not add new parameter-level details 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?
Begins with a specific verb+resource: 'Verify an x402 settlement actually landed on Base mainnet.' It clearly distinguishes itself from sibling tools by enumerating unique capabilities: real JSON-RPC receipt lookup, decoded USDC Transfer events, success/reverted status, confirmation count, and stored verification_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it is for verifying an x402 settlement on Base mainnet after the fact. The mention of 'real JSON-RPC receipt lookup' implies a more thorough check than simpler status tools, but it does not explicitly name 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.
Operational context check meant to be called on every run: current UTC time plus the latest x402 Bazaar pulse, with source evidence and whether this wallet has called before. $0.005/call via MPP (Tempo), x402 Solana, or x402 Base; repeat calls welcome.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses cost per call, payment routes, repeat-call friendliness, and the kind of stateful information returned (whether this wallet has called before). It stops short of explicitly stating there are no side effects, but 'operational context check' strongly implies a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences, front-loaded with the core purpose and contents, then adding pricing and repeat-call guidance. Every clause earns its place; there is no filler or repetition of schema/annotation data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter operational check with no output schema, the description is largely complete: it explains when to call, what information is returned, how much it costs, and which routes can pay. It does not specify the exact output structure, but the listed contents are sufficient for an agent to understand what it will receive.
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?
This tool takes zero parameters, so the input schema is empty and there is no parameter semantics to explain. Per the baseline for zero-parameter tools, a 4 is appropriate since the description does not need to compensate for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('check') and resource ('operational context') and enumerates concrete contents: current UTC time, latest x402 Bazaar pulse, source evidence, and prior wallet activity. This clearly distinguishes it from similar siblings like server_time and bazaar_pulse by combining those into a single context 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?
It explicitly states when to use this tool ('meant to be called on every run') and even says repeat calls are welcome. It does not name alternatives or give when-not-to-use guidance, but the timing guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current Solana slot, block height and block time plus a prioritization-fee summary (min, median, p75, max, suggested) over the recent slots the public RPC reports; optionally scoped to up to five writable accounts. $0.002/call via x402 (Solana or Base) or MPP (Tempo); repeat calls welcome, readings cached 8 s.
| Name | Required | Description | Default |
|---|---|---|---|
| accounts | No | Optional: up to 5 comma-separated base58 pubkeys; the fee sample is then limited to transactions that lock these accounts writable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details: it is a read-only data fetch (implied by 'current' and 'summary'), it supports optional account scoping, and it notes caching and pricing. Without annotations, this transparency helps agents understand side effects and performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the core purpose and then add optional scoping and operational details. It avoids verbose explanations and stays focused on essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description is complete: it specifies the returned data (slot, height, time, fee summary), optional scoping, and operational details like pricing and caching. It does not describe an output schema, but the input is simple and the output is implied by the purpose, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description reiterates the only parameter ('accounts') with the same semantics as the schema: optional comma-separated pubkeys that scope the fee sample. While the schema already covers this, the description reinforces it and adds context that it limits to 'writable accounts', enhancing clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns current Solana slot, block height, block time, and a prioritization-fee summary. It also mentions optional scoping to up to five accounts, making the purpose specific and distinguishable from generic fee tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by mentioning pricing ($0.002/call) and caching (readings cached 8 s), which implies call frequency considerations. However, it does not explicitly state when to use this tool over alternative fee or block-info tools, so guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize any text as bullet points, a paragraph, or a one-liner — deterministic (temperature 0) flash-model summarization sized for agent pipelines. $0.008/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to summarize (truncated to 8,000 characters) | |
| style | No | Output shape | paragraph |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds value by disclosing determinism (temperature 0), flash-model selection, and pricing context, but lacks deeper detail on output format edge cases or failure 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?
A single, information-dense sentence that front-loads the core purpose and appends relevant constraints (deterministic, cost) without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool without an output schema, the description covers purpose, output styles, and operational context (determinism, cost). It implicitly defines the return as the summarized text, though not explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (text and style) with descriptions and an enum, so the description adds no new parameter-level information. Baseline 3 applies given >80% schema 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?
Description clearly names the verb 'Summarize' and the resource 'any text', plus lists three output styles. This distinguishes it from siblings like classify_text, extract_keywords, and rewrite_text.
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?
Description implies the tool is for agent pipelines and notes deterministic behavior and cost, but does not explicitly state when to prefer it over alternative text-processing tools or 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.
Recent Solana token-flow activity for one wallet or token mint: per-transaction token balance deltas with direction, counterparties, an activity read (transfer, swap, mint_burn) and RPC provenance, over a bounded window. $0.02/call via x402 (Solana or Base) or MPP; repeat calls are cache-backed.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | No | Keep only transactions that moved this mint. | |
| limit | No | Most recent transactions scanned; filters apply within them. Page with cursor.before. | |
| before | No | Signature cursor from a previous response (cursor.before) to page further back. | |
| address | Yes | Solana wallet owner or token mint (base58). | |
| activity | No | Keep only transactions of this read: transfer, swap (a public DEX program was involved), mint_burn. | any |
| direction | No | For a wallet subject: keep transactions where the wallet received (in) or sent (out) tokens. | any |
| window_hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It does disclose that the call is read-oriented, cache-backed, and costs $0.02, and it describes the return content, but it does not explicitly confirm that no state is modified, nor does it mention error conditions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loads the core purpose. The second sentence adds useful operational details about cost and caching, though the phrase 'activity read' is slightly awkward and the long parenthetical list could be tightened.
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 that there is no output schema, the description does a good job summarizing what a response will contain: balance deltas, direction, counterparties, activity type, and RPC provenance. It also covers the bounded time window, cost, and caching; it could be more complete by explicitly addressing pagination behavior, but the schema already covers cursor usage.
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 86%, with six of seven parameters described, and the description reinforces the meaning of activity, direction, and the bounded window. However, window_hours lacks a description, and the description itself adds little semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose as retrieving recent Solana token-flow activity for a wallet or mint, and it specifies the output concepts: per-transaction balance deltas, direction, counterparties, activity type, and RPC provenance. It is slightly less crisp because 'activity read' is an odd phrasing, but the overall intent is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to choose this tool over sibling tools such as wallet_analyze, wallet_spy, or token_metrics. It mentions cost and caching but does not state use cases, alternatives, or conditions under which this tool is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get free-source token price, TVL, DEX volume, fees and yield metrics. $0.003/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Base | |
| symbol | No | ||
| token_address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It correctly signals a read-only operation ('Get') and discloses a per-call cost and payment method ($0.003/call via x402), which is useful. It does not mention response shape, failure modes, or rate limits, but for a simple read-only metrics tool the cost disclosure adds meaningful 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?
One sentence with no redundancy; the main action and key output domains are front-loaded and the cost is appended efficiently. The phrase 'free-source' is slightly awkward but not bloated.
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, no annotations, and 0% parameter coverage, the description is too thin to fully support correct invocation. It lists the metric categories and cost but omits the required token_address parameter, chain behavior, and any detail about the return structure.
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 needed to explain token_address, chain, and symbol. It does not: no mention that token_address is required, no list of supported chains, and no guidance on when symbol is appropriate. The word 'token' is the only indirect link to token_address.
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 uses a clear verb ('Get') and enumerates a specific set of metrics (price, TVL, DEX volume, fees, yield), making the tool's purpose readily identifiable. It does not explicitly contrast it with siblings like crypto_price or trading_signals, but the metric list distinguishes it enough.
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 choose token_metrics over the many related sibling tools (e.g., crypto_price, market_intel, trading_signals). The description only states what it returns, leaving the agent to infer appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a bounded, transparent DEX-volume trading signal from public DEX volume, TVL and fee data. $0.005/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Base | |
| symbol | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description is the only safety and behavior disclosure. It usefully states the tool reads public DEX data and charges $0.005/call via x402, and characterizes the signal as bounded and transparent. However, it does not define 'bounded', state the return shape, or mention error or rate-limit behavior, so transparency is only partial.
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 with no filler; the return value and pricing are front-loaded. The adjectives 'bounded' and 'transparent' are vague but not bloated. For its length, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and undocumented parameters, this definition is too thin. An agent cannot learn what the signal looks like, which chains are supported, whether symbol is optional, or what 'bounded' limits the value to, so the definition is incomplete for reliable 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?
The schema provides no parameter descriptions (0% coverage), and the description never mentions chain or symbol, their formats, optionality, or allowed values. The tool name and property names imply the inputs, but the description does not compensate for the schema 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 specific action ('Return') and clearly identifies the resource: a 'bounded, transparent DEX-volume trading signal' built from public DEX volume, TVL, and fee data. This distinguishes it from generic data tools like crypto_price or token_metrics, though it does not explicitly name a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call trading_signals instead of token_metrics, market_intel, or sentiment. An agent must infer from the name and the DEX-volume mention that this is for a trading opinion, so the routing burden is entirely on the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search publicly indexed social posts using words, phrases, hashtags, account and date filters; returns bounded tweet-like results with source links. $0.005/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| since | No | ||
| until | No | ||
| words | No | ||
| phrase | No | ||
| hashtags | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states results are 'bounded' and include 'source links', and it mentions the cost per call. However, it does not disclose authentication requirements, rate limits, error handling, or the exact meaning of 'bounded'. It gives some behavioral context but lacks depth for a tool with no annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the action, lists filters, and states the output nature and cost. There is no filler or redundancy, and it is appropriately sized for the information it provides.
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 7 parameters, no annotations, and no output schema, the description is minimal and incomplete. It lacks parameter-specific details, response format specifics (beyond 'bounded tweet-like results'), and any error or edge-case information. An agent would need to guess parameter semantics and behavior, making it insufficient for reliable 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 0%, so the description must explain parameters. It lists categories (words, phrases, hashtags, account, date filters) but does not map them to the actual parameter names (to, from, since, until, words, phrase, hashtags) or explain their formats. An agent cannot confidently determine which parameter corresponds to which filter or what values are expected, making this inadequate for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches publicly indexed social posts and returns tweet-like results, which is a specific verb and resource. It distinguishes from general web search by mentioning 'social posts' and 'tweet-like results', though it doesn't explicitly name a sibling alternative. This is clear enough for an agent to understand the tool's core 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 description implies usage for social post searching via the mention of 'words, phrases, hashtags, account and date filters', but it does not provide explicit when-to-use guidance or name alternatives. An agent could infer when to use this tool (when needing social posts), but there are no explicit exclusions or comparisons to other search tools like web_search or profile_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch fresh OHLCV candles for one US ticker with optional technical indicators and source/freshness evidence. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | One US-listed ticker, uppercase letters only. | |
| interval | Yes | ||
| lookback | Yes | ||
| indicators | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It usefully adds cost ($0.01/call via x402), freshness, and source/freshness evidence. But it omits rate limits, authentication requirements, error behavior, and output structure, which are material for a paid market-data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence communicates the core action, scope, optionality, and cost with no filler. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should cover more of the invocation context. It leaves interval/lookback semantics underspecified, does not describe what the returned 'source/freshness evidence' looks like, and gives no failure-mode guidance. The tool is usable but not fully self-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 only 25%, so the description must compensate. It clarifies ticker scope and mentions that indicators are optional, but it does not explain the semantics of 'interval' or 'lookback'—notably whether lookback is measured in days or candles. This leaves a meaningful 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 uses a specific verb ('Fetch') and names the exact resource ('fresh OHLCV candles for one US ticker'), plus optional technical indicators and source/freshness evidence. This clearly distinguishes it from crypto-focused or general market 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?
The intended use case is clear: requesting fresh candle data for a single US equity. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a Base wallet: balances, bounded transfers, token holdings and counterparties from a public explorer index. $0.005/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet_address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It reveals that data comes from a public explorer index and that the caller pays $0.005/call, which implies a read-only query rather than a mutating operation. However, it leaves the important qualifier 'bounded transfers' unexplained, and mentions nothing about auth, rate limits, or error 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?
One sentence with no filler. It packs the action, target, scope, data source, and pricing into a compact front-loaded string, making it easy to scan and understand.
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 tool is low-complexity with one parameter and no output schema, and the description does give scope and source. But it does not explain what 'bounded transfers' means, nor does it differentiate itself among a large set of sibling wallet tools, leaving some ambiguity about the exact deliverable and boundaries of the analysis.
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 schema has a self-explanatory wallet_address with a strong regex, and the description supplies domain context by specifying that the address is a Base wallet and that the analysis comes from a public index. For a single parameter this is sufficient to compensate for the 0% schema-description 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?
The description uses a specific verb ('Analyze') and names a clear resource (Base wallet), then enumerates the exact analysis scope: balances, bounded transfers, token holdings, and counterparties. It does not explicitly differentiate from sibling tools like base_wallet_profile or base_transfer_search, but an agent can infer the general purpose 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?
No guidance is given about when to prefer this tool over any of the many wallet- or transfer-related siblings (e.g., base_wallet_profile, base_transfer_search, base_usdc_balance). An agent is left guessing whether to call this versus a more-specific sibling for a given need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect an EVM wallet for recent transactions, token flows, DEX swaps, NFT activity, counterparties and a heuristic risk score. $0.03/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| address | Yes | EVM wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the commercial trait "$0.03/call via x402", which tells the agent this is a paid, payment-protocol-gated call rather than a plain read. It does not state whether the operation is read-only, whether it requires x402 payment setup beforehand, or anything about latency/rate limits, leaving meaningful gaps.
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 with zero filler: capability list first, cost/access model second. Nothing is repeated from the schema or title, and the pricing constraint is placed where it is easy to find.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the fields an agent will get back, which is good compensation. But it omits chain semantics entirely and provides no routing guidance against the several wallet-oriented siblings, which is the main thing an agent needs before calling this over wallet_analyze.
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%: the address parameter is documented in the schema, but the chain parameter (enum ethereum/base, default base) has no description anywhere. The description mentions "EVM wallet" generically and never indicates multi-chain selection or which chains are supported, so it does not compensate for the coverage gap on half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("Inspect an EVM wallet") and enumerates the concrete outputs: transactions, token flows, DEX swaps, NFT activity, counterparties, risk score. That is far more specific than a tautology. However, it gives no differentiation from close siblings like wallet_analyze, base_wallet_profile, or token_flow_activity, so an agent cannot tell which to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no named alternative. The description never says how this differs from wallet_analyze or base_wallet_profile, which appear to overlap heavily. Usage is only implied by the description of scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured JSON from a web page: return URL, title, meta description, cleaned text, extraction timestamp, and payment status for agent workflows. $0.03/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page to extract |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does add genuine behavioral context: the returned payload fields, that results are for 'agent workflows', and that the call costs $0.03 via x402, which tells the agent payment is required. It says nothing about error handling, timeouts, JS rendering, or rate limits, so gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the output fields and price are packed in efficiently. Slightly dense, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description compensates by listing the return fields and the payment mechanism. What remains missing — error behavior and any preconditions on the URL — is modest given the tool's simplicity.
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 there is only one parameter, so the schema already documents 'url'. The description adds nothing about format, redirects, or constraints beyond what the schema states, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Extract structured JSON from a web page') and even enumerates the fields returned, so the agent knows exactly what it produces. It does not, however, distinguish itself from close siblings like extract_json, batch_extract, or x401_batch_extract, which is where a 5 would come from.
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 when-to-use or when-not-to-use guidance, no mention of prerequisites, and no routing to alternatives such as batch_extract for multiple URLs or web_search for discovery. The agent must infer that this is the single-page extractor purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a bounded web search over a public encyclopedic reference index: title, URL and snippet per hit, with paging and a total count. $0.01/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses boundedness, paging, total count, result fields, and per-call cost, which is meaningful. However, it does not discuss rate limits, authentication needs, query semantics, or failure behavior, so some behavioral context remains undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tightly-worded sentence with no filler. Every clause adds value: the resource scope, the return shape, paging behavior, and cost are all compressed without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool, the core call is mostly understandable: the query is obvious, and limit/offset are inferable from the schema. But the absence of sibling-routing guidance and parameter-level detail, combined with no annotations or output schema, leaves meaningful gaps in the overall contextual picture.
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 for missing parameter explanations. It mentions paging and a total count, which hints at offset behavior, but it does not explain query semantics, what limit controls, or how offset interacts with paging. The schema's min/max/defaults are useful but not accompanied by human-readable parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Run a bounded web search'), a resource ('public encyclopedic reference index'), and the output fields ('title, URL and snippet per hit'). It is clearly distinguishable from siblings like web_extract and tweets_search, but it does not explicitly call out what it is not or name an alternative.
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 prefer this tool over web_extract, research_answer, tweets_search, or other search-like siblings. The intended use is only implied by the resource type, with no exclusions or alternative routing advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an x401 proof and extract JSON from up to 10 public URLs in isolated compute with an idempotent reconciled manifest. $0.02/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| x401_proof | Yes | ||
| idempotency_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions idempotency and cost, but not the mutation safety (did it modify anything?), response format, error handling, or failure behavior. The phrase 'idempotent reconciled manifest' adds some value, but it does not state whether it is read-only or what side effects occur. This is a significant gap for a tool that involves paid calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and key constraints. It avoids redundancy and is appropriately sized, though the cost detail could be relegated to a note. Overall, it is efficient and well-structured.
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 (nested items, x401 proof, paid) and the absence of annotations or output schema, the description is incomplete. It omits critical usage details like how to construct x401_proof, what the 'idempotent reconciled manifest' returns, and how to handle failures. An agent would need to inspect the schema deeply, but with 0% schema description coverage, even the schema lacks explanations for many fields.
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%, and the description fails to explain any parameter semantics. The items array's structure (url, schema) is not described at the top level, and idempotency_key is only self-explanatory by name. The description does not compensate for the lack of schema descriptions, leaving the agent with minimal guidance on how to construct valid calls.
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 action (verify, extract), the resource (x401 proof, URLs), and the key constraints (up to 10 public URLs, isolated compute, idempotent manifest). It is specific enough to distinguish from general extraction tools, though it does not explicitly name a sibling to compare against.
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 implies usage for batch extraction with an x401 proof, but does not specify when to use this tool versus alternatives like batch_extract or batch_url_json. It mentions 'isolated compute' as a context but lacks explicit when-not or alternative conditions, leaving the agent to infer the differentiator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Point it at any URL that claims to sell over x402 and get a conformance verdict: does it actually return a 402, is the challenge valid v2 JSON, are the payment requirements complete, is the price above the facilitator settlement floor, and does the PAYMENT-REQUIRED header match the body. $0.02/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The https URL of the x402 endpoint to verify | |
| method | No | HTTP method the endpoint sells on | GET |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool makes a paid call ($0.02/call via x402), which is a critical behavioral trait an agent must know before invoking. It also reveals the scope of the check (a conformance verdict with specific criteria). It does not mention side effects, rate limits, or failure modes, but the paid-call disclosure is significant and goes beyond what the schema shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core action and then lists the verification criteria in a scannable list. The pricing note is a single short sentence at the end. Every word earns its place; no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters, 100% schema coverage, and no output schema, the description is quite complete. It tells the agent what the tool does, what it checks, and that it costs money. The only gaps are the lack of an explicit output format (though no output schema exists) and no mention of error cases or prerequisites like needing a funded x402 wallet. These are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining what the 'url' parameter is used for (the endpoint to verify) and implicitly that 'method' selects the HTTP method the endpoint sells on. It also adds the pricing context that ties to the call. This is above the baseline because it clarifies the purpose of the parameters in the verification workflow, though it doesn't add format-level 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 opens with a specific verb ('verify') and a precise resource ('any URL that claims to sell over x402'), then enumerates the exact conformance checks it performs (402 status, valid v2 JSON, payment requirements, price floor, header-body match). This clearly distinguishes it from siblings like x402_facilitator_health or x402_receipt_lookup, which target different x402 aspects.
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 implies when to use it: when you need a conformance verdict on an x402 endpoint. It names the target ('any URL that claims to sell over x402') and the cost ($0.02/call), which helps an agent decide. However, it does not explicitly state when not to use it or name alternatives like x402_facilitator_health for network-level checks, 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.
Is the x402 payment rail up right now? Parallel live probes of the two facilitators most production x402 settlement runs through: supported kinds, schemes and networks from one, reachability, HTTP status and latency from the other, which is the one this service settles both its rails through. $0.003/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it performs live probes, checks specific attributes, and mentions the cost per call ($0.003). It implies a read-only health check without explicitly stating non-destructiveness, but the nature of 'probes' makes side effects unlikely. It does not describe return format or error behavior, but the core behavior is transparent enough.
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 a clear question but the second sentence is a dense run-on that tries to pack too much detail into one breath. It could be broken into clearer, more structured sentences. The cost information is useful but adds to the clutter. It is not overly long but lacks crisp structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what is probed but never states what the tool returns or how an agent should interpret the result. Since there is no output schema and no annotations, the description should clarify whether it returns a simple boolean, structured metrics, etc. This is a significant gap for an agent deciding if this tool fits the task and how to use the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so the baseline for parameter semantics is 4. The description does not need to explain parameters because there are none, and the schema coverage is 100% by virtue of being empty.
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 checks the health of the x402 payment rail via parallel live probes of two specific facilitators. It specifies exactly what is measured (supported kinds, schemes, networks, reachability, HTTP status, latency) and distinguishes itself as a health-check tool, differentiating it from siblings like x402_endpoint_verify or settlement_verify.
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 question 'Is the x402 payment rail up right now?' clearly sets the context for when to use it. It implies usage for health monitoring but does not explicitly name alternative tools or exclusion conditions. Since the context is clear and no exclusions are needed, it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a stored settlement-verify receipt by its verification_id — the durable record of an on-chain USDC settlement check (payer, payee, amount, status) issued by settlement_verify. $0.002/call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| verification_id | Yes | UUID returned by settlement_verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the record fields (payer, payee, amount, status), the durable/on-chain nature, and the $0.002/call cost. It doesn't cover error cases or authentication, but for a read-only retrieval the key behavioral traits are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, followed by a meaningful detail about the receipt contents and pricing. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is complete. It explains what the receipt contains, how it is identified, and its cost, covering the return value implicitly. No significant gaps remain.
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%: verification_id is already described as 'UUID returned by settlement_verify'. The description repeats 'by its verification_id' and adds the term 'durable record', but does not add new syntax or format details beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'stored settlement-verify receipt' keyed by verification_id. It explicitly contrasts with the sibling settlement_verify by positioning this as the retrieval of the durable record issued by that tool, making its unique role 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 description implies when to use the tool: after calling settlement_verify, to fetch the stored receipt. It names the issuing tool and the lookup key, but it does not explicitly state when not to use it or name alternatives beyond the natural pairing with settlement_verify.
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.
proxy_implementationanswer_with_sources1 field changedInput schema / properties / question / examplesAdded value: +[
+ "What is the x402 payment protocol?"
+]company_research1 field changedInput schema / properties / ticker / examplesAdded value: +[
+ "COIN"
+]crypto_price1 field changedInput schema / properties / symbol / examplesAdded value: +[
+ "ETH"
+]inference1 field changedInput schema / properties / messages / examplesAdded value: +[
+ [
+ {
+ "content": "Say hello in five words.",
+ "role": "user"
+ }
+ ]
+]sentiment3 fields changedInput schema / properties / text / examplesAdded value: +[
+ "Settlement volume on Base doubled this quarter while prices held."
+]Input schema / properties / topic / descriptionPrevious value: -"Topic to gather and score instead"New value: +"Topic to gather and score instead of text"Input schema / properties / topic / examplesAdded value: +[
+ "agent payments"
+]wallet_spy1 field changedInput schema / properties / address / examplesAdded value: +[
+ "0x970007590aCC5C938cd51345B17AF51B1B40D3Ab"
+]web_extract1 field changedInput schema / properties / url / examplesAdded value: +[
+ "https://example.com/"
+]people_enrich1 field changedInput schema / properties / linkedin_url / descriptionPrevious value: -"LinkedIn profile URL"New value: +"professional profile URL"people_record_normalize1 field changedInput schema / properties / linkedin_url / descriptionPrevious value: -"LinkedIn profile URL"New value: +"professional profile URL"award_flight_searchchat_completionpdl_people_enrichpeople_enrichpeople_record_normalizepeople_searchprepaid_access_tokenprofile_searchrep_agi_prepaid_tokensrep_cheaptokens_buyrep_linkedpanda_searchrep_stableenrich_people_enrichrep_stableenrich_people_searchrep_stableenrich_searchseats_aero_searchweb_searchpayer_profilerun_pythonsolana_priority_feereprice_regret8 fields changedInput schema / descriptionAdded value: +"Exactly one of resource_url or seller_payto is required."Input schema / examplesPrevious value: -[
- {
- "resource_url": "https://api.aidress.ai/pay/agent_funding_lonestaroracle_xyz"
- }
-]New value: +[
+ {
+ "resource_url": "https://x402.shizu.me/crypto"
+ }
+]Input schema / properties / cursorAdded value: +{
+ "description": "Opaque paging cursor from a previous seller_payto response.",
+ "type": "string"
+}Input schema / properties / resource_url / descriptionPrevious value: -"The listing resource URL exactly as the x402 Bazaar reports it (http/https)."New value: +"One listing: the resource URL exactly as the x402 Bazaar reports it (http/https). Mutually exclusive with seller_payto."Input schema / properties / seller_paytoAdded value: +{
+ "description": "All listings paid to this address (the payTo the Bazaar reports); up to 25 per page with a cursor. Mutually exclusive with resource_url.",
+ "type": "string"
+}Input schema / properties / since_dateRemoved value: -{
- "description": "Optional ISO date (YYYY-MM-DD); only snapshots on or after this date are replayed.",
- "type": "string"
-}Input schema / properties / window_daysAdded value: +{
+ "default": 30,
+ "description": "How many snapshot days back from the latest snapshot to replay (7–90, default 30).",
+ "maximum": 90,
+ "minimum": 7,
+ "type": "integer"
+}Input schema / requiredRemoved value: -[
- "resource_url"
-]reprice_regretagent_preflight_bundle1 field changedInput schema / properties / wallet / examplesAdded value: +[
+ "0x4200000000000000000000000000000000000006"
+]agent_return_context1 field changedInput schema / examplesAdded value: +[
+ {
+ "components": [
+ "time",
+ "bazaar_delta",
+ "bazaar_trending"
+ ],
+ "since_snapshot": "2026-08-28"
+ }
+]rep_stableenrich_people_enrich1 field changedInput schema / examplesAdded value: +[
+ {
+ "company": "Analytical Engines",
+ "email": "ada@example.com",
+ "location": "London",
+ "name": "Ada Lovelace",
+ "requested_fields": [
+ "email",
+ "company",
+ "location",
+ "job_title",
+ "linkedin_url"
+ ]
+ }
+]us_equity_snapshot1 field changedInput schema / properties / ticker / examplesAdded value: +[
+ "AAPL"
+]token_flow_activityresearch_answerdune_querydune_queryrep_stableenrich_people_searchrep_stableenrich_search13 fields changedInput schema / properties / current_company_domainsRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "exact_match": {
- "type": "boolean"
- },
- "exclude": {
- "type": "boolean"
- },
- "value": {
- "type": [
- "string",
- "number"
- ]
- }
- },
- "required": [
- "value"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "type": "array"
-}Input schema / properties / current_company_headquartersRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "exact_match": {
- "type": "boolean"
- },
- "exclude": {
- "type": "boolean"
- },
- "value": {
- "type": [
- "string",
- "number"
- ]
- }
- },
- "required": [
- "value"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "type": "array"
-}Input schema / properties / current_company_industriesRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "exact_match": {
- "type": "boolean"
- },
- "exclude": {
- "type": "boolean"
- },
- "value": {
- "type": [
- "string",
- "number"
- ]
- }
- },
- "required": [
- "value"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "type": "array"
-}Input schema / properties / current_company_namesRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "exact_match": {
- "type": "boolean"
- },
- "exclude": {
- "type": "boolean"
- },
- "value": {
- "type": [
- "string",
- "number"
- ]
- }
- },
- "required": [
- "value"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "type": "array"
-}Input schema / properties / current_company_specialtiesRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "exact_match": {
- "type": "boolean"
- },
- "exclude": {
- "type": "boolean"
- },
- "value": {
- "type": [
- "string",
- "number"
- ]
- }
- },
- "required": [
- "value"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "type": "array"
-}Input schema / properties / current_position_seniority_levelRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "exact_match": {
- "type": "boolean"
- },
- "exclude": {
- "type": "boolean"
- },
- "value": {
- "type": [
- "string",
- "number"
- ]
- }
- },
- "required": [
- "value"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "type": "array"
-}Input schema / properties / current_position_titlesRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "exact_match": {
- "type": "boolean"
- },
- "exclude": {
- "type": "boolean"
- },
- "value": {
- "type": [
- "string",
- "number"
- ]
- }
- },
- "required": [
- "value"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "type": "array"
-}Input schema / properties / person_locationsRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "exact_match": {
- "type": "boolean"
- },
- "exclude": {
- "type": "boolean"
- },
- "value": {
- "type": [
- "string",
- "number"
- ]
- }
- },
- "required": [
- "value"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "type": "array"
-}Input schema / properties / person_namesRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "exact_match": {
- "type": "boolean"
- },
- "exclude": {
- "type": "boolean"
- },
- "value": {
- "type": [
- "string",
- "number"
- ]
- }
- },
- "required": [
- "value"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "type": "array"
-}Input schema / properties / person_skillsRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "exact_match": {
- "type": "boolean"
- },
- "exclude": {
- "type": "boolean"
- },
- "value": {
- "type": [
- "string",
- "number"
- ]
- }
- },
- "required": [
- "value"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "type": "array"
-}Input schema / properties / queryAdded value: +{
+ "maxLength": 512,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / search_afterRemoved value: -{
- "maxLength": 512,
- "type": "string"
-}Input schema / requiredAdded value: +[
+ "query"
+]solana_ops_contextmarket_inteltoken_metricstrading_signalswallet_analyzeus_equity_snapshotPay-per-use weather, environment, finance, and on-chain intelligence tools for AI agents via x402.
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
x402 paid API tools for AI agents on Solana: crypto safety, market data, KYB/AML verification.
Pay-per-call crypto market intelligence for AI agents. USDC on Base via x402.
Add one secure layer between your agents and this server.
