> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myfundedperpetuals.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP Server

> Connect AI assistants and agents to the MyFundedPerps REST API through the hosted Model Context Protocol server.

## 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:

```
https://mcp.myfundedperpetuals.com
```

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](/idempotency) and
[Errors and rate limits](/errors-and-rate-limits) applies unchanged.

<Warning>
  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.
</Warning>

## 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](/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:

| Property | Value                                                             |
| -------- | ----------------------------------------------------------------- |
| Access   | Trade on all accounts, or read-only if the client requests `read` |
| Expiry   | 90 days after approval                                            |
| Ceiling  | 5 active sessions; a new approval revokes the oldest              |

<Note>
  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.
</Note>

### Sandbox

The sandbox has no OAuth flow. To point an MCP client at your
[sandbox](/sandbox) accounts, send an `fp_test_` key as a bearer header
instead (created in
[API Key Settings](https://myfundedperpetuals.com/settings?section=api-keys)
under the Test environment):

```
Authorization: Bearer fp_test_...
```

## Connect a client

### Claude Code

```bash theme={null}
claude mcp add --transport http funding-perpetuals \
  https://mcp.myfundedperpetuals.com
```

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:

```json theme={null}
{
  "mcpServers": {
    "funding-perpetuals": {
      "type": "http",
      "url": "https://mcp.myfundedperpetuals.com"
    }
  }
}
```

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](/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:

| Field        | Meaning                                                       |
| ------------ | ------------------------------------------------------------- |
| `status`     | The HTTP status of the underlying REST call                   |
| `request_id` | The `X-Request-Id` of the call, for support and debugging     |
| `body`       | The REST response, including `data` or the API error envelope |

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](/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](/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.