What can you do with this server?

The Neo N3 MCP Server is a production-ready Model Context Protocol server that provides comprehensive Neo N3 blockchain integration with 34 tools and 9 resources for blockchain operations. Core Capabilities: * Network Management: Get current network mode and switch between mainnet/testnet * Blockchain Queries: Retrieve blockchain information, block counts, specific blocks by height/hash, and transaction details * Wallet Operations: Create new wallets with secure private key management and import existing wallets using private keys or WIF format * Asset Management: Check NEO, GAS, and NEP-17 token balances, transfer assets between addresses, estimate transfer fees, and claim accumulated GAS rewards * Contract Interactions: List famous contracts (NEO, GAS, NEP-17 tokens), get detailed contract information including manifest and methods, invoke smart contracts with parameters, and estimate gas costs for invocations * Resources (Read-Only Access): Network status monitoring, blockchain data access, contract registry, and asset information via neo:// URLs Key Features: * Multi-network support for both mainnet and testnet * Enterprise-grade security with input validation and error handling * Built-in rate limiting and network resilience * Multiple deployment options via NPM, Docker, and direct integration with MCP clients like Claude Desktop

Which integrations are available for this server?

Enables containerized deployment of the Neo N3 MCP server, supporting isolated and consistent execution environments across different platforms. Hosts the source code repository for the Neo N3 MCP server, enabling version control and collaboration on the codebase. Supports comprehensive testing of the Neo N3 MCP server functionality, ensuring reliability of blockchain interactions. Hosts the Neo N3 MCP documentation website, providing users with comprehensive guides and API references for interacting with the Neo N3 blockchain. Provides tools for running the Neo N3 MCP server as an NPM package using Node.js, offering a simple way to access the blockchain functionality. Allows installation and distribution of the Neo N3 MCP server as a package through the NPM registry, making it easily accessible to users. Used for implementing the Neo N3 MCP server with strong typing, providing enhanced development experience and code reliability.

How do I use Neo N3 MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Neo N3 MCP Server check my wallet balance on testnet" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

Neo N3 MCP Server

by r3e-network

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Neo MCP Server

@r3e/neo-mcp is an MCP server for Neo N3 blockchain queries and controlled, auditable transaction submission. It ships three entrypoints:

Entrypoint	Command	Protocol
MCP stdio	`npm start`	MCP over stdin/stdout, for local clients such as Claude Desktop and Cursor
MCP HTTP	`npm run start:mcp-http`	MCP 2026-07-28 stateless HTTP, for remote MCP clients
REST API	`npm run start:http`	Bespoke REST/JSON; not an MCP transport

The two HTTP servers are unrelated and configured separately. See Remote MCP 2026 HTTP and docs/remote-mcp-transport.md.

Current version: 4.1.0. Node.js >=22 is required. Version 4 speaks only MCP 2026-07-28; clients using the removed initialization/session protocol are rejected rather than downgraded.

Quick Start

Install and run the MCP stdio server:

npm install -g @r3e/neo-mcp
neo-mcp

Or run it without a global install:

npx -y @r3e/neo-mcp

Example Claude Desktop or Cursor configuration:

{
  "mcpServers": {
    "neo-n3": {
      "command": "npx",
      "args": ["-y", "@r3e/neo-mcp"],
      "env": {
        "NEO_NETWORK": "testnet",
        "NEO_TESTNET_RPC": "https://testnet1.neo.coz.io:443",
        "LOG_LEVEL": "info"
      }
    }
  }
}

Related MCP server: BrianKnows MCP Server

Programmatic API

The package root exports the MCP server, HTTP server, services, network enums, and validated configuration:

import { NeoNetwork, NeoService } from '@r3e/neo-mcp';

const neo = new NeoService(
  'https://testnet1.neo.coz.io:443',
  NeoNetwork.TESTNET,
);

const blockCount = await neo.getBlockCount();
console.log({ blockCount, height: Math.max(0, blockCount - 1) });

NeoMcpServer exposes run() and close() for applications that manage the stdio transport lifecycle themselves.

Configuration

Variable	Purpose	Default
`NEO_NETWORK`	`mainnet`, `testnet`, or `both`; HTTP requires one network	`both`
`NEO_MAINNET_RPC`	Mainnet RPC endpoint	`https://mainnet1.neo.coz.io:443`
`NEO_TESTNET_RPC`	Testnet RPC endpoint	`https://testnet1.neo.coz.io:443`
`NEO_RPC_TIMEOUT_MS`	Per-operation Neo RPC deadline in milliseconds	`15000`
`NEO_ALLOW_INSECURE_RPC`	Allow a remote plaintext HTTP RPC URL	`false`
`NEO_MAX_TRANSACTION_FEE_GAS`	Maximum combined system and network fee for a signed transaction, in GAS	`20`
`NEO_ENABLE_WRITES`	Register state-changing tools and HTTP routes	`false`
`NEO_SIGNER_WIF_FILE`	Owner-only regular file containing the single server signer WIF	required for writes
`NEO_WRITE_STATE_DIR`	Durable idempotency journal directory	`$WALLETS_DIR/.write-operations`
`NEO_MCP_REQUEST_STATE_KEY`	Independent HMAC key for MCP multi-round-trip approval state	required for writes
`HTTP_WRITE_APPROVAL_API_KEY`	Independent bearer token for HTTP write approval	required for writes
`NEO_ENABLE_WALLET_ADMIN`	Enable HTTP wallet create/import administration	`false`
`N3INDEX_API_BASE_URL`	Remote contract name lookup base URL	`https://api.n3index.dev`
`N3INDEX_ENABLED`	Enable N3Index-backed name resolution	`true`
`EXPLORER_ACCOUNT_WATCH_ENABLED`	Enable the double-opt-in Explorer account Watch request tool	`false`
`EXPLORER_ACCOUNT_WATCH_API_URL`	Fixed Explorer Watch API endpoint	`https://www.neo3scan.com/api/account-watches`
`EXPLORER_ACCOUNT_WATCH_API_TOKEN`	Dedicated bearer for the Explorer Watch API; must differ from MCP/REST bearers	required when enabled
`HTTP_HOST`	REST API listen address	`127.0.0.1`
`HTTP_API_KEY`	Bearer token for REST API routes	unset
`HTTP_CORS_ORIGINS`	Comma-separated exact HTTP/HTTPS origins	empty
`HTTP_MAX_BODY_BYTES`	Maximum HTTP request body size	`1048576` (1 MiB)
`MCP_HTTP_PORT`	Remote MCP transport listen port	`3001`
`MCP_HTTP_HOST`	Remote MCP transport listen address	`127.0.0.1`
`MCP_HTTP_PATH`	Remote MCP endpoint path	`/mcp`
`MCP_HTTP_BEARER`	Bearer token for the remote MCP endpoint; required unless `MCP_HTTP_HOST` is loopback	unset
`MCP_HTTP_ALLOWED_ORIGINS`	Comma-separated exact origins allowed to connect from a browser	empty
`MCP_HTTP_MAX_CONCURRENT_REQUESTS`	Concurrent in-flight MCP request cap	`128`
`MCP_HTTP_MAX_SUBSCRIPTIONS`	Concurrent `subscriptions/listen` stream cap	`128`
`MCP_HTTP_MAX_BODY_BYTES`	Maximum MCP POST body size	`4194304` (4 MiB)
`MCP_HTTP_BODY_TIMEOUT_MS`	Deadline for receiving an MCP request body	`30000`
`MCP_HTTP_HEADERS_TIMEOUT_MS`	Deadline for receiving MCP headers	`30000`
`MCP_HTTP_REQUEST_TIMEOUT_MS`	Overall MCP HTTP request deadline	`300000`
`MCP_HTTP_KEEP_ALIVE_MS`	SSE keepalive interval; `0` disables it	`15000`
`WALLETS_DIR`	Directory for persisted encrypted wallet records	`./wallets`
`RATE_LIMITING_ENABLED`	Enable request rate limiting	enabled outside test environments
`MAX_REQUESTS_PER_MINUTE`	Per-client minute limit	`60`
`MAX_REQUESTS_PER_HOUR`	Per-client hour limit	`1000`
`LOG_LEVEL`	`debug`, `info`, `warn`, or `error`	`info`
`LOG_CONSOLE`	Enable console logging	enabled outside test environments
`LOG_FILE`	Log file path; setting it enables file logging	`./logs/neo-mcp.log`
`LOG_FILE_ENABLED`	Enable file logging without setting `LOG_FILE`	`false`
`PORT`	HTTP listen port	`3000`

The aliases NEO_MAINNET_RPC_URL, NEO_TESTNET_RPC_URL, and NEO_NETWORK_MODE remain supported.

Remote RPC endpoints must use HTTPS. Plain HTTP is accepted for loopback RPC endpoints; setting NEO_ALLOW_INSECURE_RPC=true explicitly permits remote plaintext HTTP and should be limited to controlled development environments.

When NEO_NETWORK=both, read-only MCP calls without an explicit network use mainnet. Every state-changing call requires an explicit network and an idempotency key. The HTTP entrypoint rejects both; set NEO_NETWORK=mainnet or NEO_NETWORK=testnet.

Writes are disabled by default. To enable them, create an owner-only signer file outside the repository and configure durable state:

install -m 0600 /dev/stdin /run/secrets/neo-signer-wif
export NEO_ENABLE_WRITES=true
export NEO_SIGNER_WIF_FILE=/run/secrets/neo-signer-wif
export NEO_WRITE_STATE_DIR=/var/lib/neo-mcp/write-operations
export NEO_MCP_REQUEST_STATE_KEY="$(openssl rand -hex 32)"
export HTTP_WRITE_APPROVAL_API_KEY="$(openssl rand -hex 32)"

The MCP and HTTP request schemas never accept WIFs, private keys, or passwords. MCP writes use the 2026-07-28 input_required flow. The server signs the opaque requestState, binds it to tools/call, expires it after ten minutes, and executes only after the re-entered response accepts the exact intent fingerprint. HTTP writes return a pending intent and require a separate approval request authenticated by HTTP_WRITE_APPROVAL_API_KEY.

Account intelligence remains evidence-first: analyze_account_graph exposes the replayable, network-scoped transfer graph and curated metadata only. The backend's deterministic exchange-sweep, coordinated-signer, community-affinity, and graph-similarity detector queue is deliberately not exposed as public identity data; pending candidates require human review before they can become curated metadata.

As of 2026-08-01, both production network detector timers have completed their detector rerun successfully. The resulting pending queue is operational review evidence only and is not returned by analyze_account_graph.

HTTP API

This is a bespoke REST/JSON API, not an MCP transport. MCP clients cannot connect to it; they use the stdio entrypoint or the remote MCP transport.

Build and start the HTTP entrypoint:

npm ci
npm run build
export HTTP_API_KEY="$(openssl rand -hex 32)"
NEO_NETWORK=mainnet npm run start:http

The server listens on 127.0.0.1:3000 by default. A non-loopback HTTP_HOST requires HTTP_API_KEY, and every configured API key must contain at least 32 bytes. When a key is configured, send it as a bearer token on every route except GET /live and GET /health:

curl http://127.0.0.1:3000/live
curl http://127.0.0.1:3000/health
curl -H "Authorization: Bearer $HTTP_API_KEY" \
  http://127.0.0.1:3000/api/blockchain/height

The HTTP listener does not terminate TLS. Plaintext HTTP is supported only on loopback or a trusted host-local proxy network. Remote clients must use HTTPS through a TLS-terminating reverse proxy or load balancer; direct remote plaintext HTTP is unsupported because bearer tokens traverse requests.

The height endpoint distinguishes the node's block count from the latest block index:

{
  "blockCount": 12346,
  "height": 12345
}

HTTP_CORS_ORIGINS is an optional exact-origin allowlist. For example:

HTTP_CORS_ORIGINS=https://console.example.com,https://admin.example.com

Origins must use HTTP or HTTPS and cannot contain paths, credentials, query strings, or fragments. Wildcard CORS is not supported.

POST and PUT bodies must be JSON objects. The default body limit is 1 MiB and can be changed with HTTP_MAX_BODY_BYTES. A write request creates an immutable pending intent:

curl -X POST http://127.0.0.1:3000/api/transfers \
  -H "Authorization: Bearer $HTTP_API_KEY" \
  -H "Idempotency-Key: transfer-2026-07-11-001" \
  -H 'Content-Type: application/json' \
  -d '{"network":"mainnet","toAddress":"Nb...","asset":"NEO","amount":"1"}'

Approve only after comparing the returned fingerprint with the intended request:

curl -X POST http://127.0.0.1:3000/api/write-intents/INTENT_ID/approve \
  -H "Authorization: Bearer $HTTP_WRITE_APPROVAL_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"fingerprint":"RETURNED_64_HEX_FINGERPRINT"}'

See API.md for the tool and route reference.

Remote MCP 2026 HTTP

The stateless MCP 2026-07-28 HTTP transport serves the same non-custodial MCP surface as the stdio entrypoint to remote clients. It is a separate process from the REST API, listens on its own port, and has its own configuration and bearer token. The only default external side effect is request_account_watch, which is disabled unless explicitly configured and can only send a double-opt-in verification message; it cannot activate a subscription.

npm ci
npm run build
export MCP_HTTP_BEARER="$(openssl rand -hex 32)"
NEO_NETWORK=mainnet npm run start:mcp-http

The server listens on 127.0.0.1:3001 by default and exposes:

Method	Path	Purpose
`POST`	`MCP_HTTP_PATH` (default `/mcp`)	Stateless MCP `2026-07-28` requests such as `server/discover`, `tools/list`, and `tools/call`
`OPTIONS`	`MCP_HTTP_PATH`	CORS preflight
`GET`	`/healthz`	Unauthenticated liveness probe

A non-loopback MCP_HTTP_HOST requires MCP_HTTP_BEARER and rejects a token shorter than 32 bytes, mirroring the HTTP_API_KEY rule for the REST entrypoint. When a token is configured, clients send Authorization: Bearer <token> on every request to MCP_HTTP_PATH; /healthz stays unauthenticated so probes can reach it.

Connect with the MCP TypeScript SDK:

import {
  Client,
  StreamableHTTPClientTransport,
} from '@modelcontextprotocol/client';

const transport = new StreamableHTTPClientTransport(new URL('http://127.0.0.1:3001/mcp'), {
  authProvider: { token: async () => process.env.MCP_HTTP_BEARER },
});
const client = new Client(
  { name: 'my-client', version: '2.0.0' },
  {
    capabilities: {},
    versionNegotiation: { mode: { pin: '2026-07-28' } },
  },
);
await client.connect(transport);
const { tools } = await client.listTools();

Like the REST listener, this listener serves plaintext HTTP and does not terminate TLS. Remote clients must reach it through a TLS-terminating reverse proxy. Requests are stateless, so replicas do not need sticky routing.

See remote-mcp-transport.md for the full configuration reference, an end-to-end local run against the Neo Explorer agent, production deployment guidance, and troubleshooting.

Docker

The production Compose file is docker/docker-compose.yml. It defines two services from the same image: neo-mcp runs the REST API on port 3000, and neo-mcp-http runs the remote MCP transport on port 3001. Each requires its own token, binds the host port to 127.0.0.1 by default, and persists wallet records in its own volume:

export HTTP_API_KEY="$(openssl rand -hex 32)"
export MCP_HTTP_BEARER="$(openssl rand -hex 32)"
docker compose -f docker/docker-compose.yml up -d

Start only the remote MCP service. Compose interpolates the whole file before selecting a service, so the REST service's mandatory HTTP_API_KEY must be set to any non-empty placeholder even though its container is never started here (the ">= 32 bytes" check only runs when that container actually starts):

HTTP_API_KEY=unused-when-starting-only-the-mcp-service \
MCP_HTTP_BEARER="$(openssl rand -hex 32)" \
  docker compose -f docker/docker-compose.yml up -d neo-mcp-http

To run a published image instead of building the checkout, use the digest-only registry overlay with the image repository and the release artifact's 64-character lowercase hexadecimal digest:

NEO_MCP_IMAGE_REPOSITORY=r3enetwork/neo-mcp \
NEO_MCP_IMAGE_DIGEST=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef \
HTTP_API_KEY="$HTTP_API_KEY" \
MCP_HTTP_BEARER="$MCP_HTTP_BEARER" \
  docker compose -f docker/docker-compose.yml \
    -f docker/docker-compose.registry.yml up -d

Set HTTP_BIND_ADDRESS=0.0.0.0 (REST) or MCP_HTTP_BIND_ADDRESS=0.0.0.0 (remote MCP) only when the service must be reachable by a TLS-terminating reverse proxy or load balancer. Do not expose either plaintext listener directly to remote clients.

The development Compose file binds locally and supplies local-development tokens by default. It defines neo-mcp-dev for the REST API and neo-mcp-http-dev for the remote MCP transport:

docker compose -f docker/docker-compose.dev.yml up -d

Those default tokens are for local development only. Override HTTP_API_KEY and MCP_HTTP_BEARER for any shared environment.

Build and run without Compose:

npm run docker:build
export HTTP_API_KEY="$(openssl rand -hex 32)"
npm run docker:run -- --detach

See DOCKER.md for image, volume, and helper-script details.

MCP Tools and Resources

The default MCP surface exposes 58 non-custodial tools. Every tool that both chains implement takes a required chain discriminator, "n3" or "neox", with no silent default; single-chain tools reject the chain they do not serve. The network parameter is always "mainnet" or "testnet"; the registry rewrites it for Neo X internally, so callers never spell out a chain-qualified network name.

Server and data utilities: get_network_mode, get_wallet, inspect_neo_value, convert_neo_data, get_neo_service_info, analyze_stablecoins
Chain, both chains: get_chain_info, get_block_height, get_block, get_transaction, get_transaction_status, get_balance
Contracts, both chains: call_contract, get_contract_info, simulate_call
Construct, both chains: build_transfer, build_contract_call
Neo ecosystem reads: decode_neo_script, query_nns, query_neofs, get_oracle_info
Dedicated Neo N3 construct: build_vote, build_nns_operation
Explorer and intelligence: explorer_get_address, analyze_address, analyze_account_graph, analyze_consensus_health, analyze_address_connection, analyze_transaction, investigate_transactions, analyze_contract, analyze_contract_upgrades, get_contract_source_verification, inspect_contract_code, analyze_neox_transaction, analyze_neox_block, analyze_neox_address, analyze_neox_contract, analyze_neox_token, explorer_list_address_transactions, explorer_list_address_transfers, explorer_list_token_holders, explorer_search, query_explorer
Verified notification action: request_account_watch sends a cooldown-limited verification message for one explicit Neo N3 network, address, and email. It is non-destructive and idempotent; the watch remains inactive until the recipient confirms in the Explorer.
Neo N3 only: get_application_log, wait_for_transaction, get_unclaimed_gas, get_nep17_transfers, get_nep11_balances, get_nep11_transfers, get_contract_status, list_famous_contracts, estimate_transfer_fees, estimate_invoke_fees, explorer_list_address_assets, query_explorer_find
Neo X only: analyze_neox_transaction, analyze_neox_block, analyze_neox_address, analyze_neox_contract, analyze_neox_token, query_explorer_graphql

call_contract is strictly read-only: invokefunction on Neo N3, eth_call on Neo X. The build_* tools run the exact read-only simulation and return UNSIGNED transaction proposals for a wallet to review and sign; no default-surface tool holds a key, signs, or broadcasts. build_vote pins the native NEO contract, while build_nns_operation pins the network-correct NameService contract and operation arguments.

query_neofs requires an explicit network field. The selected N3 network is preserved as address context in the result, while the fixed NeoFS gateway remains global; this prevents the assistant from presenting a mainnet/testnet N3 context as a NeoFS gateway switch. Constructed N3 and Neo X proposals are returned with an unsigned-only boundary and are simulated before the Explorer exposes them to a wallet.

Explorer AI roadmap

The canonical cross-repository plan is maintained in the Neo OS Fura AI Plan and Roadmap. Neo MCP is the typed orchestration boundary: it exposes deterministic Explorer evidence and unsigned, simulated proposals to the assistant while keeping wallet review, signing, and broadcasting outside the hosted MCP service.

analyze_transaction is the primary Neo N3 investigation tool. Its v2 response adds stable evidence IDs, bounded counts, exact grouped fund flows, conservative failure classification, and code-based findings. Clients should cite those IDs, preserve exact decimal strings, and disclose when detailed opcode or storage traces are unavailable.

investigate_transactions composes one to twelve confirmed Neo N3 transactions into a deterministic, immutable evidence set. It returns a block-ordered timeline, complete per-transaction analyses, and observed asset relationships with source transactions, evidence references, confidence classes, and the requested_transactions_only sampling boundary. It does not infer shared ownership, causality, hidden calls, or activity outside the set.

analyze_contract is the primary Neo N3 contract-intelligence tool. Its v1 response returns network-scoped ABI, Manifest permission and trust, NEF method token, compiler, update, and source-verification facts with stable evidence IDs. Clients must keep declared source URLs, safe=false ABI methods, deterministic static findings, verified source, simulation, and vulnerability claims distinct.

inspect_contract_code is the paginated code-inspection companion. It returns bounded NeoVM operands, resolved syscall names, ABI method ownership, and static control-flow targets with stable opcode evidence IDs. It is deterministic disassembly, not a runtime trace, verified source, decompilation, or simulation.

analyze_contract_upgrades compares immutable indexed contract artifacts by update counter. It reports exact complete or partial historical coverage, SHA-256 artifact identities, and structural ABI method/event/standard changes. Missing versions are never synthesized, and storage compatibility remains not_determined because manifest and NEF artifacts cannot prove a storage layout.

get_contract_source_verification returns the immutable reproducibility record for each verified update counter: source bundle digest, immutable repository commit, compiler settings, and exact manifest, NEF, binary, and script hashes. Only a record for the current update counter verifies current code. Exact artifact equality is not a security audit.

A locally launched stdio server with NEO_ENABLE_WRITES=true, NEO_SIGNER_WIF_FILE, and NEO_MCP_REQUEST_STATE_KEY registers four additional Neo N3 tools that sign with that owner-supplied key: transfer_assets, invoke_contract_write, claim_gas, deploy_contract. They require an idempotencyKey, an explicit network, a modern client that can fulfil an embedded form request, and acceptance of the exact returned intent fingerprint through input_required. The MCP HTTP transport is read-only by design and ignores the setting.

The curated contract list is intentionally empty until each entry has a current network hash and a verified on-chain manifest. Generic contract tools accept a script hash, Neo address, exact N3Index name, or a name learned from a live manifest.

estimate_transfer_fees and estimate_invoke_fees return exact integer decimal strings in networkFeeDatos and systemFeeDatos, plus formatted GAS strings in networkFeeGas and systemFeeGas. Before any transaction is signed or broadcast, the combined system and network fee must not exceed NEO_MAX_TRANSACTION_FEE_GAS.

deploy_contract accepts compiler output as a complete serialized NEF object, nef: { encoding: "hex" | "base64", data: string }, together with its manifest. Raw VM bytecode is not a deployable NEF artifact.

get_block_height returns both blockCount and height, where height is max(0, blockCount - 1).

For Neo N3 block analysis, pass includeStateRoot: true to get_block to receive the exact StateService root plus local and StateValidator-validated height boundaries. The returned validated flag is true only when the requested root is at or below the validated boundary. Neo X rejects this N3-only option, and ordinary block lookups do not incur the extra RPC calls. Neo N3 block responses also include a deterministic ISO-8601 timeIso alongside the node's millisecond time value.

Resources:

neo://network/status
neo://mainnet/status
neo://testnet/status
neo://block/{height}

Security Notes

Keep both HTTP listeners bound to loopback unless remote access is required.
Terminate TLS before every remote HTTP connection; a bearer token authenticates requests but does not encrypt itself in transit.
Use a randomly generated token of at least 32 bytes for HTTP_API_KEY and MCP_HTTP_BEARER.
Keep NEO_ENABLE_WRITES=false on any remotely reachable MCP listener; the remote transport must never carry a transaction signer.
Keep EXPLORER_ACCOUNT_WATCH_ENABLED=false unless the deployment intentionally supports verification email. When enabled, use a dedicated 32-byte-or-longer EXPLORER_ACCOUNT_WATCH_API_TOKEN that differs from every transport/API bearer.
Keep the signer WIF only in the owner-only NEO_SIGNER_WIF_FILE; never send it through MCP or HTTP.
Persist WALLETS_DIR on controlled storage with restrictive permissions.
State-changing MCP tools require an explicit network, a stable idempotency key, and an exact input_required approval whose request state passes HMAC, expiry, method-binding, intent, network, operation, and fingerprint checks.
Remote plaintext HTTP RPC endpoints are rejected unless NEO_ALLOW_INSECURE_RPC=true; prefer HTTPS.
Signed transactions are rejected when their combined system and network fees exceed NEO_MAX_TRANSACTION_FEE_GAS.
Rate limiting is enabled by default outside test-like environments.

Testing

# Deterministic unit tests; excludes tests/mcp-*.test.ts
npm run test:unit

# Compile, then run deterministic built-server smoke and lifecycle checks
npm run build
npm run test:mcp

# Unit tests + build + deterministic MCP checks
npm run test:all

# Opt-in public RPC checks; requires a build and network access
npm run build
npm run test:mcp:live

# Explicit stress suite; requires a build
npm run test:mcp:stress

npm run test:integration is an additional built-server integration script that calls public RPC endpoints; it is not part of test:all.

Release and Dependency Checks

npm audit and npm audit --omit=dev are expected to pass. The package uses a scoped lodash@4.18.1 override for the transitive @cityofzion/neon-core dependency.

./scripts/prepare-release.sh installs the lockfile, runs type checking, deterministic tests, the build, both audits, package validation, Compose validation, and container builds. It updates the version only after verification and does not create a commit or tag.

GitHub Actions tests Node.js 22 and 24. Published GitHub releases can publish the npm package and Docker image when the required repository secrets are configured; no production deployment target is defined in this repository.

Documentation

Troubleshooting

Installation failures: verify node --version reports Node.js 22 or newer, then retry npm ci or the package install.
HTTP_API_KEY is required: the HTTP process is listening on a non-loopback host. Set a key containing at least 32 bytes or bind HTTP_HOST to a loopback address.
HTTP 401: send Authorization: Bearer <HTTP_API_KEY> on all routes except /live and /health.
HTTP 413: reduce the request size or increase HTTP_MAX_BODY_BYTES to a positive integer.
Remote MCP 401: send Authorization: Bearer <MCP_HTTP_BEARER>; /healthz is the only unauthenticated route.
Remote MCP -32022: the client did not pin 2026-07-28, or attempted the removed legacy initialization flow. Upgrade to @modelcontextprotocol/client v2.
Remote MCP -32020: the request's Mcp-Method, Mcp-Name, or protocol-version headers disagree with its body. Use the v2 SDK instead of hand-building the envelope.
RPC errors: verify the selected RPC URL is reachable and supports the requested Neo RPC method.

License

MIT. See LICENSE.

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose. For example, get_balance, get_nep11_balances, and get_nep17_balances are separated by token standard; get_contract_info and get_contract_status are distinguished by metadata vs. status. No significant overlap.

Naming Consistency5/5

All tool names use snake_case and follow a consistent verb_noun pattern (e.g., get_balance, create_wallet, deploy_contract). No mixing of conventions.

Tool Count4/5

27 tools is slightly above the typical 3-15 range but still reasonable given the broad scope covering wallets, contracts, tokens, blocks, NeoFS, and fees. It feels a bit heavy but not excessive.

Completeness4/5

The toolset covers major workflows like wallet management, asset transfers, contract deployment/invocation, and blockchain queries. Minor gaps exist, such as missing contract update or token metadata retrieval, but the core functionality is well-covered.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
214
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
A
maintenance
MCP Server for the Notion API, enabling Claude to interact with Notion workspaces.
Updated a month ago (2026-07-31 07:14 UTC)
31
4,626
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 a year 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 a year 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

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/r3e-network/neo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server