Flow-Blockchain-Tools für das Model Context Protocol (MCP). Dieses Paket bietet eine Reihe von Tools für die Interaktion mit der Flow-Blockchain über das Model Context Protocol.
Erhalten Sie das FLOW-Guthaben für jede Adresse
Erhalten Sie das Token-Guthaben für jedes Flow-Token
COA-Kontoinformationen abrufen
Vertragsquellcode abrufen
Erhalten Sie detaillierte Kontoinformationen einschließlich Speicherstatistiken
Related MCP server: XRPL MCP
# Using npm
npm install @outblock/flow-mcp
# Using bun
bun add @outblock/flow-mcpUm dieses Tool mit Claude zu verwenden, fügen Sie Ihrer MCP-Konfiguration Folgendes hinzu:
{
"mcpServers": {
"flow": {
"command": "npx",
"args": ["-y", "@outblock/flow-mcp"]
}
}
}Ihre MCP-Konfiguration finden Sie unter:
macOS: ~/Library/Application Support/Claude/mcp.json
Windows: %APPDATA%/Claude/mcp.json
Linux: ~/.config/Claude/mcp.json
Starten Sie Claude nach dem Hinzufügen der Konfiguration neu, um den neuen MCP-Server zu laden.
Erhalten Sie den FLOW-Saldo für jede Adresse:
{
name: 'get_flow_balance',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}Erhalten Sie detaillierte Kontoinformationen:
{
name: 'get_account_info',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}Erhalten Sie das Guthaben für jedes Flow-Token:
{
name: 'get_token_balance',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}COA-Kontoinformationen abrufen:
{
name: 'get_coa_account',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}Vertragsquellcode abrufen:
{
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 dependenciesDieses Projekt verwendet FastMCP für Entwicklung und Tests. FastMCP bietet eine optimierte Entwicklungserfahrung für MCP-Server.
# 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 buildSo fügen Sie Ihren Entwicklungs-MCP-Server zu Claude Desktop hinzu:
Erstellen Sie das Projekt:
bun run buildFügen Sie Ihrer Claude Desktop-Konfiguration hinzu:
// 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"]
}
}
}Das Projekt enthält ein Skript zur Unterstützung der Erstellung neuer MCP-Tools:
bun run scripts/create-tool.ts <tool-name>Dies wird:
Erstellen Sie ein neues Tool-Verzeichnis unter src/tools/<tool-name>
Generieren Sie die grundlegende Werkzeugstruktur, einschließlich:
index.ts (Hauptimplementierung)
schema.ts (JSON-Schema für Tool-Parameter)
test.ts (Testdatei)
Aktualisieren Sie die Indexdatei des Tools, um das neue Tool zu exportieren
Beispiel:
bun run scripts/create-tool.ts weatherfeat : Neue Funktion (verbessert Nebenversion)
fix : Fehlerbehebung (verbessert die Patch-Version)
BREAKING CHANGE : Breaking Change (erhöht die Hauptversion)
Dieses Projekt verwendet die Standardversion für die automatisierte Versionsverwaltung. Führen Sie bun run release aus, um eine neue Version zu erstellen.
Stellen Sie sicher, dass Sie bei npm angemeldet sind:
npm loginErstellen Sie das Projekt:
bun run buildVeröffentlichen Sie das Paket:
npm publishDenken Sie daran, die Versionsnummer mit bun run release zu aktualisieren, bevor Sie neue Versionen veröffentlichen.
MIT-Lizenz – Einzelheiten finden Sie unter LIZENZ.
Beiträge sind willkommen! Senden Sie gerne einen Pull Request.
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…