Which integrations are available for this server?

CI/CD pipeline integration for automated testing, coverage reporting, and build validation Built with TypeScript for type-safe development and configuration validation Comprehensive testing framework for unit and integration tests with coverage reporting Schema validation for API inputs, parameters, and configuration management

How do I use Bitso MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bitso MCP Server list withdrawals for BTC from last week" 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.

Bitso MCP Server

by blaze-xyz

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Bitso MCP Server

An MCP server for the Bitso API that provides tools to access withdrawals and fundings data. Built with TypeScript, featuring comprehensive testing, dual transport support, and production-ready best practices.

Features

🏦 Bitso API Integration

Complete Withdrawals API support (list, get by ID, get by multiple IDs, get by origin IDs)
Complete Fundings API support (list, get by ID)
Proper authentication with API key/secret and HMAC signature
Support for all API filtering and pagination parameters

🚀 Production Ready

Dual transport support (stdio for Claude Desktop, HTTP for development)
Comprehensive error handling and logging
Type-safe configuration with Zod validation
Project-root-aware file logging system

🧪 Comprehensive Testing

Two-tier testing strategy (unit + integration tests)
Real MCP protocol testing (not mocked functions)
MSW for consistent API mocking
High test coverage with Vitest

🛠️ Developer Experience

Hot reloading with TypeScript watch mode
Tool generation script
ESM support with proper module resolution
CI/CD pipeline with GitHub Actions

📦 Best Practices

Modular tool organization
Zod schema validation for all inputs
Structured logging with file output
Caching with configurable TTL

Related MCP server: Bitso MCP Server

Quick Start

1. Setup

npm install

2. Configure Environment

cp .env.example .env
# Edit .env with your Bitso API credentials

Required environment variables:

BITSO_API_KEY: Your Bitso API key
BITSO_API_SECRET: Your Bitso API secret

3. Build and Test

# Build the project
npm run build

# Run tests
npm run test

# Start development server (HTTP mode)
npm run start:http

4. Add to Claude Desktop

Add to your Claude Desktop configuration (claude_desktop_config.json):

{
  "mcpServers": {
    "bitso-mcp-server": {
      "command": "node",
      "args": ["/path/to/bitso-mcp-server/dist/src/index.js"],
      "env": {
        "BITSO_API_KEY": "your-bitso-api-key",
        "BITSO_API_SECRET": "your-bitso-api-secret"
      }
    }
  }
}

Available Tools

The server provides 6 tools to interact with the Bitso API:

Withdrawals Tools

list_withdrawals - List withdrawals with optional filtering
- Parameters: currency, limit, marker, method, origin_id, status, wid
get_withdrawal - Get specific withdrawal by ID
- Parameters: wid (required)
get_withdrawals_by_ids - Get multiple withdrawals by comma-separated IDs
- Parameters: wids (required, e.g., "wid1,wid2,wid3")
get_withdrawals_by_origin_ids - Get withdrawals by client-supplied origin IDs
- Parameters: origin_ids (required, e.g., "origin1,origin2,origin3")

Fundings Tools

list_fundings - List fundings with optional filtering
- Parameters: limit, marker, method, status, fids
get_funding - Get specific funding by ID
- Parameters: fid (required)

Development Guide

Project Structure

src/
├── tools/           # MCP tool implementations
│   └── bitso-tools.ts  # Bitso API tools
├── utils/           # Shared utilities
│   └── logging.ts   # Project-root-aware logging
├── client.ts        # Bitso API client with authentication
├── config.ts        # Environment configuration
├── types.ts         # TypeScript type definitions
└── index.ts         # Main server entry point

tests/
├── unit/            # Fast unit tests with MSW mocking
├── integration/     # Real MCP protocol tests
├── helpers/         # Test utilities
│   ├── mcp-test-helper.ts
│   ├── test-server-factory.ts
│   └── test-config.ts
├── mocks/           # MSW request handlers
└── setup.ts         # Test environment setup

Creating New Tools

Use the built-in tool generator:

npm run build
npm run create-tool

Or create manually following the pattern in src/tools/bitso-tools.ts:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const MyToolSchema = z.object({
  param: z.string().min(1, "Parameter is required"),
});

export function registerMyTools(server: McpServer, client: BitsoApiClient): void {
  server.tool(
    "my_tool",
    {
      description: "Description of what the tool does",
      inputSchema: {
        type: "object",
        properties: {
          param: {
            type: "string",
            description: "Parameter description",
          },
        },
        required: ["param"],
      },
    },
    async (params): Promise<ToolResult> => {
      try {
        const validatedParams = MyToolSchema.parse(params);
        
        // Your tool logic here
        
        return {
          content: [
            {
              type: "text",
              text: "Tool response"
            }
          ]
        };
      } catch (error) {
        // Error handling
        return {
          content: [
            {
              type: "text",
              text: `Error: ${error instanceof Error ? error.message : String(error)}`
            }
          ]
        };
      }
    }
  );
}

Testing Strategy

This template uses a two-tier testing approach:

Unit Tests (`tests/unit/`)

Test business logic in isolation
Mock external APIs using MSW
Fast execution, run frequently during development
Focus on data transformations, caching, validation

Integration Tests (`tests/integration/`)

Test through real MCP protocol
Use actual MCP server instances
Validate tool registration and MCP compliance
Ensure proper request/response formatting

# Run unit tests (fast)
npm run test:unit

# Run integration tests (slower, full MCP protocol)
npm run test:integration

# Run all tests with coverage
npm run test:coverage

Transport Modes

Stdio Transport (Production)

Used by Claude Desktop and other MCP clients:

npm start
# or
node dist/src/index.js

HTTP Transport (Development)

Useful for debugging and development:

npm run start:http
# Server available at http://localhost:3000/mcp

Logging and Debugging

The template includes a sophisticated logging system:

Debug logs: Written to mcp-debug.log in project root
Project-root-aware: Works from both source and compiled code
Structured logging: JSON formatting for complex data
Console output: Errors also logged to stderr

Check logs during development:

tail -f mcp-debug.log

Configuration Management

Configuration uses Zod for type-safe validation:

// src/config.ts
const ConfigSchema = z.object({
  apiKey: z.string().min(1, 'API_KEY environment variable is required'),
  apiEndpoint: z.string().url().default('https://api.example.com'),
  // ... other config
});

Environment variables are validated on startup with clear error messages.

API Integration

Client Pattern

The template includes a robust API client pattern:

// Automatic caching
const resources = await client.getResources(); // Cached for 5 minutes

// Error handling
try {
  const resource = await client.getResource(id);
} catch (error) {
  // Errors are logged and can be handled
}

// Connection testing
const isHealthy = await client.testConnection();

Bitso API Authentication

The server uses HMAC-SHA256 authentication required by the Bitso API:

// Authentication headers are automatically generated
const authHeaders = {
  'key': config.apiKey,
  'signature': hmacSignature,  // Generated using API secret
  'nonce': timestamp
};

Each request is signed using:

API Secret (from environment)
HTTP method
Request path
Request body (if any)
Current timestamp as nonce

Deployment

Building for Production

npm run build
npm test

CI/CD

The template includes a GitHub Actions workflow (.github/workflows/ci.yml):

Unit tests: Fast feedback on basic functionality
Integration tests: Full MCP protocol validation
Coverage reporting: Ensure code quality
Build validation: Verify compilation

Environment Variables

Production deployment requires:

BITSO_API_KEY=your-production-api-key
BITSO_API_SECRET=your-production-api-secret
BITSO_API_ENDPOINT=https://api.bitso.com  # Production endpoint
CACHE_TTL_SECONDS=300
TIMEOUT=30000

Best Practices

Tool Development

Always use Zod schemas for parameter validation
Return MCP-compliant responses with { content: [...] } format
Handle errors gracefully with user-friendly messages
Log extensively for debugging and monitoring
Test through MCP protocol using integration tests

Error Handling

// Good: MCP-compliant error response
return {
  content: [
    {
      type: "text",
      text: `Error: ${error.message}`
    }
  ]
};

// Bad: Throwing unhandled errors
throw new Error("Something went wrong");

Performance

Use caching for expensive API calls
Implement request timeouts
Log performance metrics
Monitor API rate limits

Troubleshooting

Common Issues

Tool not appearing in Claude:

Check build succeeded: npm run build
Restart Claude Desktop
Check mcp-debug.log for errors
Verify claude_desktop_config.json configuration

Tests failing:

Run unit tests first: npm run test:unit
Check MSW handlers match your API expectations
Verify integration tests use real MCP server instances

API connection issues:

Verify environment variables are set
Test API credentials manually
Check network connectivity and firewalls
Review API endpoint URLs

Debug Mode

Enable detailed logging:

DEBUG=true npm start

Contributing

Fork the repository
Create a feature branch
Add tests for new functionality
Ensure all tests pass: npm test
Build successfully: npm run build
Submit a pull request

License

MIT License. See LICENSE for details.

Available Tools

6 tools

get_fundingD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_withdrawalD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_withdrawals_by_idsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_withdrawals_by_origin_idsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_fundingsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_withdrawalsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.0.0Sep 24, 2025
- First observedget_funding
- First observedget_withdrawal
- First observedget_withdrawals_by_ids
- First observedget_withdrawals_by_origin_ids
- First observedlist_fundings
- First observedlist_withdrawals

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

D1.8/5.0

Scored 2026-04-18 09:00 across 6 tools

Disambiguation3/5

The tools have clear distinctions between funding and withdrawal operations, with specific 'get' and 'list' variants. However, the two 'get_withdrawals_by_*' tools could be confusing as they serve similar purposes (retrieving withdrawals by different ID types) without clear differentiation in their names or descriptions.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with underscores, using 'get' for single retrievals and 'list' for collections. The naming is predictable and uniform across all six tools, with no deviations in style or convention.

Tool Count4/5

Six tools is a reasonable number for a financial transaction server, covering core funding and withdrawal operations. It's slightly lean but appropriate for the apparent scope, though it might benefit from additional tools for actions like creating or updating transactions.

Completeness2/5

The toolset is severely incomplete for a financial platform, covering only read operations (get and list) for fundings and withdrawals. There are no tools for creating, updating, or deleting transactions, which are essential for a full CRUD lifecycle in this domain, leaving significant gaps that will hinder agent workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Bity B
io.github.mcp-dir
Bity crypto bank (Bitybank / Bitypreço), account balance per coin, market data (ticker, order book,
Cryptocurrency Finance Blockchain
142
Synci AOAuth
io.synci
Read-only access to your bank, investment, and crypto accounts: balances, transactions, holdings.
Finance
52
RhoOAuth
co.rho
Tools for your business banking with Rho, including accounts, transactions, and more
Finance Payments & Billing
1
Bitstamp A
io.github.pipeworx-io
Bitstamp keyless public market: ticker, orderbook, transactions, OHLC, trading pairs.
Finance Cryptocurrency
432

Related MCP Servers

Bybit Server
Finance Blockchain API Testing
dlwjdtn535
A
license
B
quality
D
maintenance
Interact seamlessly with the Bybit API to fetch market data, manage your account, and execute trades. Leverage powerful tools to enhance your trading experience and automate your strategies effortlessly. If you wish to use an API key restricted to your personal IP address, you must configure the MCP
Updated 4 months ago (2026-05-29 02:27 UTC)
15
9
MIT
Bitso MCP Server
Cryptocurrency RAG Systems
frahman5
A
license
Not graded
quality
D
maintenance
Enables access to Bitso cryptocurrency exchange data through comprehensive withdrawal and funding transaction tools. Features production-ready authentication, caching, and complete API integration for monitoring exchange activities.
Updated a year ago (2025-08-12 04:47 UTC)
MIT
Bithumb MCP Server
Cryptocurrency Finance Blockchain
zereight
A
license
B
quality
D
maintenance
Enables interaction with the Bithumb cryptocurrency exchange API to fetch market data, manage account balances, and execute trading operations including limit orders, market orders, and withdrawals.
Updated a year ago (2025-05-04 13:04 UTC)
19
20 npm
MIT
Conekta MCP Serverofficial
Finance E-commerce & Retail
conekta
F
license
A
quality
D
maintenance
Enables interaction with the Conekta payment API to manage orders, customers, subscriptions, and financial transactions. It provides a comprehensive suite of tools for core payment operations like processing refunds, creating checkouts, and monitoring account balances.
Updated 5 months ago (2026-04-24 20:04 UTC)
32
2
-

Bitso MCP Server

Features

Quick Start

1. Setup

2. Configure Environment

3. Build and Test

4. Add to Claude Desktop

Available Tools

Withdrawals Tools

Fundings Tools

Development Guide

Project Structure

Creating New Tools

Testing Strategy

Unit Tests (tests/unit/)

Integration Tests (tests/integration/)

Transport Modes

Stdio Transport (Production)

HTTP Transport (Development)

Logging and Debugging

Configuration Management

API Integration

Client Pattern

Bitso API Authentication

Deployment

Building for Production

CI/CD

Environment Variables

Best Practices

Tool Development

Error Handling

Performance

Troubleshooting

Common Issues

Debug Mode

Contributing

License

Related Resources

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Conekta MCP Serverofficial

Unit Tests (`tests/unit/`)

Integration Tests (`tests/integration/`)