여러 LLM API를 한곳에서 액세스하세요. ChatGPT, Claude, DeepSeek, Gemini, Grok, Kimi, Perplexity, Mistral 및 Hugging Face Inference Router를 지능형 모델 선택, 환경 설정 및 프롬프트 로깅 기능과 함께 호출할 수 있습니다.
Cursor 및 Claude Desktop과 같은 AI 코딩 환경을 위해 여러 대규모 언어 모델(LLM) API에 대한 통합 액세스를 제공하는 MCP(Model Context Protocol) 서버입니다.
🌐 9개 LLM 제공업체 – ChatGPT, Claude, DeepSeek, Gemini, Grok, Kimi, Perplexity, Mistral, Hugging Face
🎯 스마트 모델 선택 – 태그 기반 환경 설정 (코딩, 비즈니스, 추론, 수학, 창의적 작업, 일반)
📊 프롬프트 로깅 – 기록, 통계 및 분석을 통해 모든 프롬프트 추적
💰 비용 최적화 – 환경 설정에 따라 플래그십 모델 또는 저렴한 모델 선택
⚡ 간편한 설정 – Cursor에서 클릭 한 번으로 설치하거나 간단한 수동 설정 가능
🔄 모든 LLM 호출 – 모든 제공업체로부터 동시에 응답 받기
Related MCP server: OpenRouter MCP Server
여러 LLM에 액세스할 준비가 되셨나요? 몇 초 만에 설치하세요:
Cursor에 설치 (권장):
또는 수동 설치:
npm install -g cross-llm-mcp
# Or from source:
git clone https://github.com/JamesANZ/cross-llm-mcp.git
cd cross-llm-mcp && npm install && npm run buildcall-chatgpt – OpenAI의 ChatGPT API
call-claude – Anthropic의 Claude API
call-deepseek – DeepSeek API
call-gemini – Google의 Gemini API
call-grok – xAI의 Grok API
call-kimi – Moonshot AI의 Kimi API
call-perplexity – Perplexity AI API
call-mistral – Mistral AI API
call-huggingface – Hugging Face Inference Router (OpenAI 호환 허브 모델)
call-all-llms – 동일한 프롬프트로 모든 LLM 호출
call-llm – 이름으로 특정 제공업체 호출
get-user-preferences – 현재 환경 설정 가져오기
set-user-preferences – 기본 모델, 비용 환경 설정 및 태그 기반 환경 설정 설정
get-models-by-tag – 태그별 모델 찾기 (코딩, 비즈니스, 추론, 수학, 창의적 작업, 일반)
get-prompt-history – 필터를 사용하여 프롬프트 기록 보기
get-prompt-stats – 프롬프트 로그에 대한 통계 가져오기
delete-prompt-entries – 기준에 따라 로그 항목 삭제
clear-prompt-history – 모든 프롬프트 로그 지우기
위의 설치 링크를 클릭하거나 다음을 사용하세요:
cursor://anysphere.cursor-deeplink/mcp/install?name=cross-llm-mcp&config=eyJjcm9zcy1sbG0tbWNwIjp7ImNvbW1hbmQiOiJucHgiLCJhcmdzIjpbIi15IiwiY3Jvc3MtbGxtLW1jcCJdfX0=설치 후 Cursor 설정에서 API 키를 추가하세요 (아래 구성 참조).
요구 사항: Node.js 18+ 및 npm
# Clone and build
git clone https://github.com/JamesANZ/cross-llm-mcp.git
cd cross-llm-mcp
npm install
npm run buildclaude_desktop_config.json에 추가하세요:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"cross-llm-mcp": {
"command": "node",
"args": ["/absolute/path/to/cross-llm-mcp/build/index.js"],
"env": {
"OPENAI_API_KEY": "your_openai_api_key_here",
"ANTHROPIC_API_KEY": "your_anthropic_api_key_here",
"DEEPSEEK_API_KEY": "your_deepseek_api_key_here",
"GEMINI_API_KEY": "your_gemini_api_key_here",
"XAI_API_KEY": "your_grok_api_key_here",
"KIMI_API_KEY": "your_kimi_api_key_here",
"PERPLEXITY_API_KEY": "your_perplexity_api_key_here",
"MISTRAL_API_KEY": "your_mistral_api_key_here",
"HF_TOKEN": "your_huggingface_token_here"
}
}
}
}구성 후 Claude Desktop을 다시 시작하세요.
사용하려는 LLM 제공업체에 대한 환경 변수를 설정하세요:
export OPENAI_API_KEY="your_openai_api_key"
export ANTHROPIC_API_KEY="your_anthropic_api_key"
export DEEPSEEK_API_KEY="your_deepseek_api_key"
export GEMINI_API_KEY="your_gemini_api_key"
export XAI_API_KEY="your_grok_api_key"
export KIMI_API_KEY="your_kimi_api_key"
export PERPLEXITY_API_KEY="your_perplexity_api_key"
export MISTRAL_API_KEY="your_mistral_api_key"
export HF_TOKEN="your_huggingface_token"
# Or: HUGGINGFACE_API_KEY (same as HF_TOKEN)
# Optional: DEFAULT_HUGGINGFACE_MODEL, HUGGINGFACE_INFERENCE_BASE_URL (default https://router.huggingface.co/v1)Anthropic: https://console.anthropic.com/
DeepSeek: https://platform.deepseek.com/
Google Gemini: https://makersuite.google.com/app/apikey
xAI Grok: https://console.x.ai/
Moonshot AI: https://platform.moonshot.ai/
Perplexity: https://www.perplexity.ai/hub
Mistral: https://console.mistral.ai/
Hugging Face: https://huggingface.co/settings/tokens에서 Inference(서버리스 / Inference Providers) 액세스 권한이 있는 세분화된 토큰을 생성하세요. 지원되는 모델은 Chat Completion을 참조하세요.
이 서버는 Hugging Face의 호스팅된 Inference Router를 호출합니다. 가중치를 다운로드하거나 Node 내부에서 PyTorch/GGUF를 실행하지 않습니다. 머신에서 모델을 실행하려면 Ollama, llama.cpp, Text Generation Inference 또는 Hugging Face Inference Endpoints와 같은 도구를 사용한 다음, 해당 서비스가 API를 노출하는 경우 다른 클라이언트를 해당 서비스로 지정하세요.
OpenAI로부터 응답 받기:
{
"tool": "call-chatgpt",
"arguments": {
"prompt": "Explain quantum computing in simple terms",
"temperature": 0.7,
"max_tokens": 500
}
}Inference Router를 통해 허브 모델로부터 응답 받기 (model은 허브 저장소 ID, 예: Qwen/Qwen2.5-7B-Instruct):
{
"tool": "call-huggingface",
"arguments": {
"prompt": "Reply with exactly: ok",
"model": "Qwen/Qwen2.5-7B-Instruct",
"temperature": 0.3,
"max_tokens": 32
}
}모든 제공업체로부터 응답 받기:
{
"tool": "call-all-llms",
"arguments": {
"prompt": "Write a short poem about AI",
"temperature": 0.8
}
}각 작업 유형에 가장 적합한 모델을 자동으로 사용:
{
"tool": "set-user-preferences",
"arguments": {
"defaultModel": "gpt-4o",
"costPreference": "cheaper",
"tagPreferences": {
"coding": "deepseek-r1",
"general": "gpt-4o",
"business": "claude-3.5-sonnet-20241022",
"reasoning": "deepseek-r1",
"math": "deepseek-r1",
"creative": "gpt-4o"
}
}
}프롬프트 로그 보기:
{
"tool": "get-prompt-history",
"arguments": {
"provider": "chatgpt",
"limit": 10
}
}모델은 강점에 따라 태그가 지정됩니다:
코딩: deepseek-r1, deepseek-coder, gpt-4o, claude-3.5-sonnet-20241022
비즈니스: claude-3-opus-20240229, gpt-4o, gemini-1.5-pro
추론: deepseek-r1, o1-preview, claude-3.5-sonnet-20241022
수학: deepseek-r1, o1-preview, o1-mini
창의적 작업: gpt-4o, claude-3-opus-20240229, gemini-1.5-pro
일반: gpt-4o-mini, claude-3-haiku-20240307, gemini-1.5-flash
다각적 분석 – 여러 LLM으로부터 다양한 관점 얻기
모델 비교 – 응답을 비교하여 강점과 약점 파악
비용 최적화 – 각 작업에 가장 비용 효율적인 모델 선택
품질 보증 – 여러 모델의 응답을 교차 참조
지능형 선택 – 코딩, 비즈니스, 추론 등을 위해 자동으로 최적의 모델 사용
프롬프트 분석 – 자동 로깅을 통해 사용량, 비용 및 패턴 추적
빌드 도구: Node.js, TypeScript, MCP SDK
종속성: @modelcontextprotocol/sdk, superagent, zod
플랫폼: macOS, Windows, Linux
환경 설정 저장소:
Unix/macOS: ~/.cross-llm-mcp/preferences.json
Windows: %APPDATA%/cross-llm-mcp/preferences.json
프롬프트 로그 저장소:
Unix/macOS: ~/.cross-llm-mcp/prompts.json
Windows: %APPDATA%/cross-llm-mcp/prompts.json
⭐ 이 프로젝트가 도움이 되었다면 GitHub에서 별을 눌러주세요! ⭐
기여를 환영합니다! 이슈를 열거나 풀 리퀘스트를 제출해 주세요.
MIT 라이선스 – 자세한 내용은 LICENSE.md를 참조하세요.
이 프로젝트가 유용하다고 생각되면 지원을 고려해 주세요:
⚡ Lightning Network
lnbc1pjhhsqepp5mjgwnvg0z53shm22hfe9us289lnaqkwv8rn2s0rtekg5vvj56xnqdqqcqzzsxqyz5vqsp5gu6vh9hyp94c7t3tkpqrp2r059t4vrw7ps78a4n0a2u52678c7yq9qyyssq7zcferywka50wcy75skjfrdrk930cuyx24rg55cwfuzxs49rc9c53mpz6zug5y2544pt8y9jflnq0ltlha26ed846jh0y7n4gm8jd3qqaautqa₿ Bitcoin: bc1ptzvr93pn959xq4et6sqzpfnkk2args22ewv5u2th4ps7hshfaqrshe0xtp
Ξ Ethereum/EVM: 0x42ea529282DDE0AA87B42d9E83316eb23FE62c3f
Decode a Lightning invoice
| Name | Required | Description | Default |
|---|---|---|---|
| invoice | Yes | BOLT11 Lightning invoice |
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 states the action 'decode' but doesn't explain what decoding entails (e.g., extracting payment details, checking validity, or returning structured data). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and output.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. No unnecessary words or redundant information are included.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., decoded fields like amount, timestamp, or destination) or potential errors (e.g., invalid invoice format). For a decoding tool with no structured output documentation, this leaves the agent guessing about results.
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%, with the parameter 'invoice' documented as a 'BOLT11 Lightning invoice'. The description doesn't add any meaning beyond this, such as format examples or validation rules. Since the schema already provides adequate 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'decode' and the resource 'Lightning invoice', making the purpose immediately understandable. It doesn't differentiate from siblings like 'decode_tx' or 'pay_invoice', but the core action is specific enough to understand what the tool does.
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 'decode_tx' or 'validate_address'. It doesn't mention prerequisites, such as needing a valid BOLT11 invoice, or clarify that this is for decoding rather than processing payments (which 'pay_invoice' handles).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a Bitcoin transaction
| Name | Required | Description | Default |
|---|---|---|---|
| rawHex | Yes | Transaction hex |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, if it requires network access, potential rate limits, error conditions, or what the decoded output looks like. The description is functional but lacks context about how the tool behaves.
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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool with one parameter.
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 tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'decode' entails (e.g., parsing inputs/outputs, scripts), the format of the result, or error handling. Given the complexity of Bitcoin transactions and lack of structured context, more completeness is needed.
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 schema description coverage is 100%, with the parameter 'rawHex' fully documented in the schema as 'Transaction hex'. The description adds no additional meaning beyond this, so it meets the baseline for high schema coverage without compensating value.
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 ('decode') and resource ('a Bitcoin transaction'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_transaction' or 'decode_invoice', which prevents 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing raw hex data), exclusions, or comparisons to sibling tools like 'get_transaction' (which might retrieve transaction details differently).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a new Bitcoin key pair and address
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if this requires network connectivity, has rate limits, stores keys securely, or what format the output takes (e.g., public/private keys, address type). This leaves significant gaps for agent understanding.
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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it highly concise and well-structured.
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 complexity of generating cryptographic keys and the lack of annotations and output schema, the description is incomplete. It doesn't explain return values (e.g., key formats), security implications, or error conditions, leaving the agent with insufficient context for safe and effective use.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids discussing parameters, focusing on the tool's purpose. A baseline of 4 is applied as it compensates adequately for the lack of parameters.
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 ('Generate') and the resource ('a new Bitcoin key pair and address'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'validate_address' or 'pay_invoice', which prevents 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.
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 'validate_address' for checking existing addresses or 'pay_invoice' for transactions. It lacks context about prerequisites, such as needing Bitcoin network access or when key generation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest block
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only states the action without details on permissions, rate limits, response format, or potential side effects. For a tool with zero annotation coverage, this is insufficient to inform the agent adequately.
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 extremely concise with a single sentence, 'Get the latest block', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration.
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 lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., block data structure, error handling) or provide context for its use among siblings. For a tool with no structured support, more descriptive content is needed.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate here, but it could have clarified the lack of parameters explicitly. Baseline is 4 due to the absence of parameters.
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 'Get the latest block' clearly states the action (get) and resource (latest block), making the purpose understandable. However, it lacks specificity about what a 'block' refers to in this context (e.g., blockchain block, data block) and does not differentiate from sibling tools like 'get_transaction', leaving room for ambiguity.
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. It does not mention any prerequisites, context, or comparisons to sibling tools such as 'get_transaction' or 'decode_tx', leaving the agent without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction details
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | Transaction ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits such as whether this is a read-only operation, error handling, rate limits, or authentication needs. It mentions 'details' but doesn't specify what those include.
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 extremely concise with 'Get transaction details'—a single, front-loaded sentence that efficiently conveys the core purpose without unnecessary words. However, it may be overly terse for a tool with no annotations or output schema.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what transaction details are returned, error conditions, or how it differs from sibling tools. For a tool with one parameter but no structured context, more information is needed.
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 has 100% description coverage, clearly documenting the 'txid' parameter. The description adds no additional meaning beyond the schema, so it meets the baseline of 3 for adequate but not enhanced parameter semantics.
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 'Get transaction details' states the basic action (get) and resource (transaction details), but it's vague about what specific details are retrieved and doesn't differentiate from sibling tools like 'decode_tx' or 'get_latest_block'. It provides minimal but adequate purpose information.
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 'decode_tx' (which might decode transaction data) or 'get_latest_block' (which retrieves block information). The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pay a Lightning invoice
| Name | Required | Description | Default |
|---|---|---|---|
| invoice | Yes | BOLT11 Lightning invoice |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Pay a Lightning invoice' which implies a financial transaction, but doesn't clarify if this is irreversible, requires authentication, has rate limits, or what happens on success/failure. This is inadequate for a payment tool with zero annotation coverage.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point without unnecessary elaboration.
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 payment tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after payment (success confirmation, error handling), doesn't mention security implications, and provides minimal behavioral context despite the tool's financial nature.
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 has 100% description coverage, with the 'invoice' parameter documented as 'BOLT11 Lightning invoice'. The description doesn't add any additional meaning beyond what the schema provides, such as format examples or validation requirements, so it meets the baseline for high schema coverage.
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 ('Pay') and target resource ('a Lightning invoice'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'decode_invoice' or 'get_transaction', but it's specific enough to understand what the tool does.
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 'decode_invoice' or 'validate_address'. It doesn't mention prerequisites, such as requiring a valid invoice or sufficient balance, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a Bitcoin address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The Bitcoin address to validate |
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. 'Validate' implies a read-only check, but the description doesn't specify what validation entails (format, checksum, network type), whether it requires network connectivity, what happens with invalid inputs, or what the output format will be. This leaves 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?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple validation tool and is perfectly front-loaded.
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 validation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what constitutes validation, what the tool returns (success/failure, validation details, error messages), or how it differs from related sibling tools. The agent would lack critical context to use this tool effectively.
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 schema has 100% description coverage, with the single parameter 'address' clearly documented as 'The Bitcoin address to validate'. The description adds no additional parameter semantics beyond what the schema already provides, so 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('validate') and resource ('Bitcoin address'), making the purpose immediately understandable. However, it doesn't differentiate this validation tool from potential sibling tools that might also validate addresses in different contexts or with different criteria.
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. It doesn't mention whether this is for address format validation, network compatibility checking, or other specific validation contexts, nor does it reference any sibling tools that might serve related purposes.
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.
decode_invoicedecode_txgenerate_keyget_latest_blockget_transactionpay_invoicevalidate_addressScored across 7 tools
Each tool has a clearly distinct purpose targeting specific resources and actions in the Bitcoin/Lightning domain. For example, decode_invoice and pay_invoice handle Lightning payments, while decode_tx and get_transaction handle Bitcoin transactions, with no overlapping functionality that would cause confusion.
All tool names follow a consistent verb_noun pattern using snake_case, such as decode_invoice, generate_key, and validate_address. This uniformity makes the tool set predictable and easy to understand for agents.
With 7 tools, the server is well-scoped for its purpose of Bitcoin and Lightning operations. Each tool serves a specific, necessary function without redundancy, making the count appropriate for the domain's core needs.
The tool set covers key operations like decoding, generating, validating, and paying, but there are minor gaps such as creating invoices or managing wallet balances. However, agents can still perform essential workflows with the provided tools.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
MCP server for building and testing AI agents with multi-model experimentation and insights.
