Pay-per-call Base & Arc onchain facts for agents: address risk, USDC payment check, tx explain.
Scored across 6 tools
Each tool maps to a distinct task: catalog, network status, address preflight, balances, transaction explanation, and payment verification. However, address_profile partially overlaps usdc_balances by also returning USDC and native balances, which could cause occasional misselection.
All tool names use consistent snake_case and are readable. The set still mixes noun_noun names like address_profile, network_status, and usdc_balances with verb_noun names like explain_transaction and verify_usdc_payment, so it is not a strict uniform verb_noun pattern.
Six tools is well-scoped for a focused Base/Arc chain-data and payment-safety toolkit. Each tool has a clear role, with one free catalog tool and five atomic paid operations.
The surface covers the core workflow: discovering tools, checking network conditions, profiling addresses, checking balances, explaining transactions, and verifying USDC payments. Minor gaps remain, such as a dedicated allowance/approval check, but agents can mostly work around them with address_profile and explain_transaction.
Preflight any address on Base or Arc before paying or approving it: EOA vs contract vs EIP-7702-delegated wallet, EIP-1967 proxy implementation/admin, owner(), Safe multisig threshold, ERC-20 metadata, USDC + native balance, Sourcify verification, and risk flags. Costs $0.005 USDC on Base per call via x402 (unpaid calls return the x402 PaymentRequired; any x402 MCP client pays automatically).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say read-only and open-world; the description adds material behavior the agent cannot infer: the $0.005 USDC Base charge, that unpaid calls return a PaymentRequired, and that x402 clients settle automatically. That pricing/auth disclosure is exactly the kind of context beyond structured fields that matters for invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: the front-loaded capability list is followed by the operational cost note. The dense enumeration is functional here because each item is a distinct returned field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must enumerate return content — and it does, item by item. Combined with the payment behavior and the chain option, an agent has everything needed to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It explains that the tool operates "on Base or Arc," mapping the chain enum to concrete meaning, and address is self-evident from the pattern. It doesn't discuss defaults or format beyond that, keeping it at 4 rather than 5.
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 ("Preflight") plus resource ("any address") and enumerates exactly what is reported: EOA vs contract vs 7702 delegation, proxy implementation/admin, owners, Safe threshold, ERC-20 metadata, balances, verification, risk flags. This is clearly distinct from siblings like usdc_balances or verify_usdc_payment, which cover narrower slices.
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?
"Before paying or approving it" gives a clear triggering condition and the payment mechanics (x402 auto-pay for MCP clients) tell the agent what to expect operationally. It stops short of naming alternatives or exclusions, so it lands just under an explicit when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Lists every ChainKit tool with its price, required inputs and an example, plus how x402 payment works. Call this first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint true and openWorldHint false, while the description adds relevant context: the tool is free, covers every ChainKit tool, and explains x402 payment. It leaves out rate limits or output format, but adds meaningful behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no waste, front-loaded with "Free." before the core purpose and the first-call instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description explains exactly what the catalog returns: tool names, prices, required inputs, examples, and x402 payment mechanics. Combined with annotations covering safety, it is complete enough 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?
Zero parameters are required, so there are no parameter semantics to document. The baseline for a parameterless tool is 4, and the description does not need to compensate for schema gaps.
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 the specific verb "Lists" and resource "every ChainKit tool", enumerates the returned fields (price, required inputs, example, x402 payment), and distinguishes itself from sibling action tools with "Call this first."
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 instructs "Call this first", giving clear usage context for initial discovery. It does not name when-not to use it or list alternatives, but for a catalog tool the first-call guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a Base or Arc transaction in plain JSON: status, confirmations, fee, method selector, created contract, and every ERC-20 transfer decoded with symbol and decimals. Costs $0.004 USDC on Base per call via x402 (unpaid calls return the x402 PaymentRequired; any x402 MCP client pays automatically).
| Name | Required | Description | Default |
|---|---|---|---|
| tx | Yes | ||
| chain | No | base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Going well beyond the readOnlyHint/openWorldHint annotations, it discloses the per-call price ($0.004 USDC on Base), the payment rail (x402), and the exact failure mode for unpaid calls (PaymentRequired response). That is precisely the behavioral context an agent needs before invoking a paid 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 core capability is front-loaded and every clause earns its place, including the cost/payment sentence. The return-field list is long, but each item is genuinely informative rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description properly enumerates the return shape (status, confirmations, fee, selector, created contract, decoded ERC-20 transfers) and covers the payment model. Minor gaps remain around confirmations semantics and chain/transaction mismatch 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 0%, so the description must compensate, and it only partially does: 'Base or Arc transaction' maps to the chain enum and its default but adds nothing about the 'tx' hash format or what chain selection does to decoding. The schema's pattern and enum carry the rest, leaving this at a baseline-plus level.
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 ('Explain') and resource ('a Base or Arc transaction') and enumerates exactly what the response contains: status, confirmations, fee, method selector, created contract, and decoded ERC-20 transfers. This distinguishes it clearly from address_profile and verify_usdc_payment, which cover different resources.
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 usage context clear (any x402 MCP client, paid calls only) and states that unpaid calls return PaymentRequired, which implicitly tells the agent it must be x402-capable. It does not, however, name when to prefer a sibling like address_profile or verify_usdc_payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live block height, gas price and fee estimates (transfer, ERC-20 transfer, contract call) for Base or Arc. On Arc fees are quoted directly in USDC. Costs $0.001 USDC on Base per call via x402 (unpaid calls return the x402 PaymentRequired; any x402 MCP client pays automatically).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnly and openWorld; the description adds material behavioral facts the annotations cannot: a per-call price ($0.001 USDC on Base via x402), the failure mode for unpaid calls (PaymentRequired), and the fact that x402 MCP clients handle payment automatically. Arc's USDC-denominated fees are also disclosed.
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 data returned, then the chain nuance, then the payment model. The payment sentence is dense with parenthetical clauses but every clause carries operational information an agent needs.
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 describe return content — it does, specifying block height, gas price, and three fee-estimate variants. Combined with annotations for safety and the explicit payment/x402 behavior, nothing required for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'chain' parameter, so the description must carry the meaning — and it does, naming both valid values and explaining that Arc changes fee denomination to USDC. It omits that the schema default is 'base', leaving the no-argument case unstated.
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 the exact resource (network status) and enumerates what comes back: live block height, gas price, and fee estimates for three transaction types, scoped to Base or Arc. No sibling (address_profile, usdc_balances, verify_usdc_payment, explain_transaction, chainkit_catalog) overlaps this resource, so an agent can select it without inference.
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 content list (call it when you need block height or gas/fee quotes), and the Arc fee-denomination note hints at a chain choice. But there is no explicit when-to-use/when-not-to-use statement and no routing to alternatives such as chainkit_catalog or verify_usdc_payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USDC and native balance of one address on both Base and Arc in a single call. Costs $0.002 USDC on Base per call via x402 (unpaid calls return the x402 PaymentRequired; any x402 MCP client pays automatically).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations with critical behavior an agent cannot infer: cost of $0.002 USDC per call, x402 payment gating, that unpaid calls return PaymentRequired, and that x402 MCP clients pay automatically. This is exactly the kind of paid-endpoint context the annotation set cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, with the capability front-loaded and the payment mechanics second. Each sentence carries distinct information (scope + cost/gating).
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-param, read-only, no-output-schema tool, the description covers the essential context: what data, which chains, and the payment flow. Minor gaps remain around the return shape (e.g., whether native balance means ETH and how per-chain results are keyed).
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?
One parameter with 0% schema description coverage; the schema's regex conveys the 0x address format. The description only says 'one address', adding nothing about whether the same address is used on both chains or what else identifies it, 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?
States a specific resource (USDC and native balance) with explicit scope: one address across two named chains (Base and Arc) in one call. This clearly separates it from the broader address_profile sibling, 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?
Usage is implied by the scope statement (use when you need balances only, on Base/Arc), but there is no explicit when-to-use/when-not or reference to address_profile as the alternative for broader data. The payment note clarifies a precondition rather than a selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that a transaction paid at least N USDC to an address on Base or Arc (handles Arc native-USDC logs). Returns verified true/false, confirmations, matching transfers and reasons. Use it to confirm a customer paid before delivering. Costs $0.003 USDC on Base per call via x402 (unpaid calls return the x402 PaymentRequired; any x402 MCP client pays automatically).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| tx | Yes | ||
| from | No | ||
| chain | No | base | |
| minAmount | No | ||
| minConfirmations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond readOnlyHint/openWorldHint by disclosing the paid-call mechanics: $0.003 USDC on Base per call via x402, unpaid calls return PaymentRequired, and x402-capable MCP clients pay automatically. It also flags the Arc native-USDC log handling quirk, which an agent could not infer from annotations or 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?
Three front-loaded sentences with almost no waste; purpose comes first, then usage, then cost. The mid-sentence parenthetical about Arc logs slightly interrupts the primary statement but earns its place by flagging a real quirk.
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?
Covers the full picture for a 6-parameter tool with no output schema: what is checked, what the response contains (verified flag, confirmations, matching transfers, reasons), the payment/auth requirement, and chain coverage. Nothing essential 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 description coverage is 0%, so the description carries the burden. It conveys the meaning of `to`, `chain`, and `minAmount` ('at least N USDC', 'Base or Arc'), and hints at confirmations in the return description, but `from`, the `tx` format, and the semantics/units of `minConfirmations` are never 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?
Names a specific verb and resource with scope: verifies that a transaction paid at least N USDC to an address on Base or Arc. It is clearly distinguishable from siblings like explain_transaction and usdc_balances, which describe rather than verify payments.
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 states the intended use case: 'Use it to confirm a customer paid before delivering.' That gives a clear decision context, but it never names when NOT to use it or which sibling to reach for instead (e.g. explain_transaction for inspecting a tx without a payment check).
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.
address_profilechainkit_catalogexplain_transactionnetwork_statususdc_balancesverify_usdc_paymentPay-per-call tx explainer, DeFi yields, token safety, SEC 8-K and OFAC data via x402 (USDC on Base).
Pay-per-call agent tools, x402 v1+v2, USDC Base/Solana: audit, extract, enrich, URL safety, crypto
Pay-per-call agent tools on Base: market pulse, USDC stats, crypto prices, JSON repair, DNS, URLs.
Check a Base contract, transaction or web page before you act. Free pricing, paid per call in USDC.
Add one secure layer between your agents and this server.
