inference-mcp

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 the two auth paths, the exact error envelope (isError "error: <code> (<status>): <message>"), and the specific failure codes no_channel_key and invalid_channel with their 401/404 causes (not found, bad secret, closed). It stops short of stating that the call is read-only or whether it consumes quota.

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

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

Two sentences, front-loaded with what the tool returns, then auth, then error semantics. Dense but every clause carries information; the error-code parenthetical is slightly compressed but 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?

No output schema exists, and the description compensates by enumerating the returned fields (balance, spend, request count) and the failure contract. An agent could call this correctly from the description alone; only quota/rate-limit and read-only status are unaddressed.

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

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

Schema coverage is 100% and the single parameter already documents the channelId:channelSecret format and the 'omit to use Authorization header (preferred)' rule. The description's auth sentence largely restates that, adding no new syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb (check) and resource (prepaid channel balance) plus the exact fields returned: remaining Bitcoin BSV balance, spend, and request count. The resource is clearly distinct from siblings like open_channel or infer, though no sibling is named 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 description covers the auth choice (Authorization header preferred over apiKey) but never says when to reach for this tool versus open_channel or the infer variants, nor any preconditions beyond having a channel key. 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.

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

With no annotations, the description carries the full disclosure burden and does so thoroughly: per-token metering, what the receipt contains, that thinking models bill hidden reasoning as output, the maxTokens floor raised to 1024 for those models, that nothing is charged on any error, and that the server does not verify its own receipt. The enumerated error codes with HTTP statuses and per-code causes go well beyond a typical tool description.

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?

Content is front-loaded: what it does, what it returns, auth requirement, then behavioral caveats, then errors. The error-code enumeration is long but each code carries a distinct action, so it earns its space; the paragraph is dense enough that an agent must parse one large block rather than discrete sections.

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

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

There is no output schema, and the description compensates by naming the returned fields (completion, satoshis charged, model routed to, remaining balance, usageReceipt) and pointing at the offline verification path. For a paid, mutating-in-effect call with no annotations, nothing an agent needs in order to call it safely appears to be missing.

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

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

Schema coverage is 100%, so the schema already documents all six parameters; the description nonetheless adds behavior the schema cannot express, notably that apiKey is the fallback and the Authorization header is preferred, and that maxTokens is silently raised to at least 1024 for thinking models. It does not add much to 'prompt', 'system', or 'webSearch' beyond what the schema states.

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

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

The opening sentence names a specific verb and resource ('run one metered inference') plus the payment rail (Bitcoin BSV prepaid channel), which implicitly separates it from x402_infer and xrp_infer. It stops short of naming those siblings, so an agent must infer the routing rather than being told it.

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

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

Prerequisites are explicit (a funded channel key is required, via Authorization header or apiKey) and error remediation routes the agent to concrete next steps: call list_models on invalid_request, top up or lower maxTokens on insufficient_balance, retry on upstream_failed. There is no explicit statement of when to prefer this over the x402_infer/xrp_infer siblings, which is the only gap.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses the live pricing behavior tied to the current BSV/USD rate, states the auth requirement explicitly ('No key needed'), and signals the proper call order. It does not describe the exact response shape, but for a simple catalog tool this is a minor gap.

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

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

Two short, information-dense sentences. The main action is front-loaded, followed by the key pricing detail and a practical usage instruction. No filler or repetition.

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

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

For a zero-parameter tool with no output schema and no annotations, the description provides the essentials: what is listed, in what unit, with what freshness, auth requirements, and when to call it. An exact return format would be beneficial, but the description is otherwise complete enough 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 tool has zero parameters, so parameter ambiguity is not a concern. The description additionally notes that no API key is needed, which covers the only setup detail an agent might otherwise wonder about.

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: 'List the models this BSV inference gateway sells.' It clearly identifies what the tool returns and adds a distinguishing detail (live retail price in satoshis per 1,000 tokens) that sets it apart from the 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 instruction 'Call first to choose a model' gives clear sequential context, and 'No key needed' removes a likely prerequisite concern. It does not explicitly name alternatives such as infer, but the intended role as a preliminary discovery step is clear enough.

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

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

With no annotations, the description carries the burden and does well: it discloses that funding is a real BSV payment signed by a wallet, that it occurs externally on the website, and that the returned key is used as 'Authorization: Bearer channelId:channelSecret' or apiKey. It does not say precisely what calling the tool itself returns or whether it is idempotent.

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 first states purpose, the second front-loads the critical constraint (payment happens elsewhere) and the follow-up credential format. 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?

For a zero-parameter instructional tool with no output schema, the description covers the essential flow: pay on the website, receive a channel key, present it as a bearer token. Minor gaps remain around what the call itself returns and error behavior, but an agent can act correctly on what is given.

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

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

The tool takes zero parameters, so the baseline is 4 and the schema has nothing to clarify. The mention of 'apiKey' refers to credential usage on subsequent calls rather than a parameter of this tool, which is slightly ambiguous but not misleading.

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 ('Explains how to open + fund a prepaid channel') and makes clear that the tool returns instructions rather than performing the funding. It is distinguishable from siblings like channel_balance and infer, though it never explicitly names them.

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 key usage constraint (funding happens once, at the website, not through this call) and how to use the resulting credential, so usage is implied. But it never says when an agent should invoke this tool versus going straight to infer or x402_infer, nor what triggers the need for a channel.

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

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

With no annotations, the description carries the full burden and does so: it declares non-custodial behavior, that a `wif` argument is refused, that step 1 spends nothing, and enumerates failure codes with their spend consequences (payment_failed spends nothing, upstream_failed settled and has no automatic refund, with a contact path). This is exactly the behavioral context an agent cannot infer elsewhere.

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

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

Front-loaded with purpose and billing model, then the two steps, then the error taxonomy — the ordering is deliberate and every sentence carries operational content. It is dense and long, but nearly all of the length is load-bearing given the payment protocol.

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 annotations and no output schema, yet the description covers return values (completion plus on-chain settlement txid) and the full error surface with spend implications. Nothing an agent needs to call this safely is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that `payment` is the base64 X-PAYMENT value signed for the step-1 quote and must be paired with the identical prompt/model/maxTokens/webSearch, which is call-sequence semantics the schema cannot express.

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

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

The opening sentence states a specific verb and resource ('Run one inference') plus the billing model ('paid PER CALL in Bitcoin BSV via x402, no prepaid channel'), which immediately separates it from the sibling `infer` and the channel-based tools (`channel_balance`, `open_channel`). An agent can select it without opening the schema.

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

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

It spells out the exact two-step call sequence (quote first, then pay and re-call) and implicitly contrasts with a prepaid channel. It does not explicitly name which sibling to use instead when a channel already exists, so usage is clear but not fully routed.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: non-custodial, never accepts an xrpSeed, quote retrieval spends nothing, payment is checked before broadcast, validation is awaited, and returns include completion, settlement tx hash, and signed receipt. It also documents error codes and their financial implications, including pending retry behavior and the no-automatic-refund case after an upstream failure.

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 the two-step flow is clearly numbered, so the dense paragraph remains navigable. It is long and occasionally packed with error-code detail, but the complexity of the payment flow justifies most of the length.

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

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

There is no output schema and no annotations, so the description must explain return values and failure behavior, which it does: completion, settlement tx hash, signed receipt, and structured error codes with statuses and implications. It is complete enough for an agent to understand the full quote-pay-settle lifecycle.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds significant meaning for the payment parameter by specifying the required base64 X-PAYMENT structure, the quote source, and that the same prompt/model/maxTokens must be reused on the second call. It adds less beyond the schema for system and maxTokens, but the payment semantics are materially clarified.

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: run one paid inference on the XRP Ledger via x402, per call, with no channel. It also differentiates the payment model from channel-based siblings such as open_channel and channel_balance by emphasizing 'PER CALL' and 'no channel'.

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 two-step usage flow: first call without payment to obtain the 402 quote, then sign an XRP Payment and call again with the same prompt, model, and maxTokens. It does not explicitly compare this tool against siblings like infer or x402_infer, but the 'no channel' and per-call framing provides clear contextual guidance.

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