Provides tools for inspecting Coinbase accounts, holdings, and cryptocurrency prices through the Coinbase Advanced Trade API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CryptoPilot MCP What's the price of Bitcoin?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🌐 English | Español
A read-only MCP server that brings your crypto and brokerage portfolio into Claude Desktop.
CryptoPilot MCP connects Claude Desktop to your Coinbase and SnapTrade portfolio data through the Model Context Protocol (MCP). It gives developers and power users a local-first way to inspect accounts, holdings, prices, and provider health without building a custom integration from scratch. The server is read-only by design: it does not trade, transfer funds, or expose transaction actions.
Two providers: Coinbase Advanced Trade and SnapTrade for brokerage aggregation.
Five MCP tools: list_providers, list_accounts, list_holdings, get_quote, and get_provider_health.
Read-only by design: no trading, no transfers, and no transactions tool.
Type-safe TypeScript with Zod validation for MCP schemas and environment configuration.
Automatic retry with backoff for 429 and 5xx responses.
Local-first: no telemetry, no external servers, and no cloud dependencies operated by this project.
Related MCP server: QuantPlay MCP Server
Node.js 18+
Claude Desktop: download Claude
Coinbase account (optional) and/or SnapTrade account (optional)
git clone https://github.com/cryptopilot-tools/cryptopilot-mcp.git
cd cryptopilot-mcp
npm install
npm run buildConfigure Claude Desktop as described below.
Go to Coinbase API settings.
Create a new API key with View permissions only. Do not enable trading permissions.
Allow all accounts you want to analyze.
Save the API Key Name and Private Key.
Sign up at SnapTrade.
Create a client in the SnapTrade dashboard.
Save the Client ID and Consumer Key.
Create a user, then save the User ID and User Secret.
Edit your Claude Desktop config at:
~/Library/Application Support/Claude/claude_desktop_config.jsonAdd the mcpServers entry below. Replace every REPLACE_ME value and update the server path to the absolute path on your machine.
{
"mcpServers": {
"cryptopilot": {
"command": "node",
"args": ["/absolute/path/to/cryptopilot-mcp/dist/server.js"],
"env": {
"COINBASE_API_KEY_NAME": "REPLACE_ME",
"COINBASE_API_PRIVATE_KEY": "REPLACE_ME",
"SNAPTRADE_CLIENT_ID": "REPLACE_ME",
"SNAPTRADE_CONSUMER_KEY": "REPLACE_ME",
"SNAPTRADE_USER_ID": "REPLACE_ME",
"SNAPTRADE_USER_SECRET": "REPLACE_ME",
"SNAPTRADE_DEFAULT_ACCOUNT_ID": "REPLACE_ME"
}
}
}
}Restart Claude Desktop after saving the file.
list_providersReturns configured providers and their capabilities.
Example input:
{}Example output:
{
"providers": [
{
"id": "coinbase",
"displayName": "Coinbase",
"capabilities": {
"accounts": true,
"holdings": true,
"transactions": false,
"quotes": true
}
}
]
}list_accountsReturns accounts, optionally filtered by provider.
Example input:
{
"provider": "snaptrade"
}Example output:
{
"accounts": [
{
"id": "snaptrade:account-id",
"provider": "snaptrade",
"name": "Robinhood Individual",
"type": "brokerage",
"balance": {
"amount": 1000,
"currency": "USD"
}
}
]
}list_holdingsReturns holdings for a provider account. Requires provider and accountId.
Example input:
{
"provider": "coinbase",
"accountId": "coinbase:account-id"
}Example output:
{
"holdings": [
{
"symbol": "BTC",
"quantity": 0.05,
"price": {
"amount": 80000,
"currency": "USD"
},
"marketValue": {
"amount": 4000,
"currency": "USD"
}
}
]
}get_quoteReturns a current price for a symbol. Requires provider and symbol; SnapTrade quotes also require an accountId unless a default account is configured.
Example input:
{
"provider": "coinbase",
"symbol": "BTC"
}Example output:
{
"quote": {
"symbol": "BTC-USD",
"provider": "coinbase",
"price": {
"amount": 80000,
"currency": "USD"
},
"asOf": "2026-01-01T00:00:00.000Z"
}
}get_provider_healthReturns health and configuration status for each provider.
Example input:
{}Example output:
{
"health": [
{
"ok": true,
"provider": "coinbase",
"checkedAt": "2026-01-01T00:00:00.000Z",
"details": {
"transport": "http-fetch"
}
}
]
}Claude Desktop
│ (MCP stdio)
↓
cryptopilot-mcp server
│
↓
BaseProvider (abstract)
│ │
↓ ↓
CoinbaseProvider SnapTradeProvider
│ │
↓ ↓
Coinbase API SnapTrade APIThe server runs over MCP stdio and exposes provider-neutral tools to Claude Desktop. Each provider implements the shared BaseProvider abstraction, then normalizers convert provider-specific responses into canonical account, holding, and quote types. Zod schemas validate MCP tool inputs and outputs at the server boundary.
Read-only API keys are strongly recommended. Do not enable trading permissions.
.env.local is never committed and is covered by .gitignore.
No telemetry, no analytics, and no external servers are operated by this project.
Credentials are stored only on your local machine in Claude Desktop configuration or local environment files.
See SECURITY.md for vulnerability reporting.
Coinbase + SnapTrade providers
5 core MCP tools
Transactions tool
More providers based on user demand (Alpaca, IBKR direct, etc.)
CI/CD pipeline
npm package publication
Anthropic Directory submission
Contributions are welcome, especially provider integrations, reliability improvements, and documentation fixes. See CONTRIBUTING.md before opening a pull request.
Disclaimer: CryptoPilot is an independent open-source project. It is not affiliated with, endorsed by, or sponsored by Anthropic, Coinbase, SnapTrade, or any brokerage. This software does not provide financial advice. Use at your own risk and consult a licensed financial advisor for investment decisions.
MIT — see LICENSE
Check health for one configured provider or all configured providers.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Optional provider id such as coinbase or snaptrade. |
| Name | Required | Description |
|---|---|---|
| health | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as side effects, permissions, rate limits, or what 'health' entails (e.g., status codes). Minimal transparency.
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?
Single sentence that is front-loaded and contains no extraneous information. Perfectly concise for a simple tool.
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?
Output schema is present, so return value documentation is not needed. Description adequately covers tool purpose and parameter, though it could clarify what 'health' means. Adequate for a straightforward check.
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 a description for the single parameter. Description adds examples ('such as coinbase or snaptrade'), providing extra clarity beyond 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?
Description clearly states verb ('Check health') and resource ('provider'), and specifies scope ('one configured provider or all configured providers'). It is distinct from siblings like get_quote or list_providers.
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?
Description implies usage for checking health of providers but does not explicitly state when to use versus alternatives or when not to use. It lacks usage context beyond the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a canonical market quote for a symbol from a configured provider.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Provider id such as coinbase or snaptrade. | |
| symbol | Yes | Ticker or asset symbol, for example BTC or AAPL. | |
| accountId | No | Optional canonical account id. Required by providers like SnapTrade for quotes. |
| Name | Required | Description |
|---|---|---|
| quote | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It suggests a read-only operation ('get a canonical market quote'), which implies no side effects. However, it does not mention potential behaviors like rate limits or authentication requirements. The clarity on the core action is sufficient for this simple tool.
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?
Single sentence of 12 words, concise and front-loaded. No wasted words, every part 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?
Given the presence of an output schema and full schema coverage, the description is adequate for a simple read tool. It lacks elaboration on 'canonical' or provider specifics, but overall completeness is high for the tool's complexity.
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%, and the description adds no additional meaning beyond the schema's parameter descriptions. Baseline of 3 is appropriate as the schema handles parameter semantics adequately.
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 the action (Get), resource (market quote), and context (for a symbol from a configured provider). It distinguishes from sibling tools like get_provider_health, list_accounts, etc., which serve different purposes.
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?
Description does not provide explicit guidance on when to use this tool versus alternatives. The schema hints at optional accountId required by some providers, but the description itself lacks when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List canonical accounts from one configured provider or all configured providers.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Optional provider id such as coinbase or snaptrade. |
| Name | Required | Description |
|---|---|---|
| accounts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that accounts are 'canonical' but does not discuss authentication, rate limits, or other behavioral traits.
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, effectively front-loading the key information.
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?
The description is fairly complete given the simple parameter and presence of an output schema. It covers the tool's core function without needing to detail return values.
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 description adds value beyond the schema by explaining the optional 'provider' parameter with examples (coinbase, snaptrade), enhancing understanding of its use.
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 'list' and the resource 'canonical accounts', and distinguishes between listing from one provider or all providers, differentiating it from siblings like list_providers.
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 usage for listing accounts but does not provide explicit guidance on when to use vs. alternatives, nor does it mention when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List canonical holdings for an account from a configured provider.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Provider id such as coinbase or snaptrade. | |
| accountId | Yes | Canonical account id like coinbase:uuid or snaptrade:account-id. |
| Name | Required | Description |
|---|---|---|
| holdings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It does not mention if the list is paginated, rate-limited, or what 'canonical' entails. The brevity leaves the agent uninformed about important behavioral aspects.
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-formed sentence front-loading the core action. Every word earns its place without redundancy.
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 presence of an output schema, return values need not be explained. However, the description omits context about what 'canonical' means or how the provider is configured. For a simple listing tool, it is minimally adequate but not fully complete.
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%, so the schema already describes the parameters. The description adds little beyond restating the context of provider and account. Baseline 3 is appropriate as no extra value is provided.
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 ('List') and the resource ('canonical holdings for an account from a configured provider'), which distinguishes it from sibling tools like list_accounts or get_quote. The verb and resource are specific and 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?
No explicit guidance on when to use this tool vs alternatives. The context of sibling tools suggests this is for holdings, but the description does not mention when not to use it or any prerequisites. The usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured portfolio data providers and their capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| providers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are present, the description clearly indicates a read-only listing operation ('List... providers and their capabilities'), which is transparent for a tool with no parameters and no side effects.
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?
A single sentence that front-loads the purpose with zero waste. Every word is necessary and informative.
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 zero-parameter tool with an output schema, the description is complete. It states exactly what is listed (providers and capabilities), and the output schema provides further detail.
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?
There are no parameters, so the baseline is 4. The description adds no parameter info, but none is needed.
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 uses specific verb 'List' and resource 'configured portfolio data providers and their capabilities', clearly distinguishing it from sibling tools like get_provider_health (health check) and get_quote (quote).
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 implicitly suggests using this tool to retrieve the list of providers, but it provides no explicit when-to-use/when-not-to-use guidance or alternatives.
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. Dates show when Glama detected each change.
v1.0.0get_provider_healthget_quotelist_accountslist_holdingslist_providersEach tool has a clearly distinct purpose: health checking, quoting, account listing, holdings listing, and provider listing. No overlaps or ambiguities.
All tool names follow a consistent 'verb_noun' pattern using lowercase with underscores. Verbs are either 'get' or 'list', making the set predictable.
With 5 tools, the server is well-scoped for a crypto portfolio data provider. Each tool covers a necessary function without bloat or thinness.
The set covers core read operations (health, quotes, accounts, holdings, providers) but lacks trading or transaction capabilities, which may be needed for a full crypto pilot tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect your portfolio to Claude, ChatGPT, or Codex to analyze it and make smarter investments.
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Not another dashboard. A wealth analyst for every asset a bank can't sync, inside Claude.
Read-only access to your bank, investment, and crypto accounts: balances, transactions, holdings.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cryptopilot-tools/cryptopilot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
