How do I use MIST.cash 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., "@MIST.cash MCP Server generate a transaction secret for sending 50 USDC to 0x1234abc..." 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.

MIST.cash MCP Server

by joadataarg

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Servidor MCP para MIST.cash SDK

Un servidor del Protocolo de Contexto de Modelo (MCP) que expone la funcionalidad de pagos privados de MIST.cash en Starknet. Este servidor permite a los agentes de IA interactuar con el protocolo de pagos preservadores de privacidad de MIST.cash a través de una interfaz estandarizada.

🌟 Características

5 Herramientas MCP para operaciones de transacción
2 Recursos MCP para información de contratos y transacciones
Privacidad Primero: Aprovecha el sistema de pruebas de conocimiento cero de MIST.cash
Soporte Multi-Token: ETH, USDC, USDT, DAI en Starknet
Listo para Producción: Lógica de reintento, tiempos de espera (timeouts) y manejo integral de errores

Related MCP server: Armor Crypto MCP

📋 Requisitos Previos

Node.js 20 o superior (si se ejecuta localmente)
Docker (recomendado para equipos)
Acceso a un proveedor RPC de Starknet (o Appchain compatible)

🚀 Instalación y Configuración

Opción 1: Docker (Recomendado para el Equipo)

Esta es la forma más sencilla de asegurar que todos en el equipo tengan el mismo entorno.

Construir la imagen:
```
docker build -t mcp-mistcash .
```

Ejecutar con Docker:

Para usarlo con clientes MCP (como Claude Desktop), usarás el comando docker run. Nota la bandera -i que es requerida para la comunicación stdio.

docker run -i --rm \
  -e STARKNET_RPC_URL=https://ztarknet-madara.d.karnot.xyz \
  -e STARKNET_NETWORK=mainnet \
  -e CHAMBER_CONTRACT_ADDRESS=0xTuDireccionDeContrato \
  mcp-mistcash

Opción 2: Desarrollo Local (Node.js)

Clonar e instalar dependencias:
```
cd mcp-mistcash
npm install
```

Configurar variables de entorno:

Crea un archivo .env basado en el ejemplo:

cp .env.example .env

Edita .env con tu configuración (ejemplo para Madara Appchain):

STARKNET_RPC_URL=https://ztarknet-madara.d.karnot.xyz
STARKNET_NETWORK=mainnet
MCP_LOG_LEVEL=info
# Opcional: Dirección del contrato Chamber (Requerido para Madara si no usas Mainnet)
# CHAMBER_CONTRACT_ADDRESS=0x...

Construir el proyecto:
```
npm run build
```

🔌 Integración con Clientes de IA

Para que tu equipo pueda usar estas herramientas en su día a día, deben configurar su cliente de IA preferido.

Claude Desktop

Añade lo siguiente a tu archivo de configuración claude_desktop_config.json:

Ruta del archivo de configuración:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Configuración con Docker (Recomendada)

{
  "mcpServers": {
    "mist-cash": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e", "STARKNET_RPC_URL=https://ztarknet-madara.d.karnot.xyz",
        "-e", "STARKNET_NETWORK=mainnet",
        "mcp-mistcash"
      ]
    }
  }
}

Configuración Local (Alternativa)

{
  "mcpServers": {
    "mist-cash": {
      "command": "node",
      "args": ["/ruta/absoluta/a/mcp-mistcash/dist/index.js"],
      "env": {
        "STARKNET_RPC_URL": "https://ztarknet-madara.d.karnot.xyz",
        "STARKNET_NETWORK": "mainnet"
      }
    }
  }
}

Cursor IDE

Añade esto a tus configuraciones de MCP en Cursor:

{
  "mist-cash": {
    "command": "docker",
    "args": [
        "run",
        "-i",
        "--rm",
        "-e", "STARKNET_RPC_URL=https://ztarknet-madara.d.karnot.xyz",
        "-e", "STARKNET_NETWORK=mainnet",
        "mcp-mistcash"
    ]
  }
}

🛠️ Herramientas Disponibles

1. `generar_secreto_transaccion`

Genera un secreto criptográfico para una transacción privada.

Parámetros:

claiming_key (string, requerido): Clave de reclamación para la transacción
recipient_address (string, requerido): Dirección Starknet (0x...)

2. `obtener_assets_transaccion`

Obtiene los activos de una transacción.

⚠️ ADVERTENCIA: Esta función muestra activos incluso si ya han sido gastados. Usa verificar_existencia_transaccion para una verificación precisa.

Parámetros:

transaction_key (string, requerido): Clave de la transacción a consultar
recipient_address (string, requerido): Dirección Starknet del receptor
provider_rpc_url (string, opcional): URL RPC personalizada

3. `verificar_existencia_transaccion`

Verifica si existe una transacción con activos específicos. Ideal para transacciones completamente privadas.

Parámetros:

claiming_key (string, requerido): Clave de reclamación
recipient (string, requerido): Dirección del receptor
token_address (string, requerido): Dirección del contrato del token
amount (string, requerido): Cantidad en unidades base (wei)

4. `calcular_hash_transaccion`

Calcula el hash único de una transacción.

Parámetros:

transaction_key (string, requerido): Clave de la transacción
recipient_address (string, requerido): Dirección del receptor
token_address (string, requerido): Dirección del token
amount (string, requerido): Cantidad en unidades base

5. `obtener_configuracion_chamber`

Obtiene la configuración del contrato Chamber y los tokens soportados.

Parámetros:

network (enum, opcional): "mainnet" o "sepolia" (por defecto: "mainnet")

📚 Recursos Disponibles

`chamber://contract-info`

Información estática sobre el contrato Chamber de MIST.cash, incluyendo ABI, direcciones y características.

`chamber://tx/{txHash}`

Detalles para una transacción específica por hash.

🔒 Consideraciones de Seguridad

✅ Prácticas Seguras

Sin Claves Privadas: Solo se manejan claves de reclamación (públicas)
Validación de Direcciones: Todas las direcciones Starknet son validadas
Logging Seguro: Los secretos de las transacciones nunca se registran en los logs
Validación de Entrada: Esquemas Zod validan todas las entradas

⚠️ Advertencias Importantes

Transacciones Gastadas: obtener_assets_transaccion no detecta activos gastados
Costos RPC: Monitorea el uso del RPC para evitar costos inesperados
Retrasos de Red: Timeout de 30 segundos en todas las llamadas al contrato

🏗️ Estructura del Proyecto

mcp-mistcash/
├── src/
│   ├── index.ts                 # Servidor MCP principal
│   ├── types.ts                 # Definiciones de tipos TypeScript
│   ├── tools/                   # Implementación de herramientas
│   ├── resources/               # Recursos MCP
│   └── utils/                   # Utilidades (provider, validación)
├── Dockerfile                   # Configuración para construir la imagen Docker
├── package.json
├── tsconfig.json
├── .env.example
└── README.md

🤝 Contribuciones

Las contribuciones son bienvenidas. Por favor asegúrate de:

Que todas las herramientas tengan manejo de errores adecuado
Los esquemas Zod validen las entradas
El código siga las mejores prácticas de TypeScript
La documentación esté actualizada

📄 Licencia

MIT

Construido con ❤️ para las comunidades de Starknet y MCP

Available Tools

5 tools

calcular_hash_transaccionC

Calculate the unique hash of a transaction using transaction parameters.

ParametersJSON Schema

Name	Required	Description
`transaction_key`	Yes	Transaction key
`recipient_address`	Yes	Starknet address of the recipient
`token_address`	Yes	Token contract address
`amount`	Yes	Amount in base units (wei)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic function without details on traits like computational cost, error conditions, or output format. For a tool with no annotations, this is inadequate as it misses critical behavioral context.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It is appropriately sized and front-loaded, making it easy to understand quickly.

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

Completeness2/5

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

Given the complexity (4 required parameters) and lack of annotations and output schema, the description is incomplete. It does not explain the hash algorithm, output format, or potential errors, leaving significant gaps for the agent to understand the tool fully.

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

Parameters3/5

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

The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional meaning beyond the schema, such as explaining how parameters interact or their role in hash calculation. Baseline is 3 when schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('Calculate') and the target ('unique hash of a transaction'), which is specific and understandable. However, it does not explicitly differentiate from sibling tools like 'verificar_existencia_transaccion' or 'generar_secreto_transaccion', which might involve related transaction operations, so it lacks sibling differentiation for a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, such as when to choose this over sibling tools like 'verificar_existencia_transaccion' for hash verification. This leaves the agent without usage direction.

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

generar_secreto_transaccionC

Generate a transaction secret for private payments. Creates a cryptographic secret using a claiming key and recipient address.

ParametersJSON Schema

Name	Required	Description	Default
`claiming_key`	Yes	Claiming key for the transaction
`recipient_address`	Yes	Starknet address of the recipient (must start with 0x)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states 'Creates a cryptographic secret' which implies a write operation, but lacks details on permissions, side effects, rate limits, or response format. For a tool that likely involves sensitive data (transaction secrets), this is a significant gap in behavioral disclosure.

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 concise and front-loaded with the main purpose in the first sentence. Both sentences are relevant, with no wasted words. However, it could be slightly more structured by separating usage context from parameter mentions.

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

Completeness2/5

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

Given no annotations, no output schema, and a tool that creates cryptographic secrets (likely a mutation with security implications), the description is incomplete. It doesn't cover error conditions, return values, or important behavioral traits like whether the secret is stored or transient. For this complexity level, 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 description coverage is 100%, so the schema already documents both parameters ('claiming_key' and 'recipient_address'). The description adds minimal value by mentioning these parameters in context ('using a claiming key and recipient address'), but doesn't provide additional semantics beyond what the schema offers. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Generate a transaction secret for private payments' specifies the verb (generate) and resource (transaction secret) with context (private payments). It distinguishes from siblings like 'calcular_hash_transaccion' (calculate hash) and 'verificar_existencia_transaccion' (verify existence) by focusing on secret generation, though it doesn't explicitly contrast them.

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

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. The description mentions 'private payments' as context but doesn't specify prerequisites, conditions, or comparisons to sibling tools like 'obtener_assets_transaccion' (get transaction assets). Without explicit when/when-not instructions, usage is implied but not well-defined.

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

obtener_assets_transaccionA

Fetch assets from a transaction. WARNING: This shows assets even if already spent. Use verificar_existencia_transaccion for accurate verification.

ParametersJSON Schema

Name	Required	Description
`transaction_key`	Yes	Transaction key to query
`recipient_address`	Yes	Starknet address of the recipient
`provider_rpc_url`	No	Optional custom Starknet RPC URL

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and discloses key behavioral traits: it warns that assets may be shown even if already spent, which is crucial for understanding the tool's limitations. However, it doesn't cover other aspects like rate limits or authentication needs, leaving some gaps.

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

Conciseness5/5

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

The description is front-loaded with the main purpose and includes a critical warning in a second sentence, with zero wasted words. Every sentence earns its place by providing essential information efficiently.

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

Completeness3/5

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

Given the complexity (a fetch operation with a warning), no annotations, and no output schema, the description is adequate but has clear gaps: it explains the purpose and usage well but lacks details on return values or error handling, making it minimally viable for the context.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters. The description doesn't add any meaning beyond what the schema provides, such as explaining how 'transaction_key' and 'recipient_address' relate to fetching assets, but it doesn't need to compensate for low coverage.

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

Purpose4/5

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

The description clearly states the verb 'fetch' and resource 'assets from a transaction', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'verificar_existencia_transaccion' beyond mentioning it as an alternative for verification, so it's not fully sibling-aware.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool vs. alternatives: it includes a WARNING about showing assets even if spent and directly names 'verificar_existencia_transaccion' for accurate verification, offering clear context and exclusions.

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

obtener_configuracion_chamberB

Get Chamber contract configuration including contract address, network, and supported tokens.

ParametersJSON Schema

Name	Required	Description	Default
`network`	No	Starknet network	mainnet

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), but doesn't cover aspects like authentication needs, rate limits, error conditions, or what happens if the configuration isn't found. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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?

The description is a single, efficient sentence that front-loads the purpose and specifies the retrieved data. There is no wasted language or redundancy, making it appropriately sized for the tool's complexity.

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

Completeness3/5

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

Given the tool has one parameter with full schema coverage and no output schema, the description is adequate but incomplete. It explains what configuration is retrieved but doesn't cover behavioral aspects like error handling or response format. For a read-only tool with minimal parameters, it meets basic needs but lacks depth for robust agent use.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the single parameter ('network') with its type, enum values, and default. The description mentions 'network' as part of the retrieved configuration but doesn't add syntax, format, or usage details beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate.

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

Purpose4/5

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

The description clearly states the action ('Get') and the resource ('Chamber contract configuration'), specifying what information is retrieved (contract address, network, and supported tokens). It distinguishes from siblings by focusing on configuration retrieval rather than transaction-related operations, though it doesn't explicitly name alternatives.

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. The description doesn't mention prerequisites, context for retrieving configuration, or differentiate from potential sibling tools that might handle similar data. Usage is implied only by the tool's name and description.

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

verificar_existencia_transaccionB

Verify if a transaction exists with specific assets. For fully private transactions where assets are not publicly visible.

ParametersJSON Schema

Name	Required	Description
`claiming_key`	Yes	Claiming key for the transaction
`recipient`	Yes	Starknet address of the recipient
`token_address`	Yes	Token contract address (e.g., ETH, USDC)
`amount`	Yes	Amount in base units (wei)
`provider_rpc_url`	No	Optional custom Starknet RPC URL

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions verifying existence for private transactions, but doesn't explain what 'verify' entails (e.g., returns a boolean, error handling, network calls), authentication needs, rate limits, or side effects. For a tool with no annotations and potential complexity (private transactions), this is a significant gap, though it at least hints at the context.

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 concise with two sentences that directly state the purpose and context. It's front-loaded with the main action and avoids unnecessary details. However, it could be slightly more structured by explicitly separating usage guidance, but overall it's efficient with zero waste.

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

Completeness2/5

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

Given the tool's complexity (verifying private transactions), no annotations, no output schema, and 100% schema coverage, the description is incomplete. It lacks details on what the tool returns, error conditions, or behavioral traits, leaving gaps for an AI agent to understand how to use it effectively. The schema covers inputs, but the overall context is insufficient.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no specific meaning beyond the schema (e.g., it doesn't explain relationships between parameters like 'claiming_key' and 'recipient'). Baseline is 3 when schema does the heavy lifting, as the description doesn't compensate with additional insights.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Verify if a transaction exists with specific assets.' It specifies the verb (verify) and resource (transaction with assets), and distinguishes it from siblings by mentioning 'fully private transactions where assets are not publicly visible,' which suggests a unique use case. However, it doesn't explicitly differentiate from all siblings (e.g., 'obtener_assets_transaccion' might be related), so it's not a perfect 5.

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 'fully private transactions where assets are not publicly visible,' providing some context. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'obtener_assets_transaccion' or other siblings), nor does it mention prerequisites or exclusions. The guidance is present but limited to an implied scenario.

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

Install Server

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

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: calcular_hash_transaccion computes a transaction hash, generar_secreto_transaccion creates a cryptographic secret, obtener_assets_transaccion fetches assets, obtener_configuracion_chamber retrieves contract configuration, and verificar_existencia_transaccion verifies transaction existence. The descriptions explicitly differentiate their functions, preventing agent misselection.

Naming Consistency5/5

All tool names follow a consistent Spanish verb_noun pattern (e.g., calcular_hash_transaccion, generar_secreto_transaccion) using snake_case throughout. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.

Tool Count5/5

With 5 tools, this server is well-scoped for its apparent domain of transaction and contract operations in MIST.cash. Each tool serves a specific, non-trivial function, and the count is neither too sparse nor bloated, fitting typical expectations for a focused MCP server.

Completeness4/5

The tool set covers core transaction operations (hash calculation, secret generation, asset fetching, existence verification) and contract configuration retrieval, providing a solid foundation. A minor gap exists in lacking tools for creating or modifying transactions, but agents can likely work around this for basic query and verification tasks.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

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

SwapWizard A
io.github.DeFiRe-business
Non-custodial DeFi for AI agents: swaps, concentrated liquidity (V3/V4) zaps + ranges, 5 EVM chains
Blockchain Cryptocurrency
1127
MIDAS Protocol C
io.github.BbrainFrance
Complete financial infrastructure for AI agents — payments, lending, escrow & more.
Finance Payments & Billing
2
Tollbooth Swap API A
xyz.tollboothswap.api
Token swaps and honeypot/rug checks for AI agents on 8 chains, paid per-call in USDC via x402.
Cryptocurrency Blockchain Web3 & Decentralized Tech
611
Blixtworks A
com.blixtworks.www
63 pay-per-call tools for agents: vision, text, data, web, blockchain. USDC on Base via x402.
Blockchain Cryptocurrency AI & Machine Learning
681

Related MCP Servers

Snak
Developer Tools Cloud Platforms
KasarLabs
A
license
Not graded
quality
D
maintenance
Build powerful and secure AI agents powered by Starknet.
Updated 10 months ago (2025-10-31 13:57 UTC)
2
96
MIT
Armor Crypto MCP
Cryptocurrency Blockchain Web3 & Decentralized Tech
emmaThompson07
A
license
C
quality
D
maintenance
Enables AI agents to interact with cryptocurrency ecosystems through wallet management, trading operations (swaps, DCA, limit orders), staking, and multi-chain support starting with Solana.
Updated a year ago (2025-09-26 02:22 UTC)
37
GPL 3.0
AgentBTC MCP Server
Blockchain Cryptocurrency Web3 & Decentralized Tech
bkblocksolutions-rgb
A
license
A
quality
D
maintenance
Enables AI agents to perform Bitcoin and Lightning Network payments using a non-custodial, zero-trust architecture. It provides 13 tools for wallet management, invoice creation, and payment processing while keeping node credentials local to the user's machine.
Updated 6 months ago (2026-02-20 03:36 UTC)
13
17
MIT
remit.md MCP Server
Finance Autonomous Agents Blockchain
pay-skill
A
license
Not graded
quality
F
maintenance
Enables AI agents to perform financial transactions such as direct payments, escrows, and bounty management using natural language with zero code integration. It provides a comprehensive suite of tools for fund streaming, subscriptions, and reputation tracking to facilitate secure agent-to-agent commerce.
Updated 5 months ago (2026-04-07 19:51 UTC)
22
MIT

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/joadataarg/Mcp-mistcash'

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

Servidor MCP para MIST.cash SDK

🌟 Características

📋 Requisitos Previos

🚀 Instalación y Configuración

Opción 1: Docker (Recomendado para el Equipo)

Opción 2: Desarrollo Local (Node.js)

🔌 Integración con Clientes de IA

Claude Desktop

Configuración con Docker (Recomendada)

Configuración Local (Alternativa)

Cursor IDE

🛠️ Herramientas Disponibles

1. generar_secreto_transaccion

2. obtener_assets_transaccion

3. verificar_existencia_transaccion

4. calcular_hash_transaccion

5. obtener_configuracion_chamber

📚 Recursos Disponibles

chamber://contract-info

chamber://tx/{txHash}

🔒 Consideraciones de Seguridad

✅ Prácticas Seguras

⚠️ Advertencias Importantes

🏗️ Estructura del Proyecto

🤝 Contribuciones

📄 Licencia

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `generar_secreto_transaccion`

2. `obtener_assets_transaccion`

3. `verificar_existencia_transaccion`

4. `calcular_hash_transaccion`

5. `obtener_configuracion_chamber`

`chamber://contract-info`

`chamber://tx/{txHash}`