en es ja ko zh

Neo N3 MCP Server

Name: Neo N3 MCP Server
Author: r3e-network

by r3e-network

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Protocolo de contexto del modelo Neo N3 (MCP) v1.4.0

El Protocolo de Contexto de Modelo (MCP) de Neo N3 proporciona una interfaz estandarizada para que los agentes y aplicaciones de IA interactúen con la blockchain de Neo N3. Esta implementación de servidor busca la simplicidad y facilidad de uso, ejecutándose directamente a través de npx sin necesidad de configuración manual del entorno para un uso estándar.

Agregar el MCP a un cliente (por ejemplo, VS Code)

Configure su cliente para utilizar el servidor de E/S estándar a través de npx :

Opción A: Configuración de usuario de VS Code (JSON)

Agregue lo siguiente a su JSON de configuración de usuario ( Ctrl+Shift+P > Preferences: Open User Settings (JSON) ):

{
  "mcp": {
    "servers": {
      "neo-n3": { // You can choose any name
        "command": "npx",
        "args": [
          "-y", // Auto-confirm npx installation/update
          "@r3e/neo-n3-mcp"
        ]
      }
    }
  }
}

Opción B: Configuración del espacio de trabajo ( .vscode/mcp.json )

Crea un archivo llamado mcp.json dentro del directorio .vscode :

{
  "servers": {
    "neo-n3": { // You can choose any name
      "command": "npx",
      "args": [
        "-y", // Auto-confirm npx installation/update
        "@r3e/neo-n3-mcp"
      ]
    }
  }
}

Opción C: Otros clientes (por ejemplo, Cursor)

Siga las instrucciones de su cliente para agregar un servidor MCP mediante un comando. Proporcione el comando npx y los argumentos ["-y", "@r3e/neo-n3-mcp"] .

Related MCP server: BrianKnows MCP Server

Herramientas disponibles

Para obtener parámetros y ejemplos detallados, consulte la documentación de API.md.

Configuración y red

Herramienta	Descripción	Parámetros clave
`get_network_mode`	Obtener el modo de red configurado actualmente	Ninguno
`set_network_mode`	Establecer el modo de red activo para llamadas posteriores	`mode` : "solo red principal", "solo red de prueba" o "ambos"

Información de blockchain

Herramienta	Descripción	Parámetros clave
`get_blockchain_info`	Obtenga la altura actual y la información general de la red	`network`
`get_block_count`	Obtener la altura actual del bloque	`network`
`get_block`	Obtener detalles del bloque por hash o altura	`network` , `hashOrHeight`
`get_transaction`	Obtener detalles de la transacción por ID de transacción	`network` , `txid`
`check_transaction_status`	Comprobar si una transacción está confirmada	`network` , `txid`

Gestión de billeteras y cuentas

Herramienta	Descripción	Parámetros clave
`create_wallet`	Crear un nuevo archivo de billetera encriptado	`password`
`import_wallet`	Importar billetera existente desde WIF/clave privada	`key` , `password`
`get_balance`	Obtener saldos de tokens para una dirección	`network` , `address`

Transferencias de activos

Herramienta	Descripción	Parámetros clave
`transfer_assets`	Envíe tokens NEO, GAS u otros NEP-17	`network` , `fromWIF` , `toAddress` , `asset` , `amount` , `confirm`
`estimate_transfer_fees`	Calcule las tarifas de red y sistema para una transferencia	`network` , `fromAddress` , `toAddress` , `asset` , `amount`

Interacción de contratos inteligentes

Herramienta	Descripción	Parámetros clave
`list_famous_contracts`	Enumere los contratos conocidos compatibles con el servidor	`network`
`get_contract_info`	Obtener detalles (hash, métodos) de un contrato famoso	`network` , `contractName`
`invoke_contract` (reemplaza invocar_lectura/escritura)	Invocar un método de contrato inteligente (lectura o escritura)	`network` , `scriptHash` , `operation` , `args` , `fromWIF` (para escribir), `confirm` (para escribir)

NeoFS (Almacenamiento descentralizado)

Herramienta	Descripción	Parámetros clave
`neofs_create_container`	Crear un contenedor de almacenamiento NeoFS	`network` , `fromWIF` , `ownerId` , `rules` , `confirm`
`neofs_get_containers`	Lista de contenedores propiedad de un ID	`network` , `ownerId`

NeoBurger (Servicio de staking)

Herramienta	Descripción	Parámetros clave
`neoburger_deposit`	Deposite NEO para recibir bNEO	`network` , `fromWIF` , `confirm`
`neoburger_withdraw`	Retirar NEO devolviendo bNEO	`network` , `fromWIF` , `amount` , `confirm`

Solicitudes de ejemplo

Obtenga información sobre blockchain

Pedido:

{
  "name": "get_blockchain_info",
  "arguments": {
    "network": "mainnet"
  }
}

Respuesta:

{
  "result": {
    "height": 3456789,
    "network": "mainnet"
  }
}

Transferir activos

Pedido:

{
  "name": "transfer_assets",
  "arguments": {
    "network": "testnet",
    "fromWIF": "YourSenderWalletWIF",
    "toAddress": "NZNos2WqTbu5oCgyfss9kUJgBXJqhuYAaj",
    "asset": "NEO",
    "amount": "1",
    "confirm": true
  }
}

Respuesta:

{
  "result": {
    "txid": "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
    "address": "NVbGwMfRQVudQCcChhCFwQRwSxr5tYEqQs",
    "network": "testnet"
  }
}

Manejo de errores

El servidor MCP devuelve respuestas de error estandarizadas:

{
  "error": {
    "code": "INVALID_PARAMETER",
    "message": "Invalid network parameter. Must be 'mainnet' or 'testnet'."
  }
}

Códigos de error comunes:

INVALID_PARAMETER : parámetro faltante o no válido
NETWORK_ERROR : Error al conectarse al nodo Neo N3
BLOCKCHAIN_ERROR : Error de la cadena de bloques Neo N3
WALLET_ERROR : Error con las operaciones de la billetera
CONTRACT_ERROR : Error con las operaciones del contrato inteligente
UNAUTHORIZED : Operación no permitida
INTERNAL_ERROR : Error inesperado del servidor

Mejores prácticas de seguridad

Manejo de WIF: Tenga mucho cuidado al proporcionar claves de Formato de Importación de Monedero (WIF). Asegúrese de que el entorno donde se ejecuta el servidor MCP y el canal de comunicación sean seguros. Considere ejecutar el servidor localmente o dentro de una red confiable. Evite exponer el servidor públicamente sin una autenticación robusta y seguridad de transporte (HTTPS).
Almacene los archivos de billetera de forma segura si utiliza enfoques basados en archivos (aunque la API actual parece estar basada en WIF).
Utilice confirm: true para todas las operaciones de cambio de estado (transferencias, invocaciones de contrato) para garantizar que la red procese la transacción.
Almacene los archivos de su billetera de forma segura con contraseñas seguras
Utilice testnet para desarrollo y pruebas
Mantenga su servidor Neo N3 MCP actualizado a la última versión

Servidor HTTP

Además del servidor MCP, este paquete también proporciona un servidor HTTP que expone la funcionalidad de Neo N3 mediante una API RESTful. El servidor HTTP se inicia automáticamente al ejecutar el servidor MCP y escucha en el puerto 3002 de forma predeterminada.

Puntos finales HTTP

Punto final	Método	Descripción
`/api/blockchain/info`	CONSEGUIR	Obtenga información sobre blockchain
`/api/blockchain/height`	CONSEGUIR	Obtener la altura actual del bloque
`/api/blocks/:height`	CONSEGUIR	Obtener detalles del bloque por altura
`/api/transactions/:txid`	CONSEGUIR	Obtener detalles de la transacción por ID de transacción
`/api/accounts/:address/balance`	CONSEGUIR	Obtener saldos de tokens para una dirección
`/api/wallets`	CORREO	Crear una nueva billetera
`/api/wallets/:address`	CONSEGUIR	Obtener información de la billetera
`/api/wallets/import`	CORREO	Importar una billetera desde WIF o clave privada
`/api/network/mode`	CONSEGUIR	Obtener el modo de red actual
`/api/contracts/:name/invoke`	CORREO	Invocar un método de contrato inteligente
`/api/contracts/deploy`	CORREO	Implementar un nuevo contrato inteligente

Ejemplo de solicitudes HTTP

# Get blockchain information
curl http://localhost:3002/api/blockchain/info

# Get the current block height
curl http://localhost:3002/api/blockchain/height

# Get token balances for an address
curl http://localhost:3002/api/accounts/NZNos2WqTbu5oCgyfss9kUJgBXJqhuYAaj/balance

# Create a new wallet
curl -X POST -H "Content-Type: application/json" -d '{"password":"your-password"}' http://localhost:3002/api/wallets

# Get the current network mode
curl http://localhost:3002/api/network/mode

# Deploy a smart contract
curl -X POST -H "Content-Type: application/json" -d '{
  "wif": "your-private-key-wif",
  "script": "base64-encoded-contract-script",
  "manifest": {
    "name": "MyContract",
    "groups": [],
    "features": {},
    "abi": {
      "methods": [
        {
          "name": "myMethod",
          "parameters": [],
          "returnType": "Boolean",
          "offset": 0
        }
      ],
      "events": []
    },
    "permissions": [
      {
        "contract": "*",
        "methods": "*"
      }
    ],
    "trusts": [],
    "supportedStandards": []
  }
}' http://localhost:3002/api/contracts/deploy

Beneficios del servidor HTTP

Accesibilidad : proporciona acceso a la funcionalidad de la cadena de bloques Neo N3 para aplicaciones que no admiten el protocolo MCP
Simplicidad : API RESTful simple que se puede utilizar con cualquier cliente HTTP
Compatibilidad : funciona con aplicaciones y marcos web existentes
Pruebas : más fácil de probar y depurar que el protocolo MCP

Pruebas

Este paquete incluye pruebas de integración para verificar la funcionalidad tanto del servidor MCP como del servidor HTTP.

Ejecución de pruebas

# Build the project
npm run build

# Run the core functionality tests
npm run test:core

# Run the HTTP integration tests
npm run test:http

# Run the MCP integration tests
npm run test:integration

Recursos

Licencia

Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.

Available Tools

19 tools

estimate_invoke_feesC

Estimate network and system fees for a contract invocation by script hash or a generic contract reference.

ParametersJSON Schema

Name	Required	Description
`args`	No	Optional: Method arguments
`network`	No	Optional: Network
`contract`	No	Generic contract reference: known name, script hash, or Neo address
`operation`	Yes	Method name
`nameOrHash`	No	Backward-compatible alias for contract name or script hash
`scriptHash`	No	Contract script hash
`contractName`	No	Exact contract name resolved through N3Index or a live manifest
`signerAddress`	Yes	Signer address

TDQS

C2.8/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It only states 'estimate fees' without explaining what this entails (e.g., simulation, return format, side effects). Minimal behavioral context is provided.

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

Conciseness3/5

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

Single sentence is concise but overly brief. It conveys the core function without waste, but lacks structure or front-loading of critical details.

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?

No output schema exists, yet description omits return value clues. With 8 parameters, it fails to guide which to use for different scenarios (e.g., contract vs nameOrHash vs scriptHash). Incomplete for the tool's complexity.

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?

Input schema has 100% description coverage, so parameters are documented. The description adds 'by script hash or generic contract reference' which aligns with multiple parameter options, but does not clarify relationships or preferred usage among them.

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 estimates network and system fees for contract invocations, specifying that it can use a script hash or generic contract reference. However, it does not explicitly distinguish from the sibling 'estimate_transfer_fees' tool, which is inferred but not stated.

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 explicit guidance on when to use this tool versus alternatives. The name suggests contract invocation fee estimation, but no conditions, prerequisites, or exclusions are provided.

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

estimate_transfer_feesB

Estimate network and system fees for a transfer.

ParametersJSON Schema

Name	Required	Description
`asset`	Yes	Asset hash
`amount`	Yes	Amount
`network`	No	Optional: Network
`toAddress`	Yes	Recipient address
`fromAddress`	Yes	Sender address

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided; description does not disclose behavioral traits (e.g., idempotency, side effects, permissions). Fails to add 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.

Conciseness5/5

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

Single sentence, front-loaded, and concise with no unnecessary words.

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?

Lacks description of return values (no output schema), which is essential for an estimation tool. Could mention that it does not execute a transfer.

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?

Input schema has 100% description coverage; description adds no extra meaning to parameters beyond the schema.

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

Purpose5/5

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

Clearly states the tool estimates network and system fees for a transfer, distinguishing it from sibling `estimate_invoke_fees` which estimates invocation fees.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for fee estimation before transfers but no explicit guidance on when to use this versus alternatives like `estimate_invoke_fees` or `transfer_assets`.

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

get_application_logA

Get the application log for a transaction hash.

ParametersJSON Schema

Name	Required	Description	Default
`txid`	Yes	Transaction hash (64 hex chars, optional 0x prefix)
`network`	No	Optional: Network

TDQS

A3.5/5.0

Behavior2/5

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 read-only nature, side effects, or required permissions. The description's single sentence does not compensate for the lack of transparency.

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 no wasted words. It is appropriately sized for the simple functionality.

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 log retrieval tool with no output schema, the description is minimal but adequate. However, it does not hint at the log content or return format, which could be useful for agents.

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% coverage with descriptions for both parameters ('txid' and 'network'). The description adds no additional meaning beyond what the schema provides, meeting baseline expectations.

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

Purpose5/5

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

The description clearly states 'Get the application log for a transaction hash.' It uses a specific verb and resource, and distinguishes from sibling tools like 'get_transaction' which returns different data.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving logs for a transaction but provides no explicit guidance on when to use this tool versus alternatives or any exclusions.

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

get_balanceA

Get NEO, GAS, and NEP-17 balances for an address.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Neo N3 address
`network`	No	Network to use: "mainnet" or "testnet"

TDQS

A3.5/5.0

Behavior2/5

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

No annotations exist, so the description must cover behavioral traits. It only states the output type (balances) but omits details like error handling, rate limits, or authentication requirements.

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?

A single sentence conveys the entire purpose efficiently with no wasted words. It is front-loaded and 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?

The tool is simple and the description covers the essential purpose. However, without an output schema, the return format is undefined, and the description does not elaborate on the structure of the balances. Adequate but not complete.

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

Parameters4/5

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

The description adds value by listing specific token types (NEO, GAS, NEP-17), which is not in the schema. The schema already fully describes parameters, so baseline is 3; the extra detail raises it to 4.

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

Purpose5/5

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

The description clearly states it gets NEO, GAS, and NEP-17 balances for a given address. The verb 'get' and resource 'balances' are specific, and it distinguishes from sibling tools like get_nep11_balances.

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 such as get_nep17_transfers or get_nep11_balances. The description lacks any contextual cues for selection.

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

get_blockC

Get block details by height or hash.

ParametersJSON Schema

Name	Required	Description	Default
`network`	No	Optional: Network
`hashOrHeight`	Yes	Block hash (64 hex chars) or block height (number)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It does not disclose behavioral traits like error handling for invalid hash/height, network fallback behavior, or size limits. The verb 'Get' implies read-only, but more is needed for transparency.

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

Conciseness4/5

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

The description is a single concise sentence that front-loads the purpose. While very short, it contains no filler. However, it could be considered under-specified rather than concise.

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 no output schema and no annotations, the description should mention what the returned 'block details' include (e.g., all fields, transactions). The absence makes it somewhat incomplete for an AI agent to fully understand the output.

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 coverage is 100%, so the baseline is 3. The description adds no new meaning beyond the schema's parameter descriptions, which already explain the hash/height distinction and optional network parameter.

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 'Get' and the resource 'block details', and specifies the lookup method 'by height or hash'. This distinguishes it from siblings like get_blockchain_info or get_block_count, though it doesn't detail what 'details' includes.

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 such as get_transaction or get_block_count. The description lacks context for when one might prefer this over siblings.

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

get_blockchain_infoA

Get blockchain height, validator info, and the active network.

ParametersJSON Schema

Name	Required	Description	Default
`network`	No	Network to use: "mainnet" or "testnet"

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description must carry the burden. It mentions returned info but does not explicitly state it is read-only or discuss any side effects, though 'Get' implies a safe read operation.

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?

One concise sentence that front-loads the purpose with no redundant or extraneous information. Every word contributes value.

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

Completeness4/5

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

The description lists the specific pieces of information returned, compensating for the lack of output schema. It does not mention the optionality of the network parameter, but overall it is sufficient for a simple tool.

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 coverage is 100% with a description for the single parameter. The tool description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the verb 'Get' and the specific resources: blockchain height, validator info, and active network. It is distinct from sibling tools like get_balance or get_block.

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

Usage Guidelines3/5

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. However, the purpose implies use for overall blockchain state, but no comparison to siblings like get_network_mode or get_block_count.

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

get_block_countB

Get the block count and latest block height for the selected network.

ParametersJSON Schema

Name	Required	Description	Default
`network`	No	Network to use: "mainnet" or "testnet"

TDQS

B3.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 states the tool retrieves data but fails to mention side effects, permissions, rate limits, or response structure. The lack of any safety or mutation context 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.

Conciseness5/5

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

A single, front-loaded sentence that wastes no words. Every part is essential, and the structure is optimally concise for quick parsing.

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

Completeness4/5

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

Given the tool's simplicity (1 parameter, no output schema), the description adequately conveys the return value (block count and height). Minor ambiguity around 'block count' (whether it is total or something else) prevents a perfect score, but it is otherwise complete.

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% and fully describes the 'network' parameter (mainnet or testnet). The description adds no additional meaning beyond 'selected network', so it meets the baseline of 3 without improvement.

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

Purpose5/5

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

The description explicitly states the tool returns 'block count and latest block height' for the selected network, clearly distinguishing it from siblings like 'get_block' (returns a specific block) and 'get_blockchain_info' (returns broader chain info). Verb 'Get' plus resource 'block count and height' is specific and unambiguous.

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 such as 'get_block' or 'get_blockchain_info'. The description does not specify context or prerequisites, leaving the agent to infer usage from the name alone.

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

get_contract_infoC

Get metadata and operations for a contract by known name, script hash, or Neo address.

ParametersJSON Schema

Name	Required	Description
`network`	No	Network to use: "mainnet" or "testnet"
`contract`	No	Generic contract reference: known name, script hash, or Neo address
`nameOrHash`	No	Backward-compatible alias for contract name or script hash
`contractName`	No	Supported contract name

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided. Description does not disclose that it is a read-only operation, does not mention rate limits, authentication, or what 'operations' means. Minimal behavioral context beyond 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.

Conciseness4/5

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

Single sentence, no wasted words. However, could include more useful details without being verbose.

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?

No output schema, no annotations, and description does not explain what 'metadata and operations' entails or the response format. Four optional parameters with no required ones may confuse an AI agent on what to provide.

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

Parameters2/5

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

Schema has 100% description coverage, but the description merely restates the identification methods without clarifying the redundancy or relationship between the three similar parameters (contract, contractName, nameOrHash). Adds no meaningful information beyond the schema.

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

Purpose5/5

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

Description clearly states the verb 'Get' and the resource 'metadata and operations for a contract', and specifies three identification methods (name, script hash, Neo address). This distinguishes it from sibling tools like get_contract_status or deploy_contract.

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 on when to use this tool vs alternatives such as get_contract_status, get_application_log, or list_famous_contracts. Does not mention prerequisites or when not to use.

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

get_contract_statusB

Check whether a contract is deployed and inspect its current on-chain status by known name, script hash, or Neo address.

ParametersJSON Schema

Name	Required	Description
`network`	No	Network to use: "mainnet" or "testnet"
`contract`	No	Generic contract reference: known name, script hash, or Neo address
`nameOrHash`	No	Backward-compatible alias for contract name or script hash
`contractName`	No	Supported contract name

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states it checks deployment and status, but no mention of side effects, read-only nature, or response behavior.

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?

Single sentence front-loading purpose. No redundant words or 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?

Adequate for a simple look-up tool, but no output schema or description of what 'inspect status' returns. Sibling tools exist but no hints.

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 coverage is 100%, so schema already describes parameters. Description does not add extra meaning beyond what's in the schema.

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?

Description clearly states the tool checks contract deployment and status by name, script hash, or address. Verb and resource are specific, and it distinguishes from siblings like get_contract_info by mentioning the lookup methods, though not explicitly.

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 on when to use this tool vs siblings (e.g., get_contract_info). No mention of when not to use it or prerequisites.

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

get_nep11_balancesB

Get NEP-11 balances for an address.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Neo N3 address
`network`	No	Network to use: "mainnet" or "testnet"

TDQS

B3.3/5.0

Behavior2/5

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

No annotations exist, so the description must convey behavioral traits. It does not mention rate limits, authentication, output format, or any side effects. The brief sentence 'Get NEP-11 balances for an address' provides 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.

Conciseness5/5

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

The description is a single sentence, front-loaded, and contains no extraneous information. Every word earns its place.

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 tool with 2 parameters and no output schema, the description is minimally complete but lacks details on return type, error handling, or example usage. It could mention that balances are returned as a list of token 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?

Schema coverage is 100%, so the description adds no additional meaning beyond the schema descriptions. It does not elaborate on the parameters (e.g., address format, network enumeration). Baseline 3 is appropriate given full schema coverage.

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

Purpose5/5

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

The description clearly states the tool fetches NEP-11 balances for an address, using a specific verb and resource. It distinguishes from sibling tools like get_balance (NEP-17) and get_nep11_transfers (transfers vs balances).

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 on when to use this tool versus alternatives, no prerequisites, exclusions, or context provided. The description only says 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_nep11_transfersC

Get NEP-11 transfer history for an address.

ParametersJSON Schema

Name	Required	Description
`address`	Yes	Neo N3 address
`network`	No	Network to use: "mainnet" or "testnet"
`toTimestampMs`	No	Optional end timestamp in Unix epoch milliseconds
`fromTimestampMs`	No	Optional start timestamp in Unix epoch milliseconds

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavioral traits. It only states a read operation ('Get'), but fails to mention pagination, rate limits, response size, or error conditions. This is insufficient for an agent to anticipate side effects or constraints.

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

Conciseness4/5

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

The description is a single, concise sentence that front-loads the purpose. It wastes no words, though it could be more informative without sacrificing brevity.

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 lack of annotations and output schema, the description should elaborate on return format, pagination, and edge cases (e.g., empty history). It only states the basic function, leaving significant gaps for an agent.

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 each parameter already has a description in the schema. The tool description adds no extra meaning or context for parameters beyond 'transfer history'. Baseline 3 is appropriate as no additional value 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 tool retrieves NEP-11 transfer history for an address. The verb 'Get' and resource 'NEP-11 transfer history' are specific. However, it does not explicitly differentiate from the sibling tool get_nep17_transfers, although the token standard is distinct in the name.

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_nep17_transfers or get_nep11_balances. The description lacks context on prerequisites, typical use cases, or exclusions.

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

get_nep17_transfersB

Get NEP-17 transfer history for an address.

ParametersJSON Schema

Name	Required	Description
`address`	Yes	Neo N3 address
`network`	No	Network to use: "mainnet" or "testnet"
`toTimestampMs`	No	Optional end timestamp in Unix epoch milliseconds
`fromTimestampMs`	No	Optional start timestamp in Unix epoch milliseconds

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as pagination, rate limits, data freshness, or authentication requirements. It merely restates the purpose.

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

Conciseness4/5

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

The description is a single, concise sentence. While it lacks detail, it is efficient and front-loaded with the key purpose.

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?

The tool has no output schema, yet the description does not hint at the return format or structure of transfer history. For a query tool, this incomplete context hampers effective 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?

The input schema has 100% description coverage, so each parameter is documented. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.

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

Purpose5/5

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

The description clearly states the tool retrieves NEP-17 transfer history for an address, using a specific verb and resource. It distinguishes from siblings like get_nep11_transfers (different token standard) and get_balance (just balance).

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like get_nep11_transfers. The context is implied from the name and schema, but no direct comparison or exclusion criteria are provided.

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

get_network_modeA

Get the active network mode and available Neo networks.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

The description does not disclose any behavioral traits beyond the basic read operation. No annotations are provided, so the description carries the full burden. It does not mention authentication, rate limits, or whether the list of networks is complete or filtered.

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 tool's purpose. No superfluous words or unnecessary details.

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?

While the tool is simple and the description covers the basics, it lacks details on the return format. Given the absence of an output schema, the description should ideally hint at the structure of the response (e.g., JSON fields) to help the agent parse results. Also, no contextual info on prerequisites or side effects.

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

Parameters4/5

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

The tool has no parameters, so the input schema covers 100% of the interface. The description adds value by specifying that it returns both the active mode and the available networks, which is meaningful context beyond the empty schema.

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

Purpose5/5

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

Description clearly states the tool retrieves the active network mode and available Neo networks. Verb 'Get' and resource 'network mode' and 'Neo networks' are specific and unambiguous. It distinguishes from sibling 'set_network_mode'.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. However, the purpose implies it is for reading network mode, and the sibling 'set_network_mode' handles writing, which provides indirect context.

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

get_transactionB

Get transaction details by hash.

ParametersJSON Schema

Name	Required	Description	Default
`txid`	Yes	Transaction hash (64 hex chars, optional 0x prefix)
`network`	No	Optional: Network

TDQS

B3.2/5.0

Behavior2/5

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

No annotations exist, and the description does not disclose behavioral traits like idempotency, error handling (e.g., missing transaction), or rate limits.

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

Conciseness4/5

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

Extremely concise with one front-loaded sentence, but lacks structure for complex 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?

No output schema, so description should elaborate on return details or network optionality. Currently minimal for a tool with two parameters and many siblings.

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 coverage is 100% with clear parameter descriptions. The description adds no additional value beyond restating 'by hash'.

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

Purpose5/5

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

Description clearly states the tool retrieves transaction details using a hash, distinguishing it from sibling tools like get_block 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance provided. Lacks context on when to use this tool over alternatives, such as get_block for block-level queries or get_balance for account data.

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

get_unclaimed_gasB

Get the amount of GAS claimable by an address.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Neo N3 address
`network`	No	Network to use: "mainnet" or "testnet"

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits, but it only states 'get the amount' without clarifying that it is a read-only operation with no side effects, authentication needs, or rate limits.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no wasted words, though it could be slightly more informative without losing conciseness.

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 output schema and no annotations, the description fails to mention return format, whether the operation is read-only, or any other contextual information needed for correct invocation.

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 coverage is 100%, so the description adds no additional meaning beyond what the schema provides; baseline score applies.

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

Purpose5/5

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

The description clearly states the tool retrieves the amount of GAS claimable by an address, distinguishing it from the sibling tool 'claim_gas' which would perform the claim action.

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 'claim_gas', nor are there any prerequisites or exclusion criteria mentioned.

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

get_walletA

Get sanitized metadata for a locally stored wallet by address.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Neo N3 address

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It mentions 'sanitized metadata' but does not disclose side effects, error conditions, or permissions. This is minimal for a read operation.

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 sentence that is front-loaded with the verb and resource. It is concise without any redundant information.

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

Completeness4/5

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

For a simple tool with one parameter and no output schema, the description adequately covers input and output. However, it could explicitly mention what 'locally stored' means or handle missing wallet cases.

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 coverage is 100%, and the schema already describes the parameter (address). The description adds 'locally stored wallet' context but does not enhance understanding beyond the schema's own description.

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

Purpose5/5

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

The description clearly states the action (Get), the resource (sanitized metadata for a locally stored wallet), and the parameter (by address). It effectively distinguishes from sibling tools like create_wallet or import_wallet.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit when-to-use or when-not-to-use guidance. While it implies use for retrieving wallet metadata, it lacks alternatives or exclusions compared to siblings like import_wallet.

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

invoke_contractB

Run a read-only smart contract invocation without signing or broadcasting a transaction.

ParametersJSON Schema

Name	Required	Description
`args`	No	Method arguments as an array of values
`network`	No	Network to query
`contract`	No	Contract reference: script hash, Neo address, exact N3Index name, or a previously discovered manifest name
`operation`	Yes	Contract method name to invoke
`nameOrHash`	No	Contract name or script hash (alias for contract)
`scriptHash`	No	Contract script hash (40 hex chars, optional 0x prefix)
`contractName`	No	Exact contract name resolved through N3Index or a live manifest

TDQS

B3.3/5.0

Behavior3/5

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

The description states it is read-only and non-broadcasting, clarifying it is non-destructive. However, with no annotations provided, it fails to disclose other behavioral aspects like error handling, result structure, or limits. The read-only trait is the key behavioral detail, earning a 3.

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

Conciseness4/5

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

A single concise sentence conveys the core purpose with no redundancy. However, it could be slightly more structured (e.g., separate lines for key details) without losing brevity.

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 7 parameters and no output schema, the description is too minimal. It does not explain how to use multiple contract identifiers, expected output format, or error conditions. For a tool of this complexity, more context is needed.

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 coverage is 100%, so the descriptions in the schema already document all parameters. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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

Purpose5/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: performing a read-only contract invocation without signing or broadcasting. This precisely distinguishes it from other tools like estimate_invoke_fees or get_contract_info.

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, nor does it explain which parameter among the multiple contract identifiers (contract, nameOrHash, scriptHash, contractName) should be used in different scenarios. Required parameter 'operation' is mentioned in schema but not in description context.

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

list_famous_contractsB

List supported well-known contracts for the selected network.

ParametersJSON Schema

Name	Required	Description	Default
`network`	No	Network to use: "mainnet" or "testnet"

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided. Description does not disclose behavioral traits like auth requirements or data freshness. Only states basic action.

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?

Single sentence, efficient and to the point with no wasted words.

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?

Description is minimal. Does not explain what 'famous contracts' are or if the list is dynamic. Agent may lack full context for correct invocation.

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 covers the parameter with description of allowed values. Description adds no new semantics.

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

Purpose5/5

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

Description clearly states it lists supported well-known contracts for a selected network, with verb and resource. It distinguishes from sibling tools like deploy_contract or get_contract_info.

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 on when to use this tool vs alternatives. No context on prerequisites or network availability.

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

wait_for_transactionC

Wait for a transaction to be confirmed on-chain.

ParametersJSON Schema

Name	Required	Description
`txid`	Yes	Transaction hash (64 hex chars, optional 0x prefix)
`network`	No	Optional: Network
`timeoutMs`	No	Optional timeout in milliseconds
`pollIntervalMs`	No	Optional polling interval in milliseconds
`includeApplicationLog`	No	Include the application log once the transaction confirms

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It fails to disclose polling behavior, timeout consequences, or side effects. The fact that it waits is implied but not detailed (e.g., does it block until confirmed or return immediately?).

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

Conciseness4/5

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

Single sentence with no wasted words. However, given the lack of annotations, the description is too short to convey necessary behavioral information; conciseness could be improved with more context.

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?

No output schema, 5 parameters, and no annotations. The description does not explain return value, error conditions, or how parameters like timeoutMs affect behavior, leaving the agent with significant gaps.

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 has 100% description coverage for parameters, so description adds no additional meaning. Baseline score of 3 is appropriate since the schema already explains each parameter's purpose.

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?

Description clearly states the tool waits for a transaction to be confirmed, using specific verb and resource. However, it does not differentiate from siblings like get_transaction which could also check confirmation status.

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 on when to use this tool versus alternatives (e.g., get_transaction for one-time check). The description lacks context about prerequisite conditions or post-conditions.

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 updatesv3.1.0Jul 12, 2026

Removedclaim_gas
Removedcreate_wallet
Removeddeploy_contract

Changedestimate_invoke_fees2 fields changed

changedInput schema / properties / contractName / description

Previous value: -"Supported contract name"New value: +"Exact contract name resolved through N3Index or a live manifest"

removedInput schema / properties / signers

Removed value: -{
-  "description": "Optional: Signer scopes",
-  "items": {},
-  "type": "array"
-}

Removedimport_wallet

Changedinvoke_contract7 fields changed

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Set to true to execute write operations (safety confirmation)",
-  "type": "boolean"
-}

changedInput schema / properties / contract / description

Previous value: -"Contract reference: known name (e.g. \"NeoFS\"), script hash (0x...), or Neo address"New value: +"Contract reference: script hash, Neo address, exact N3Index name, or a previously discovered manifest name"

changedInput schema / properties / contractName / description

Previous value: -"Known contract name (e.g. \"GAS\", \"NEO\", \"NeoFS\")"New value: +"Exact contract name resolved through N3Index or a live manifest"

removedInput schema / properties / fromWIF

Removed value: -{
-  "description": "Sender WIF private key (required for write operations)",
-  "type": "string"
-}

changedInput schema / properties / network / description

Previous value: -"Network to use: mainnet or testnet"New value: +"Network to query"

addedInput schema / properties / network / enum

Added value: +[
+  "mainnet",
+  "testnet"
+]

removedInput schema / properties / signers

Removed value: -{
-  "description": "Transaction signer scopes for write operations",
-  "items": {},
-  "type": "array"
-}

Removedneofs_create_container
Removedneofs_get_containers
Removedset_network_mode
Removedtransfer_assets

23 tool updatesv2.0.0May 4, 2026
- Addedclaim_gas
- Addedcreate_wallet
- Addeddeploy_contract
- Addedestimate_invoke_fees
- Addedestimate_transfer_fees
- Addedget_application_log
- Addedget_block
- Changedget_contract_info4 fields changed
  - addedInput schema / properties / contract
```
Added value: +{
+  "description": "Generic contract reference: known name, script hash, or Neo address",
+  "type": "string"
+}
```
  - changedInput schema / properties / contractName / description
```
Previous value: -"Contract name"New value: +"Supported contract name"
```
  - addedInput schema / properties / nameOrHash
```
Added value: +{
+  "description": "Backward-compatible alias for contract name or script hash",
+  "type": "string"
+}
```
  - removedInput schema / required
```
Removed value: -[
-  "contractName"
-]
```
- Addedget_contract_status
- Addedget_nep11_balances
- Addedget_nep11_transfers
- Addedget_nep17_transfers
- Changedget_network_mode1 field changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
- Addedget_transaction
- Addedget_unclaimed_gas
- Addedget_wallet
- Addedimport_wallet
- Addedinvoke_contract
- Addedneofs_create_container
- Addedneofs_get_containers
- Addedset_network_mode
- Addedtransfer_assets
- Addedwait_for_transaction
6 tool updatesv1.0.0Aug 15, 2025
- First observedget_balance
- First observedget_block_count
- First observedget_blockchain_info
- First observedget_contract_info
- First observedget_network_mode
- First observedlist_famous_contracts

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.2/5.0

Scored 2026-09-10 03:09 across 19 tools

Disambiguation3/5

Most tools target distinct resources, but get_balance and get_nep17_balances overlap since get_balance already includes NEP-17 balances. get_blockchain_info and get_network_mode also share active-network information, and get_contract_info vs get_contract_status could be confused without careful reading.

Naming Consistency4/5

The naming is mostly consistent with clear get_* prefixes and snake_case verbs. Minor deviations exist with list_famous_contracts, wait_for_transaction, invoke_contract, and estimates, but they are still predictable and readable.

Tool Count3/5

At 19 tools, the server sits in the heavier range and feels borderline for a focused toolkit. Each tool is individually reasonable, but the set could be tightened by consolidating overlapping query tools.

Completeness3/5

The server covers a solid range of read-only Neo N3 operations: balances, transfers, blocks, transactions, contracts, fees, and network info. However, there are notable gaps for a full blockchain MCP surface, such as sending transfers, claiming GAS, or performing signed contract invocations.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
mcp-klever-vm A
io.github.klever-io
MCP server for Klever blockchain smart contract development.
Blockchain Developer Tools Code Execution
16331
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
237
BittensorMCPOAuth
io.github.btmcp
Hosted MCP server for live Bittensor chain reads and self-custodial on-chain writes.
Blockchain Cryptocurrency Web3 & Decentralized Tech
1

Related MCP Servers

Notion MCP Server
Note Taking Content Management Systems App Automation
suekou
A
license
A
quality
B
maintenance
MCP Server for the Notion API, enabling Claude to interact with Notion workspaces.
Updated 2 months ago (2026-07-31 07:14 UTC)
31
850 npm
922
MIT
BrianKnows MCP Server
Blockchain Search RAG Systems
antoncoding
F
license
C
quality
D
maintenance
An MCP server that connects Claude to BrianKnows' blockchain knowledge base, allowing users to search for blockchain/DeFi information and interact with a specialized agent across multiple knowledge bases.
Updated 2 years ago (2025-03-13 16:48 UTC)
3
-
GOAT MCP Server
Blockchain Command Line
cryptoleek-team
F
license
Not graded
quality
D
maintenance
An MCP server that connects Claude for Desktop with blockchain functionality, allowing users to check balances and send tokens on EVM and Solana chains through natural language interactions.
Updated 2 years ago (2025-03-14 04:43 UTC)
-
KaiaFun MCP
Blockchain Web3 & Decentralized Tech Cryptocurrency
weero-finance
A
license
Not graded
quality
C
maintenance
An MCP server that enables token listing, trading, and interaction with the Kaia blockchain via Claude Desktop.
Updated a year ago (2025-04-06 20:20 UTC)
1
Apache 2.0

Protocolo de contexto del modelo Neo N3 (MCP) v1.4.0

Agregar el MCP a un cliente (por ejemplo, VS Code)

Herramientas disponibles

Configuración y red

Información de blockchain

Gestión de billeteras y cuentas

Transferencias de activos

Interacción de contratos inteligentes

NeoFS (Almacenamiento descentralizado)

NeoBurger (Servicio de staking)

Solicitudes de ejemplo

Obtenga información sobre blockchain

Transferir activos

Manejo de errores

Mejores prácticas de seguridad

Servidor HTTP

Puntos finales HTTP

Ejemplo de solicitudes HTTP

Beneficios del servidor HTTP

Pruebas

Ejecución de pruebas

Recursos

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches