Bitpanda Developer API MCP Server

Official

by bitpanda-labs

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct resource or operation: asset metadata, portfolio snapshot, single price, price list, trade history, transaction history, and wallet balances. No two tools have overlapping purposes.
Naming Consistency5/5
Tool names follow a consistent pattern: 'get_' for retrieving a single entity (asset, portfolio, price) and 'list_' for enumerating collections (prices, trades, transactions, wallets). This makes the set predictable and easy to navigate.
Tool Count5/5
7 tools is well-scoped for a cryptocurrency exchange API. It covers essential read operations (asset data, portfolio, prices, trades, transactions, wallets) without unnecessary bloat, and each tool serves a clear purpose.
Completeness4/5
The tool surface covers the primary read-only needs: asset info, portfolio, prices, transactions, and wallets. Minor gaps exist, such as lack of order placement or deposit/withdrawal operations, but these are likely out of scope for a 'Developer API' focused on data retrieval.
Average 3.5/5 across 7 of 7 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add behavioral context beyond the annotations (readOnlyHint=true, openWorldHint=true). It fails to mention pagination, sorting, or that the result is a list. With annotations already declaring safety, the bar is lower, but the description should still clarify open world behavior or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb, and contains no fluff. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, 0% schema coverage, and the presence of an output schema (not seen), the description is incomplete. It omits pagination details, the semantics of the 'all' flag, and date range format. It fails to compensate for the lack of param descriptions, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions only four filter categories (wallet, flow, asset, date) but does not explain what 'flow' means or address parameters like page_size, limit, or all. It adds minimal meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'asset transactions' with optional filters. It distinguishes from siblings like list_trades and list_wallets, though 'flow' is ambiguous and not explained. Overall, the purpose is clear but lacks specificity on what constitutes a transaction vs. a trade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_trades. The description does not mention prerequisites, limitations, or scenarios where this tool is preferred. This is a significant gap given the sibling tool list_trades exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds no new behavioral context (e.g., error handling, pagination). It simply restates the function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence that efficiently conveys the core action. It could be slightly expanded without losing conciseness, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and presence of an output schema, the description is minimally adequate. However, it omits any mention of metadata scope or expected results, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and a single parameter (asset_id), the description does not explain the format or constraints beyond the schema's type string. This is insufficient for a parameter with no enums or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get asset metadata by asset UUID,' specifying a concrete verb and resource. It distinguishes from sibling tools like get_portfolio and get_price, which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. The description lacks context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no additional behavioral context beyond the basic listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste, but could be more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and openWorldHint, the description lacks explanations for pagination, the 'all' flag, and data completeness. Output schema exists but does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description mentions optional filters (trade_type, operation, asset_type, date range) but does not clarify all parameters (e.g., page_size, limit) or map them explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List your buy/sell trades on Bitpanda' with a specific verb and resource, and it is distinct from sibling tools like get_asset or list_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through listing trades but does not provide explicit guidance on when to use this tool versus alternatives like list_transactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe, consistent data. The description adds context about filtering options but does not contradict annotations. It does not mention pagination behavior, but given annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second explains two key parameters. No wasted words, but could be more structured (e.g., listing all parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return format is covered. However, pagination parameters (page_size, limit) are not mentioned in the description, which is a gap for effective use. The description is adequate for basic use but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage. The description explains non_zero and asset_id but omits page_size and limit. This leaves a significant gap for agents to understand how to control pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists wallet balances for Bitpanda. The verb 'list' and resource 'asset wallet balances' are specific. However, it does not explicitly differentiate from siblings like list_transactions or list_trades, leaving potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use non_zero and asset_id parameters. However, there is no guidance on when to use this tool versus alternatives (e.g., get_portfolio for portfolio summary, list_trades for trade history).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds valuable detail: returns balance, price, EUR value, sorting behavior (default field 'value', alias parameter 'sort'). This goes beyond the annotations, though it does not disclose pagination or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses only three sentences with no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, presence of an output schema, and annotations covering safety and variability, the description provides sufficient context. It could mention that the portfolio is for the authenticated user, but that is implied. Slight gap on handling null sort parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains that sorting is by 'value' (default) or 'name' and that 'sort' is a CLI-compatible alias. This partially compensates for missing schema descriptions, but does not list exact allowed values or interaction between sort_by and sort parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an aggregated portfolio view with EUR valuations, listing returned fields (balance, price, EUR value) and sorting options. This distinguishes it from sibling tools like get_asset or list_wallets which are more granular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like get_asset or list_trades. It does not mention prerequisites, limitations, or typical use cases, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. Description adds no extra behavioral details (e.g., update frequency, rate limits), but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no wasted words. Properly front-loaded with purpose and example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, description covers essential purpose and example. Could improve by referencing sibling tools for guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides example values (BTC, ETH) but no additional semantics like allowed formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'price', includes example symbols (BTC, ETH), and clearly distinguishes from sibling tools like get_asset or list_prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for current price of a single asset, but does not explicitly state when not to use or provide alternatives among siblings (e.g., list_prices for multiple prices).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond readOnlyHint: default returns held assets, all_assets/all synonyms, limit=0 means no cap. Could mention pagination, but sufficient with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus line break. Front-loaded with core purpose. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input parameters, default behavior, and special limit value. Output schema exists, so return values not needed. Adequate for a list tool with three optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description explains all three parameters: all_assets/all as synonyms for full list, limit for row cap with special zero behavior. Fully compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List ticker prices,' specifying verb and resource. It distinguishes from sibling 'get_price' by implying a list operation and from other list tools by focusing on prices. Default behavior (held assets) further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (list prices, default held assets) and how to adjust via parameters. Lacks explicit mention of alternatives like 'get_price' for single price, but sibling list aids inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bitpanda-mcp MCP server](https://glama.ai/mcp/servers/bitpanda-labs/bitpanda-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bitpanda-labs/bitpanda-mcp)

Score Badge

Copy to your README.md:

[![bitpanda-mcp MCP server](https://glama.ai/mcp/servers/bitpanda-labs/bitpanda-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bitpanda-labs/bitpanda-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitpanda-labs/bitpanda-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server