Provides tools for interacting with the Arc Testnet blockchain, including querying USDC balances, transaction details, block information, network info, agent information (ERC-8004), and job status (ERC-8183).
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., "@Arc MCP Server Get the USDC balance of 0x54b4B44749a95070560509B6Ec0be501665CcF63"
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 that gives AI tools direct access to Arc Testnet blockchain data.
get_balance — Get USDC balance for any address
get_transaction — Get transaction details by hash
get_block — Get latest block information
get_tx_count — Get transaction count for an address
get_agent_info — Get ERC-8004 agent information
get_job_status — Get ERC-8183 job status
get_network_info — Get network info and contract addresses
Related MCP server: THORChain MCP Server
git clone https://github.com/consumeobeydie/arc-mcp-server.git
cd arc-mcp-server
npm installclaude mcp add --transport stdio arc-testnet node /path/to/arc-mcp-server/src/index.jsAsk Claude Code:
"Get the USDC balance of 0x54b4B44749a95070560509B6Ec0be501665CcF63"
"Get Arc Testnet network info"
"Get ERC-8004 agent info"
"Get status of job 110935"
Parameter | Value |
Network | Arc Testnet |
Chain ID | 5042002 |
RPC URL | |
Gas Token | USDC |
Explorer |
Get ERC-8004 agent information for the main Arc Intelligence agent
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. It does not disclose whether the tool is read-only, has side effects, requires authorization, or how it handles missing agents. The simple nature of the tool reduces the need for extensive transparency, but the description remains silent on even basic behavioral traits.
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 sentence, front-loaded with the action and target. Every word serves a purpose, and there is no 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 simplicity (no parameters, no annotations, no output schema), the description is minimal but adequate. However, it lacks information about the return value or any constraints, which would be helpful for an agent. It meets the minimum viable standard but could be improved.
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 no parameters, and the schema covers 100% of the input. With zero parameters, the baseline is 4. The description adds no parameter information because none exist, which 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 it 'Get ERC-8004 agent information for the main Arc Intelligence agent', which is a specific verb+resource. It distinguishes from sibling tools like get_balance, get_block, etc., which focus on different entities.
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 given on when to use this tool versus alternatives. For example, there is no mention of scenarios where get_agent_info is preferred over get_network_info or get_job_status. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get USDC balance of any address on Arc Testnet
| Name | Required | Description | Default |
|---|---|---|---|
| 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 must carry the full behavioral burden. It indicates a read operation (getting balance) but does not mention authorization requirements, rate limits, error handling, or response format.
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 sentence of 10 words, front-loaded with the verb, containing no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no nested objects, no output schema), the description is adequate but lacks details like return value format (e.g., decimal or wei) and potential error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'address', which includes a description. The tool's description adds context about the network but does not provide additional syntax or format 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 it gets the USDC balance for any address on Arc Testnet, using a specific verb and resource, and is distinct from sibling tools like get_block or get_transaction.
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 for checking USDC balance on Arc Testnet, but does not explicitly state when not to use it or mention alternative tools for other tokens.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest block information from Arc Testnet
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as what data is returned, permission requirements, or any side effects. The description is too terse to ensure correct expectations.
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, well-formed sentence with no extraneous words. It is maximally concise while still communicating 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?
For a tool with no parameters and no output schema, the description is adequate but minimal. It does not specify the structure of the returned block information, which could be helpful for an agent. Scores a 3 as a middle ground.
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 no parameters, so schema description coverage is 100%. The description adds no parameter information, which is acceptable given the absence of parameters. 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 explicitly states the action ('Get'), the resource ('latest block information'), and the network ('Arc Testnet'), making the tool's purpose very clear and distinct from sibling tools like get_transaction or get_balance.
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 for retrieving the latest block info but provides no guidance on when to use this tool over alternatives or any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ERC-8183 job status on Arc Testnet
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID to check status for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose all behavioral traits. It only says 'Get status', implying read-only, but lacks details on rate limits, error handling, or polling 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?
Single sentence, front-loaded with action, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter and no output schema, the description covers the basic purpose. However, it fails to explain what the status response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description in schema is adequate. The description adds no extra meaning 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?
Description clearly states verb 'Get', resource 'ERC-8183 job status', and context 'on Arc Testnet'. It distinguishes itself from sibling get_* tools by specifying a unique resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Implied usage is checking job status, but no alternatives or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Arc Testnet network information and key contract addresses
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the basic purpose. It does not explicitly state that it is read-only or safe, though 'get' implies that. Minimal 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, concise sentence with no wasted words. It is appropriately 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?
The description states it returns 'network information and key contract addresses' but does not detail what specific fields or data are included. Without an output schema, more specificity would be helpful for an agent to understand the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% (no params). The description does not need to add parameter meaning. Baseline score for 0 params is 4.
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 specifies the verb 'Get' and the resource 'Arc Testnet network information and key contract addresses'. It distinguishes from sibling tools like get_agent_info or get_balance, which focus on different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidelines or when-to-use vs alternatives. However, the context from sibling names implies it's for network-level queries, so it's minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction details on Arc Testnet
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | Transaction hash to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only implies a read operation ('Get'), but lacks details on error handling, required permissions, rate limits, or what happens for invalid hashes. This is insufficient for a safe tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. However, it is too brief for the required informational load, but within the scope of conciseness it scores well.
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 one required parameter, no output schema, and no annotations, the description is incomplete. It does not mention return format, error behavior, or any preconditions, leaving significant 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% (the single parameter tx_hash has a description). The tool description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Get) and resource (transaction details), and specifies the network (Arc Testnet). This distinguishes it from sibling tools like get_balance or get_block, though it doesn't explicitly contrast 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?
No guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites or exclusions. The description simply states what it does without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction count (nonce) for an address on Arc Testnet
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address to check transaction count |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description adds the context of 'Arc Testnet' but does not disclose any behavioral traits such as read-only nature, rate limits, or error conditions. The 'get' verb implies a safe read operation, but this is not explicitly stated.
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, well-formed sentence that conveys the core purpose without any extraneous words. It is front-loaded with the key action.
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 (one parameter, no output schema), the description adequately covers the purpose and network context. However, it could mention that the result is the nonce or provide a brief note on return value.
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 address parameter. The description does not add any semantic meaning beyond what the schema provides, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get transaction count' and identifies the resource 'address on Arc Testnet'. It clearly distinguishes from sibling tools like get_balance and get_transaction, which deal with different data.
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 (on Arc Testnet) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
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.
v1.0.0get_agent_infoget_balanceget_blockget_job_statusget_network_infoget_transactionget_tx_countEach tool targets a distinct piece of blockchain data: agent info, balance, block, job status, network info, transaction, and transaction count. Their purposes are clearly separated, leaving no ambiguity.
All tools follow a uniform `get_` + noun pattern (e.g., get_balance, get_block), making the naming predictable and easy to understand.
With 7 tools, the server is well-scoped for its purpose as a read-only blockchain explorer. This number is appropriate—neither too few to be useful nor too many to be overwhelming.
The set covers core blockchain queries: balances, blocks, transactions, network info, and agent details. However, it lacks common features like event logs, contract state queries, or search/filtering, which would make it more complete for a full blockchain explorer.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/consumeobeydie/arc-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server