モデルコンテキストプロトコル（MCP）用のFlowブロックチェーンツール。このパッケージは、モデルコンテキストプロトコルを介してFlowブロックチェーンとやり取りするためのツールセットを提供します。
任意のアドレスのFLOW残高を取得
Flowトークンのトークン残高を取得する
COAアカウント情報を取得する
契約のソースコードを取得する
ストレージ統計を含む詳細なアカウント情報を取得します
Related MCP server: XRPL MCP
# Using npm
npm install @outblock/flow-mcp
# Using bun
bun add @outblock/flow-mcpこのツールを Claude で使用するには、MCP 構成に以下を追加します。
{
"mcpServers": {
"flow": {
"command": "npx",
"args": ["-y", "@outblock/flow-mcp"]
}
}
}MCP 構成は次の場所にあります。
macOS: ~/Library/Application Support/Claude/mcp.json
Windows: %APPDATA%/Claude/mcp.json
Linux: ~/.config/Claude/mcp.json
設定を追加したら、Claude を再起動して新しい MCP サーバーをロードします。
任意のアドレスの FLOW 残高を取得します。
{
name: 'get_flow_balance',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}詳細なアカウント情報を取得します:
{
name: 'get_account_info',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}Flowトークンの残高を取得します:
{
name: 'get_token_balance',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}COA アカウント情報を取得します:
{
name: 'get_coa_account',
input: {
address: string,
network?: 'mainnet' | 'testnet'
}
}契約のソースコードを取得します:
{
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 dependenciesこのプロジェクトでは、開発とテストにFastMCPを使用しています。FastMCPは、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 build開発用 MCP サーバーを Claude Desktop に追加するには:
プロジェクトをビルドします。
bun run buildClaude 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"]
}
}
}このプロジェクトには、新しい MCP ツールの作成に役立つスクリプトが含まれています。
bun run scripts/create-tool.ts <tool-name>これにより、次のようになります。
src/tools/<tool-name>の下に新しいツールディレクトリを作成します。
以下を含む基本的なツール構造を生成します。
index.ts (メイン実装)
schema.ts (ツールパラメータのJSONスキーマ)
test.ts (テストファイル)
新しいツールをエクスポートするためにツールのインデックスファイルを更新します
例：
bun run scripts/create-tool.ts weatherfeat : 新機能 (マイナーバージョンをアップグレード)
fix ：バグ修正（パッチバージョンをアップグレード）
BREAKING CHANGE : 破壊的変更 (メジャーバージョンを上げる)
このプロジェクトでは、自動バージョン管理のためにstandard-versionを使用しています。新しいバージョンを作成するには、 bun run releaseを実行してください。
npm にログインしていることを確認します。
npm loginプロジェクトをビルドします。
bun run buildパッケージを公開します。
npm publish新しいバージョンを公開する前に、 bun run releaseを使用してバージョン番号を更新することを忘れないでください。
MIT ライセンス - 詳細についてはライセンスを参照してください。
貢献を歓迎します！お気軽にプルリクエストを送信してください。
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…