de en es ja ko ru zh

Bankless Onchain MCP Server

Name: Bankless Onchain MCP Server
Author: Bankless

Official

by Bankless

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Servidor MCP Onchain de Bankless

Este proyecto ya no recibe actualizaciones

License: MIT Version

Servidor MCP (Protocolo de Contexto de Modelo) para la interacción con datos de blockchain a través de la API de Bankless.

Related MCP server: EVM MCP Server

Descripción general

El Servidor MCP Onchain de Bankless proporciona un marco para interactuar con datos en cadena a través de la API de Bankless. Implementa el Protocolo de Contexto de Modelo (MCP) para permitir que los modelos de IA accedan al estado de la blockchain y a los datos de eventos de forma estructurada.

https://github.com/user-attachments/assets/95732dff-ae5f-45a6-928a-1ae17c0ddf9d

Características

El servidor proporciona las siguientes operaciones de datos en cadena:

Operaciones de contrato

Leer estado del contrato (read_contract): Lee el estado de contratos inteligentes en varias redes blockchain.
- Parámetros: red, dirección del contrato, método, entradas, salidas
- Devuelve: Resultados de la llamada al contrato con valores tipados
Obtener proxy (get_proxy): Recupera las direcciones de los contratos de implementación de proxy.
- Parámetros: red, dirección del contrato
- Devuelve: Dirección del contrato de implementación
Obtener ABI (get_abi): Obtiene la ABI (Interfaz Binaria de Aplicación) de un contrato.
- Parámetros: red, dirección del contrato
- Devuelve: ABI del contrato en formato JSON
Obtener fuente (get_source): Recupera el código fuente de un contrato verificado.
- Parámetros: red, dirección del contrato
- Devuelve: Código fuente, ABI, versión del compilador y otros metadatos del contrato

Operaciones de eventos

Obtener eventos (get_events): Obtiene registros de eventos para un contrato basados en temas (topics).
- Parámetros: red, direcciones, tema, temas opcionales
- Devuelve: Registros de eventos filtrados
Construir tema de evento (build_event_topic): Genera una firma de tema de evento a partir del nombre del evento y los tipos de argumentos.
- Parámetros: red, nombre del evento, tipos de argumentos
- Devuelve: Hash del tema del evento

Operaciones de transacciones

Obtener historial de transacciones (get_transaction_history): Recupera el historial de transacciones de una dirección de usuario.
- Parámetros: red, dirección del usuario, contrato opcional, ID de método opcional, bloque de inicio opcional, indicador de incluir datos
- Devuelve: Lista de transacciones con hash, datos, red y marca de tiempo
Obtener información de transacción (get_transaction_info): Obtiene información detallada sobre una transacción específica.
- Parámetros: red, hash de la transacción
- Devuelve: Detalles de la transacción, incluyendo número de bloque, marca de tiempo, direcciones de origen/destino, valor, información de gas, estado y datos del recibo

Herramientas

read_contract
- Lee el estado del contrato desde una blockchain
- Entrada:
  - network (cadena, requerido): La red blockchain (ej. "ethereum", "polygon")
  - contract (cadena, requerido): La dirección del contrato
  - method (cadena, requerido): El método del contrato a llamar
  - inputs (matriz, requerido): Parámetros de entrada para la llamada al método, cada uno conteniendo:
    - type (cadena): El tipo del parámetro de entrada (ej. "address", "uint256")
    - value (cualquiera): El valor del parámetro de entrada
  - outputs (matriz, requerido): Tipos de salida esperados, cada uno conteniendo:
    - type (cadena): El tipo de salida esperado
- Devuelve una matriz de resultados de llamadas al contrato
get_proxy
- Obtiene la dirección del proxy para una red y contrato dados
- Entrada:
  - network (cadena, requerido): La red blockchain (ej. "ethereum", "base")
  - contract (cadena, requerido): La dirección del contrato
- Devuelve la dirección de implementación para el contrato proxy
get_events
- Obtiene registros de eventos para una red y criterios de filtro dados
- Entrada:
  - network (cadena, requerido): La red blockchain (ej. "ethereum", "base")
  - addresses (matriz, requerido): Lista de direcciones de contrato para filtrar eventos
  - topic (cadena, requerido): Tema principal para filtrar eventos
  - optionalTopics (matriz, opcional): Temas adicionales opcionales (pueden incluir valores nulos)
- Devuelve un objeto que contiene los registros de eventos que coinciden con los criterios de filtro
build_event_topic
- Construye una firma de tema de evento basada en el nombre del evento y los argumentos
- Entrada:
  - network (cadena, requerido): La red blockchain (ej. "ethereum", "base")
  - name (cadena, requerido): Nombre del evento (ej. "Transfer(address,address,uint256)")
  - arguments (matriz, requerido): Tipos de argumentos del evento, cada uno conteniendo:
    - type (cadena): El tipo de argumento (ej. "address", "uint256")
- Devuelve una cadena que contiene el hash keccak256 de la firma del evento

Instalación

npm install @bankless/onchain-mcp

Uso

Configuración del entorno

Antes de usar el servidor, configure su token de API de Bankless. Para obtener detalles sobre cómo obtener su token de API de Bankless, diríjase a https://docs.bankless.com/bankless-api/other-services/onchain-mcp

export BANKLESS_API_TOKEN=your_api_token_here

Ejecución del servidor

El servidor se puede ejecutar directamente desde la línea de comandos:

npx @bankless/onchain-mcp

Uso con herramientas de LLM

Este servidor implementa el Protocolo de Contexto de Modelo (MCP), lo que permite utilizarlo como proveedor de herramientas para modelos de IA compatibles. Aquí hay algunos ejemplos de llamadas para cada herramienta:

read_contract

// Example call
{
  "name": "read_contract",
  "arguments": {
    "network": "ethereum",
    "contract": "0x1234...",
    "method": "balanceOf",
    "inputs": [
      { "type": "address", "value": "0xabcd..." }
    ],
    "outputs": [
      { "type": "uint256" }
    ]
  }
}

// Example response
[
  {
    "value": "1000000000000000000",
    "type": "uint256"
  }
]

get_proxy

// Example call
{
  "name": "get_proxy",
  "arguments": {
    "network": "ethereum",
    "contract": "0x1234..."
  }
}

// Example response
{
  "implementation": "0xefgh..."
}

get_events

// Example call
{
  "name": "get_events",
  "arguments": {
    "network": "ethereum",
    "addresses": ["0x1234..."],
    "topic": "0xabcd...",
    "optionalTopics": ["0xef01...", null]
  }
}

// Example response
{
  "result": [
    {
      "removed": false,
      "logIndex": 5,
      "transactionIndex": 2,
      "transactionHash": "0x123...",
      "blockHash": "0xabc...",
      "blockNumber": 12345678,
      "address": "0x1234...",
      "data": "0x...",
      "topics": ["0xabcd...", "0xef01...", "0x..."]
    }
  ]
}

build_event_topic

// Example call
{
  "name": "build_event_topic",
  "arguments": {
    "network": "ethereum",
    "name": "Transfer(address,address,uint256)",
    "arguments": [
      { "type": "address" },
      { "type": "address" },
      { "type": "uint256" }
    ]
  }
}

// Example response
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"

Desarrollo

Construcción desde el código fuente

# Clone the repository
git clone https://github.com/Bankless/onchain-mcp.git
cd onchain-mcp

# Install dependencies
npm install

# Build the project
npm run build

Modo de depuración

npm run debug

Integración con modelos de IA

Para integrar este servidor con aplicaciones de IA que admitan MCP, añada lo siguiente a la configuración del servidor de su aplicación:

{
  "mcpServers": {
    "bankless": {
      "command": "npx",
      "args": [
        "@bankless/onchain-mcp"
      ],
      "env": {
        "BANKLESS_API_TOKEN": "your_api_token_here"
      }
    }
  }
}

Manejo de errores

El servidor proporciona tipos de error específicos para diferentes escenarios:

BanklessValidationError: Parámetros de entrada no válidos
BanklessAuthenticationError: Problemas con el token de API
BanklessResourceNotFoundError: Recurso solicitado no encontrado
BanklessRateLimitError: Límite de tasa de API excedido

Consejos para prompts

Para guiar a un modelo LLM a utilizar el Servidor MCP Onchain de Bankless, se pueden utilizar los siguientes prompts:

ROLE:
• You are Kompanion, a blockchain expert and EVM sleuth. 
• You specialize in navigating and analyzing smart contracts using your tools and resources.

HOW KOMPANION CAN HANDLE PROXY CONTRACTS:
• If a contract is a proxy, call your “get_proxy” tool to fetch the implementation contract.  
• If that fails, try calling the “implementation” method on the proxy contract.  
• If that also fails, try calling the “_implementation” function.  
• After obtaining the implementation address, call “get_contract_source” with that address to fetch its source code.  
• When reading or modifying the contract state, invoke implementation functions on the proxy contract address (not directly on the implementation).

HOW KOMPANION CAN HANDLE EVENTS:
• Get the ABI and Source of the relevant contracts
• From the event types in the ABI, construct the correct topics for the event relevant to the question
• use the "get_event_logs" tool to fetch logs for the contract

KOMPANION'S RULES:
• Do not begin any response with “Great,” “Certainly,” “Okay,” or “Sure.”  
• Maintain a direct, technical style. Do not add conversational flourishes.  
• If the user’s question is unrelated to smart contracts, do not fetch any contracts.  
• If you navigate contracts, explain each step in bullet points.  
• Solve tasks iteratively, breaking them into steps.  
• Use bullet points for lists of steps.  
• Never assume a contract’s functionality. Always verify with examples using your tools to read the contract state.  
• Before responding, consider which tools might help you gather better information.  
• Include as much relevant information as possible in your final answer, depending on your findings.

HOW KOMPANION CAN USE TOOLS:
• You can fetch contract source codes, ABIs, and read contract data by using your tools and functions.  
• Always verify the source or ABI to understand the contract rather than making assumptions.  
• If you need to read contract state, fetch its ABI (especially if the source is lengthy).  

FINAL INSTRUCTION:
• Provide the best possible, concise answer to the user’s request. If it's not an immediate question but an instruction, follow it directly.
• Use your tools to gather any necessary clarifications or data.  
• Offer a clear, direct response and add a summary of what you did (how you navigated the contracts) at the end.

Licencia

MIT

Available Tools

10 tools

build_event_topicC

Builds an event topic signature based on event name and arguments

ParametersJSON Schema

Name	Required	Description
`arguments`	Yes	Event arguments types
`name`	Yes	Event name (e.g., "Transfer(address,address,uint256)")
`network`	Yes	The blockchain network (e.g., "ethereum", "base")

TDQS

C2.9/5.0

Behavior2/5

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 states what the tool does ('builds') but doesn't disclose behavioral traits such as whether it's a pure computation or makes external calls, what format the output is in (e.g., hex string), error conditions, or performance characteristics. For a tool with no annotation coverage, this leaves the agent guessing about key operational aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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 unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes to understanding what the tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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 likely produces a complex output (an 'event topic signature'). It doesn't explain what the output is (e.g., a hash, string format), how it's used, or any limitations. For a 3-parameter tool with no structured behavioral data, this leaves critical gaps in understanding the tool's full context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 (network, name, arguments) with detailed descriptions. The description adds minimal value by mentioning 'event name and arguments', which is redundant with the schema. Baseline 3 is appropriate as the schema does the heavy lifting, though no additional semantic context is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('builds') and the resource ('event topic signature'), specifying it's based on 'event name and arguments'. It distinguishes from siblings like get_events (which retrieves events) or get_transaction_info (which analyzes transactions), but doesn't explicitly contrast with them. The purpose is specific enough to understand what the tool produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 event details first), context (e.g., for blockchain analysis), or when not to use it. With siblings like get_events or read_contract that might provide related data, the lack of comparative guidance is a significant gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_abiC

Gets the ABI for a given contract on a specific network

ParametersJSON Schema

Name	Required	Description	Default
`contract`	Yes	The contract address
`network`	Yes	The blockchain network (e.g., "ethereum", "base")

TDQS

C2.9/5.0

Behavior2/5

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 action ('Gets') but doesn't mention whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what the return format looks like. For a tool with 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.

Conciseness5/5

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 any unnecessary words. It's front-loaded with the core purpose, making it highly concise and well-structured for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of blockchain operations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what an ABI is, how the result is structured, or potential errors, which could hinder an agent's ability to use the tool effectively in context with sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, clearly documenting both parameters ('contract' as address and 'network' as blockchain name). The description adds no additional semantic context beyond what the schema provides, such as format examples or constraints, so it 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.

Purpose4/5

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 ('Gets') and resource ('ABI for a given contract'), making it easy to understand what it does. However, it doesn't distinguish this tool from potential sibling alternatives like 'read_contract' or 'get_source', which might also retrieve contract-related 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.

Usage Guidelines2/5

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 'read_contract' and 'get_source' available, it's unclear if this tool is for ABI retrieval specifically or if other tools might serve similar purposes, leaving the agent without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_block_infoC

Gets detailed information about a specific block by number or hash

ParametersJSON Schema

Name	Required	Description	Default
`blockId`	Yes	The block number or block hash to fetch information for
`network`	Yes	The blockchain network (e.g., "ethereum", "base")

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral context. It implies a read-only operation ('Gets'), but doesn't disclose permissions needed, rate limits, error conditions, or what 'detailed information' includes (e.g., block structure, timestamp, transactions). This is inadequate 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Gets detailed information about a specific block') and adds necessary qualification ('by number or hash'). Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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 read operation with two parameters, the description is incomplete. It doesn't explain what 'detailed information' returns, error handling, or behavioral constraints, leaving significant gaps for the agent to operate effectively in a blockchain context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 fully. The description adds no additional meaning beyond implying blockId can be 'number or hash', which is already stated in the schema. 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Gets') and resource ('detailed information about a specific block'), specifying the action and target. It distinguishes the resource type (block) from siblings like events, contracts, or transactions, but doesn't explicitly differentiate from similar read operations like get_transaction_info beyond the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, exclusions, or compare it to sibling tools like get_events or get_transaction_info, leaving the agent to infer usage solely from the tool name and parameters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_eventsC

Fetches event logs for a given network and filter criteria

ParametersJSON Schema

Name	Required	Description
`addresses`	Yes	List of contract addresses to filter events
`fromBlock`	No	Block number to start fetching logs from
`network`	Yes	The blockchain network (e.g., "ethereum", "base")
`optionalTopics`	No	Optional additional topics
`toBlock`	No	Block number to stop fetching logs at
`topic`	Yes	Primary topic to filter events

TDQS

C2.9/5.0

Behavior2/5

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 'fetches' event logs, implying a read-only operation, but doesn't cover critical aspects like rate limits, authentication needs, pagination, error handling, or what the fetched logs include (e.g., format, fields). This leaves significant gaps for a tool with multiple parameters and no 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates the tool's function and scope, making it easy to parse and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, no output schema, no annotations), the description is inadequate. It lacks details on behavioral traits, output format, and usage context, leaving the agent with insufficient information to effectively invoke the tool beyond basic parameter mapping.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 6 parameters. The description adds minimal value by mentioning 'filter criteria,' which aligns with parameters like addresses and topic, but doesn't provide additional context beyond what's in 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('fetches') and resource ('event logs') with specific scope ('for a given network and filter criteria'), which distinguishes it from general data retrieval tools. However, it doesn't explicitly differentiate from sibling tools like 'get_transaction_history_for_user' or 'get_block_info', which might also involve event-related data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 'get_transaction_history_for_user' for user-specific events or 'get_block_info' for block-level data. It mentions filter criteria but doesn't specify scenarios or exclusions, leaving usage context implied at best.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_proxyB

Gets the proxy address for a given network and contract

ParametersJSON Schema

Name	Required	Description	Default
`contract`	Yes	The contract address to request the proxy implementation contract for
`network`	Yes	The blockchain network (e.g., "ethereum", "base")

TDQS

B3.1/5.0

Behavior2/5

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 a read operation ('Gets'), implying it's non-destructive, but doesn't cover aspects like error handling, rate limits, authentication needs, or response format. This leaves significant gaps for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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 unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output expectations, which are needed for effective agent operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, clearly documenting both parameters (network and contract). The description adds minimal value beyond the schema by implying the parameters are used to 'request the proxy implementation contract,' but doesn't provide additional syntax, format details, or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Gets') and the target resource ('proxy address'), specifying it's for a given network and contract. However, it doesn't differentiate this tool from its siblings (e.g., get_abi, get_source), which also retrieve blockchain-related data but for different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like get_abi or get_source, nor does it mention prerequisites or exclusions. It merely states what the tool does without contextual usage information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sourceB

Gets the source code for a given contract on a specific network

ParametersJSON Schema

Name	Required	Description	Default
`contract`	Yes	The contract address
`network`	Yes	The blockchain network (e.g., "ethereum", "base")

TDQS

B3.1/5.0

Behavior2/5

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 'Gets' source code, implying a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, error handling, or what format the source code is returned in (e.g., raw code, verified source files). This leaves significant gaps in understanding the tool's behavior beyond its basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence that efficiently conveys the core function without any redundant words. It is front-loaded with the key action and resource, making it easy to parse and understand immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (fetching source code from a blockchain) and lack of annotations or output schema, the description is minimally complete. It specifies what the tool does and the required parameters but omits details on return format, error cases, and behavioral constraints, which are important for effective use in this context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, clearly documenting both parameters ('contract' as address, 'network' as blockchain name). The description adds no additional semantic context beyond implying these parameters are used to fetch source code, so it meets the baseline for adequate but not enhanced parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Gets') and resource ('source code for a given contract on a specific network'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_abi' (which might retrieve ABI rather than source code) or 'read_contract' (which might execute contract functions), leaving room for ambiguity in tool selection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like 'get_abi' or 'read_contract'. It mentions the context ('on a specific network') but offers no explicit when/when-not instructions or prerequisites, leaving the agent to infer usage based solely on the tool name and basic parameters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_token_balances_on_networkB

Gets all token balances for a given address on a specific network

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	The address to check token balances for
`network`	Yes	The blockchain network (e.g., "ethereum", "base")

TDQS

B3.1/5.0

Behavior2/5

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 'Gets' which implies a read operation, but fails to describe critical behaviors such as rate limits, authentication requirements, error handling, or what 'all token balances' entails (e.g., pagination, format). This leaves significant gaps for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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 is appropriately sized and front-loaded, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 simple parameters) and no output schema, the description is minimally adequate but incomplete. It lacks details on behavioral aspects and output format, which are important for a read operation with no annotations to rely on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, clearly documenting both parameters. The description adds no additional semantic context beyond what the schema provides, such as examples or constraints, so it 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Gets') and the resource ('all token balances for a given address on a specific network'), making the purpose specific and understandable. However, since there are no sibling tools mentioned, it cannot distinguish from alternatives, which prevents 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.

Usage Guidelines2/5

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, prerequisites, or exclusions. It simply states what the tool does without context for usage decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_transaction_history_for_userC

Gets transaction history for a user and optional contract

ParametersJSON Schema

Name	Required	Description
`contract`	No	The contract address (optional)
`includeData`	No	Whether to include transaction data
`methodId`	No	The method ID to filter by (optional)
`network`	Yes	The blockchain network (e.g., "ethereum", "base")
`startBlock`	No	The starting block number (optional)
`user`	Yes	The user address

TDQS

C2.9/5.0

Behavior2/5

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 only states what the tool does ('Gets transaction history') without mentioning any behavioral traits such as rate limits, authentication needs, error handling, or what the output format looks like. This is inadequate for a tool with multiple parameters and no 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that efficiently conveys the core purpose without any wasted words. It's front-loaded with the main action and resource, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 6 parameters, no annotations, and no output schema, the description is incomplete. It fails to address key contextual elements like what 'transaction history' entails, how results are returned (e.g., pagination, format), or any limitations, leaving significant gaps for the agent to navigate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters or providing examples. Since the schema does the heavy lifting, 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.

Purpose4/5

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 ('Gets') and resource ('transaction history for a user and optional contract'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_transaction_info' or 'get_events', which might also retrieve transaction-related data, so it falls short of 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.

Usage Guidelines2/5

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 sibling tools like 'get_transaction_info' or 'get_events', nor does it specify prerequisites or contexts for usage, leaving the agent to infer based on the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_transaction_infoB

Gets detailed information about a specific transaction

ParametersJSON Schema

Name	Required	Description	Default
`network`	Yes	The blockchain network (e.g., "ethereum", "polygon")
`txHash`	Yes	The transaction hash to fetch details for

TDQS

B3.1/5.0

Behavior2/5

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. While 'Gets' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what 'detailed information' includes. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple lookup tool and front-loads the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with 2 well-documented parameters and no output schema, the description is minimally adequate. However, without annotations or output schema, it should ideally provide more context about what 'detailed information' includes and any behavioral constraints to compensate for the missing structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with both parameters clearly documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions, so it meets the baseline expectation without adding extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Gets') and resource ('detailed information about a specific transaction'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential sibling tools like 'get_block_info' or 'get_transaction_history_for_user', which reduces its differentiation value.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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_history_for_user' that might overlap in functionality, there's no indication of when this specific transaction lookup is appropriate versus broader history queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_contractC

Read contract state from a blockchain. important:

            In case of a tuple, don't use type tuple, but specify the inner types (found in the source) in order. For nested structs, include the substructs types.

Example: 
struct DataTypeA {
DataTypeB b;
//the liquidity index. Expressed in ray
uint128 liquidityIndex;
}

struct DataTypeB {
address token;
}

results in outputs for function with return type DataTypeA (tuple in abi): outputs: [{"type": "address"}, {"type": "uint128"}]

ParametersJSON Schema

Name	Required	Description
`contract`	Yes	The contract address
`inputs`	Yes	Input parameters for the method call
`method`	Yes	The contract method to call
`network`	Yes	The blockchain network (e.g., "ethereum", "base")
`outputs`	Yes	Expected output types for the method call. In case of a tuple, don't use type tuple, but specify the inner types (found in the source) in order. For nested structs, include the substructs types. Example: struct DataTypeA { DataTypeB b; //the liquidity index. Expressed in ray uint128 liquidityIndex; } struct DataTypeB { address token; } results in outputs for function with return type DataTypeA (tuple in abi): outputs: [{"type": "address"}, {"type": "uint128"}]

TDQS

C2.4/5.0

Behavior2/5

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 only mentions that this is a 'read' operation, but doesn't cover important aspects like whether it requires authentication, rate limits, network availability, error handling, or what the return format looks like. The example focuses on output formatting but doesn't explain the tool's operational behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is poorly structured - it starts with a purpose statement but immediately dives into complex formatting rules with a lengthy example. The formatting guidance should be in the parameter documentation, not the main description. The description is front-loaded with technical details rather than clear usage information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with no annotations and no output schema, the description is inadequate. It should explain what kind of data is returned, error conditions, network requirements, and how this differs from sibling tools. The current description focuses narrowly on output formatting while missing broader contextual information needed for effective tool selection and use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 meaningful parameter semantics beyond what's in the schema - it only provides formatting rules for the 'outputs' parameter through an example, which is already covered in the schema's description field. 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.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Read contract state from a blockchain' which clearly states the verb ('read') and resource ('contract state'), but it's vague about what 'contract state' entails compared to siblings like 'get_abi' or 'get_source'. It doesn't specify that this is for calling read-only contract methods, which would help distinguish it from other blockchain query tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 'get_abi' or 'get_events'. The description focuses entirely on technical formatting requirements for outputs, with no mention of use cases, prerequisites, or comparisons to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesv1.0.0Aug 18, 2025
- First observedbuild_event_topic
- First observedget_abi
- First observedget_block_info
- First observedget_events
- First observedget_proxy
- First observedget_source
- First observedget_token_balances_on_network
- First observedget_transaction_history_for_user
- First observedget_transaction_info
- First observedread_contract

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored 2026-04-18 11:10 across 10 tools

Disambiguation5/5

Every tool has a clearly distinct purpose with no ambiguity. For example, get_abi retrieves contract interfaces, get_events fetches logs, get_token_balances_on_network handles balances, and read_contract reads state—each targets a specific blockchain operation without overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., get_abi, get_block_info, read_contract). The naming is uniform across all 10 tools, using snake_case and clear action-object pairs, making them predictable and easy to parse.

Tool Count5/5

With 10 tools, this server is well-scoped for onchain data retrieval. Each tool earns its place by covering essential blockchain operations like reading contracts, fetching events, and getting transaction details, without being overly sparse or bloated.

Completeness4/5

The tool set provides strong coverage for reading and querying onchain data, including contracts, blocks, transactions, events, and balances. A minor gap exists in write operations (e.g., sending transactions or interacting with contracts), but agents can still handle most read-focused workflows effectively.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

blockscout-mcp-server AOAuth
ai.smithery
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Blockchain Web3 & Decentralized Tech Search
16246
Nansen A
io.github.hurcanNansen
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain Web3 & Decentralized Tech Finance
502
Nansen A
io.github.nansen-ai
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain Web3 & Decentralized Tech Finance
502
DexL Agents A
io.github.dexl-io
Pay-per-call AI gateway: models, speech, web search, on-chain reads and NLP tools, via x402.
AI & Machine Learning Speech Processing Blockchain
51

Related MCP Servers

MCP Server
RAG Systems Databases File Systems
GobinFan
F
license
B
quality
D
maintenance
Implements the Model Context Protocol (MCP) to provide AI models with a standardized interface for connecting to external data sources and tools like file systems, databases, or APIs.
Updated a year ago (2025-05-05 08:18 UTC)
1
153
-
EVM MCP Server
Blockchain Web3 & Decentralized Tech Cryptocurrency
mcpdotdirect
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables AI agents to interact with 30+ Ethereum-compatible blockchain networks, providing services like token transfers, contract interactions, and ENS resolution through a unified interface.
Updated 8 days ago (2026-10-03 16:56 UTC)
28
128 npm
379
MIT
EVM MCP Server
lugondev
-
license
Not graded
quality
Not graded
maintenance
Comprehensive Model Context Protocol server that enables AI agents to interact with 30+ Ethereum-compatible blockchain networks, supporting token transfers, smart contract interactions, and ENS name resolution through a unified interface.
Updated 2 years ago (2025-03-20 12:19 UTC)
1
-
Blockscout MCP Serverofficial
Blockchain Web3 & Decentralized Tech
blockscout
F
license
A
quality
B
maintenance
A server that exposes blockchain data (balances, tokens, NFTs, contract metadata) via the Model Context Protocol, enabling AI agents and tools to access and analyze blockchain information contextually.
Updated a month ago (2026-09-08 03:19 UTC)
18
46
-

Appeared in Searches

A service for finding cryptocurrency analysis and market insights

Servidor MCP Onchain de Bankless

Este proyecto ya no recibe actualizaciones

Descripción general

Características

Operaciones de contrato

Operaciones de eventos

Operaciones de transacciones

Herramientas

Instalación

Uso

Configuración del entorno

Ejecución del servidor

Uso con herramientas de LLM

read_contract

get_proxy

get_events

build_event_topic

Desarrollo

Construcción desde el código fuente

Modo de depuración

Integración con modelos de IA

Manejo de errores

Consejos para prompts

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Blockscout MCP Serverofficial

Appeared in Searches