모델 컨텍스트 프로토콜(MCP)을 위한 플로우 블록체인 도구입니다. 이 패키지는 모델 컨텍스트 프로토콜을 통해 플로우 블록체인과 상호 작용하기 위한 도구 세트를 제공합니다.
모든 주소에 대한 FLOW 잔액을 받으세요
모든 Flow 토큰에 대한 토큰 잔액을 얻으세요
COA 계정 정보 받기
계약 소스 코드 가져오기
저장 통계를 포함한 자세한 계정 정보를 얻으세요
Related MCP server: XRPL MCP
지엑스피1
Claude와 함께 이 도구를 사용하려면 MCP 구성에 다음을 추가하세요.
{
"mcpServers": {
"flow": {
"command": "npx",
"args": ["-y", "@outblock/flow-mcp"]
}
}
}MCP 구성은 다음에서 확인할 수 있습니다.
macOS: ~/Library/Application Support/Claude/mcp.json
윈도우: %APPDATA%/Claude/mcp.json
리눅스: ~/.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 buildClaude Desktop에 개발 MCP 서버를 추가하려면:
프로젝트를 빌드하세요:
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…