How to Connect Bitget MCP to Claude, Cursor, and AI Agents: API Keys, Config and Test Prompts (2026 Guide)

Key Takeaways

• Bitget MCP Connects Claude, Cursor, and AI Agents to Bitget’s V2 REST API: Bitget MCP is Bitget’s official Model Context Protocol server, allowing MCP-compatible AI tools such as Claude, Cursor, VS Code, and other AI agents to access supported Bitget exchange workflows through natural-language prompts.

• 58 Tools Across 9 Bitget Modules: Bitget MCP provides 58 tools across 9 modules, including Spot, Futures, Account, Margin, Copy Trading, Convert, Earn, P2P, and Broker. This allows AI agents to work with market data, account queries, portfolio management, trading workflows, and other supported exchange functions.

• API Keys, Config, and Permissions Are Required for Private Workflows: Public market data tools can be tested first, but account queries, portfolio review, order placement, transfers, and other private actions require Bitget API credentials, including APIKey, SecretKey, and Passphrase. Users should choose the correct permission scope before connecting Bitget MCP to any AI agent.

• Claude and Cursor Can Connect Through MCP Configuration: Claude Desktop can connect to Bitget MCP through its MCP server configuration, while Claude Code can use a CLI command. Cursor can connect through a .cursor/mcp.json configuration file, usually with selected modules such as spot, futures, and account to stay within tool limits.

• Security Must Come Before Trading Automation: Beginners should test public market data prompts first, then read-only account prompts, and only consider trading-enabled workflows after the MCP setup is working correctly. API credentials should be stored securely, withdrawal permissions should be avoided, and every trading-related action should require human confirmation.

What Is Bitget MCP?

Bitget MCP is Bitget’s official Model Context Protocol server for connecting AI agents to Bitget’s V2 REST API. It allows MCP-compatible tools such as Claude, Cursor, VS Code, OpenClaw, Windsurf, and other AI-agent environments to query market data, access supported account information, and prepare trading-related workflows through natural-language prompts.

In simple terms, Bitget MCP acts as a bridge between an AI assistant and Bitget’s exchange infrastructure. Instead of manually writing every API request, users can ask an AI agent to perform supported tasks such as checking spot prices, reviewing futures data, retrieving order book depth, checking account balances, or preparing an order workflow for review.

Bitget MCP provides 58 tools across 9 modules: Spot, Futures, Account, Margin, Copy Trading, Convert, Earn, P2P, and Broker. These modules allow AI agents to work with different parts of the Bitget ecosystem, from public market-data queries to private account and trading-related functions that require API credentials.

For example, an AI agent can use Bitget MCP to call supported tools for spot tickers, order book data, candlestick data, account balances, futures positions, copy trading workflows, or order preparation. This makes Bitget MCP useful for traders, developers, and AI-agent builders who want to connect natural-language prompts with structured exchange tools.

Bitget MCP is usually run through a Node.js package such as bitget-mcp-server, often launched with an npx command inside an MCP-compatible client configuration. The client configuration typically includes the server command, selected modules, and environment variables for Bitget API credentials when private account access is needed.

Before You Start: What You Need to Connect Bitget MCP

Before connecting Bitget MCP to Claude, Cursor, or another AI agent, users should prepare the required account access, API credentials, runtime environment, and MCP-compatible client. This setup is important because Bitget MCP can connect AI agents with both public market data and private account-related workflows, depending on the API permissions enabled.

The basic requirements include:

For the safest setup, users should begin with public market data tools before connecting private account permissions. Market data workflows, such as checking spot prices, order book depth, candlestick data, or futures funding rates, are the lowest-risk starting point because they do not require broad account access.

After market data prompts work correctly, users can test read-only account workflows such as balance checks, open position summaries, and account exposure reviews. Trading permissions should only be added later, after the user understands how the MCP client, Bitget MCP server, API key permissions, and confirmation flow work together.

A safe preparation flow looks like this:

Bitget account → API key creation → permission selection → secure credential storage → MCP client setup → market data test → read-only account test → trading workflow test with human confirmation

This preparation step helps users avoid common setup problems such as missing environment variables, incorrect API permissions, unavailable tools, or unsafe trading access.

Step 1: Create a Bitget API Key

To connect Bitget MCP to Claude, Cursor, or another AI agent for private workflows, users need to create a Bitget API key. Public market data may be available without private account access, but account queries, portfolio review, order placement, and trading-related actions require authenticated API credentials.

A typical Bitget API key setup includes three credential components:

• APIKey: identifies the API credential.

• SecretKey: signs authenticated requests.

• Passphrase: adds an extra authentication layer for API access.

To create a Bitget API key, users should log in to their Bitget account, open the API management section, and create a new API key dedicated to Bitget MCP. For a safer organization, the key name should clearly describe its purpose, such as “Bitget MCP Read-Only Test” or “Bitget MCP Trading Review.”

During setup, users should choose the permission scope carefully. For the first connection, it is safer to start with market data or read-only account access instead of enabling trading permissions immediately. Withdrawal permissions should not be enabled for AI-agent workflows.

After the API key is created, users should copy the APIKey, SecretKey, and Passphrase into a secure storage location. These credentials should not be saved in screenshots, public documents, GitHub repositories, shared chat logs, or unsecured configuration files.

A safer API key creation workflow looks like this:

Create dedicated API key → Choose minimum permissions → Enable IP whitelist where available → Store credentials securely → Connect to Bitget MCP → Test market data first

Using a dedicated API key for Bitget MCP helps users separate AI-agent workflows from other trading systems. It also makes it easier to rotate credentials, disable access, or adjust permissions later if needed.

Step 2: Choose the Right API Permissions

API permissions decide what an AI agent can do through Bitget MCP. This is one of the most important setup steps because the wrong permission scope can expose private account data or allow trading actions before the user is ready.

For most users, Bitget MCP permissions can be divided into three practical levels:

Beginners should start with public market data whenever possible. This allows users to confirm that Claude, Cursor, or another AI agent can connect to Bitget MCP without exposing account-level permissions.

After market data works correctly, users can test read-only account access. This is useful for prompts such as “Show my available balance” or “Summarize my open futures positions.” Read-only access can still expose sensitive account information, so credentials should be stored securely and never shared publicly.

Trading permission should only be enabled after the MCP setup has been tested and the user understands the risks. Trading-enabled workflows allow order placement, order cancellation, trigger orders, position management, or other write operations where supported. Every trading-related action should require explicit human confirmation.

A safer permission ladder looks like this:

Market data first → read-only account access → trading permission with human confirmation

Users should not enable withdrawal permissions for AI-agent workflows. AI agents do not need withdrawal access to check markets, review account information, or prepare trading workflows. Keeping withdrawal permissions disabled reduces unnecessary account risk.

Step 3: Install or Access the Bitget MCP Server

After preparing a Bitget account and API permissions, the next step is to install or access the Bitget MCP server. Bitget MCP is commonly launched through a Node.js package, which allows MCP-compatible clients such as Claude, Cursor, VS Code, and other AI-agent environments to call supported Bitget tools.

A typical Bitget MCP server command uses npx, such as:

npx -y bitget-mcp-server

This command allows the MCP-compatible client to launch the Bitget MCP server when needed. Depending on the setup, users may also need to define selected modules and environment variables for API credentials.

A general MCP server configuration include:

Users should treat this as a configuration pattern, not a universal setup for every client. Exact field names, file locations, and supported options differ depending on the MCP-compatible environment. Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, and other AI-agent clients may each handle MCP server configuration differently.

For safer configuration, API credentials should be stored through environment variables or secure secret management rather than hardcoded into files. If credentials must be referenced in a local config file, users should make sure the file is private, excluded from version control, and never shared publicly.

Before moving to Claude or Cursor setup, users should confirm that:

• Node.js is installed and available.

• The npx command works in the terminal.

• The Bitget MCP server package can be launched.

• API credentials are stored securely.

• The selected API permissions match the intended workflow.

• Withdrawal permission is not enabled.

• Market data prompts will be tested before account or trading prompts.

Once the Bitget MCP server can be launched, users can add it to Claude, Cursor, or another MCP-compatible AI agent.

Step 4A: Add Bitget MCP to Claude

Claude can connect to MCP servers through supported MCP configuration. Once Bitget MCP is installed or available through the npx command, users can add it to Claude so the assistant can access supported Bitget tools.

For Claude Desktop, the general process is:

1. Open the Claude Desktop MCP configuration file.

2. Add a new MCP server entry for Bitget MCP.

3. Set the command to launch the Bitget MCP server.

4. Add the required environment variables for Bitget API credentials if private tools are needed.

5. Save the configuration file.

6. Restart Claude Desktop.

7. Check whether Bitget MCP tools appear in the Claude tool list.

8. Test a public market data prompt first.

A general Claude Desktop configuration pattern looks like this:

Users should replace the placeholder values with secure credential references. For safer setup, credentials should be stored as environment variables or managed through a secret manager rather than written directly into shared files.

For Claude Code, users may be able to add an MCP server through a CLI-style command, depending on the current Claude Code MCP setup. The exact command format can change, so users should follow the latest Claude and Bitget MCP documentation. The important idea is the same: Claude needs a server entry that tells it how to launch Bitget MCP and which environment variables are available.

After Claude is configured, the first test should be a low-risk market data prompt, such as:

“Show me the latest BTCUSDT spot market data from Bitget.”

If the tool appears and returns data correctly, users can then test additional market-data prompts before moving to read-only account queries. Account-related or trading-related prompts should only be tested after confirming that API permissions are configured correctly.

Step 4B: Add Bitget MCP to Cursor

Cursor can connect to MCP servers through its MCP configuration, allowing developers to use Bitget MCP inside an AI coding and agent workflow. This is useful for users who want to test Bitget market data prompts, account queries, or trading workflow preparation while working in a development environment.

A common Cursor setup uses a .cursor/mcp.json file inside the project or workspace. The configuration tells Cursor how to launch the Bitget MCP server and which environment variables are available for API authentication.

A general Cursor MCP configuration pattern looks like this:

In some setups, users may choose selected Bitget MCP modules such as spot, futures, and account to keep the tool list focused and easier for the AI agent to use. This can be helpful when the MCP client has tool-count limits or when users only want to expose specific workflows.

A safer Cursor setup checklist includes:

1. Create or open the .cursor/mcp.json configuration file.

2. Add the Bitget MCP server entry.

3. Set the command and arguments for the server.

4. Add API credentials through environment variables or secure local references.

5. Limit exposed modules where possible.

6. Save the configuration.

7. Restart or reload Cursor.

8. Confirm that Bitget MCP tools appear.

9. Test public market data prompts before account or trading prompts.

For security, users should avoid committing .cursor/mcp.json if it contains credential values. The file should be excluded from version control when sensitive environment variables or local secrets are included.

After Cursor recognizes Bitget MCP, users can test a low-risk prompt such as:

“Check the BTCUSDT futures funding rate from Bitget.”

If the prompt works correctly, users can move to other market-data prompts, then read-only account prompts, and finally trading-related prompts only after permission settings and confirmation rules are reviewed.

Step 4C: Connect Bitget MCP to Other AI Agents

Claude and Cursor are common MCP-compatible environments, but they are not the only places where Bitget MCP can be used. Other AI-agent clients, developer tools, and MCP-compatible applications may also connect to Bitget MCP if they support custom MCP server configuration.

The general setup pattern is similar across most MCP-compatible clients:

AI agent client → MCP server configuration → Bitget MCP server → Bitget API credentials → Bitget V2 REST API → structured tool result → AI response

To connect Bitget MCP to another AI agent, users usually need to:

1. Confirm that the AI client supports MCP server configuration.

2. Install or access the Bitget MCP server package.

3. Add a Bitget MCP server entry to the client configuration.

4. Define the server command, such as npx.

5. Add the required server arguments, such as -y bitget-mcp-server.

6. Add Bitget API credentials through environment variables or secure references if private tools are needed.

7. Select or limit exposed modules where supported.

8. Restart or reload the AI client.

9. Test a public market data prompt before using private account tools.

A general configuration pattern looks like this:

Users should treat this as a flexible template rather than a universal configuration. Different AI-agent clients may use different file names, configuration formats, module options, or credential handling methods. The most important requirement is that the client can launch or connect to the Bitget MCP server and pass the required environment variables securely.

For non-Claude and non-Cursor clients, users should check three things before testing:

• whether the client supports local or remote MCP servers;

• whether it can pass environment variables securely;

• whether it shows available Bitget MCP tools after configuration.

After the tools appear, users should follow the same safe testing ladder: market data first, read-only account queries second, and trading-related prompts only after human confirmation rules are in place.

Step 5: Test Market Data Prompts First

After Bitget MCP is connected to Claude, Cursor, or another AI agent, users should test public market data prompts before using account or trading-related tools. Market data prompts are the safest first step because they help confirm whether the MCP server, client configuration, and tool connection are working correctly without exposing private account information.

Good first test prompts include:

• “Show me the latest BTCUSDT spot market data from Bitget.”

• “Check the BTCUSDT order book data where available.”

• “Show recent BTCUSDT K-line or candlestick data.”

• “Check the BTCUSDT futures funding rate.”

• “Summarize current ETHUSDT market conditions.”

• “Compare BTCUSDT spot and futures market data where available.”

• “Show open interest data for BTCUSDT futures where supported.”

These prompts help verify whether the AI agent can call supported Bitget MCP market-data tools and return structured information. If the AI agent gives a generic answer without using a tool, users should check whether the Bitget MCP server is active and whether the tool list is visible in the client.

When reviewing the response, users should check:

If market data prompts work correctly, users can move to read-only account prompts. If they fail, users should troubleshoot the MCP server path, configuration file, Node.js setup, environment variables, client restart, and tool visibility before adding private API permissions.

Step 6: Test Read-Only Account Prompts

After market data prompts work correctly, users can test read-only account prompts. These prompts help confirm whether Bitget MCP can access private account information through the configured API credentials without enabling trading actions.

Read-only account prompts may require API credentials with account or read permissions. They should be tested only after users confirm that Bitget MCP is connected correctly and that credentials are stored securely.

Useful read-only test prompts include:

• “Show my available account balance.”

• “Summarize my spot account status.”

• “Show my open futures positions.”

• “Review my futures account exposure.”

• “Show my available margin where supported.”

• “Summarize my account assets and available balance.”

• “Explain my current position exposure without placing any trades.”

When testing read-only account prompts, users should check:

Read-only account prompts are useful for portfolio summaries, balance checks, position monitoring, and risk review. However, account data is still sensitive. Users should avoid sharing screenshots, logs, or AI responses that include private balance information.

If read-only prompts fail, common causes include missing API credentials, incorrect passphrase, disabled account permissions, expired or invalid API keys, IP whitelist mismatch, or environment variables that are not loading correctly.

Step 7: Test Trading-Related Prompts Only With Human Confirmation

Trading-related prompts should be tested only after market data prompts and read-only account prompts are working correctly. These prompts may involve order placement, order cancellation, trigger orders, position management, or other write operations where supported by Bitget MCP and the selected API permissions.

For safety, trading-related prompts should be written around preparation, explanation, and manual approval. The AI agent should not execute trades automatically unless the user has intentionally enabled trading permissions and confirmed the action.

Safer trading-related test prompts include:

• “Prepare a BTCUSDT spot order workflow for my review, but do not place the order.”

• “Explain the required steps for a BTCUSDT futures order without executing it.”

• “Check whether this order request matches my risk limits before I confirm.”

• “Summarize the order details, including symbol, side, order type, price, and size, before execution.”

• “Prepare a trigger order workflow and wait for my confirmation.”

• “Review my current position exposure before preparing any new futures order.”

• “Do not place, cancel, or modify any order unless I explicitly confirm.”

Before enabling trading-related prompts, users should verify:

A safe trading workflow should look like this:

Market data check → account/position review → AI summary → order preparation → user confirmation → execution

This keeps Bitget MCP in an assistant role. The AI agent can help prepare and explain trading workflows, but final execution should remain under user control.

Bitget MCP Configuration Best Practices

A good Bitget MCP setup should be secure, organized, and easy to troubleshoot. Since MCP configuration can connect AI agents to both public market data and private account tools, users should treat the configuration file as part of their trading infrastructure.

• Use Environment Variables for API Credentials: APIKey, SecretKey, and Passphrase should be stored as environment variables or in a secure secret manager. Avoid hardcoding credentials directly into Claude, Cursor, VS Code, or project configuration files.

• Use a Dedicated API Key for Bitget MCP: Instead of reusing an API key from another bot or trading system, create a separate key for Bitget MCP. This makes it easier to control permissions, rotate credentials, and disable access if needed.

• Separate Read-Only and Trading Configurations: Users can create one configuration for read-only account review and another for trading-enabled workflows. This reduces the risk of accidentally giving trading access to prompts that only need account data.

• Limit Enabled Modules Where Possible: If the AI agent only needs Spot, Futures, and Account tools, users can keep the setup focused on those modules where supported. Limiting exposed tools can make the agent easier to control and reduce unnecessary complexity.

• Keep Local Config Files Private: Files such as Claude configuration files or .cursor/mcp.json should not be shared publicly if they include credential references. If the project uses Git, sensitive configuration files should be added to .gitignore.

• Restart the Client After Configuration Changes: MCP tools may not appear until the AI client is restarted or reloaded. After changing the configuration, users should restart Claude, Cursor, VS Code, or the relevant AI-agent environment.

• Test One Permission Level at a Time: Start with public market data, then test read-only account access, and only test trading-enabled workflows after confirming that the earlier steps work correctly.

• Review Tool Names and Available Functions: After Bitget MCP loads, users should check which tools are visible in the AI client. This helps confirm whether the expected modules and functions are available.

• Monitor Logs and Tool Calls: Logs can help identify missing environment variables, invalid credentials, permission errors, timeouts, or rate-limit issues. Users should review logs before assuming that the AI agent or MCP server is malfunctioning.

• Keep Bitget MCP Updated: MCP servers, AI clients, and API behavior may change over time. Users should follow official Bitget MCP documentation and update the MCP server package when needed.

A clean configuration process should look like this:

Create dedicated API key → store credentials securely → configure MCP server → restart client → verify tools → test market data → test read-only access → test trading workflows only with confirmation

Common Bitget MCP Connection Errors and Fixes

When connecting Bitget MCP to Claude, Cursor, or another AI agent, most setup issues come from configuration paths, missing credentials, permission mismatches, or client reload problems. The table below summarizes common errors and how to fix them.

A good troubleshooting process is to move from low-risk checks to higher-permission checks. First, confirm that the MCP server launches. Then confirm that tools appear in the AI client. Next, test public market data prompts. Only after that should users test read-only account prompts or trading-related workflows.

If a problem appears after enabling account or trading permissions, users should pause the workflow and review credentials, permission scope, IP whitelist settings, logs, and tool-call outputs before continuing.

Security Rules for Connecting Bitget MCP to AI Agents

Connecting Bitget MCP to Claude, Cursor, or another AI agent can make crypto workflows easier to manage, but it also introduces permission and account-security responsibilities. Users should treat the MCP setup as part of their trading infrastructure, not as a casual chatbot connection.

• Start With Market Data Only: The safest first test is public market data, such as prices, tickers, order book data, candlesticks, funding rates, or open interest. These prompts help confirm that the MCP connection works before exposing private account information.

• Use Read-Only Access Before Trading Access: If users want the AI agent to review balances, positions, margin status, or account exposure, they should use read-only permissions where possible. Trading permission should only be added after the read-only workflow is working correctly.

• Never Enable Withdrawal Permissions for AI Agents: AI agents do not need withdrawal access to check market data, summarize account information, or prepare trading workflows. Keeping withdrawal permissions disabled reduces unnecessary account risk.

• Separate API Keys by Workflow: A safer setup uses one API key for read-only workflows and a separate key for trading-enabled workflows. This makes it easier to limit access, rotate credentials, and disable trading access without disrupting market-data or account-review workflows.

• Use IP Whitelisting Where Available: IP whitelisting can restrict API access to approved environments. This helps reduce the risk of unauthorized use if an API key is exposed.

• Store Credentials Securely: APIKey, SecretKey, and Passphrase should be stored in environment variables or secret managers. Users should not place them in public code repositories, shared documents, screenshots, browser notes, or chat logs.

• Require Human Confirmation Before Trading Actions: Trading prompts should be designed for preparation and review, not automatic execution. Every order placement, cancellation, trigger order, position-management action, or copy trading-related action should require explicit user confirmation.

• Review Logs and Tool Calls Regularly: Users should monitor tool-call history, failed requests, permission errors, rate-limit messages, and unexpected responses. Logs can help detect configuration issues, prompt ambiguity, or unintended tool use.

• Do Not Treat Bitget MCP as a Risk-Control System: Bitget MCP provides structured access to supported Bitget tools, but it does not replace trading strategy, backtesting, liquidation analysis, stop-loss planning, position sizing, or portfolio risk management.

A safe security model should look like this:

Public market data → read-only account access → trading permission with manual confirmation → ongoing log review

This structure keeps Bitget MCP useful for AI-assisted workflows while reducing the risks of over-permissioned API keys, unintended trading actions, and unsupervised automation.

Conclusion

Connecting Bitget MCP to Claude, Cursor, and other AI agents gives users a structured way to access supported Bitget exchange tools through natural-language prompts. Instead of building every API connection manually, users can configure Bitget MCP, add the required API credentials, and let MCP-compatible agents retrieve market data, review account information, summarize positions, or prepare trading workflows when the correct permissions are enabled.

The safest setup starts with a clear permission ladder: test public market data first, move to read-only account prompts second, and only consider trading-enabled workflows after the user understands API scope, MCP configuration, and security controls. Claude, Cursor, VS Code, and other AI-agent environments may use different configuration formats, but the core setup logic is the same: configure the MCP server, pass credentials securely, restart the client, verify tool visibility, and test with low-risk prompts before moving to private workflows.

Bitget MCP should not be treated as an autonomous trading bot or a replacement for risk management. Its value comes from giving AI agents structured access to supported Bitget tools, while final trading decisions, permission settings, order confirmation, and account security remain under user control. For most users, the best approach is to keep credentials secure, avoid withdrawal permissions, separate read-only and trading keys, monitor tool calls, and require explicit human confirmation before any trading-related action.