Herramientas de la cadena de bloques Flow para el Protocolo de Contexto de Modelo (MCP). Este paquete proporciona un conjunto de herramientas para interactuar con la cadena de bloques Flow a través del Protocolo de Contexto de Modelo.
Obtenga el saldo de FLOW para cualquier dirección
Obtenga saldo de tokens para cualquier token de Flow
Obtener información de la cuenta COA
Obtener el código fuente del contrato
Obtenga información detallada de la cuenta, incluidas las estadísticas de almacenamiento
Related MCP server: XRPL MCP
# Using npm
npm install @outblock/flow-mcp
# Using bun
bun add @outblock/flow-mcpPara utilizar esta herramienta con Claude, agregue lo siguiente a su configuración de MCP:
{
"mcpServers": {
"flow": {
"command": "npx",
"args": ["-y", "@outblock/flow-mcp"]
}
}
}Puede encontrar la configuración de su MCP en:
macOS: ~/Library/Application Support/Claude/mcp.json
Ventanas: %APPDATA%/Claude/mcp.json
Linux: ~/.config/Claude/mcp.json
Después de agregar la configuración, reinicie Claude para cargar el nuevo servidor MCP.
Obtenga el saldo de FLOW para cualquier dirección:
{
name: 'get_flow_balance',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}Obtenga información detallada de la cuenta:
{
name: 'get_account_info',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}Obtenga saldo para cualquier token de Flow:
{
name: 'get_token_balance',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}Obtener información de la cuenta COA:
{
name: 'get_coa_account',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}Obtener el código fuente del contrato:
{
name: 'get_contract',
input: {
address: string,
contractName: string,
network?: 'mainnet' | 'testnet'
}
}flow-mcp/
├── src/
│ ├── tools/ # MCP tools implementation
│ │ ├── flowBalance/ # Flow balance tool
│ │ ├── accountInfo/ # Account info tool
│ │ ├── tokenBalance/ # Token balance tool
│ │ ├── coaAccount/ # COA account tool
│ │ └── getContract/ # Contract source tool
│ ├── utils/ # Shared utilities
│ ├── prompts/ # MCP prompts
│ ├── types/ # Type definitions
│ └── bin/ # CLI implementation
├── biome.json # Linting configuration
├── tsconfig.json # TypeScript configuration
└── package.json # Project dependenciesEste proyecto utiliza FastMCP para el desarrollo y las pruebas. FastMCP proporciona una experiencia de desarrollo optimizada para servidores MCP.
# Install dependencies
bun install
# Format code
bun run format
# Run tests
bun test
# Run development server
bun run dev
# Inspect the server
bun run inspect
# Build
bun run buildPara agregar su servidor MCP de desarrollo a Claude Desktop:
Construir el proyecto:
bun run buildAñade a tu configuración de Claude Desktop:
// You only need the argument if you need to pass arguments to your server
{
"mcpServers": {
"your-server-name": {
"command": "node",
"args": ["/path/to/your/project/dist/main.js", "some_argument"]
}
}
}El proyecto incluye un script para ayudar a crear nuevas herramientas MCP:
bun run scripts/create-tool.ts <tool-name>Esto hará lo siguiente:
Cree un nuevo directorio de herramientas en src/tools/<tool-name>
Genere la estructura básica de la herramienta incluyendo:
index.ts (implementación principal)
schema.ts (esquema JSON para parámetros de herramientas)
test.ts (archivo de prueba)
Actualice el archivo de índice de herramientas para exportar la nueva herramienta
Ejemplo:
bun run scripts/create-tool.ts weatherfeat : Nueva característica (mejora versión menor)
fix : Corrección de errores (versión del parche de mejoras)
BREAKING CHANGE : Cambio radical (incrementa la versión principal)
Este proyecto utiliza la versión estándar para la gestión automatizada de versiones. Ejecute bun run release para crear una nueva versión.
Asegúrese de haber iniciado sesión en npm:
npm loginConstruir el proyecto:
bun run buildPublicar el paquete:
npm publishRecuerde actualizar el número de versión utilizando bun run release antes de publicar nuevas versiones.
Licencia MIT: consulte LICENCIA para obtener más detalles.
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Get detailed account information including balance and storage stats for a Flow address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Flow address to check account information for | |
| network | No | Flow network to use | mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool retrieves information, but lacks details on potential side effects, authorization, or rate limits. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should fully describe return values. It mentions 'balance and storage stats' but 'detailed' is vague. The sibling tools suggest a more comprehensive response, but this is not clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with descriptions for both parameters. The description adds context by mentioning 'balance and storage stats', but this does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'detailed account information', specifying balance and storage stats. It distinguishes from siblings like get_flow_balance (specific balance) and get_coa_account (different type of account).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_flow_balance or get_token_balances. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the COA account information for a Flow address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Flow address to check COA account for | |
| network | No | Flow network to use | mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but only states 'Get' implying read-only. It does not disclose permissions, error behavior, or any side effects, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 params, no output schema), the description should explain what COA is and what information is returned. It does neither, leaving the agent uncertain about the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, which already detail 'address' and 'network'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'COA account information' for a Flow address, but fails to explain what COA stands for or how it differs from siblings like get_account_info, which reduces clarity for effective tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool vs alternatives, nor any prerequisites or context. The description does not help an agent decide between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the source code of a contract deployed at a specific address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Flow address where the contract is deployed | |
| network | No | Flow network to use | mainnet |
| contractName | Yes | Name of the contract to fetch |
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 authentication requirements, rate limits, or side effects. The lack of any behavioral context beyond the basic function is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence of 13 words with no unnecessary information. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with complete parameter descriptions, the description is minimally adequate. However, it does not describe the return format or potential error conditions, which could be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no semantic value beyond what is in the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'source code of a contract', and the deployment context 'at a specific address'. This distinctly separates it from sibling tools that deal with account info, balances, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidelines, but the tool's purpose is clear from the name and description. No when-not-to-use or alternatives are provided, so agents must infer context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the FLOW balance for a Flow address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Flow address to check balance for | |
| network | No | Flow network to use | mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral traits such as safety (read-only) or any side effects. It merely restates the action without adding context beyond the schema, which is insufficient for a tool with no annotation aid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It efficiently communicates the tool's purpose without redundancy, preserving clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should clarify the return format (e.g., balance as a string in smallest units). It omits this detail, leaving agents uncertain about the response structure for a fundamentally simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description coverage is 100%, with adequate descriptions for both parameters. The tool's description adds no extra meaning or usage details beyond what the schema already provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), resource ('FLOW balance'), and scope ('for a Flow address'). It effectively distinguishes from sibling tools like get_token_balances, which handle other token types, making the tool's specific role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing the native token balance on Flow but provides no explicit guidance on when to avoid this tool or alternatives. It lacks comparative context with sibling tools, leaving the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the balances of all fungible tokens for a Flow address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Flow address to check balance for | |
| network | No | Flow network to use | mainnet |
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 pagination, rate limits, or whether the tool requires specific permissions. It only states the basic 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with two parameters, the description does not mention the return format or that it returns a list of balances. For a basic tool, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no extra semantic context 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'balances of all fungible tokens', and the scope 'for a Flow address'. It distinguishes from siblings like 'get_flow_balance' by specifying 'all fungible tokens'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_flow_balance' or 'get_account_info'. The description lacks context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_account_infoget_coa_accountget_contractget_flow_balanceget_token_balancesScored across 5 tools
There is overlap between get_account_info and get_flow_balance, as account info includes balance. Additionally, get_token_balances may overlap with the balance portion of account info. However, the descriptions provide some distinction.
All tools follow the consistent verb_noun pattern with 'get_' prefix, making them predictable and easy to understand.
5 tools is well-scoped for a read-only Flow blockchain information server. Each tool addresses a distinct query need without being overwhelming.
The set covers essential read operations for Flow accounts (balance, tokens, contracts, COA). Minor gaps exist such as missing block info or non-fungible token queries, but core functionality is present.
Safety-first EVM and Bitcoin RPC tools for balances, contracts, blocks, and transactions
Non-custodial Solana toolkit: rug-checks, swaps, portfolios, token minting, multisig, Arweave.
Paid, source-backed wallet and API checks. Prepaid tools; free discovery. Never signs transactions.
Provide AI agents and automation tools with contextual access to blockchain data including balance…