13 free Base tools: address labels, tx explain, balances, receipts, gas, logs, bytecode.
Scored across 14 tools
Most tools have clearly distinct purposes, but a few pairs require careful reading: get_block_number vs get_block_by_number and get_transaction vs get_transaction_receipt could be momentarily confused, though descriptions clarify each. get_gas_price and estimate_gas are also adjacent but semantically different.
All tools use consistent snake_case with a verb_noun pattern (estimate_gas, get_balance, get_transaction_receipt, search_labels_by_category). Minor descriptive suffixes like '_simple' do not break the convention.
14 tools is well within the ideal 3-15 range for a read-only blockchain data server. Each tool covers a distinct query or labeling operation, so no obvious padding.
Coverage is strong for a read-only Base explorer: balances, gas, blocks, transactions, receipts, contract code, logs, address labels, risk scores, and transaction explanation. Minor gaps exist for token-level balances beyond ETH/USDC, transaction counts per address, or block lookup by hash.
Estimate gas needed for a transaction. Useful for dapps and wallets to show users how much gas they'll pay.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient address (0x + 40 hex) | |
| from | Yes | Sender address (0x + 40 hex) | |
| value | No | ETH value to send (in wei, hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the entire behavioral burden. It does not state whether the transaction is simulated or broadcast, whether it can fail/revert, or that the call is a safe read, which are the key concerns for an estimation endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action. The second sentence is partly decorative (restating the estimate in user-facing terms) but it is not wasteful enough to penalize heavily.
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 should ideally characterize the return value (e.g. hex gas units). It only says "gas needed," leaving the return format unspecified for a tool whose whole purpose is producing a number.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the from/to/value semantics and formats are already fully documented in the schema. The description adds no parameter-level meaning beyond that, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (estimate) and resource (gas for a transaction), so the agent knows exactly the operation. It does not differentiate itself from the nearby sibling get_gas_price, which a caller could plausibly confuse with 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?
"Useful for dapps and wallets to show users how much gas they'll pay" gives a plausible context of use, so usage is implied rather than absent. However, it never says when to prefer this over get_gas_price, nor what prerequisites (e.g. a valid from/to pair) are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a transaction in plain English: who sent what to whom, with address labels. FREE simplified version of our premium explain tool.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | Transaction hash (0x + 64 hex) |
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 disclose output nature (plain English, address labels) and a free-vs-premium distinction. However it omits failure modes (invalid hash), rate limits, auth needs, and depth of the 'simplified' output, leaving real behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core action and output shape. The premium/free clause is mildly promotional but still informative and brief, so minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema and no annotations, the description conveys what the agent gets back (plain-English explanation with labels) and the positioning versus a premium version. Missing only edge-case/failure behavior, which is minor here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single tx_hash parameter, so the schema already documents format (0x + 64 hex). The description adds no parameter-level detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Explain a transaction') and sketches the output ('who sent what to whom, with address labels'), which clearly separates it from the raw-data sibling get_transaction. It does not name a sibling explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'FREE simplified version of our premium explain tool' line implies this is the lightweight/free path, guiding usage implicitly. There is no explicit when-to-use, when-not, or named alternative, so it is only implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a human-readable label for an EVM address (100K+ entity labels: exchanges, bridges, protocols, scams). FREE, no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address (0x + 40 hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a genuinely useful behavioral trait — the call is FREE with no payment required — which is meaningful in a payment-gated tool ecosystem. It does not disclose return behavior for unlabeled addresses, rate limits, or data freshness.
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 sentence that front-loads the purpose, then parenthetically conveys coverage breadth and cost. Every clause carries information an agent can use; no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema and no annotations, the description covers purpose, corpus scope, and cost. It could note what is returned when no label exists (a gap given there is no output schema), but otherwise it is 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?
Only one parameter exists and schema description coverage is 100%, so the schema already documents the '0x + 40 hex' format fully. The description adds no format, validation, or normalization guidance beyond what the schema supplies, 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 and resource ('Get a human-readable label for an EVM address') and adds useful scope detail about the label corpus (exchanges, bridges, protocols, scams). It does not explicitly distinguish itself from the sibling search_labels_by_category, which is the closest alternative, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent with an address wanting a label would pick this. However, the description never states when to use this versus search_labels_by_category or how it relates to get_address_risk_score, so no explicit when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a risk score (0-100) for an address based on our 100K+ labeled address database. Scam addresses score 90-100; known exchanges/bridges score 0-20; unknown addresses score 50. Use this BEFORE sending funds to verify the destination.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address (0x + 40 hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does meaningful work: it discloses the scoring model's behavior (scam addresses 90-100, exchanges/bridges 0-20, unknown 50). The unknown=50 disclosure is especially valuable because it warns the agent that an unlabeled address is not evidence of risk. It omits performance/latency, coverage limits, and data freshness, keeping it at 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action, then the interpretation guide, then the call-to-action. Every sentence earns its place and none restates structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by explaining how to read the returned score, including the ambiguous unknown=50 case. It leaves minor gaps around chain coverage and whether scores are cached/live, but an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the address format ('EVM address (0x + 40 hex)'). The description adds no syntax, chain, or format detail beyond that, 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+resource ('Get a risk score for an address') and immediately scopes it with the 0-100 range and data source ('100K+ labeled address database'). This clearly distinguishes it from sibling get_address_label, which returns labels rather than a scored risk verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit triggering condition: 'Use this BEFORE sending funds to verify the destination.' That is a clear when-to-use cue. It stops short of naming alternatives (e.g., get_address_label for labeling only) or stating when not to bother, so it is a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ETH balance of an address on Base
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address (0x + 40 hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read via 'Get' but says nothing about whether the address may be a contract, whether invalid addresses error or return zero, or how the chain is selected (Base is hardcoded or implicit).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It is efficient, though arguably too terse for a tool that returns an untyped value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, read-only) and there is no output schema, so the description should ideally state the return units (wei vs. formatted ETH) and error behavior. Neither is covered, leaving a genuine gap for a value-returning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter is fully documented with its format ('EVM address (0x + 40 hex)'), so the schema does the heavy lifting. The description adds no parameter meaning beyond what the schema already provides, which is the baseline 3 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get), resource (ETH balance), target (an address), and scope (on Base). The resource name implicitly distinguishes it from the sibling get_usdc_balance, so an agent can route correctly, but the description never explicitly differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no alternatives named, despite a dense sibling set including get_usdc_balance and get_address_risk_score. The agent must infer from the resource name alone that this is a plain balance read rather than a risk or label lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get block details by block number: timestamp, miner, transaction count, gas used.
| Name | Required | Description | Default |
|---|---|---|---|
| block_number | Yes | Block number (decimal) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read but does not disclose error behavior for invalid or future block numbers, whether pruning/archive limits apply, or whether the whole block's transaction list is included. For a tool with zero annotation coverage this is a real 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?
One front-loaded sentence with no filler; the enumerated return fields are compact. It is efficient, though the colon list is slightly dense and could be trimmed or turned into explicit return-value guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, listing the salient returned fields (timestamp, miner, tx count, gas used) is genuinely useful for an agent. Missing only edge-case behavior and sibling differentiation, which keeps it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is documented as 'Block number (decimal)'. The description repeats the lookup key but adds no format, range, or tag alternatives (e.g., 'latest') beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (block details) plus the lookup key (block number) and the fields returned, which is more specific than a bare name restatement. However, it never distinguishes itself from the sibling get_block_number, so an agent must infer which one returns height versus full block details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus alternatives such as get_block_number or get_transaction, and no preconditions (e.g., valid/mined block range). The usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current latest block number on Base
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' implies a read with no side effects and the chain is disclosed (Base), which is meaningful context. However it does not explicitly state read-only/idempotent behavior or the response shape, leaving a modest gap for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Scope (current latest) and target chain (Base) are established immediately.
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 trivial no-argument read tool with schema coverage at 100%, the description is nearly sufficient; it names the returned value and the chain. The only shortfall is the absence of any return-format or freshness/pagination note, which is minor here.
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 of 4 applies. Nothing about argument syntax or defaults needs explaining.
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 (Get) and resource (block number) with a scope qualifier (current latest on Base). The word 'latest' implicitly separates it from sibling get_block_by_number, though the description never names that sibling 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?
No explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. Usage is only implied by 'current latest', which a capable agent can infer but must reason about against get_block_by_number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get contract bytecode at an address. Useful for checking if an address is a contract or a wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address (0x + 40 hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what is returned (bytecode) and a purpose, but not what happens for an EOA (empty result vs. error), chain scoping, or rate/behavioral limits. For a simple read tool this is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, action and use case front-loaded, with no redundant or filler content. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must stand alone; it explains the return value as bytecode but omits edge-case behavior (empty result for non-contracts) and chain context. Adequate for a minimal lookup tool but not 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 description coverage is 100% for the single address parameter ('EVM address (0x + 40 hex)'), so the schema already documents the only input. The description adds no format or validation detail beyond that, which is the baseline case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get contract bytecode at an address'), so the agent knows exactly what is fetched. It does not name or distinguish itself from siblings like get_address_label or get_balance, which also operate on addresses, so it stops short of full sibling differentiation.
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 second sentence gives a concrete usage condition: 'Useful for checking if an address is a contract or a wallet.' That is clear context for when to pick this tool, though no alternatives or exclusions (e.g., use get_address_label for identity) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get event logs from a contract in a block range. Useful for tracking transfers, approvals, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| to_block | Yes | End block number (decimal) | |
| from_block | Yes | Start block number (decimal) | |
| contract_address | Yes | Contract address (0x + 40 hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It does not disclose pagination limits, whether block range size is capped, rate limits, or what happens on an invalid or too-wide range. It only says what it returns, not behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, purpose front-loaded, no waste. The second sentence is somewhat generic but keeps the description tight and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with no annotations, no output schema, and a fully-covered schema, the description is minimally complete. It omits return shape details, pagination or range limits, and failure behavior that an agent would benefit from knowing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented in the schema. The description adds the notion of a block range but no format or constraint details beyond that; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Get event logs from a contract') with a scope qualifier ('in a block range'). It distinguishes itself adequately from siblings like get_transaction_receipt or get_block_by_number, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for tracking transfers, approvals, etc.' implies usage context but does not state when to prefer this tool over siblings or any preconditions. No explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current gas price on Base
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only says 'current', implying a live read. It does not state units (gwei vs wei), whether it is a snapshot or averaged value, or any caching/auth behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, which is appropriate for a trivial no-arg read. It is arguably too terse, but that cost shows up as incompleteness rather than verbosity.
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 no-arg read tool with no output schema, the agent still lacks the return format and units, which are the main things it would need to use the value correctly. The core concept is self-evident, so it is adequate but not 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 nothing for the description to explain beyond what the empty schema already conveys. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (get current gas price) plus the scope (on Base), so the agent knows exactly what is returned. It does not, however, differentiate itself from the sibling estimate_gas, which an agent could easily confuse with 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?
There is no when-to-use guidance and no mention of alternatives such as estimate_gas, even though that sibling covers a closely related need. Usage must be inferred entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction details by hash on Base
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | Transaction hash (0x + 64 hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not state that this is a read-only call, what happens for an unknown or pending hash, what fields 'details' includes, or whether the response is a live chain read.
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 short sentence with zero filler and the key qualifier (on Base) front-loaded. It is efficient, though its brevity edges toward under-specification rather than true conciseness.
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, annotation-free read tool with no output schema, the description covers the minimum but omits return content, error behavior, and sibling differentiation. An agent could invoke it, but without confidence about what comes back or when to prefer it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents the 0x + 64 hex format, so the description adds nothing beyond 'by hash'. Baseline 3 applies when the schema does the heavy lifting.
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 (get), resource (transaction), lookup key (hash) and scope (on Base), so the agent knows exactly what it retrieves. However, it does not differentiate from close siblings like get_transaction_receipt or explain_transaction_simple, leaving the agent to guess which transaction tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no prerequisites, and never names an alternative. With get_transaction_receipt and explain_transaction_simple in the sibling list, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction receipt by hash: success/failure status, gas used, logs. Useful for checking if a tx succeeded.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | Transaction hash (0x + 64 hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the response contents (status, gas used, logs), which is genuine behavioral information, but says nothing about what happens for an unknown or still-pending hash, whether the call errors or returns null, or any auth/rate-limit constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the resource and return fields; nothing is padded. The second sentence partly restates the already-listed "success/failure status," which is a small redundancy but not wasteful enough to penalize more.
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 cover behavior; it lists the returned fields but not their structure or the pending/not-found case. For a one-parameter read this is adequate to call correctly, but a receipt-specific tool should address the unavailable-receipt scenario.
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 there is only one parameter, whose format (0x + 64 hex) the schema already documents. The description's "by hash" phrasing adds no syntax or validation detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (get transaction receipt) and names the identifying key (by hash), plus enumerates the payload: success/failure status, gas used, logs. That clearly separates it from sibling get_transaction, which returns the transaction itself rather than its receipt, though the description never names that sibling 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?
"Useful for checking if a tx succeeded" gives an implied usage context, which is slightly better than nothing. But it offers no when-not guidance (e.g., use get_transaction for pending txs or for input data) and does not name any alternative among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get USDC balance of an address on Base (stablecoin balance, more useful than ETH for most agents)
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address (0x + 40 hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It conveys only that this is a Base USDC read; it says nothing about return units (raw 6-decimals vs human-readable), behavior for invalid/unchecksummed addresses, error cases, 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?
One sentence with the resource and network scoping front-loaded, followed by a short parenthetical. The ETH comparison is mildly promotional but does serve routing, so nothing is truly wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with a fully described schema and no output schema, the essentials are present. It still omits anything about the return value's format, which matters for a token balance where decimal scaling is ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter and 100% schema description coverage, the schema already defines 'address' as an EVM address (0x + 40 hex). The description adds only the chain context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('Get USDC balance of an address') and pins the network ('on Base'), which is a real differentiator among these chain-query siblings. The parenthetical contrast with ETH implies it is not the same as get_balance, but it does not name that sibling 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?
'More useful than ETH for most agents' is an implicit steer toward choosing this over a native-balance tool, but there is no explicit when-to-use or when-not-to-use statement, and no alternative is named. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search all labeled addresses by category (e.g. exchange, bridge, protocol, scam). Returns up to 50 matches.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category to search: exchange, bridge, protocol, scam, nft, defi, other |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose one concrete trait: results are capped at 50 matches. It says nothing about whether results are ordered, whether more results are retrievable, or whether the operation is read-only, leaving meaningful gaps for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler; the purpose is front-loaded and the result cap follows immediately. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool with no output schema, the description covers purpose, valid category examples, and result size, which is most of what an agent needs. Minor omissions (ordering, exhaustiveness of the 50-match cap) keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already enumerates the full category list (exchange, bridge, protocol, scam, nft, defi, other). The description's examples duplicate rather than extend that, 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?
The description states a specific verb and resource ('Search all labeled addresses by category') and names example values, so the agent knows exactly what the tool returns. It does not explicitly differentiate itself from the sibling get_address_label, which appears to be the closest related tool, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you want to enumerate labeled addresses of a given category rather than look up one known address. However, there is no explicit when-to-use/when-not guidance and no named alternative such as get_address_label for single-address lookups.
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.
get_address_risk_scoreestimate_gasexplain_transaction_simpleget_address_labelget_balanceget_block_by_numberget_block_numberget_contract_codeget_contract_logsget_gas_priceget_transactionget_transaction_receiptget_usdc_balancesearch_labels_by_categoryBase on-chain address labels (eth-labels 104k category tags), tx explainer, clusters, CCTP USDC.
8 CIPHER tools — Solana scan, breach check, Jito, FRED, Drift, repo health, more. x402-paid on Base.
15 data tools at $0.01 USDC/call on Base via x402. Free discovery; x402 wallet client required.
62 pay-per-call web, DNS, EVM and data tools. x402 USDC on Base, $0.003-$0.02 per call, no signup.
Add one secure layer between your agents and this server.