Skip to main content

​
What is the MCP server?

The Model Context Protocol (MCP) is an open standard that lets AI applications such as Claude, Claude Code, and other MCP-capable agents call external APIs as tools. MyFundedPerps hosts an MCP server that exposes the REST trading and read operations as tools, so an assistant can list your challenge accounts, quote markets, place and manage orders, and inspect positions and fills on your behalf. The server speaks the current stateless MCP revision (2026-07-28) over Streamable HTTP:
There is nothing to install or run yourself. You sign in through OAuth in your browser, and each tool call then runs as one authenticated REST request under your own session, so everything in Idempotency and Errors and rate limits applies unchanged.
Tools placed under an AI assistant’s control can cancel orders and close positions. Configure the client to request the read scope when the assistant only needs to observe, and prefer a sandbox key while you evaluate an agent.

​
Documentation and connection URLs

This guide is at /mcp-server on the documentation site. The documentation site’s /mcp path belongs to Mintlify’s documentation-search service and can return 401 Unauthorized when opened in a browser. Use https://mcp.myfundedperpetuals.com in your trading MCP client. See API capabilities for the supported operations and features that still require the website.

​
Sign in with OAuth

OAuth is the sign-in method for the MCP server. There is no key to copy: connect the server and your MCP client opens a browser page where you review what the client is asking for and approve it with your normal MyFundedPerps sign-in.
  1. Add the server to your MCP client (examples below) and start it.
  2. The client discovers the authorization flow automatically and opens myfundedperpetuals.com/mcp/auth in your browser.
  3. Review the client name, access level, and expiry, then choose Approve.
  4. The client receives its own session and starts calling tools.
Sessions minted this way:
API keys are for direct REST API and SDK calls, not for MCP. A live fp_live_ key sent to the MCP server is refused with a prompt to sign in with OAuth, and an MCP session cannot be replayed against the REST hosts.

​
Sandbox

The sandbox has no OAuth flow. To point an MCP client at your sandbox accounts, send an fp_test_ key as a bearer header instead (created in API Key Settings under the Test environment):

​
Connect a client

​
Claude Code

The first tool use prompts the OAuth sign-in in your browser.

​
Other MCP clients

Any client that supports Streamable HTTP with OAuth can connect:
Clients register themselves automatically: the server supports both Client ID Metadata Documents and Dynamic Client Registration, so no manual client setup is needed. For sandbox testing, add the Authorization header with an fp_test_ key instead.

​
Tools

The two CLI authentication endpoints are excluded because MCP uses its own OAuth flow. Each exposed operation is one tool, named after the matching fperp CLI command: list-accounts, get-market-quote, create-order, cancel-order, close-position, and so on. Tool arguments use the same snake_case names as the REST API’s path, query, and body fields, and each tool’s schema includes nested objects and arrays, required fields, enums, and numeric constraints. Protective-exit batches expose the complete expected_orders snapshot and the cancel, modify, and place operation shapes, including OCO pairing. The REST API still enforces trading rules and current account state. Results are JSON with three parts: Failed calls are reported as tool errors carrying the standard error envelope with error.code and per-field error.details, so an agent can correct its input and retry. Responses with status 429 include retry_after_seconds.

​
Idempotency and bulk operations

Tools for operations that require an Idempotency-Key header require an idempotency_key argument. Generate a UUID or other unique printable ASCII key (up to 128 characters) and persist it with the exact arguments before the first call. Missing, empty, whitespace-only, or malformed keys are rejected before an upstream request is sent. The server echoes your key in the result. Clients that previously omitted this argument must now supply it. Retry a lost response with the same key, identical arguments, and the same credential. Never generate a replacement key for an uncertain outcome: that starts a new operation and can create duplicate exposure. Reconcile ordinary orders through client_order_id when available. See Idempotency for the endpoint’s replay behavior. Bulk operations (cancel-all-account-orders, close-all-account-positions) can return status 202 while work remains. Retain the original arguments and key, wait for retry_after_seconds, then repeat the call to advance it. All trading writes advertise destructiveHint: true and idempotentHint: false. These conservative hints cover both exposure changes and removal or replacement of protective orders. An HTTP PUT method alone does not make a mutable exit batch safe to repeat. For writes without an idempotency key, read current state and reconcile an uncertain outcome before submitting another write. Read tools advertise read-only and idempotent hints.

​
Rate limits

MCP tool calls consume the same per-key, per-user, and platform budgets as direct REST requests; see Errors and rate limits. The MCP host additionally applies the same per-IP abuse ceiling as the REST hosts (about 300 requests per minute per IP). A rejected request returns status 429 with a Retry-After header and is always safe to retry.