AI procurement for web search, news, finance, blockchain, social, enrichment and travel APIs.
Scored across 14 tools
Descriptions work hard to disambiguate ("For a natural-language job choose kevaremesh_route_intent instead", "For 2–5 needs use kevaremesh_quote_provider_batch"), but several clusters still overlap: find_owned_api vs route_intent vs discover_provider_candidates vs use_infrastructure(catalog) all begin a discovery flow, and check_owned_receipt vs locate_owned_receipt vs reconcile_gateway_receipt differ only by which identifier the agent happens to hold. auto_use and use_infrastructure's paid_execute also both describe paid admission/execution, forcing the agent to reason about pre-authorization state before selecting.
Nearly all tools follow a kevaremesh_verb_noun snake_case pattern (check_owned_receipt, quote_provider_route, retrieve_paid_api_result), with a uniform server prefix. Minor deviations: kevaremesh_auto_use is a vague verb-less action name and kevaremesh_agent_commerce_status is a noun phrase rather than an action.
14 tools is within the well-scoped 3-15 band and each maps to a distinct step in an x402 discovery-quote-pay-receipt lifecycle. A couple of pairs (quote_provider_route/quote_provider_batch, the three receipt tools) could plausibly be merged, keeping it just short of ideal.
Coverage is strong across the domain: discovery (owned APIs, third-party candidates, intent routing), schema inspection, free preview, quoting, paid execution, and a full receipt lifecycle including loss recovery and cached result retrieval. Gaps are minor — no spend/budget reporting, purchase history listing, or cancellation/refund path is exposed.
Returns exact URL origins, verified payment-disable flags, historical 0.001 USDC route-fee model and explicit distinction between KEVAREMESH fees and upstream provider money.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description needn't restate that. It adds genuine context beyond annotations: the fee model is described as 'historical' at 0.001 USDC, and it flags an explicit separation between KEVAREMESH fees and upstream provider money — an important interpretive caveat. It does not say whether the call itself is free, whether data is live vs cached, or what happens on an unreachable upstream.
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, front-loaded with the verb 'Returns' and listing the concrete artifacts in descending importance. Slightly list-like and lacks a framing clause, but nothing is padded.
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 parameters, the description must stand in for the return shape, which it does by naming URL origins, payment-disable flags, fee model, and fee-attribution distinction. It's still silent on response format and on how the release status gates the other sibling tools, which keeps it 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?
The tool takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. The description correctly spends its words on what comes back rather than inventing 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 opens with 'Returns' and enumerates the payload (URL origins, payment-disable flags, route-fee model, fee attribution), so an agent can infer this is a status/inspection read. However, it never states the subject plainly as 'report the commerce release state of the service', and it offers no differentiation from siblings like kevaremesh_discover_provider_candidates or kevaremesh_quote_provider_route.
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 among the eleven sibling tools. An agent must guess whether this is a pre-flight check before quoting/routing or a diagnostic to run afterward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI FIRST: if the buyer's agent is pre-authorized for autonomous x402 spending, use this single MCP tool. No human checkout, approvals or manual invoice at KEVAREMESH. On first call return standard x402 MCP PaymentRequired; compatible payer automatically signs within its preconfigured budget and retries the SAME tool with _meta['x402/payment']. Merchant independently verifies and charges only the exact authorized payment. For owned APIs a paid result may require chain confirmations: use this same tool with receipt_id to resume automatically without paying again. For infrastructure buy and activate a 24h Access Pass automatically, then execute the requested operation; if confirmation is pending, resume with returned access_key and the same operation/input. If a facilitator receipt was lost, an independently observed Base transaction_hash may be supplied ONLY alongside an existing receipt_id or access_key for no-charge recovery. If buyer auto-payment is disabled, the buyer's client alone must obtain human authorization before signing. Buyer maintains keys and budgets; no seller-side custody, no repeated charge on uncertain receipts.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| slug | No | ||
| input | No | Original owned API input or live infrastructure operation input | |
| operation | No | ||
| access_key | No | For resuming an already-paid infrastructure pass; private bearer key, no new payment | |
| receipt_id | No | For resuming an already-paid owned result; NEVER buy or sign again | |
| request_id | No | Optional infrastructure operation idempotency key; reuse on retries. Omit for same-input cache per pass, or supply a new key to refresh. | |
| transaction_hash | No | Optional Base transaction hash ONLY for recovering an existing receipt_id or access_key; independently verified, no new payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden and does so well. It discloses the x402 PaymentRequired challenge, automatic signing, merchant verification, no repeated charges, resume via receipt_id or access_key, 24h Access Pass activation, transaction_hash recovery constraints, and the human-authorization fallback when auto-payment is disabled.
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 directive and most sentences carry relevant behavioral information. However, it is a dense single paragraph with long run-on sentences, repeated phrasing such as 'same tool' and 'no repeated charge,' and could be more structured for an agent 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?
For a complex multi-step payment and execution tool with no annotations and no output schema, the description covers most lifecycle states including payment challenge, resume, access-pass pending confirmation, and lost-receipt recovery. It is not fully complete because some parameters are under-explained and the exact output shape is not described.
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 63%, and the schema already documents several key parameters such as receipt_id, access_key, request_id, and transaction_hash. The description reinforces resume and recovery semantics, but it leaves slug unexplained and only implies the kind enum 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 states a specific operation: executing buyer-authorized x402 auto-payments and API operations for owned or infrastructure resources. It is clear enough to identify the tool's job, but it does not crisply distinguish itself from siblings such as kevaremesh_use_infrastructure or kevaremesh_retrieve_paid_api_result.
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 a clear condition for use: when the buyer's agent is pre-authorized for autonomous x402 spending. It also explains resume cases with receipt_id or access_key. However, it does not explicitly name alternatives or state when to prefer a sibling tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks an existing UUID receipt and optionally reconciles a prior Base USDC payment using its real transaction hash if the facilitator response was lost. Never makes a purchase, signs, transfers, repeats a payment or calls an external paid provider.
| Name | Required | Description | Default |
|---|---|---|---|
| reconcile | No | ||
| receipt_id | Yes | ||
| transaction_hash | No | Optional already-executed Base payment hash. Only with reconcile=true; never sends payment. |
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 on side-effect disclosure: it explicitly says the tool never makes a purchase, signs, transfers, repeats a payment, or calls an external paid provider. It still lacks details about authorization requirements, error conditions, and what reconciliation changes internally.
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 and front-loads the core operation before adding safety constraints. Every sentence earns its place by clarifying either purpose or side-effect boundaries.
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 annotations, no output schema, and only 33% schema description coverage, the definition is adequate but not complete. It clearly covers purpose and safety, but an agent still lacks information about return values, authorization needs, and how to interpret reconciliation outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description must compensate. It adds conceptual meaning for all three parameters, especially that receipt_id is an existing UUID, reconcile is optional and tied to a lost facilitator response, and transaction_hash is a real already-executed Base payment hash. However, it does not fully document the receipt_id pattern, the default reconcile behavior, or the exact dependency between reconcile and transaction_hash.
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: 'Checks an existing UUID receipt' and optionally 'reconciles a prior Base USDC payment.' It clearly scopes the operation as receipt-checking plus optional reconciliation, but does not explicitly distinguish itself from nearby siblings such as locate_owned_receipt or reconcile_gateway_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: use it with an existing UUID receipt, and use the optional reconcile path specifically 'if the facilitator response was lost.' It also rules out purchasing behavior, but it does not explicitly say when to prefer this over sibling tools like locate_owned_receipt or reconcile_gateway_receipt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Choose when an agent wants to search several candidate third-party APIs using one free metadata gateway, rather than individually browsing suppliers. Supply the explicit capability and search terms. Discovery returns unverified supplier names and prices, not authentication rights. No provider API is executed and no payment is made.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| capability | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, yet the description still adds substance: no provider API is executed, no payment is made, and results are explicitly unverified metadata rather than authorization. That distinction between discovery and entitlement is real information an agent cannot get from the annotations alone. A residual gap is that nothing is said about result freshness 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 opening sentence is front-loaded with the selection condition, and each following sentence adds a distinct fact. Minor redundancy between the title's "no authorization implied" and the body's "not authentication rights," but nothing is wasted overall.
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 the essential risk profile (read-only, no execution, no payment) and characterizes the return payload as unverified names and prices, which suits a tool with no output schema. However, with zero schema description coverage it leaves the agent guessing at what a valid "capability" string looks like and what limit does, which matters 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 0%, so the description carries the full burden and only partially meets it: "Supply the explicit capability and search terms" maps to the two required fields but explains nothing about valid value formats. The limit parameter (default 5, max 10) is never mentioned, and "explicit capability" is undefined.
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 ("search several candidate third-party APIs") and frames it against an inferior approach ("individually browsing suppliers"). It contrasts implicitly with the owned/quote siblings by stressing "unverified supplier names and prices, not authentication rights," though it never names a sibling tool outright.
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?
"Choose when an agent wants to search several candidate third-party APIs" gives a clear triggering condition plus a rejected alternative (browsing suppliers individually). It stops short of routing the agent to the adjacent quote_provider_batch or find_owned_api tools for follow-up steps, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Choose when an AI already knows a capability or product keyword and wants to find relevant KEVAREMESH-owned APIs and their original contracts. Discover prices, current real paid availability, input limits, and free preview links. For a natural-language job choose kevaremesh_route_intent instead. No purchase or execution occurs here.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Search words from capability, slug or module kind |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description stays consistent while adding useful context: what the agent will see back (prices, current real paid availability, input limits, free preview links) and that no purchase or execution happens. It stops short of describing pagination or result-count behavior beyond the limit parameter, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the selection condition and the alternative; each sentence carries distinct information. The list of returned data points is dense but relevant 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?
With only two parameters, no output schema, and full annotation coverage, the description supplies what an agent needs: input model, what data comes back, and a guarantee of no side effects. Only the undocumented 'limit' behavior keeps it 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 only 50%: 'query' is documented in the schema, but 'limit' has no description anywhere. The description reinforces the query semantics (capability or product keyword, matching the 'slug or module kind' note) but never explains the result cap, so it does not compensate 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?
The description names a specific verb and resource ('find relevant KEVAREMESH-owned APIs and their original contracts') and immediately distinguishes the tool's input model (keyword-driven) from the intent-routing sibling. An agent can identify this tool without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit selection condition ('when an AI already knows a capability or product keyword'), names the alternative for the other case ('For a natural-language job choose kevaremesh_route_intent instead'), and adds a scope exclusion ('No purchase or execution occurs here'). Nothing about when to use vs. avoid it is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free lookup of a 24-item reviewed API's original input schema and whether one of 21 actual algorithms can be previewed. This is not a paid API execution contract or merchant authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine value by stating the lookup is free and conveys neither an execution contract nor an authorization, but says nothing about unknown-slug behavior or the shape of the returned schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core capability front-loaded and the scope disclaimer second. Slight waste in the cryptic numeric counts, but nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does convey the two things returned (original input schema and preview feasibility). But for a lookup keyed on an opaque slug, it omits error/not-found behavior and leaves the '24-item'/'21 algorithms' references unexplained, so an agent still has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the meaning of 'slug'. It only implies that slug identifies one of the reviewed APIs in a 24-item catalog; it never explains what the slug denotes, how to obtain one, or what happens if it is not in the catalog. The regex pattern in the schema covers format but not 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?
States a specific verb (free lookup) and resource (a reviewed API's original input schema) plus a secondary return (whether an algorithm can be previewed). This distinguishes it from siblings like kevaremesh_preview_owned_api and kevaremesh_find_owned_api, though the unexplained '24-item' and '21 algorithms' counts read as internal jargon.
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 negative framing ('This is not a paid API execution contract or merchant authorization') tells the agent what this tool does not do, which implicitly steers execution/authorization intents elsewhere. However, no alternative tool is named and no positive condition for choosing this over preview_owned_api or find_owned_api is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
If an authorized x402 payment was reserved but the network response containing its receipt UUID was lost, compute SHA-256 of the exact original Payment-Signature header locally and supply ONLY the 64-character hexadecimal fingerprint. This free lookup never accepts the raw signature, creates a charge, executes a paid API or contacts a payment facilitator. The fingerprint itself is private bearer material.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_signature_sha256 | Yes | SHA-256 hex of the exact original raw Payment-Signature header. NEVER put the signed payment header itself in this field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and mostly succeeds: it states the call is free, creates no charge, runs no paid API, and contacts no facilitator — plus that the fingerprint itself is bearer material and must not be the raw signature. The remaining gap is failure behavior (what a not-found fingerprint yields) and whether the lookup is authenticated or rate-limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the triggering scenario before the mechanics and the safety constraints. Every clause carries information: condition, derivation, input format, safety profile, secret-handling warning — no restatement of the tool name 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?
No output schema and no annotations, so the description must carry return semantics — and it never states what the response looks like on success (presumably the receipt UUID) or on a miss (unknown fingerprint, ambiguous match). The input side is complete and the security posture is well covered, but the return contract is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so baseline would be 3, but the description earns more by specifying the derivation (SHA-256 of the exact original header, computed locally), the exact accepted form (64-character hex), and reinforcing the prohibition on passing the raw signature. It does not address case-normalization or what to do if the original header was altered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource combination: recovers a lost receipt UUID by supplying a SHA-256 fingerprint of the original Payment-Signature header, with a clear triggering condition (payment reserved, response lost). It does not, however, differentiate itself from plausible siblings such as kevaremesh_check_owned_receipt or kevaremesh_reconcile_gateway_receipt, leaving the agent to infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit triggering condition: use when an authorized x402 payment was reserved but the network response carrying the receipt UUID was lost. No exclusions or named alternatives are given, so an agent must still decide on its own between this, check_owned_receipt and reconcile_gateway_receipt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
After finding an owned API SKU, run its actual reviewed pure algorithm on the healthy replacement database. Limited to 21 no-network modules; other 3 are held. Preview is free, severely rate limited, has no wallet or paid entitlement, and does not imply a commercial release.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| arguments | Yes | Reviewed native API arguments. Total serialized request payload <= 4KiB. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add real value: severe rate limiting, no wallet/paid entitlement, no-network execution, only 21 modules eligible with 3 held, and no commercial-release implication. However, it says nothing about what the call returns (result vs. receipt vs. locator), whether execution is idempotent, or what failures look like for the held modules.
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 action and its precondition front-loaded before the constraint/safety caveats. Every clause carries distinct information (eligibility, cost, rate limit, entitlement, semantics of the result).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter execution tool with no output schema and no annotations, the definition covers input-side constraints well but leaves the output side entirely undefined. An agent cannot tell from the description whether a successful run returns the computed value directly or something it must later redeem, which matters given the presence of receipt-oriented 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 coverage is only 50%: `arguments` is documented (4KiB serialized limit) but `slug` has only a regex and no description in the schema. The description partially compensates by implying the slug is the SKU found earlier and that arguments must match the reviewed contract, but it does not reference the sibling input-contract tool that defines those arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource: run an owned API's reviewed pure algorithm on a healthy replacement database, and it explicitly scopes the call to SKUs obtained via a prior find step. It implicitly distinguishes itself from find_owned_api and retrieve_paid_api_result, but never names those siblings to make the distinction 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?
"After finding an owned API SKU" establishes the prerequisite step, and the free/no-wallet framing signals when to choose this over paid paths. It stops short of naming an explicit alternative (e.g. the paid retrieval tool) or stating when the preview should be skipped, so it is clear context rather than a full when/when-not rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when an AI agent needs one bounded, free comparison for 1–5 specified provider capabilities. Calls only KEVAREMESH Gateway /quote; no provider execution, credentials, wallet signature or payment. Candidate discovery never grants rights to use a provider.
| Name | Required | Description | Default |
|---|---|---|---|
| preference | No | balanced | |
| requirements | Yes | ||
| max_total_upstream_usd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: no provider execution, no credentials, no wallet signature, no payment, and the important caveat that candidate discovery never grants rights to use a provider. Annotations already cover the read-only/idempotent/non-destructive profile, and the description meaningfully supplements them with cost and authorization boundaries.
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 tight, front-loaded sentences with no filler; the usage cue comes first and the safety boundaries follow. Slightly dense but every sentence 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?
The description explains cost and execution boundaries well, but for a tool with no output schema it never describes what a quote response contains (candidate list, prices, totals) and leaves two of three parameters unexplained. There is a real gap an agent would want filled before calling.
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 only indirectly conveys that requirements is capped at 5 capabilities. It says nothing about max_total_upstream_usd or the preference enum (balanced/cheapest/proven), leaving required budget semantics and pricing behavior undocumented.
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 concrete action (bounded, free comparison of 1–5 provider capabilities) and names the endpoint it hits (/quote). It is specific enough to distinguish from discovery tools, but it never contrasts with the near-identical sibling kevaremesh_quote_provider_route, leaving ambiguity about batch vs single-route quoting.
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?
'Use when an AI agent needs one bounded, free comparison for 1–5 specified provider capabilities' gives a clear use condition and implies single-call/batch scope. However, it gives no when-not guidance and does not tell the agent when to prefer quote_provider_route or discover_provider_candidates instead, so routing between the closely related quoting tools is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Choose when an agent wants a free price comparison for one named provider API capability within a strict price ceiling. Calls only the free KEVAREMESH Gateway quote. For 2–5 needs use kevaremesh_quote_provider_batch. Neither operation purchases upstream APIs or handles buyer funds.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | ||
| capability | Yes | ||
| max_unit_price_usd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new context: it calls only the free gateway quote and 'neither operation purchases upstream APIs or handles buyer funds,' which prevents a costly misread. It stops short of saying what happens when the ceiling is too low (error vs. empty result).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with zero filler: purpose, gateway scope, alternative, then the no-purchase caveat. The key differentiator and the sibling routing are 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?
No output schema exists, yet the description never says what a quote contains (price, provider identity, availability) or whether an unmeetable ceiling yields an error or an empty result. For a quote tool with three undocumented parameters, that leaves a real gap the agent must discover by calling.
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 carry the load. It does explain two parameters implicitly — 'one named provider API capability' for capability and 'strict price ceiling' for max_unit_price_usd — but 'goal' is left undefined and no formats or limits (e.g., USD granularity, capability naming convention) are given.
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 concrete verb and resource ('free price comparison for one named provider API capability within a strict price ceiling') and immediately distinguishes itself from the batch sibling. An agent can tell this apart from kevaremesh_quote_provider_batch without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the selection condition (single capability, free comparison, strict ceiling) and routes 2–5 needs to kevaremesh_quote_provider_batch by name. No inference required about when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a gateway request ID and buyer-held finalize token, poll prior Base USDC settlement evidence. It may finalize a verified existing fee and return the associated paid route capability. Never signs, pays again, submits provider requests or creates routes.
| Name | Required | Description | Default |
|---|---|---|---|
| finalize_token | Yes | ||
| gateway_request_id | 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 so well: it discloses that it polls state, may finalize a verified existing fee, and explicitly does not sign, pay again, submit provider requests, or create routes. It still omits idempotency behavior, retry/timeout semantics, and auth expectations beyond the token, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and inputs, then the possible side effect, then the negative guarantees. Every sentence adds distinct information with no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema tool the description covers inputs, possible outcome (finalize fee, return paid route capability), and safety boundaries. It lacks detail on failure modes or what happens when no settlement evidence is found, but nothing essential to invoking it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate; it does by identifying both inputs and adding meaning the schema cannot convey -- the request ID references a gateway request and the token is a 'buyer-held finalize token' authorizing reconciliation. Format constraints remain schema-only, which is acceptable.
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 concrete verb+resource: reconcile a gateway receipt by polling prior Base USDC settlement evidence, possibly finalizing an existing fee and returning a paid route capability. This clearly distinguishes it from read-only siblings like check_owned_receipt or locate_owned_receipt, though it does not name those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'already submitted' and the title imply the precondition (a prior payment exists), and 'no additional fee' hints at when to prefer this over a fresh payment. However, no explicit when-not conditions or named alternatives (e.g. check_owned_receipt vs retrieve_paid_api_result) are given, leaving routing partly 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 original AES-GCM cached result for a settled and chain-verified owned API payment. The result is available for up to 24 hours. No additional payment, no new provider calls or API execution.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | 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. It usefully discloses caching, a 24-hour TTL, no additional payment, and no new provider calls or API execution, but it omits auth requirements, error behavior for expired or invalid receipts, and idempotency 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 three tight sentences with no waste. It front-loads the operation and follows with availability and side-effect constraints, each sentence earning 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 one-parameter fetch tool with no annotations and no output schema, the description covers the main behavior and constraints. It is still incomplete because it does not explain how to obtain receipt_id or what happens when the receipt is expired, unsettled, or not owned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter, receipt_id, and schema description coverage is 0%. The description mentions a 'verified receipt' but does not explain what receipt_id is, where to obtain it, or how it relates to the sibling receipt tools, leaving the schema pattern as the only 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 uses a specific verb and resource: 'Fetch the original AES-GCM cached result' for a 'settled and chain-verified owned API payment.' This clearly identifies the operation and distinguishes it from general payment or receipt tools, though it does not explicitly name sibling 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 states the prerequisite condition ('settled and chain-verified owned API payment') and the 24-hour availability window, which implies when the tool applies. However, it does not explicitly say when not to use it or route the agent to sibling tools like check_owned_receipt, locate_owned_receipt, or reconcile_gateway_receipt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Choose first when an AI wants to solve a task such as CSV to JSON, Base64, URL parsing, JSON validation, hashing, UUIDs or timezone conversion, without knowing a product name. One request discovers matching existing KEVAREMESH tools, real input schemas where available, indicative prices and verified live checkout status. Optional supplier metadata is free, never a grant of third-party access. This discovery tool cannot pay or execute.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | ||
| limit | No | ||
| capability | No | ||
| include_input_contracts | No | Inline the actual reviewed input schemas for at most two matching executable local APIs. Free metadata GET only. | |
| include_provider_candidates | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is lower. The description still adds real context beyond them: what the single request returns (schemas where available, indicative prices, verified live checkout status) and the caveat that free supplier metadata 'is never a grant of third-party access' and that the tool cannot pay or execute.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the selection trigger 'Choose first when...'. Every sentence carries information (use cases, return payload, access caveat), though the second sentence packs several payload elements at once.
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, so the description must describe results, and it does: matching tools, real input schemas where available, indicative prices, live checkout status. Given five parameters and sparse schema docs, the bare spots are limit/capability semantics, but the caller otherwise knows what comes back and what the tool will not do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% - just include_input_contracts is documented in the schema. The description implies 'goal' through its example use cases and touches 'include_provider_candidates' via the supplier-metadata sentence, but 'limit' and 'capability' are explained nowhere. With low coverage the description needed to compensate and largely does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: discover matching KEVAREMESH tools/APIs for a task, with concrete examples (CSV to JSON, Base64, URL parsing, hashing). Scope is bounded by 'without knowing a product name' and 'cannot pay or execute'. It does not name the sibling tools it supersedes (find_owned_api, discover_provider_candidates), so differentiation is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Choose first when an AI wants to solve a task ... without knowing a product name' gives a clear selection condition. The negative case is also signalled: 'this discovery tool cannot pay or execute' tells the agent to look elsewhere for payment/execution. No sibling is named as the alternative, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One agent-facing entry to the rights-verified bounded external API catalog (Frankfurter, USGS, Crossref and ROR where currently enabled). Read the live catalog to discover available operations. Actions: catalog, execute, batch, resolve, pass_catalog and paid_execute. Free operations remain bounded. A buyer-authorized x402 24h Access Pass supports independently verified paid admission with capped immediate API execution; the MCP tool does not sign, buy, or move funds. It cannot perform purchases, send funds, forward arbitrary URLs or execute upstream fee-bearing APIs. The live catalog combines current first-party products and rights-eligible external operations when independent checks succeed; inventory counts are not hardcoded.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| jobs | No | ||
| input | No | For currency_rate: base/quote ISO codes; for currency_convert add amount; currency_history add date; USGS operations use empty object; Crossref DOI lookup requires doi, publication search requires query; ROR organization search uses query and ROR record uses id. Always consult the live catalog for exact schemas. | |
| action | No | catalog | |
| operation | No | Use an exact operation name returned by action=catalog. The hub enforces permitted operations, original inputs and per-provider rights before use. | |
| access_key | No | For paid_execute only: the buyer-held 32-byte random access key from an independently confirmed x402 Access Pass. Treat as private; never expose in public logs or chat. | |
| request_id | No | Optional paid_execute logical invocation key. Reuse exactly on retries; a new key refreshes live data. Omission caches identical operation/input per pass. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the MCP tool does not sign, buy, or move funds; cannot purchase, send funds, forward arbitrary URLs, or execute fee-bearing upstream APIs; free operations are bounded; paid access requires an independently verified x402 Access Pass; and the catalog is live rather than hardcoded. It still omits error behavior, rate limits, and response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and most sentences add a real constraint, but the prose is dense with repeated rights/jargon language ('rights-verified', 'rights-compatible', 'rights-eligible') and long compound clauses that reduce scannability.
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 complex 7-parameter tool with nested objects and no output schema, the description covers purpose and payment/security boundaries but leaves major gaps: how to choose between its actions, how the parameters interact, and what results or errors to expect. It is adequate but 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 description coverage is only 57%, so the description should compensate, but it does not explain goal, jobs, input structure, action semantics, or request_id behavior beyond what the schema already contains. It mentions paid_execute and access_key only obliquely by describing the Access Pass, 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 states a specific verb and resource: an agent-facing entry point to a rights-verified external API catalog with actions catalog/execute/batch/resolve/pass_catalog/paid_execute. It clearly says what the tool is, but it does not distinguish itself from siblings such as kevaremesh_auto_use or kevaremesh_route_intent, leaving overlap ambiguous.
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 implies usage: 'Read the live catalog to discover available operations' suggests catalog-first, and it separates free bounded operations from buyer-authorized paid_execute. However, there is no explicit when-to-use-this-vs-alternative guidance against the many sibling tools, so the agent must infer routing.
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.
kevaremesh_auto_use1 field changedInput schema / properties / request_idAdded value: +{
+ "description": "Optional infrastructure operation idempotency key; reuse on retries. Omit for same-input cache per pass, or supply a new key to refresh.",
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+}kevaremesh_use_infrastructure1 field changedInput schema / properties / request_idAdded value: +{
+ "description": "Optional paid_execute logical invocation key. Reuse exactly on retries; a new key refreshes live data. Omission caches identical operation/input per pass.",
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+}kevaremesh_auto_use1 field changedInput schema / properties / transaction_hashAdded value: +{
+ "description": "Optional Base transaction hash ONLY for recovering an existing receipt_id or access_key; independently verified, no new payment",
+ "pattern": "^0x[0-9a-fA-F]{64}$",
+ "type": "string"
+}kevaremesh_auto_usekevaremesh_use_infrastructure2 fields changedInput schema / properties / access_keyAdded value: +{
+ "description": "For paid_execute only: the buyer-held 32-byte random access key from an independently confirmed x402 Access Pass. Treat as private; never expose in public logs or chat.",
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+}Input schema / properties / action / enumPrevious value: -[
- "catalog",
- "execute",
- "batch",
- "resolve"
-]New value: +[
+ "catalog",
+ "execute",
+ "batch",
+ "resolve",
+ "pass_catalog",
+ "paid_execute"
+]kevaremesh_use_infrastructure4 fields changedInput schema / properties / input / descriptionPrevious value: -"For currency_rate: base/quote ISO codes; for currency_convert add amount; currency_history add date; USGS operations use empty object; Crossref DOI lookup requires doi, publication search requires query."New value: +"For currency_rate: base/quote ISO codes; for currency_convert add amount; currency_history add date; USGS operations use empty object; Crossref DOI lookup requires doi, publication search requires query; ROR organization search uses query and ROR record uses id. Always consult the live catalog for exact schemas."Input schema / properties / operation / descriptionAdded value: +"Use an exact operation name returned by action=catalog. The hub enforces permitted operations, original inputs and per-provider rights before use."Input schema / properties / operation / enumRemoved value: -[
- "currency_rate",
- "currency_convert",
- "currency_history",
- "currency_currencies",
- "earthquake_m45_day",
- "earthquake_significant_week",
- "crossref_doi_lookup",
- "crossref_search_publications"
-]Input schema / properties / operation / patternAdded value: +"^[a-z][a-z0-9_]{1,80}$"kevaremesh_use_infrastructure2 fields changedInput schema / properties / input / descriptionPrevious value: -"For currency_rate: base/quote ISO codes; for currency_convert add amount; currency_history add date; USGS operations use empty object."New value: +"For currency_rate: base/quote ISO codes; for currency_convert add amount; currency_history add date; USGS operations use empty object; Crossref DOI lookup requires doi, publication search requires query."Input schema / properties / operation / enumPrevious value: -[
- "currency_rate",
- "currency_convert",
- "currency_history",
- "currency_currencies",
- "earthquake_m45_day",
- "earthquake_significant_week"
-]New value: +[
+ "currency_rate",
+ "currency_convert",
+ "currency_history",
+ "currency_currencies",
+ "earthquake_m45_day",
+ "earthquake_significant_week",
+ "crossref_doi_lookup",
+ "crossref_search_publications"
+]kevaremesh_use_infrastructurekevaremesh_agent_commerce_statuskevaremesh_check_owned_receiptkevaremesh_discover_provider_candidateskevaremesh_find_owned_apikevaremesh_get_owned_input_contractkevaremesh_locate_owned_receiptkevaremesh_preview_owned_apikevaremesh_quote_provider_batchkevaremesh_quote_provider_routekevaremesh_reconcile_gateway_receiptkevaremesh_retrieve_paid_api_resultkevaremesh_route_intentkevaremesh_use244 pay-per-call AI APIs: crypto, DeFi, markets, official data, compliance and developer tools.
One key to 1,000+ paid data APIs: enrichment, SEO/SERP, scraping, places, news. Pay per call.
One key and one balance for 2,500+ data APIs from 90+ providers. Your AI agent pays per call.
Real-time data API for AI Agents: stocks, weather, forex, logistics, search, scrape, news, IP.
Add one secure layer between your agents and this server.
