Provides comprehensive monitoring and interaction capabilities for Arbitrum chains, including chain health monitoring, batch posting status, assertion tracking, gas price monitoring, node operations, and account management across Arbitrum One, Nova, and Orbit chains.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Arbitrum MCP Server what's the current status of Arbitrum One?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for interfacing with Arbitrum Nitro nodes and chains in natural language. Monitor chain health, batch posting, assertions, and gas prices across all Arbitrum networks including core chains (Arbitrum One, Nova) and Orbit chains.
Monitor Arbitrum chains with natural language queries through any MCP-compatible client
Related MCP server: Onchain MCP Server
Comprehensive Chain Status - Complete health overview for any Arbitrum chain
Batch Posting Monitoring - Track sequencer batch delivery and backlog
Assertion Monitoring - Monitor NodeCreated vs NodeConfirmed events
Gas Price Monitoring - Track current gas prices and detect spikes
ArbOS Version Detection - Get current ArbOS version for any chain
Core Arbitrum Chains - Arbitrum One, Arbitrum Nova
Orbit Chains - All public Orbit chains (Xai, Superposition, etc.)
Auto-Resolution - Contract addresses resolved automatically from chain names
Health checks and sync status
Transaction tracing (arbtrace_*)
Debug and validation APIs
Maintenance operations
Timeboost express lanes
"What is the current status of Xai?"
comprehensive_chain_status --chainName "Xai""Are batches being posted for Arbitrum One?"
batch_posting_status --chainName "Arbitrum One""Check gas prices on Nova"
gas_status --chainName "Nova"comprehensive_chain_status - Complete chain health overview
batch_posting_status - Batch posting monitoring
assertion_status - Assertion creation/confirmation tracking
gas_status - Current gas price information
list_chains - Show all available Arbitrum chains
search_chains - Find chains by name or ID
chain_info - Get detailed chain information
arbos_version - Get ArbOS version for any chain
node_health - Check node health status
sync_status - Get synchronization status
latest_block - Get latest block information
get_balance / get_balance_ether - Check account balances
get_transaction / get_transaction_receipt - Transaction details
is_contract - Check if address is a contract
Comprehensive Monitoring - Complete chain health overview in one query
Multi-Chain Support - Consistent interface across all Arbitrum chains
Natural Language Interface - Query blockchain data using plain English
Real-Time Data - Live blockchain data with automatic chain discovery
Troubleshooting Ready - Quick health checks for issue diagnosis
Gas & Performance Tracking - Monitor network congestion and costs
The easiest way to run the MCP server with maximum client compatibility:
# Run directly from Docker Hub (no build required!)
docker run -i --rm dewanshparashar/arbitrum-mcp# Install dependencies
npm install
# Build
npm run build
# Run
npm startAdd to your Claude Desktop configuration:
{
"mcpServers": {
"arbitrum-mcp": {
"command": "docker",
"args": ["run", "-i", "--rm", "dewanshparashar/arbitrum-mcp"]
}
}
}{
"mcpServers": {
"arbitrum-mcp": {
"command": "docker",
"args": ["run", "-i", "--rm", "dewanshparashar/arbitrum-mcp"]
}
}
}# Install dependencies
npm install
# Build
npm run build
# Run tests
npm test
# Development mode with watch
npm run devSee DOCKER.md for detailed Docker setup instructions.
⚠️ Important: When using Docker containers to connect to local testnodes, use http://host.docker.internal:8547 instead of http://127.0.0.1:8547 for the RPC URL.
TypeScript - Type-safe development
Viem - Ethereum client for blockchain interactions
@arbitrum/sdk - Official Arbitrum SDK for core chain data
MCP SDK - Model Context Protocol implementation
Docker - Containerized deployment
Fork the repository
Create a feature branch
Add tests for new functionality
Submit a pull request
MIT License - see LICENSE file for details.
Check the health status of the transaction publisher/sequencer (requires admin API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL |
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 mentions 'requires admin API', which adds context about authentication needs, but doesn't disclose other behavioral traits like rate limits, what 'health status' entails, or potential side effects. For a tool with no annotations, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence that front-loads the core purpose and includes the admin requirement. There's no wasted text, making it appropriately concise and well-structured.
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 no annotations and no output schema, the description is minimal but covers the basic purpose and admin context. However, for a health-check tool with potential complexity in what 'health status' means, it lacks details on return values or error conditions, making it only 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 description coverage is 100%, so the schema already documents both parameters ('rpcUrl' and 'chainName') with their descriptions. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high 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 action ('Check') and target ('health status of the transaction publisher/sequencer'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'node_health' or 'comprehensive_chain_status', which also check health-related aspects, so it doesn't fully distinguish itself from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool ('requires admin API'), indicating it's for administrative access. It doesn't specify when not to use it or name alternatives, but the admin requirement gives clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a specific message number (requires debug API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| msgNum | Yes | Message number to validate | |
| full | No | Whether to perform full validation | |
| moduleRoot | No | Optional module root hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'requires debug API' which hints at authentication or access needs, but doesn't disclose other behavioral traits like whether this is a read-only operation, what happens during validation, potential rate limits, or what the output might look like. For a tool with 5 parameters and no annotations, this is inadequate.
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 extremely concise with just one short sentence and a parenthetical note. It's front-loaded with the core purpose and wastes no words, making it easy to parse quickly despite its brevity.
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 5 parameters, no annotations, no output schema, and complexity implied by 'debug API' and validation, the description is incomplete. It doesn't explain what validation means, what results to expect, error conditions, or how this differs from other validation-related tools. For a debug tool with multiple parameters, more context is needed.
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 all 5 parameters thoroughly. The description adds no additional meaning about parameters beyond implying validation of 'msgNum'. Baseline 3 is appropriate when schema does the heavy lifting, though the description doesn't compensate with any extra context about parameter interactions or validation specifics.
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 the tool 'Validate[s] a specific message number' which provides a clear verb ('validate') and resource ('message number'), but it's vague about what validation entails and doesn't distinguish from sibling tools like 'arbdebug_validationInputsAt' or 'assertion_status' that might involve similar validation concepts. The parenthetical '(requires debug API)' adds some context but doesn't fully clarify purpose.
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 tool versus alternatives is provided. The description mentions it 'requires debug API' which implies a prerequisite but doesn't specify when this validation is needed versus other validation or debugging tools in the sibling list. There's no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get validation inputs at a specific message (requires debug API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| msgNum | Yes | Message number to get validation inputs for | |
| target | No | Target for validation inputs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('Get validation inputs') and mentions 'requires debug API' as a prerequisite. It doesn't disclose important behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, what 'validation inputs' actually returns, or any side effects. For a tool with no annotations, this is insufficient.
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, efficient sentence that states the core purpose and includes an important prerequisite ('requires debug API'). It's appropriately sized for what it covers, though it could be more front-loaded with additional context. There's no wasted verbiage 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?
Given the complexity of debugging/validation tools in blockchain contexts, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'validation inputs' are, what format they return, error conditions, or how this differs from similar debugging tools. For a tool that likely returns complex debugging data, more context is needed to help an agent use it effectively.
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 all four parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters (like how chainName and rpcUrl interact), doesn't clarify what 'target' means in context, or provide examples. With complete schema coverage, the baseline score 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?
The description states the tool 'Get validation inputs at a specific message' which provides a verb ('Get') and resource ('validation inputs'), but it's vague about what 'validation inputs' actually are in the context of Arbitrum. It mentions 'requires debug API' which adds some context but doesn't clearly differentiate this tool from siblings like 'arbdebug_validateMessageNumber' or 'arbtrace' tools that might also involve message validation or debugging.
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 no guidance on when to use this tool versus alternatives. While it mentions 'requires debug API', this doesn't specify use cases, prerequisites, or exclusions compared to sibling tools like 'arbdebug_validateMessageNumber' or other debugging/tracing tools. There's no mention of specific scenarios where this tool is appropriate versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve raw block metadata for specified block ranges (requires admin API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| fromBlock | Yes | Starting block number | |
| toBlock | No | Ending block number (defaults to fromBlock if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adds minimal behavioral context: 'requires admin API' hints at authentication needs, but doesn't disclose rate limits, error handling, what 'raw metadata' includes, or if it's read-only/destructive. For a tool with no annotations, this is insufficient.
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, efficient sentence that front-loads the core purpose. It could be slightly more structured by separating prerequisites, but it avoids waste and is appropriately sized.
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 no annotations, no output schema, and a tool that retrieves data with multiple parameters, the description is incomplete. It lacks details on return values, error cases, or how it differs from sibling tools, leaving significant 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond the schema (e.g., no clarification on 'raw metadata' or block range behavior). Baseline 3 is appropriate when 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?
The description clearly states the action ('Retrieve') and resource ('raw block metadata for specified block ranges'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'arbtrace_block' or 'latest_block' that might also retrieve block-related data, preventing a perfect score.
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 mentions 'requires admin API' which provides some context about prerequisites, but it offers no guidance on when to use this tool versus alternatives (e.g., 'arbtrace_block' for trace data or 'latest_block' for recent blocks). There's no explicit when/when-not or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest validated global state information (requires admin API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'requires admin API' which adds important context about authentication needs, but doesn't describe what 'validated global state information' includes, whether this is a read-only operation, potential rate limits, or what the response format looks like. For a tool with zero annotation coverage, this leaves significant 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?
The description is a single, efficient sentence that gets straight to the point. It front-loads the core functionality and includes the important 'requires admin API' qualification. There's no wasted language or unnecessary elaboration.
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 no annotations and no output schema, the description is incomplete for a tool that presumably returns complex global state information. The phrase 'global state information' is vague, and without annotations or output schema, there's insufficient information about what data is returned, its format, or any behavioral constraints beyond the admin API requirement.
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 fully documents both parameters. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation purely through the schema, with no value added by the description.
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 action ('Get') and resource ('latest validated global state information'), making the purpose understandable. It distinguishes itself from siblings by focusing on global state rather than specific transactions, blocks, or health checks. However, it doesn't explicitly differentiate from tools like 'comprehensive_chain_status' or 'chain_info' which might also provide state information.
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 mentions 'requires admin API', which provides some context about prerequisites, but offers no guidance on when to use this tool versus alternatives. With many sibling tools providing various chain data (e.g., 'chain_info', 'comprehensive_chain_status'), there's no indication of when this specific global state information is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the ArbOS version number for any Arbitrum chain. Use this for questions like 'what ArbOS version is Xai running?', 'ArbOS version of Arbitrum One', 'what version of ArbOS', or 'check ArbOS version'. Supports chain names like 'Xai', 'Arbitrum One', 'Nova', etc.
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One', 'Nova') - will auto-resolve to RPC URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Supports chain names like 'Xai', 'Arbitrum One', 'Nova', etc.' and implies a read-only operation ('Get'), but it does not disclose critical behavioral traits such as whether it requires authentication, potential rate limits, error handling, or the format of the returned version number. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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?
The description is appropriately sized and front-loaded, starting with the core purpose ('Get the ArbOS version number...') followed by usage examples. Every sentence adds value, such as clarifying supported chain names, but it could be slightly more structured by separating examples from core functionality for even better readability.
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 low complexity (2 optional parameters, no output schema, no annotations), the description is moderately complete. It covers the purpose and basic usage but lacks details on behavioral aspects like error cases or output format. Without annotations or an output schema, the description should do more to compensate, such as explaining what the version number looks like or common pitfalls, leaving room for improvement.
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 has 100% description coverage, so the schema already documents both parameters ('rpcUrl' and 'chainName') adequately. The description adds marginal value by providing examples of chain names (e.g., 'Xai', 'Arbitrum One', 'Nova') and noting that 'chainName' auto-resolves to RPC URL, but it does not explain parameter interactions or usage beyond what the schema states. This meets the baseline of 3 for 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's purpose with a specific verb ('Get') and resource ('ArbOS version number for any Arbitrum chain'), and distinguishes it from sibling tools by focusing exclusively on version retrieval. It provides concrete examples of use cases like 'what ArbOS version is Xai running?' which reinforces its distinct role.
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 for when to use this tool (e.g., for questions about ArbOS versions) and mentions support for specific chain names like 'Xai' and 'Arbitrum One'. However, it does not explicitly state when not to use it or name alternatives among the many sibling tools, such as 'chain_info' or 'comprehensive_chain_status', which might offer overlapping or broader chain information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get trace information for all transactions in a block (requires trace API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| blockNumOrHash | Yes | Block number or hash to trace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the 'requires trace API' prerequisite, which is useful context about authentication or capability requirements. However, it doesn't describe what 'trace information' includes, whether this is a read-only operation, potential rate limits, error conditions, or what happens if the block doesn't exist. For a tool with no annotation coverage, this leaves significant 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?
The description is a single, efficient sentence that front-loads the core purpose. The parenthetical '(requires trace API)' adds necessary context without verbosity. Every element earns its place, though it could be slightly more structured by separating the prerequisite into its own sentence.
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 no annotations and no output schema, the description is incomplete for a tool that presumably returns complex trace data. It doesn't explain what 'trace information' includes, the format of the response, or potential limitations. For a tool interacting with blockchain trace APIs, this leaves the agent without crucial context about what to expect from the operation.
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 all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting, though the description could have explained relationships between parameters (e.g., rpcUrl vs chainName precedence).
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's purpose: 'Get trace information for all transactions in a block' - specifying the verb ('Get'), resource ('trace information'), and scope ('all transactions in a block'). It distinguishes from siblings like 'arbtrace_transaction' (single transaction) and 'arbtrace_filter' (filtered traces). However, it doesn't explicitly differentiate from 'arbtrace_replayBlockTransactions' which might overlap in functionality.
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 one explicit usage condition: '(requires trace API)', indicating a prerequisite. However, it doesn't specify when to use this tool versus alternatives like 'arbtrace_replayBlockTransactions' or 'arbtrace_filter', nor does it mention when NOT to use it. The guidance is implied but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace individual calls with specified trace types (requires trace API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| callArgs | Yes | Call arguments (to, from, data, etc.) | |
| traceTypes | No | Array of trace types (e.g., ['trace', 'stateDiff']) | |
| blockNumOrHash | No | Block number or hash (defaults to 'latest') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'requires trace API', which hints at authentication or API access needs, but doesn't describe what the tool does beyond tracing (e.g., whether it's read-only, what output format to expect, rate limits, or error handling). For a tool with no annotations and complex functionality, this leaves significant gaps in understanding its 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?
The description is extremely concise with just one sentence: 'Trace individual calls with specified trace types (requires trace API)'. It's front-loaded with the core purpose and includes a useful parenthetical note. There's no wasted verbiage, making it efficient and easy to parse.
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 complexity (tracing calls on Arbitrum with multiple parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what 'trace' entails, what the output looks like, error conditions, or how it differs from sibling tools. For a specialized tool in a set with many alternatives, more context is needed to guide proper usage.
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 all 5 parameters thoroughly. The description adds minimal value beyond the schema by implying trace types are specified, but doesn't provide additional context like example trace types beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
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's purpose: 'Trace individual calls with specified trace types'. It specifies the verb ('trace'), resource ('individual calls'), and scope ('with specified trace types'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'arbtrace_block' or 'arbtrace_transaction', which likely trace 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 provides some usage context with '(requires trace API)', implying this tool is for tracing API calls and may have prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like 'arbtrace_callMany' (for multiple calls) or other tracing siblings, nor does it mention exclusions or specific scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace multiple calls in batch for efficiency (requires trace API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| calls | Yes | Array of call objects to trace | |
| blockNumOrHash | No | Block number or hash (defaults to 'latest') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'for efficiency' and 'requires trace API', which adds some context about performance and prerequisites. However, it lacks details on what 'trace' entails (e.g., what data is returned, error handling, rate limits, or side effects), leaving significant gaps for a tool that likely interacts with blockchain nodes.
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, efficient sentence that front-loads the key information ('Trace multiple calls in batch for efficiency') and includes a necessary prerequisite ('requires trace API'). There's no wasted text, and it's appropriately sized for the tool's complexity.
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 complexity of tracing blockchain calls (with 4 parameters, no output schema, and no annotations), the description is incomplete. It lacks details on what the tool returns, how errors are handled, or the scope of 'trace' (e.g., debugging info, gas usage). Without annotations or an output schema, the description should provide more behavioral context to be fully helpful.
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%, meaning all parameters are documented in the input schema. The description doesn't add any semantic details beyond what's in the schema (e.g., it doesn't explain the structure of 'calls' array items or clarify 'trace API' requirements). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate or add extra value.
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 action ('Trace multiple calls in batch') and the resource ('calls'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'arbtrace_call' (which presumably traces single calls), missing an opportunity for explicit differentiation that would warrant a score of 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 description implies when to use this tool ('for efficiency') and mentions a prerequisite ('requires trace API'), providing some contextual guidance. However, it doesn't explicitly state when to use this versus alternatives like 'arbtrace_call' or other trace siblings, nor does it specify when not to use it, keeping the guidance at an implied level rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter traces based on specified criteria (requires trace API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| filter | Yes | Filter criteria for traces |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'requires trace API,' hinting at dependencies, but fails to describe what the tool does beyond filtering (e.g., output format, pagination, rate limits, or error handling). For a tool with no annotations, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though the parenthetical 'requires trace API' could be integrated more smoothly. Overall, it's appropriately sized with 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?
Given no annotations, no output schema, and a tool that likely returns filtered trace data, the description is incomplete. It doesn't explain what the output looks like, how results are structured, or any limitations (e.g., max filters). For a filtering tool with nested parameters, more context is needed to guide effective use.
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 fully documents the three parameters (rpcUrl, chainName, filter). The description adds no additional meaning beyond implying criteria-based filtering, which is already covered by the schema's 'filter' property description. This meets the baseline for high schema coverage without extra value.
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 action ('Filter') and resource ('traces'), specifying it's based on criteria. It distinguishes from siblings like arbtrace_block or arbtrace_transaction by focusing on filtering rather than retrieving specific trace types. However, it doesn't explicitly differentiate from arbtrace_call or arbtrace_callMany, which might also involve filtering.
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 mentions 'requires trace API' as a prerequisite, which provides some context. However, it offers no guidance on when to use this tool versus alternatives like arbtrace_get or other trace-related siblings, nor does it specify scenarios where filtering is preferred over direct trace retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific trace data at a given path within a transaction (requires trace API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| txHash | Yes | Transaction hash | |
| path | No | Path to specific trace data |
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 mentions 'requires trace API', hinting at a dependency or permission need, but doesn't disclose other behavioral traits such as rate limits, error handling, or what 'specific trace data' entails (e.g., format, size). This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence that front-loads the core action ('Get specific trace data') and includes a key constraint ('requires trace API'). There is no wasted wording, making it highly concise and well-structured.
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 no annotations and no output schema, the description is incomplete for a tool with 4 parameters and complex trace data retrieval. It lacks details on return values, error conditions, or behavioral nuances, which are critical for effective use by an AI agent in this context.
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 all parameters (rpcUrl, chainName, txHash, path). The description adds minimal value by implying 'path' is used to locate trace data, but doesn't provide additional semantics beyond what's in the schema. Baseline 3 is appropriate when 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?
The description clearly states the verb ('Get') and resource ('specific trace data at a given path within a transaction'), making the purpose understandable. However, it doesn't explicitly differentiate this from sibling tools like 'arbtrace_transaction' or 'arbtrace_call', which likely retrieve different types of trace data, so it doesn't reach the highest score.
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 includes a prerequisite ('requires trace API'), which provides some context, but it doesn't specify when to use this tool versus alternatives like 'arbtrace_transaction' or 'arbtrace_call' from the sibling list. No explicit guidance on when-not-to-use or comparisons is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay and trace all transactions in a specific block (requires trace API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| blockNumOrHash | Yes | Block number or hash to replay | |
| traceTypes | No | Array of trace types (e.g., ['trace', 'stateDiff']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the trace API requirement but doesn't describe what 'replay' entails (e.g., simulated execution, state changes), potential performance impacts, rate limits, authentication needs, or output format. For a tool with 'replay' in its name and no annotations, this leaves significant 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?
The description is a single, efficient sentence that front-loads the core purpose and key requirement. Every word earns its place with zero waste or redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool named 'replayBlockTransactions' with no annotations and no output schema, the description is insufficient. It doesn't explain what 'replay' means operationally, what the trace output looks like, performance characteristics, or error conditions. Given the complexity implied by 'replay' and tracing, more context is needed for effective use.
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 parameters are well-documented in the schema itself. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., explaining trace types in more detail, clarifying blockNumOrHash format, or elaborating on RPC URL resolution). Baseline 3 is appropriate 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?
The description clearly states the action ('Replay and trace') and resource ('all transactions in a specific block'), with the specific requirement 'requires trace API' distinguishing it from basic block retrieval tools. However, it doesn't explicitly differentiate from sibling tools like 'arbtrace_block' or 'arbtrace_transaction' that might handle similar tracing 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?
The description implies usage context with 'requires trace API', suggesting this tool is for detailed transaction analysis rather than basic block data. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'arbtrace_block' or 'arbtrace_replayTransaction', nor does it mention prerequisites beyond the trace API requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay and trace a specific transaction (requires trace API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| txHash | Yes | Transaction hash to replay | |
| traceTypes | No | Array of trace types (e.g., ['trace', 'stateDiff']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool replays and traces transactions and mentions a prerequisite ('requires trace API'), but doesn't describe what 'replay' entails, what the output looks like, whether it's read-only or destructive, or any rate limits or authentication needs. This leaves significant behavioral gaps for a tool with 4 parameters.
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, efficient sentence that directly states the tool's purpose and prerequisite. It's appropriately sized and front-loaded with the core functionality, though it could be slightly more structured by separating the prerequisite into a second sentence for clarity.
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 complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, output format, and usage context relative to siblings. For a transaction replay tool with multiple parameters and no structured output documentation, the description should provide more comprehensive guidance to be 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%, meaning all parameters are documented in the input schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain 'traceTypes' options or 'chainName' mappings). According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 action ('Replay and trace') and the target resource ('a specific transaction'), which provides a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'arbtrace_transaction' or 'arbtrace_replayBlockTransactions', missing explicit differentiation that would warrant a score of 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 description mentions a prerequisite ('requires trace API') but provides no guidance on when to use this tool versus alternatives like 'arbtrace_transaction' or 'arbtrace_replayBlockTransactions'. There's no explicit when/when-not instructions or named alternatives, resulting in minimal usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get trace information for a specific transaction (requires trace API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| txHash | Yes | Transaction hash to trace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'requires trace API', which hints at a dependency or prerequisite, but doesn't disclose other traits like whether this is a read-only operation, potential rate limits, error conditions, or what the trace information includes. For a tool with no annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose and a key requirement ('requires trace API'). It's front-loaded with no wasted words, making it highly concise and well-structured for quick comprehension.
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 complexity of trace operations, no annotations, and no output schema, the description is incomplete. It lacks details on what 'trace information' entails, how it's formatted, error handling, or performance considerations. For a tool that likely returns detailed data, this minimal description leaves too many gaps for effective agent use.
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 description doesn't add any parameter-specific information beyond what's already in the input schema, which has 100% schema description coverage. Since the schema fully documents the three parameters (rpcUrl, chainName, txHash), the baseline score of 3 is appropriate, as the description doesn't need to compensate but also doesn't enhance parameter understanding.
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's purpose with a specific verb ('Get trace information') and resource ('for a specific transaction'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'arbtrace_block' or 'arbtrace_call', which likely provide different types of trace information, so it doesn't reach the highest score.
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 by specifying 'requires trace API', which suggests a prerequisite context, but it doesn't provide explicit guidance on when to use this tool versus alternatives like other 'arbtrace_' siblings. The context is somewhat implied but lacks clear when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor assertion creation and confirmation activity. Tracks NodeCreated vs NodeConfirmed events to understand rollup validation status. Critical for PM and support teams to monitor chain security and finality.
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum chain (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| parentRpcUrl | Yes | Parent chain RPC URL (e.g., Ethereum mainnet RPC) | |
| rollupAddress | Yes | Rollup contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool monitors (assertion activity, rollup validation status) but lacks critical behavioral details: whether this is a read-only operation, if it requires specific permissions, how data is returned (e.g., real-time monitoring vs historical query), or any rate limits. The description doesn't contradict annotations (none exist), but it's insufficient for a mutation/query tool with zero annotation coverage.
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 appropriately sized (three sentences) and front-loaded with the core purpose. Each sentence adds value: the first states what it does, the second elaborates on tracking specifics, and the third provides usage context. There's minimal waste, though the third sentence could be more integrated with the first two.
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 monitoring tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on what the tool returns (e.g., event logs, status summaries), behavioral constraints (e.g., read-only, permissions needed), and how parameters affect output. The high schema coverage helps with inputs, but overall context for agent invocation remains inadequate.
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 all 4 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain how parameters interact or affect monitoring behavior). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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's purpose: 'Monitor assertion creation and confirmation activity' with specific tracking of 'NodeCreated vs NodeConfirmed events'. It distinguishes itself from siblings by focusing on rollup validation status monitoring rather than general chain operations or debugging. However, it doesn't explicitly contrast with specific sibling tools like 'comprehensive_chain_status' or 'sync_status'.
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 implied usage context: 'Critical for PM and support teams to monitor chain security and finality.' This suggests when the tool is valuable but doesn't explicitly state when to use it versus alternatives like 'comprehensive_chain_status' or 'sync_status'. No specific exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit auction resolution transactions for express lane functionality (requires auctioneer API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| transaction | Yes | Auction resolution transaction data |
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 mentions 'requires auctioneer API', hinting at authentication needs, but lacks details on permissions, rate limits, side effects, or what 'submit' entails (e.g., irreversible transaction). This leaves behavioral traits largely undisclosed.
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, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by separating the API requirement into a second sentence for clarity.
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 no annotations, no output schema, and a mutation tool ('submit') with nested objects, the description is incomplete. It lacks details on authentication, transaction behavior, error handling, and return values, making it inadequate for safe and effective use.
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 all parameters. The description adds no additional meaning beyond implying 'auction resolution transaction data' for the 'transaction' parameter, but this is redundant with the schema. Baseline 3 is appropriate as 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?
The description states the tool 'submit[s] auction resolution transactions for express lane functionality', which provides a clear verb ('submit') and resource ('auction resolution transactions'). However, it doesn't differentiate from sibling tools like 'timeboost_sendExpressLaneTransaction' that also handle express lane functionality, making the purpose somewhat vague in context.
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 mentions 'requires auctioneer API', which implies a prerequisite but doesn't specify when to use this tool versus alternatives. There's no guidance on scenarios, exclusions, or comparisons with sibling tools, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor batch posting activity. Tracks when batches were last posted to the sequencer inbox and current backlog size. Essential for PM and support teams to understand chain data availability status.
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum chain (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| parentRpcUrl | Yes | Parent chain RPC URL (e.g., Ethereum mainnet RPC) | |
| sequencerInboxAddress | Yes | Sequencer inbox contract address | |
| bridgeAddress | Yes | Bridge contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions what the tool monitors (last posted batches, backlog size), it doesn't describe the tool's behavior: whether it's a read-only operation, what format the output takes, whether it requires authentication, rate limits, or potential side effects. The description provides basic functionality but lacks important behavioral context for a monitoring 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 description is appropriately concise with two sentences that efficiently convey the tool's purpose and target audience. The first sentence clearly states what the tool does, and the second explains its importance. There's no wasted verbiage, though it could be slightly more structured by explicitly separating functionality from usage 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?
For a monitoring tool with 5 parameters and no output schema, the description provides adequate but incomplete context. It explains what the tool monitors but doesn't describe the output format, return values, or what 'backlog size' and 'last posted' metrics actually represent. With no annotations and no output schema, users lack important information about what to expect from this tool's execution.
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 description provides no parameter information beyond what's already in the schema. However, with 100% schema description coverage, all 5 parameters are well-documented in the schema itself. The baseline score of 3 is appropriate since the schema does the heavy lifting, though the description adds no additional parameter context beyond the tool's overall purpose.
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's purpose: 'Monitor batch posting activity' with specific tracking of 'when batches were last posted' and 'current backlog size'. It identifies the resource as 'sequencer inbox' and mentions 'chain data availability status'. However, it doesn't explicitly differentiate from sibling tools like 'sync_status' or 'maintenance_status' that might also monitor chain status.
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 some usage context by stating it's 'Essential for PM and support teams to understand chain data availability status', which implies when this tool would be valuable. However, it doesn't explicitly state when to use this tool versus alternatives like 'sync_status' or 'comprehensive_chain_status', nor does it provide exclusion criteria or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive chain information including rollup contract address, bridge addresses, chain ID, RPC URL, explorer URL, native token details, and all bridge contract addresses. Use this for questions about rollup addresses, bridge contracts, chain IDs, or any chain-specific data for Arbitrum chains like Xai, Arbitrum One, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| chainName | Yes | Chain name to look up (e.g., 'Xai', 'Arbitrum One', 'Nova', 'Stylus') |
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 describes what data is returned (comprehensive chain information) but lacks details on behavioral traits such as error handling (e.g., what happens if chainName is invalid), performance characteristics (e.g., response time), or data freshness. The description is accurate but minimal on behavioral aspects beyond the core functionality.
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 efficiently structured in two sentences: the first lists all returned data comprehensively, and the second provides usage guidelines with examples. Every sentence adds value without redundancy, making it easy for an agent to parse and apply.
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 complexity (single parameter, no output schema, no annotations), the description is mostly complete. It clearly states the purpose, usage, and data returned. However, it lacks details on output format (e.g., JSON structure) and error handling, which could be important for an agent to interpret results correctly. The absence of an output schema means the description should ideally cover return values more explicitly.
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 the 'chainName' parameter with examples. The description adds value by specifying the scope ('Arbitrum chains like Xai, Arbitrum One, etc.') and implying that valid chain names are needed, but it doesn't provide additional syntax or format details beyond what the schema offers. With 0 parameters beyond the documented one, a baseline of 4 is appropriate as the description compensates slightly for the lack of output 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 the specific action ('Get comprehensive chain information') and enumerates the exact resources returned (rollup contract address, bridge addresses, chain ID, RPC URL, explorer URL, native token details, bridge contract addresses). It distinguishes itself from siblings like 'get_rollup_address' or 'list_chains' by emphasizing comprehensive data retrieval rather than single attributes or listings.
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 states when to use this tool: 'for questions about rollup addresses, bridge contracts, chain IDs, or any chain-specific data for Arbitrum chains like Xai, Arbitrum One, etc.' It provides clear context and examples of appropriate use cases, helping the agent differentiate from alternatives like 'get_rollup_address' (which only gets one address) or 'list_chains' (which lists chains without detailed info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the default RPC URL
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Clear' suggests a mutation operation, but the description doesn't disclose behavioral traits such as permissions required, whether this affects system state persistently, error conditions, or what happens after clearing (e.g., reverts to a default or leaves empty).
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand 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?
Given the tool has no parameters, no output schema, and no annotations, the description is minimally adequate. However, as a mutation tool, it lacks details on behavioral context (e.g., what 'clear' entails, side effects, or typical outcomes), leaving gaps for an AI agent to infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for.
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 'Clear the default RPC URL' clearly states the action (clear) and resource (default RPC URL). It distinguishes from sibling tools like 'get_rpc_url' (read) and 'set_rpc_url' (write), but doesn't explicitly mention these alternatives in the description itself.
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 is provided on when to use this tool versus alternatives like 'set_rpc_url' or 'get_rpc_url'. The description implies it resets a configuration but doesn't specify prerequisites, consequences, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive chain status including ArbOS version, batch posting, assertion monitoring, and gas prices. Perfect for PM and support teams asking 'what is the current status of XAI?' or similar comprehensive status checks. Auto-resolves contract addresses from chain name when possible.
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum chain (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve RPC URL and contract addresses | |
| parentRpcUrl | No | Parent chain RPC URL (auto-resolved if chainName provided) | |
| sequencerInboxAddress | No | Sequencer inbox contract address (auto-resolved if chainName provided) | |
| bridgeAddress | No | Bridge contract address (auto-resolved if chainName provided) | |
| rollupAddress | No | Rollup contract address (auto-resolved if chainName provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses auto-resolution capabilities ('Auto-resolves contract addresses from chain name when possible') and implies read-only behavior through 'Get' without mentioning destructive actions. However, it doesn't cover rate limits, error handling, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that each earn their place: first states purpose, second provides usage guidelines, third adds behavioral context. It's front-loaded with the core purpose but could be slightly more concise by combining some elements.
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 6-parameter tool with no annotations and no output schema, the description does well by covering purpose, usage context, and key behavioral traits. However, it doesn't explain what 'comprehensive chain status' actually returns or provide examples of the output format, which would be helpful given the lack of output schema.
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 all 6 parameters thoroughly. The description adds minimal value beyond the schema by mentioning auto-resolution for addresses when chainName is provided, but doesn't explain parameter interactions or provide additional syntax guidance. Baseline 3 is appropriate when schema does 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?
The description clearly states the tool's purpose with specific verbs ('Get comprehensive chain status') and resources ('ArbOS version, batch posting, assertion monitoring, and gas prices'). It distinguishes from siblings by emphasizing comprehensiveness, unlike more specific tools like 'arbos_version' or 'gas_status'.
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 states when to use this tool: 'Perfect for PM and support teams asking 'what is the current status of XAI?' or similar comprehensive status checks.' This provides clear context and distinguishes it from more specialized sibling tools like 'chain_info' or 'node_health'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor current gas prices on the chain. Essential for identifying gas price spikes and understanding transaction costs. Useful for PM and support teams to monitor network congestion.
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum chain (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's function (monitoring gas prices) and target users (PM and support teams), but lacks critical behavioral details such as whether this is a read-only operation, potential rate limits, authentication requirements, or what the output format looks like (especially problematic since there's no output schema). For a tool with no annotation coverage, this is a significant 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?
The description is appropriately sized with three sentences that each serve a purpose: stating the core function, explaining its importance for identifying spikes, and identifying target user groups. It's front-loaded with the main purpose and avoids unnecessary repetition or fluff. However, the third sentence about user groups could be considered slightly extraneous for pure tool functionality.
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 complexity (monitoring tool with network implications), lack of annotations, and absence of an output schema, the description is incomplete. It doesn't explain what information is returned (e.g., current gas price, historical data, congestion metrics), how results are formatted, or any behavioral constraints. For a tool that presumably provides critical network data, this leaves significant gaps for an AI agent to understand how to properly use and interpret results.
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 input schema already fully documents both parameters (rpcUrl and chainName) with descriptions. The tool description doesn't add any additional meaning or context about these parameters beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter info in the description.
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's purpose as monitoring current gas prices on the chain, identifying gas price spikes, and understanding transaction costs. It uses specific verbs ('monitor', 'identifying', 'understanding') and identifies the resource ('gas prices on the chain'). However, it doesn't explicitly differentiate this from sibling tools that might also provide gas-related information or network status.
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 context by stating it's 'essential for identifying gas price spikes' and 'useful for PM and support teams to monitor network congestion,' which suggests when this tool might be appropriate. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., other sibling tools like 'chain_info' or 'comprehensive_chain_status'), nor does it specify exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get balance of an address in wei
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the chain (optional if default is set) | |
| address | Yes | Ethereum address to check balance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool does but doesn't disclose behavioral traits like whether it's read-only, potential rate limits, error conditions, authentication needs, or what happens with invalid addresses. For a tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
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?
Extremely concise single sentence with zero waste. Every word earns its place: verb ('Get'), resource ('balance'), target ('of an address'), and unit specification ('in wei'). Front-loaded with the core purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 2 parameters, the description is insufficient. It doesn't explain what the return value looks like (balance as number/string, error formats), doesn't mention the blockchain context implied by 'wei', and provides no behavioral context. The 100% schema coverage helps with parameters but doesn't compensate for other gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it mentions 'address' but doesn't provide additional context about format validation or the rpcUrl parameter. Baseline 3 is appropriate when 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?
The description clearly states the action ('Get balance') and resource ('of an address'), specifying the unit ('in wei'). It distinguishes from sibling 'get_balance_ether' by specifying wei vs ether units. However, it doesn't explicitly mention the blockchain context or differentiate from other balance-checking tools beyond the unit.
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 tool versus alternatives like 'get_balance_ether' or other sibling tools. The description mentions 'wei' which implies a unit difference from 'get_balance_ether', but doesn't explicitly state when to choose one over the other or provide any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get balance of an address in ETH
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the chain (optional if default is set) | |
| address | Yes | Ethereum address to check balance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get balance'), implying it's non-destructive, but lacks details on permissions, rate limits, error handling, or return format. This is insufficient for a tool with potential network dependencies.
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, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the balance return value looks like (e.g., in wei or ETH), error conditions, or dependencies on the RPC URL. This leaves significant gaps for an AI agent to use the tool effectively.
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 input schema fully documents both parameters. The description adds no additional semantic context about parameters beyond what's in the schema, such as address format validation or RPC URL implications. Baseline 3 is appropriate 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?
The description clearly states the action ('Get balance') and resource ('of an address in ETH'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'get_balance' (without 'ether'), leaving ambiguity about when to use one versus the other.
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 no guidance on when to use this tool versus alternatives, such as the sibling 'get_balance' tool. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent to infer usage context independently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the rollup contract address for a specific Arbitrum chain. Use this for direct rollup address queries like 'what's the rollup address of Xai?', 'Xai rollup contract', or 'rollup address for Arbitrum One'.
| Name | Required | Description | Default |
|---|---|---|---|
| chainName | Yes | Chain name to get rollup address for (e.g., 'Xai', 'Arbitrum One', 'Nova') |
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 describes the tool's behavior as retrieving contract addresses for specific chains, which is clear but lacks details on error handling, rate limits, or authentication requirements. While it specifies the query context, it doesn't disclose potential limitations or response formats, leaving gaps for a tool with no annotation coverage.
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 appropriately sized and front-loaded, with the first sentence stating the core purpose and the second providing usage examples. Every sentence earns its place by clarifying when and how to use the tool, with no redundant or unnecessary information, making it efficient and easy to parse.
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 low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and parameter context adequately. However, it lacks details on return values or error cases, which would be beneficial since there's no output schema. For a simple query tool, this is a minor gap.
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 has 100% description coverage, with the single parameter 'chainName' well-documented in the schema. The description adds minimal value beyond the schema by implying the parameter is used for queries like 'Xai' or 'Arbitrum One', but doesn't provide additional syntax or format details. Given the high schema coverage, a baseline score 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?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('rollup contract address for a specific Arbitrum chain'), and distinguishes it from siblings by focusing on direct rollup address queries. It provides concrete examples like 'Xai' and 'Arbitrum One' to illustrate its unique function among other tools that handle different blockchain 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?
The description explicitly states when to use this tool: 'for direct rollup address queries' and provides specific query examples ('what's the rollup address of Xai?', 'Xai rollup contract', 'rollup address for Arbitrum One'). This gives clear context for usage without needing to reference alternatives, as the tool's purpose is distinct from siblings like 'get_balance' or 'chain_info'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current default RPC URL
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves the 'current default RPC URL', implying a read operation, but doesn't specify if it requires authentication, has rate limits, returns cached or real-time data, or what happens if no URL is set. This leaves significant behavioral gaps for a tool with zero annotation coverage.
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, clear sentence that directly states the tool's function without any unnecessary words. It's front-loaded and efficiently conveys the essential information, making it highly concise and well-structured.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the return value includes (e.g., URL string, error if unset) or behavioral aspects like permissions. For a tool with no structured data support, more detail is needed to fully inform 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 tool has 0 parameters, and the input schema has 100% description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's purpose instead, which aligns with the baseline expectation 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 clearly states the action ('Get') and the resource ('current default RPC URL'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'set_rpc_url' or 'clear_rpc_url', which would require mentioning it's a read-only operation versus mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like retrieving the RPC URL for configuration checks, nor does it reference sibling tools such as 'set_rpc_url' for updates or 'clear_rpc_url' for removal, leaving usage context unclear.
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
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the chain (optional if default is set) | |
| txHash | Yes | Transaction hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('Get'), implying it's non-destructive, but doesn't disclose behavioral traits like error handling, rate limits, authentication needs, or what 'details' include. This is inadequate for a tool with no annotation coverage.
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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple lookup tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'details' are returned, error conditions, or how it differs from siblings. For a tool in a complex environment with many alternatives, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no meaning beyond the schema—it doesn't explain parameter interactions, format specifics, or examples. Baseline 3 is appropriate as 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?
The description clearly states the action ('Get') and resource ('transaction details'), specifying it retrieves details by hash. It's specific about the lookup mechanism but doesn't differentiate from sibling tools like 'get_transaction_receipt' or 'arbtrace_transaction', which appear to serve similar 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?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_transaction_receipt' and 'arbtrace_transaction' available, the description lacks any context about differences, prerequisites, or exclusions, leaving usage unclear.
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
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the chain (optional if default is set) | |
| txHash | Yes | Transaction hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, the description doesn't mention authentication requirements, rate limits, error conditions, or what format the receipt returns. For a tool with no annotation coverage, this leaves significant 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?
The description is maximally concise at just 5 words, front-loading the essential purpose with zero wasted language. Every word earns its place in this efficiently structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what a transaction receipt contains, what format it returns, or how it differs from related transaction tools. The minimal description leaves too many contextual questions unanswered.
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 thoroughly. The description adds no additional parameter context beyond what's in the schema (e.g., hash format, RPC URL defaults). With complete schema coverage, the baseline score 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?
The description clearly states the action ('Get') and target resource ('transaction receipt by hash'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_transaction' or 'arbtrace_transaction' that might also retrieve transaction-related data, preventing a perfect score.
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 no guidance on when to use this tool versus alternatives. With sibling tools like 'get_transaction' and 'arbtrace_transaction' available, there's no indication of what distinguishes this receipt-fetching tool from those other transaction-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if an address is a contract
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the chain (optional if default is set) | |
| address | Yes | Address to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Check') but doesn't describe what 'contract' means in this context, potential errors (e.g., invalid addresses), rate limits, or response format. This is inadequate for a tool with network dependencies.
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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that interacts with a blockchain (implied by RPC and address parameters), the description is incomplete. It lacks output details (no schema provided), doesn't explain what constitutes a 'contract' versus other address types, and omits error handling or network behavior, leaving gaps for the 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?
Schema description coverage is 100%, so the schema fully documents both parameters. The description doesn't add any semantic context beyond implying the 'address' parameter is the target, which is already clear from the schema. This meets the baseline for 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's purpose with a specific verb ('Check') and resource ('if an address is a contract'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'get_balance' or 'get_transaction', which also operate on addresses but serve 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an RPC URL), exclusions, or related tools for checking address properties, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest block information
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the chain (optional if default is set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states this is a 'Get' operation (implying read-only), but doesn't mention any behavioral traits like rate limits, authentication needs, or what specific 'block information' includes. This is inadequate for a tool with no annotation coverage.
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, efficient sentence that gets straight to the point without any wasted words. It's appropriately sized for a simple tool and front-loaded with the core purpose.
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 no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'block information' includes, how the data is formatted, or any error conditions. For a tool that presumably returns blockchain data, more context about the return value would be helpful.
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 has 100% description coverage, with the single parameter 'rpcUrl' well-documented in the schema. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline score when schema coverage is high.
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 action ('Get') and resource ('latest block information'), making the tool's purpose immediately understandable. However, it doesn't differentiate from siblings like 'arb_get_raw_block_metadata' or 'arb_latest_validated' which might also retrieve block data, so it doesn't reach the highest score.
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 no guidance on when to use this tool versus alternatives. With many sibling tools that might retrieve block-related information (e.g., 'arb_get_raw_block_metadata', 'arb_latest_validated'), there's no indication of what makes this tool distinct or when it's preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Arbitrum Orbit chains and their names. Use this to see what chains are available for querying.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 mentions 'list all available' but lacks details on pagination, rate limits, or response format. However, it does imply a read-only operation and hints at use for querying preparation, adding some behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the purpose, and the second provides usage guidance. It's front-loaded with the core function and efficiently communicates essential information without 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?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but could be more complete. It covers purpose and usage well, but lacks details on output format or behavioral traits like performance. For a list tool, this is minimal but viable, leaving some gaps in full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but that's unnecessary here. A baseline of 4 is appropriate as it compensates for the lack of parameters by clearly stating the tool's scope.
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 verb 'list' and the resource 'Arbitrum Orbit chains and their names', making the purpose specific and unambiguous. It distinguishes from siblings like 'search_chains' by emphasizing 'all available' without filtering, and from 'chain_info' which likely provides details on a specific chain rather than listing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this to see what chains are available for querying', providing clear context for when to use this tool. It differentiates from 'search_chains' by implying this lists all chains without search criteria, and from query-focused siblings like 'arbtrace_call' by indicating it's for discovery before querying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check maintenance status - seconds since last maintenance (requires admin API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the admin API requirement, which is useful context about authentication needs. However, it doesn't describe what the tool returns (e.g., a numeric value, status object, or error conditions), whether it has side effects, rate limits, or other behavioral traits. The description adds minimal value beyond the basic purpose.
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, efficient sentence that front-loads the core purpose. Every word earns its place by specifying what's checked and the permission requirement. However, it could be slightly more structured by separating the purpose from the constraint for better readability.
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 complexity (a status check with admin requirements) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a number, status object, or error format), how to interpret the 'seconds since last maintenance' metric, or potential failure modes. For a tool with no structured output documentation, this is a significant gap.
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 fully documents both parameters (rpcUrl and chainName). The description doesn't add any parameter-specific information beyond what's in the schema, such as how these parameters interact or default behaviors. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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's purpose with a specific verb ('Check') and resource ('maintenance status'), and includes a key metric ('seconds since last maintenance'). However, it doesn't explicitly distinguish this tool from sibling tools like 'maintenance_trigger' or 'comprehensive_chain_status', which might have overlapping or related functionality.
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 some usage context by mentioning 'requires admin API', which implies this tool needs elevated permissions. However, it doesn't explicitly state when to use this tool versus alternatives like 'node_health', 'sync_status', or 'comprehensive_chain_status', nor does it provide exclusions or clear prerequisites beyond the API requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually trigger maintenance operations (requires admin API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'requires admin API' which hints at permission requirements, but doesn't describe what the tool actually does (what maintenance operations are performed), whether it's destructive, what the response looks like, or any rate limits. For a tool that presumably modifies system state, this is insufficient behavioral context.
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 appropriately concise at just 7 words. It's front-loaded with the core purpose ('Manually trigger maintenance operations') and includes the important constraint ('requires admin API') in parentheses. Every word serves a purpose with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that presumably performs system maintenance operations with no annotations and no output schema, the description is incomplete. It doesn't explain what maintenance operations are performed, what the expected outcomes are, or provide sufficient context about when and why to use it. The 'requires admin API' hint helps but doesn't compensate for the lack of behavioral transparency.
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 fully documents both parameters (rpcUrl and chainName). The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 the tool 'Manually trigger maintenance operations' which provides a clear verb ('trigger') and resource ('maintenance operations'), but it's somewhat vague about what specific maintenance operations are performed. It doesn't distinguish from siblings like 'maintenance_status' which presumably checks status rather than triggering 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?
The description mentions 'requires admin API' which provides some context about prerequisites, but doesn't explicitly state when to use this tool versus alternatives. There's no guidance about when maintenance should be triggered or what conditions warrant its use versus other tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Arbitrum node health status (requires admin API access - may not work with public RPCs)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context about access requirements ('requires admin API access') and compatibility limitations ('may not work with public RPCs'), which goes beyond what the input schema provides. However, it doesn't describe what 'health status' actually means, what metrics are checked, what the return format looks like, or any error conditions - significant gaps for a tool with no annotations or output 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?
The description is perfectly concise - a single sentence that packs essential information: the core purpose followed immediately by critical usage constraints. Every word earns its place with zero waste. The structure is front-loaded with the main purpose, making it immediately clear what the tool does.
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 that there are no annotations and no output schema, the description provides some important context about access requirements but leaves significant gaps. For a health-checking tool, the description doesn't explain what constitutes 'health status', what metrics or checks are performed, what the return format looks like, or what happens when the check fails. The access requirement information is valuable but insufficient for full completeness.
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 thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions RPC URLs in the context of admin access requirements but doesn't provide additional semantic context about the parameters themselves. This meets the baseline expectation when schema coverage is complete.
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's purpose: 'Check Arbitrum node health status' - a specific verb ('Check') and resource ('Arbitrum node health status'). It distinguishes from siblings by focusing on node health rather than other aspects like block tracing, balance checking, or chain status. However, it doesn't explicitly differentiate from similar health-related tools like 'arb_check_publisher_health' or 'comprehensive_chain_status'.
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 for when to use this tool: 'requires admin API access - may not work with public RPCs'. This gives important guidance about prerequisites and limitations. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for different scenarios, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get connected peers information (requires admin API access - will not work with public RPCs)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context about access requirements (admin API vs public RPCs), which isn't captured in the schema. However, it doesn't describe what the tool returns (peer information format), potential rate limits, error conditions, or whether this is a read-only operation (though 'Get' implies reading).
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 extremely concise - a single sentence that communicates both the core purpose and critical usage constraint. Every word earns its place, with no wasted text. The structure is front-loaded with the main functionality followed by important constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 1 parameter (100% schema coverage) but no annotations and no output schema, the description provides adequate but minimal context. It covers the purpose and access requirements but doesn't describe what the output looks like (peer information format) or other behavioral aspects. Given the simple parameter structure, this is minimally viable but leaves room for improvement.
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 schema description coverage is 100%, with the single parameter 'rpcUrl' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. With complete schema coverage, the baseline score of 3 is appropriate since the description doesn't 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?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('connected peers information'), making it immediately understandable. It doesn't explicitly differentiate from sibling tools like 'node_health' or 'chain_info', but the focus on peer connections is reasonably distinct within the context of node management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool by specifying that it 'requires admin API access' and 'will not work with public RPCs'. This gives important prerequisites for successful invocation. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Arbitrum chains by name, chain ID, or partial name match. Perfect for finding chains when you have incomplete information.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (chain name like 'Xai', 'Arbitrum One', chain ID like '42161', or partial name) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'perfect for finding chains when you have incomplete information,' which implies a search operation, but it does not disclose critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
The description is appropriately sized and front-loaded, consisting of two concise sentences that directly convey the tool's purpose and usage context without any wasted words. Every sentence earns its place by providing essential information efficiently.
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 complexity (a search function with no output schema and no annotations), the description is incomplete. It lacks details on behavioral aspects like safety, output format, or error handling, which are crucial for an AI agent to use the tool effectively. The description does not compensate for the absence of structured data, leaving gaps in contextual understanding.
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 has 100% description coverage, with the 'query' parameter well-documented in the schema. The description adds minimal value by reiterating that searches can be by 'name, chain ID, or partial name match,' which is already implied in the schema's description. Since schema coverage is high, the baseline score of 3 is appropriate, as the description does not significantly enhance parameter understanding 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 the tool's purpose with specific verbs ('search for Arbitrum chains') and resources ('by name, chain ID, or partial name match'), distinguishing it from sibling tools like 'list_chains' by emphasizing search functionality rather than listing. It explicitly mentions the types of queries accepted, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool ('when you have incomplete information'), but it does not explicitly mention when not to use it or name specific alternatives like 'list_chains' for broader queries. This gives good guidance but lacks explicit exclusions or named sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the default RPC URL for subsequent requests
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | Yes | The RPC URL to set as default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states this is a 'set' operation implying mutation, but doesn't disclose behavioral traits like whether this requires specific permissions, if it's persistent across sessions, what happens on invalid URLs, or any rate limits. The description is minimal and lacks crucial operational context.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after setting the URL, whether there's confirmation, error conditions, or how this interacts with other tools. Given the complexity of configuring RPC endpoints, more context is needed.
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% with the single parameter 'rpcUrl' well-documented in the schema. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline for high schema coverage without compensating value.
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 action ('Set') and the resource ('default RPC URL'), specifying it's for subsequent requests. It distinguishes from sibling 'clear_rpc_url' by being a set operation, but doesn't explicitly differentiate from other tools that might involve RPC configuration.
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 mentions 'for subsequent requests' which provides some context about when the effect applies, but offers no guidance on when to use this versus alternatives like 'get_rpc_url' or 'clear_rpc_url', nor any prerequisites or warnings about misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get node synchronization status (may fall back to current block number if sync API unavailable)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively reveals key traits: it's a read operation ('Get'), it may have fallback logic, and it depends on API availability. This covers safety and reliability aspects well for a simple tool, though it doesn't detail error handling or response format, which would enhance transparency further.
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, efficient sentence that front-loads the core purpose and includes critical behavioral context (the fallback mechanism). There is zero waste or redundancy, making it easy to parse and understand quickly, which is ideal for tool selection by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no annotations, and no output schema, the description is reasonably complete. It covers what the tool does and key behavioral nuances. However, it doesn't explain the return values or potential errors, which would be helpful given the lack of output schema. Overall, it's adequate but could be more comprehensive for full contextual understanding.
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 has 100% description coverage, with the parameter 'rpcUrl' clearly documented as optional with a default. The description adds no additional parameter information beyond what the schema provides, such as format examples or usage tips. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose with a specific verb ('Get') and resource ('node synchronization status'), making it immediately understandable. It distinguishes from siblings by focusing on sync status rather than health, peers, or other node metrics. However, it doesn't explicitly differentiate from tools like 'node_health' or 'comprehensive_chain_status', which might overlap in monitoring contexts.
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 by mentioning a fallback behavior ('may fall back to current block number if sync API unavailable'), which suggests when this tool might be preferred over direct block queries. However, it lacks explicit guidance on when to use it versus alternatives like 'node_health' or 'latest_block', and doesn't specify prerequisites or exclusions, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit priority transactions through express lanes for faster processing (requires timeboost API)
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No | The RPC URL of the Arbitrum node (optional if default is set) | |
| chainName | No | Chain name (e.g., 'Xai', 'Arbitrum One') - will auto-resolve to RPC URL | |
| submission | Yes | Express lane submission data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'priority transactions' and 'faster processing' which suggests performance characteristics, but doesn't disclose critical behavioral traits like authentication requirements, rate limits, cost implications, error handling, or what constitutes a successful submission. The description is insufficient for a mutation tool with zero annotation coverage.
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, efficient sentence that communicates the core purpose upfront. It avoids unnecessary elaboration while covering the essential action and prerequisite. However, it could be slightly more structured by separating the prerequisite into a second sentence for better readability.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or important behavioral constraints. While it mentions the timeboost API requirement, it lacks details about authentication, rate limits, costs, or what happens after submission. The description should provide more context given the tool's complexity and lack of structured metadata.
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 all three parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 action ('submit priority transactions') and resource ('through express lanes'), with the specific goal of 'faster processing'. It distinguishes from most sibling tools by focusing on transaction submission rather than querying or debugging. However, it doesn't explicitly differentiate from 'auctioneer_submitAuctionResolutionTransaction' which also submits 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?
The description implies usage context ('for faster processing') and mentions a prerequisite ('requires timeboost API'), but doesn't provide explicit guidance on when to use this tool versus alternatives like 'auctioneer_submitAuctionResolutionTransaction' or regular transaction submission methods. No 'when not to use' guidance is provided.
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. Dates show when Glama detected each change.
arb_check_publisher_healtharb_get_raw_block_metadataarb_latest_validatedarbdebug_validateMessageNumberarbdebug_validationInputsAtarbos_versionarbtrace_blockarbtrace_callarbtrace_callManyarbtrace_filterarbtrace_getarbtrace_replayBlockTransactionsarbtrace_replayTransactionarbtrace_transactionassertion_statusauctioneer_submitAuctionResolutionTransactionbatch_posting_statuschain_infoclear_rpc_urlcomprehensive_chain_statusgas_statusget_balanceget_balance_etherget_rollup_addressget_rpc_urlget_transactionget_transaction_receiptis_contractlatest_blocklist_chainsmaintenance_statusmaintenance_triggernode_healthnode_peerssearch_chainsset_rpc_urlsync_statustimeboost_sendExpressLaneTransactionThe tools are organized into clear functional groups (e.g., arbdebug_, arbtrace_, chain management, RPC utilities), which helps with differentiation, but there is significant overlap within groups, such as multiple arbtrace_ tools for tracing transactions and blocks with subtle distinctions that could confuse agents. Some tools like 'assertion_status' and 'batch_posting_status' have similar monitoring purposes, adding to potential ambiguity.
Most tools follow a consistent snake_case naming convention with descriptive prefixes (e.g., arb_, arbtrace_, get_, set_), but there are minor deviations like 'arbos_version' lacking an underscore and mixed verb styles (e.g., 'clear_rpc_url' vs. 'set_rpc_url' vs. 'get_rpc_url' are consistent, but others like 'timeboost_sendExpressLaneTransaction' use camelCase inconsistently). Overall, the naming is predictable but not perfectly uniform.
With 38 tools, the count is excessive for a single server, likely overwhelming for agents and leading to confusion. While the domain (Arbitrum chain management and debugging) is broad, the tools could be consolidated (e.g., multiple tracing tools) to reduce redundancy. This high number feels heavy and unoptimized for typical agent workflows.
The tool set provides comprehensive coverage for the Arbitrum domain, including chain information, debugging, tracing, monitoring, RPC management, and transaction handling. It supports CRUD-like operations (e.g., get/set RPC URLs, retrieve balances/transactions) and lifecycle actions (e.g., trigger maintenance, submit transactions), with no obvious gaps for the stated purpose of managing and querying Arbitrum chains.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
ArbitrumOracle - 12 Arbitrum tools: ERC-20, Camelot, GMX, sequencer, gas, bridge txs.
Manage your blockchain infrastructure across 80+ chains with your agents.
Agent-facing Ethereum and Base RPC, wallet/funder tracing, and notes board, metered over x402.
On-chain monitoring reads: ENS/Basename expiry, gas, token unlocks & Chainlink oracle health.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dewanshparashar/arbitrum-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
