Resolve any EVM contract ABI (even unverified, via decompilation), read, simulate, prepare txs.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 12 of 12 tools scored.
Each tool has a clearly distinct purpose: decode vs encode, prepare vs simulate, resolve ABI vs selector, etc. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., decode_tx, list_chains, resolve_abi, runtime_metrics). The only exception is 'simulate', which is a single verb but still clear and consistent with the style.
12 tools is an ideal count for a blockchain interaction server. Each tool covers a necessary step in the workflow without being overwhelming or sparse.
The tool set covers the full lifecycle of contract interaction: resolve ABI, encode/decode, simulate, prepare unsigned transactions, look up selectors, resolve names, and list chains. No obvious gaps given the server's purpose of preparing actions for external signing.
decode_txExplain a transactionADecode what a transaction did: delegated heimdall decode plus decoded_call from the resolved target ABI when available. Prefer decoded_call for typed function/arg names, and read its provenance.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain alias from GET /v1/chains (for example "ethereum", "base", "monad", "bsc") or numeric EIP-155 chain id. | |
| rpc_url | No | Override HTTP(S) RPC URL. Required for chains with no default (e.g. local/31337) or custom EVM chain ids. | |
| tx_hash | Yes | 0x transaction hash. |
| Name | Required | Description |
|---|---|---|
| chain | Yes | |
| cached | Yes | |
| source | Yes | |
| decoded | Yes | |
| tx_hash | Yes | 0x transaction hash. |
| provenance | Yes | |
| decoded_call | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by detailing the dual decoding approach and provenance, though readOnlyHint already signals safety. No contradictions.
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 concise sentences with front-loaded core function and actionable guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavioral traits and output differentiation, and output schema handles return details. Minor gap: no mention of RPC override necessity, though schema covers 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 coverage is 100%, so description adds no new parameter details. It mentions output preferences but not input specifics, meeting baseline with no degradation or improvement.
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 precisely states the tool decodes a transaction using heimdall decode and decoded_call from ABI. It clearly distinguishes from siblings like encode_call or simulate by focusing on decoding transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance to prefer decoded_call for typed names and to read provenance, but lacks explicit when-not-to-use compared to sibling tools like simulate or read_contract.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
encode_callEncode a function callAEncode a function call to calldata (0x…) without sending anything.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Function arguments, in order. Pass uint values as decimal strings. | |
| chain | Yes | Chain alias from GET /v1/chains (for example "ethereum", "base", "monad", "bsc") or numeric EIP-155 chain id. | |
| value | No | Native value in wei (decimal string), for payable functions. | |
| address | Yes | 0x contract address. | |
| rpc_url | No | Override HTTP(S) RPC URL. Required for chains with no default (e.g. local/31337) or custom EVM chain ids. | |
| function | Yes | Function name, or full signature like "transfer(address,uint256)" if overloaded. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Raw form: calldata (0x-prefixed hex bytes). |
| function_signature | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description confirms 'without sending anything', which aligns with read-only behavior. It adds value by clarifying no state change occurs, which is not explicitly in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with 8 words, containing no filler or redundant information. Every word 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?
Despite having 6 parameters, the description is minimal but sufficient given the high schema coverage and presence of an output schema. It clarifies the key behavioral aspect (no sending). Slightly more detail on the encoding process would improve completeness, but current level is adequate.
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% with descriptions for all 6 parameters. The tool description does not add additional meaning beyond the schema; it simply restates the tool's purpose. Baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool encodes a function call to calldata without sending, using a specific verb ('encode') and resource ('function call'). This distinguishes it from siblings like 'simulate' (sends) and 'decode_tx' (decodes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need calldata encoding without execution, but it does not explicitly state when to use versus alternatives like 'prepare_tx' or 'decode_tx'. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_registryExport selector commonsAReturn the CC0 selector commons as NDJSON. This can be large; prefer lookup_selector for normal agent workflows.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that output is NDJSON and may be large, complementing readOnlyHint and openWorldHint. No contradictions; could mention if data is complete but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Front-loaded purpose and usage warning. 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?
With no output schema, description specifies NDJSON format but not field structure. Given tool is a bulk export, this is adequate; slight gap in data content details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage 100%. Description correctly omits param details; baseline 4 applies as no additional meaning needed beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb 'Return' and resource 'CC0 selector commons as NDJSON', immediately distinguishing it from sibling lookup_selector by noting size and recommending 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?
Explicitly advises against using this for normal workflows and points to lookup_selector as the preferred alternative, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_chainsList supported chainsAList viem-backed chain aliases and ids. Use filters to find testnets, default-RPC chains, or a named chain before resolving contracts.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search by chain id, name, alias, or native symbol; multi-word queries also match token-by-token and without whitespace. | |
| testnets | No | When true, only testnets; when false, only mainnets. | |
| has_default_rpc | No | When true, only chains gulltoppr can query without rpc_url. |
| Name | Required | Description |
|---|---|---|
| chains | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description doesn't need to restate safety. It adds context on filtering behavior but does not disclose additional traits like rate limits or data freshness, which are acceptable for a list-read 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 sentences, no filler. The action is front-loaded, and every word earns its place. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema, annotations, and complete parameter documentation, the description supplements enough contextual information for an AI agent to invoke the tool correctly. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. The description adds value by framing filters in context ('before resolving contracts'), but does not provide syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool lists viem-backed chain aliases and ids, with explicit filtering capabilities. This distinguishes it from sibling tools like 'decode_tx' or 'read_contract', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use filters to find testnets, default-RPC chains, or a named chain before resolving contracts.' While it doesn't explicitly exclude alternatives, the purpose is distinct enough among siblings that an AI agent can infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_selectorLookup selector commonsALookup gulltoppr-proven signatures for a 4-byte function/error selector or 32-byte event topic0. Prefer these over public 4byte guesses.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | 4-byte function/error selector or 32-byte event topic0. |
| Name | Required | Description |
|---|---|---|
| entries | Yes | |
| selector | Yes | 4-byte function/error selector or 32-byte event topic0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with possible missing results. The description adds that signatures are 'gulltoppr-proven,' hinting at data source quality, but does not significantly expand on behavioral traits beyond what annotations 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?
The description is very concise: two sentences, no wasted words. The core purpose is front-loaded in the first sentence, and the second sentence adds a valuable usage hint. 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?
Given the tool's simplicity (single parameter, clear schema, annotations, and output schema), the description is complete. It adequately explains the tool's purpose and provides a usage preference, leaving no critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter with 100% coverage, including a regex pattern and description. The description merely restates the parameter's purpose ('4-byte function/error selector or 32-byte event topic0'), adding no new semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lookup gulltoppr-proven signatures for a 4-byte function/error selector or 32-byte event topic0.' It uses a specific verb (lookup) and resource (signatures), and distinguishes from siblings like decode_tx or resolve_abi by focusing on selector-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Prefer these over public 4byte guesses' provides clear guidance on when to use this tool, implying it should be chosen over less reliable alternatives. However, it does not explicitly state when not to use it or mention any other alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepare_txPrepare an unsigned transaction (hand-off)AInspectPrepare a contract WRITE for the user to sign. Returns an UNSIGNED transaction, its simulation, a human-readable summary, safety metadata, warnings, a configured signing deeplink, and an EIP-1193 wallet request when signing is recommended. IMPORTANT: this tool NEVER signs or broadcasts. Present the summary + simulation + warnings to the user. Only hand them the deeplink or wallet_request when safety.signing_recommended is true. If safety.risk_level is high or blocked, make that explicit; blocked means do not send.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Function arguments, in order. Pass uint values as decimal strings. | |
| from | Yes | The sender address (the user's wallet). No key is needed — nothing is signed. | |
| chain | Yes | Chain alias from GET /v1/chains (for example "ethereum", "base", "monad", "bsc") or numeric EIP-155 chain id. | |
| value | No | Native value in wei (decimal string), for payable functions. | |
| address | Yes | 0x contract address. | |
| rpc_url | No | Override HTTP(S) RPC URL. Required for chains with no default (e.g. local/31337) or custom EVM chain ids. | |
| function | Yes | Function name, or full signature like "transfer(address,uint256)" if overloaded. |
| Name | Required | Description |
|---|---|---|
| safety | Yes | |
| deeplink | Yes | |
| warnings | Yes | |
| simulation | Yes | |
| unsigned_tx | Yes | |
| human_summary | Yes | |
| wallet_request | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write-prep), openWorldHint=true, destructiveHint=false. The description adds key behavioral traits: never signs/broadcasts, returns safety metadata with risk levels, and warns about blocked/high risk. No contradiction with 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?
Description is a single paragraph, front-loaded with key purpose and components. Every sentence adds value: never signs, returns list, safety guidelines. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, full schema coverage, output schema present, and annotations, the description covers all essential context: what the tool does, what it returns, safety metadata and risk handling. It is complete for an agent to select and use 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% with good descriptions. The description adds extra meaning: 'from' requires no key (nothing signed), 'args' requires uint as decimal strings, and 'chain' can be alias or numeric id. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prepares a contract write for signing, listing all returned components (unsigned tx, simulation, summary, etc.). It distinguishes from siblings like simulate (simulation of signed txs) and read_contract (reads).
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 'NEVER signs or broadcasts' and provides conditional logic on when to use deeplink/wallet_request based on signing_recommended. It also instructs to present summary+simulation+warnings to user and to highlight high/blocked risk. It does not mention alternative tools for signing, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_contractRead a contract (view/pure)ACall a view/pure function and get the decoded result. No wallet, no cost. Rejects state-mutating functions.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Function arguments, in order. Pass uint values as decimal strings. | |
| chain | Yes | Chain alias from GET /v1/chains (for example "ethereum", "base", "monad", "bsc") or numeric EIP-155 chain id. | |
| address | Yes | 0x contract address. | |
| rpc_url | No | Override HTTP(S) RPC URL. Required for chains with no default (e.g. local/31337) or custom EVM chain ids. | |
| function | Yes | Function name, or full signature like "transfer(address,uint256)" if overloaded. |
| Name | Required | Description |
|---|---|---|
| raw | Yes | Raw form: calldata (0x-prefixed hex bytes). |
| decoded | Yes | |
| function_signature | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds important behavioral context: 'No wallet, no cost' and 'Rejects state-mutating functions', which clarifies constraints beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. Front-loaded with the core action ('Call a view/pure function'). Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complexity of smart contract calls, the description is complete for a read-only tool with rich annotations and a full schema. It explains the action, constraints, and output ('decoded result'). Output schema exists but description doesn't need to repeat 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 coverage is 100%, so baseline is 3. The description does not add parameter-level meaning; it focuses on overall tool behavior, which is appropriate given the schema already describes all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Call') and resource ('view/pure function') and clarifies the result ('decoded result'). It distinguishes from siblings like simulate or prepare_tx by explicitly stating it is read-only and rejects state-mutating functions.
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 clearly states when to use: for view/pure functions, and when not: state-mutating functions are rejected. However, it does not explicitly compare to sibling tools like 'simulate' or 'prepare_tx', leaving some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
registry_statsRegistry statsARead selector commons counts by proof grade and bytecode-match index size.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| bytecodes | Yes | |
| selectors | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool reads statistics by specific dimensions, but lacks details on data freshness, potential limits, or error scenarios. It does not contradict 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?
A single concise sentence efficiently conveys the tool's purpose with no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and no parameters, the description is brief but adequate to indicate what the tool does. It could be more complete by explicitly stating the output format (e.g., map or list) or aggregation level, but is generally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params, schema coverage 100%). The description adds meaning beyond the schema by specifying the two dimensions (proof grade and bytecode-match index size) that structure the output. Per guidelines, baseline is 4 for 0 params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool reads 'selector commons counts' with specific dimensions: by proof grade and bytecode-match index size. This verb+resource combination is distinct from sibling tools like decode_tx, encode_call, etc., which perform different operations.
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 usage guidance is provided. The description does not specify when to use this tool versus alternatives, nor does it mention any prerequisites or conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_abiResolve contract ABIAResolve a contract's interface from chain + address via a fallback ladder (Etherscan → Sourcify → proxy → heimdall decompile → 4byte). Returns a compact capability manifest (read vs write functions, the 'buttons'), proxy chain, token metadata, and PROVENANCE. ALWAYS read provenance: a decompiled ABI has synthetic function names — treat it with care and confirm intent before writing. Partial, proxy, and bytecode-match results lead with a WARNING before the JSON. The compact manifest/provenance is also returned as structuredContent. Use method_q/method_kind/method_limit for large ABIs. Raw ABI is omitted from MCP output to save tokens; use REST/SDK resolve_abi with include_abi=true if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain alias from GET /v1/chains (for example "ethereum", "base", "monad", "bsc") or numeric EIP-155 chain id. | |
| address | Yes | 0x contract address. | |
| rpc_url | No | Override HTTP(S) RPC URL. Required for chains with no default (e.g. local/31337) or custom EVM chain ids. | |
| method_q | No | Case-insensitive manifest method search across names, signatures, parameters, outputs, and hints. | |
| method_kind | No | Restrict manifest methods to read, write, or all. | |
| method_limit | No | Maximum number of manifest methods to return after filtering. |
| Name | Required | Description |
|---|---|---|
| chain | Yes | |
| proxy | No | |
| token | No | |
| cached | Yes | |
| abi_for | Yes | |
| address | Yes | 0x contract address. |
| interface | Yes | |
| provenance | Yes | |
| abi_omitted | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: fallback ladder, decompiled ABIs have synthetic names, proxy chain returned, raw ABI omitted to save tokens. No contradiction with readOnlyHint=true.
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?
Description is relatively long but every sentence adds functional value. Front-loaded with purpose. Could be slightly more concise but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description need not detail return values. It covers fallback ladder, warnings, proxy chain, token metadata, provenance, and large ABI handling. Fully complete for the tool's complexity.
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% (all parameters described). Description adds value by explaining method_q as case-insensitive search, method_limit as max methods, and reinforces chain types. Exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it resolves a contract's interface from chain and address via a fallback ladder. It distinguishes from siblings by listing specific capabilities like proxy chain, token metadata, and provenance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'ALWAYS read provenance' and 'treat it with care and confirm intent before writing.' Also suggests using method_q, method_kind, method_limit for large ABIs. Does not explicitly exclude contexts, but enough context given sibling tools are different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_nameResolve ENS/Basenames ⇄ addressAResolve an ENS/Basename to an address, or an address to its primary ENS/Basename. Pass chain=base for Basenames.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | An ENS/Basename (vitalik.eth, name.base.eth) or a 0x address. | |
| chain | No | Chain alias from GET /v1/chains (for example "ethereum", "base", "monad", "bsc") or numeric EIP-155 chain id. |
| Name | Required | Description |
|---|---|---|
| name | No | |
| address | No | 0x contract address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description does not need to reiterate safety. The description adds key behavioral context: it supports both forward and reverse resolution. No contradictions with 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 short sentences with zero waste. The first sentence states the core purpose, and the second gives a crucial usage hint. Ideal 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?
Given the low complexity (2 simple params), the presence of an output schema reduces the need to describe return values. The description covers both resolution directions and the chain variant, making it fully complete for agent decision-making.
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 schema already documents both parameters. The description adds context for the 'chain' parameter ('base' for Basenames) but does not provide additional detail beyond the schema's existing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool resolves ENS/Basenames to addresses and vice versa. It specifies that 'chain=base' is for Basenames, and the purpose is distinct from all sibling tools (none of which do name resolution).
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 explicitly tells when to use 'chain=base' for Basenames. However, it lacks explicit guidance on when not to use this tool or mention of alternatives, though none are needed given the unique function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
runtime_metricsRuntime metricsARead process-local resolver/rung/RPC counters for smoke checks and reliability dashboards.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| metrics | Yes | |
| uptime_seconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool reads process-local counters, confirming it is safe and local. No contradictions, and the description usefully supplements annotations with behavioral context about what specific data is 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, well-structured sentence that is front-loaded with the verb and resource. Every word serves a purpose, and there is no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and an output schema, the description sufficiently explains what the tool does and its intended use. It could be slightly more explicit about the return format, but the output schema likely covers that, so completeness is adequate.
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 are no parameters (schema coverage 100% trivially). The description adds meaning by specifying that the tool reads 'resolver/rung/RPC counters', which provides context beyond the empty schema. This is above the baseline of 4 for zero-parameter tools.
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 specifies the verb 'Read' and the exact resource 'process-local resolver/rung/RPC counters', along with the purpose 'for smoke checks and reliability dashboards'. It clearly distinguishes from sibling tools which are about transactions, encoding, and contract interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool is intended for smoke checks and reliability dashboards, implying use for monitoring or health checks. However, it does not explicitly state when not to use or mention alternatives, but given the distinct purpose and sibling tools, the usage guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulateSimulate a transactionASimulate a call and return success, gas, decoded return, and best-effort state diff / asset changes / logs. Provide a high-level call (address + function + args) or raw (to + data), never both.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Raw form: target address. | |
| args | No | Function arguments, in order. Pass uint values as decimal strings. | |
| data | No | Raw form: calldata (0x-prefixed hex bytes). | |
| from | Yes | The sender address (the user's wallet). No key is needed — nothing is signed. | |
| chain | Yes | Chain alias from GET /v1/chains (for example "ethereum", "base", "monad", "bsc") or numeric EIP-155 chain id. | |
| value | No | Native value in wei (decimal string), for payable functions. | |
| address | No | 0x contract address. | |
| rpc_url | No | Override HTTP(S) RPC URL. Required for chains with no default (e.g. local/31337) or custom EVM chain ids. | |
| function | No | Function name, or full signature like "transfer(address,uint256)" if overloaded. |
| Name | Required | Description |
|---|---|---|
| logs | Yes | |
| revert | No | |
| success | Yes | |
| gas_used | Yes | |
| state_diff | Yes | |
| return_value | No | |
| asset_changes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral details beyond readOnlyHint and openWorldHint annotations: discloses return values and notes state diff is 'best-effort'. No contradiction with annotations; simulation is read-only and open-world.
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: first states purpose and return, second provides usage guidance. Extremely concise with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description sufficiently covers return types and input constraints for a 9-parameter simulation tool. No missing critical details.
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 parameter descriptions are clear (e.g., 'no key needed' for from). Description adds value by grouping high-level vs raw parameters and enforcing 'never both' constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool simulates a call and returns success, gas, decoded return, state diff, asset changes, and logs. It distinguishes high-level vs raw input forms, setting it apart from sibling tools like read_contract or prepare_tx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit rule 'never both' for high-level vs raw forms. While it doesn't directly compare with alternatives, the return type implies simulation use case. Could be stronger with when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.