Skip to main content
Glama
CryptoAPIs-io

Crypto APIs MCP Broadcast

Official
by CryptoAPIs-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

@cryptoapis-io/mcp-broadcast

MCP server for Crypto APIs Broadcast product. Submit locally signed transactions to the blockchain.

API Version: Compatible with Crypto APIs version 2024-12-12

Features

  • Broadcast signed transaction hex to any supported blockchain

  • Supports EVM (Ethereum, Ethereum Classic, BSC, Polygon, Avalanche (C-Chain), Arbitrum, Base, Optimism, Tron)

  • Supports UTXO (Bitcoin, Bitcoin Cash, Litecoin, Dogecoin, Dash, Zcash)

  • Works with transactions signed by @cryptoapis-io/mcp-signer or any external signer

Related MCP server: Blockchain Payment MCP Server

Prerequisites

Installation

npm install @cryptoapis-io/mcp-broadcast

Or install all Crypto APIs MCP servers: npm install @cryptoapis-io/mcp

Usage

# Run with API key
npx @cryptoapis-io/mcp-broadcast --api-key YOUR_API_KEY

# Or use environment variable
export CRYPTOAPIS_API_KEY=YOUR_API_KEY
npx @cryptoapis-io/mcp-broadcast

# HTTP transport (listens on 127.0.0.1; see "Exposing the server beyond localhost")
npx @cryptoapis-io/mcp-broadcast --transport http --port 3000 --api-key YOUR_API_KEY

Claude Desktop

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "cryptoapis-broadcast": {
      "command": "npx",
      "args": ["-y", "@cryptoapis-io/mcp-broadcast"],
      "env": {
        "CRYPTOAPIS_API_KEY": "your_api_key_here"
      }
    }
  }
}

Cursor

Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "cryptoapis-broadcast": {
      "command": "npx",
      "args": ["-y", "@cryptoapis-io/mcp-broadcast"],
      "env": {
        "CRYPTOAPIS_API_KEY": "your_api_key_here"
      }
    }
  }
}

MCP Inspector

npx @modelcontextprotocol/inspector npx @cryptoapis-io/mcp-broadcast --api-key YOUR_API_KEY

n8n

  1. Start the server in HTTP mode:

    npx @cryptoapis-io/mcp-broadcast --transport http --port 3000 --api-key YOUR_API_KEY

  2. In your n8n workflow, add an AI Agent node

  3. Under Tools, add an MCP Client Tool and set the URL to http://localhost:3000/mcp

n8n in Docker: localhost inside the container is not your machine. Start the server with --host 0.0.0.0 and MCP_AUTH_TOKEN set (see Exposing the server beyond localhost), use http://host.docker.internal:3000/mcp as the URL, and add an Authorization: Bearer <token> header to the MCP Client Tool credential.

All servers default to port 3000. Use --port to assign different ports when running multiple servers.

Available Tools

broadcast_signed_transaction

Submit a signed transaction to the blockchain.

Parameter

Description

blockchain

Target blockchain (ethereum, bitcoin, binance-smart-chain, tron, polygon, etc.)

network

Network (mainnet, testnet, sepolia, mordor, nile, amoy, fuji, etc.)

signedTransactionHex

The signed transaction hex string to broadcast

CLI Arguments

Argument

Description

Default

--api-key

Crypto APIs API key

CRYPTOAPIS_API_KEY env var

--transport

Transport type: stdio or http

stdio

--host

HTTP host (use 0.0.0.0 to accept remote connections — requires an auth token with --api-key)

127.0.0.1

--auth-token

Bearer token callers must send (Authorization: Bearer <token>); prefer the MCP_AUTH_TOKEN env var

MCP_AUTH_TOKEN env var

--allowed-hosts

Comma-separated Host header allowlist for non-loopback binds

—

--port

HTTP port

3000

--path

HTTP path

/mcp

--stateless

Enable stateless HTTP mode

false

HTTP API Key Modes

When using HTTP transport, the server supports two API key modes:

  • With --api-key: The key is used for all requests. x-api-key request headers are ignored.

  • Without --api-key: Each request must include an x-api-key header with a valid Crypto APIs key. This enables hosting a public server where each user provides their own key.

# Per-request key mode (multi-tenant)
npx @cryptoapis-io/mcp-broadcast --transport http --port 3000
# Clients send x-api-key header with each request

Exposing the server beyond localhost

HTTP mode listens on 127.0.0.1 by default, so only processes on the same machine can reach it. To accept connections from other machines or containers, bind explicitly and protect the port:

# Startup-key mode: callers must present the token (the server refuses to start without one)
export MCP_AUTH_TOKEN=$(openssl rand -hex 32)
npx @cryptoapis-io/mcp-broadcast --transport http --host 0.0.0.0 --port 3000 --api-key YOUR_API_KEY \
  --allowed-hosts mcp.internal.example
# Clients send: Authorization: Bearer $MCP_AUTH_TOKEN

# Per-request key mode: no startup key, every request must carry the caller's own x-api-key
npx @cryptoapis-io/mcp-broadcast --transport http --host 0.0.0.0 --port 3000

--allowed-hosts restricts the Host header (DNS rebinding protection) when not bound to loopback. Prefer MCP_AUTH_TOKEN over --auth-token: command-line arguments are visible in the process list.

Stdio transport always requires an API key at startup.

Important: API Key Required

Warning: Making requests without a valid API key — or with an incorrect one — may result in your IP being banned from the Crypto APIs ecosystem. Always ensure a valid API key is configured before starting any server.

Remote MCP Server

Crypto APIs provides an official remote MCP server with all tools available via HTTP Streamable transport at https://ai.cryptoapis.io/mcp. Pass your API key via the x-api-key header — no installation required.

License

MIT

Available Tools

2 tools
broadcast_signed_transactionA

Broadcast locally signed transaction (Broadcast product).

Submit a signed transaction hex to the network. Supported blockchains and networks vary; see credits for per-chain cost.

Note: 'broadcast-signed-transaction' actions require confirmation. They return a preview with a one-time token instead of executing immediately.

Credits by action (source: OpenAPI): • broadcast-signed-transaction: arbitrum 80, avalanche 90, base 60, binance-smart-chain 125, bitcoin 50, bitcoin-cash 60, dash 55, dogecoin 55, ethereum 50, ethereum-classic 65, litecoin 55, optimism 70, polygon 100, solana 150, tezos 65, tron 75, xrp 50, zcash 65

Credits are indicative only and may change at any time. The actual credits spent for each API request are returned in the response headers.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextNoOptional context for the request - echoed back in response
networkYesNetwork name
blockchainYesBlockchain protocol
confirmationTokenNoConfirmation token from a previous preview response. IMPORTANT: You MUST present the warning and impact to the user and receive their explicit approval before passing this token. NEVER auto-confirm — always ask the user first. The token expires after 60 seconds.
signedTransactionHexYesSigned transaction hex to broadcast

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the confirmation/preview gate, the one-time token, and per-chain credit costs. It omits that broadcasting is irreversible once confirmed and doesn't describe the response body, which are notable for a mutation tool with no output schema.

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

Conciseness4/5

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

Purpose and the confirmation caveat are front-loaded, which is correct ordering. The long per-chain credit enumeration is the bulkiest element but is structured and decision-relevant (cost affects tool choice), so it mostly earns its place.

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 no annotations and no output schema, the description covers the critical behavioral facts (confirmation flow, token, credits) that an agent needs before invoking. Remaining gap is the return payload and irreversibility, but the essential invocation context is present.

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 parameters (blockchain, network, signedTransactionHex, context, confirmationToken) are already documented, including the enum value sets. The description's credit table adds cost context tied to the blockchain parameter but no new syntax or format detail. Baseline 3 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?

States a specific verb and resource up front: 'Submit a signed transaction hex to the network,' with the tool name and Broadcast product identified. An agent can immediately tell this is a write/submit operation for pre-signed payloads, not a signing or query tool.

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

Usage Guidelines4/5

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

Explains a crucial usage constraint: broadcast-signed-transaction actions require confirmation and return a preview with a one-time token rather than executing immediately. It also notes supported chains/networks vary. It stops short of naming a concrete alternative tool or stating when-not-to-use, but the two-step flow guidance is clear.

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

system_infoA

CryptoAPIs reference documentation — no API call, no credits consumed.

Actions: • blockchains — Supported blockchains, networks, products per chain, denominations, fiat currencies • errors — Complete error code table (HTTP status, error code, message) • credits — Credit charging structure, cost multipliers per blockchain, monitoring & operations taxes (xPub, synced addresses, blockchain events), pay-as-you-go • callbacks — Webhook mechanics: URL requirements, retry strategy (5 retries, exponential backoff), HMAC security, idempotency • limits — Throughput soft/hard limits per plan, 2.1x penalty multiplier, rate limiting behavior

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesReference topic to retrieve
contextNoOptional context for the request - echoed back in response

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and explicitly notes 'no API call, no credits consumed,' which is key behavioral information. It also discloses detailed content such as retry strategy, HMAC security, and rate-limit penalty multipliers, going well beyond a generic 'returns info' statement.

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 front-loaded with the critical 'no API call, no credits consumed' caveat and uses a compact bullet list. Each bullet covers a distinct action without wasted prose, making it highly scannable for an agent.

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

Completeness5/5

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

For a reference-documentation tool with no output schema and no annotations, this description is complete enough: it defines all five actions and gives sufficient detail about their content. It also clarifies side effects (none) and cost implications (none), covering the main contextual risks.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds significant meaning by explaining each allowed action enum value in detail (e.g., callbacks covers URL requirements, 5 retries, HMAC). This transforms enum names into actionable context and compensates fully beyond the schema's short parameter descriptions.

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 states this is CryptoAPIs reference documentation with no API call or credits consumed, and enumerates five specific topics (blockchains, errors, credits, callbacks, limits). This clearly identifies it as an informational tool distinct from domain siblings like aml.

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

Usage Guidelines4/5

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

The bulleted actions give clear contexts for when to use the tool, such as looking up error codes, credit structures, callback mechanics, or rate limits. It does not explicitly name alternatives or exclusion conditions, so it stops short of a full when/when-not specification.

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.

  1. 2 tool updatesv0.5.0
    • First observedbroadcast_signed_transaction
    • First observedsystem_info
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

A4.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools serve completely distinct purposes: one performs an action (broadcast_signed_transaction) and the other returns static reference documentation (system_info). There is no realistic way to confuse them, so misselection is essentially impossible.

Naming Consistency4/5

Both names use snake_case, which is consistent. However, the conventions differ semantically: one is a verb_noun action name while the other is a noun_phrase reference name, a minor deviation.

Tool Count3/5

Two tools is thin for a server branded as 'Crypto APIs,' even though it is scoped to the Broadcast product. system_info is a generic helper rather than a broadcast operation, so the effective actionable surface is only a single tool.

Completeness3/5

The domain is transaction broadcasting, but there is no way to check broadcast status, query a transaction, or estimate fees—all common follow-ups after submitting a signed hex. Coverage of the core send operation is present but leaves agents at a dead end for verification.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers