MCP

TRUE’s MCP server is the most direct integration path available. Every data tool the TRUE platform uses internally — prices, news, on-chain intelligence, user context — is exposed through a single Model Context Protocol endpoint that any MCP-compatible AI client can connect to in minutes. No secondary API, no reduced feature set: external clients and internal agents operate on exactly the same surface.

What it is

The TRUE MCP server implements the open Model Context Protocol standard over HTTP. It accepts standard MCP tool-call requests, authenticates them against TRUE’s token layer, executes the requested tool against live data, and returns structured results. The server is stateless per request; session continuity is the client’s responsibility. Because the MCP surface is identical to what TRUE’s own agent system uses, responses carry the same data quality, latency characteristics, and error semantics that power every TRUE chat answer.

Who it’s for

• Developers building AI-native applications that need reliable, real-time financial data without managing their own data pipelines.
• Partners embedding TRUE intelligence inside research desks, trading dashboards, or white-label AI products.
• Power users extending Claude Desktop, Cursor, or any MCP-compatible editor to answer financial questions using TRUE’s live data.

How it works

Connecting

Point any MCP-compatible client at the TRUE MCP endpoint and authenticate with a TRUE bearer token. The transport is standard HTTP; no WebSocket, no SDK install required. The full tool catalog is discoverable via the standard MCP tools/list call immediately after connection.

Authentication flow

An MCP key is the fastest path. Mint one in the TRUE app under MCP & API → Setup, send it as a Bearer header, and the connection is live. Keys start with true_sk_, are shown exactly once, expire after 90 days by default, and can be pinned to an IP allowlist. There is no sandbox tier: an MCP key reads live data as you.

OAuth is the right choice for multi-user deployments — a research workspace shared across a team, or a consumer product built on top of TRUE. The OAuth grant binds an MCP session to a specific TRUE user, inheriting that user’s watchlist, points balance, and permission scope. The full redirect flow, PKCE requirements, and token refresh cycle are documented on the Authentication page.

Making a tool call

Every call follows the standard MCP protocol shape: a method of tools/call, a name matching one of the catalog entries, and an arguments object. The server validates the argument schema, checks the token’s scope against the requested tool, executes the tool against live data, and returns a structured result. If upstream data is unavailable, the server returns a structured error — never a hallucinated payload.

Connecting from Claude Desktop

Point Claude Desktop at the MCP endpoint above with a TRUE bearer token as the authorization header. After restarting Claude Desktop, the TRUE tools appear under the MCP tools menu and are callable from any conversation. Setup takes under two minutes.

Connecting from Cursor or Continue

Both editors accept the same MCP server configuration shape as Claude Desktop. Add the TRUE server entry to your editor’s MCP configuration and restart. The tools are immediately available to the in-editor assistant.

For Developers

The MCP server uses standard HTTP transport and accepts the MCP tools/call wire format. Clients connect by pointing at the TRUE MCP endpoint with a scoped bearer token as the authorization header. Full connection details, token issuance, and the complete tool catalog with required scopes are in the Authentication and Partner Integration docs.

Available tools

The MCP catalog mirrors the tools available to TRUE’s internal agent system. Every tool below is callable from external clients with the appropriate scope.

Trading through MCP

MCP is not read-only. With the trade:execute scope an assistant can place a spot trade or a leveraged perp order on your account. What it can never do is execute one on its own: every order is approved by you, in the TRUE app, before anything is signed.

How an order actually flows

1. The assistant calls the tool once, with the trade it wants to make.
2. It gets back awaiting_user_confirmation and an approvalId. Nothing has been signed and nothing has been sent.
3. A confirmation banner appears in your TRUE app. The app must be OPEN in a browser for this to reach you.
4. You approve or you do not.
5. The assistant polls with the SAME approvalId, roughly every five seconds. The state moves to approved_executing while your app signs and submits.
6. It ends at executed with the on-chain transaction signature, or at trade_failed_in_app.

Two things that will break your first attempt

• Perp market symbols have no separator. It is SOLUSDC, BTCUSDC, ETHUSDC, XAUUSDC. Not SOL-PERP, not SOL-USD, not SOL. Call list_perp_markets and use exactly what it returns.
• You must have opened perps in the app once. That is what provisions your non-custodial DEX account. Until then a perp order has no account to land in.

Perp size is given in base-asset units as a string ("1.5" SOL), not in USD. Spot trades are the other way round: an amount in USD. Pass reduceOnly: true to close or reduce rather than adding to a position.

When a bot should not use MCP

If nobody is at the keyboard, MCP is the wrong surface: the approval step is the whole design and it needs a human. For an unattended bot, use a trade key and sign orders yourself. See Trading API.

The rules it enforces

• Scope enforcement. Every tool call is checked against the scope the token carries. A connection without read:market cannot call a market tool, and one without trade:execute is never shown a trading tool.
• Schema validation. Argument shapes are validated before execution. Malformed arguments return a structured validation error, not a silent failure.
• Per-turn tool budget. A single call cannot exhaust the rate-limit bucket; per-tool limits exist independently of the per-token limit.
• Rate limits. Per key, by tier, with standard RateLimit-* headers and Retry-After on a refusal. See Rate Limits.
• Tool versioning. Breaking changes to a tool’s argument or response shape ship as new tool names, never as mutations to an existing tool. Existing integrations are not silently broken.
• Structured errors only. When an upstream (prices, on-chain data) is unhealthy, the affected tool returns a structured error payload. The server never fills a gap with a synthesized or cached value that could be mistaken for live data.

Safety, security & trust

Token revocation is instant. A compromised key can be revoked from the TRUE dashboard and the revocation propagates across the MCP edge within seconds. There is no grace window; a revoked key is refused immediately.

Audit logging is on by default. Every tool call made against a token is logged with a timestamp, tool name, sanitized arguments, and a trace ID. Logs are available for review.

No write surface. The MCP server is read-only. No tool in the catalog can move funds, place orders, or modify user state. Execution actions flow through a separate, explicitly opt-in path described in Agentic Trading.

One surface, no second-class copy. External clients call exactly the tools TRUE’s own agents call. There is no sandbox tier and no fixture mode, so what you build against is what ships. Point a short-expiry key at a throwaway account if you want to test without touching your own.

Why it’s well thought through

Symmetry between internal and external. TRUE’s own agent system and external MCP clients call the same tools against the same infrastructure. There is no second-class external API that receives stale or degraded data. This symmetry is a design constraint, not a marketing claim: any regression in the external surface is immediately visible in the product’s own chat.

Fail-fast semantics. The MCP server is designed to surface failures clearly rather than paper over them. A tool that cannot get live data returns an error the calling LLM can reason about — “prices are temporarily unavailable for this asset” — rather than a confident-looking but stale or fabricated response. This makes LLM applications built on the MCP more reliable, because the model receives a signal it can act on.

Narrow, composable tools. Each tool does exactly one thing. This keeps the context window cost per call low, the argument shapes simple, and the surface area for misuse small. Complex queries are composed by the calling LLM across multiple tools, not by a monolithic tool that over-fetches.

Versioning as a contract. Tool names are stable. When a tool’s behavior changes in a breaking way, a new tool name is published and the old name is kept for a deprecation window. Integrations are never silently broken by a server-side change.

For Partners

White-label MCP setup is available on the partner tier. Partner accounts provision tokens for end users from a shared dashboard, brand the OAuth consent screen with custom copy and logo, and inherit the full tool surface with SLA guarantees. Revenue share, onboarding flow, and contractual terms are on Partner Integration.

Common questions

Can I use the MCP server without a TRUE account? No. Every MCP call requires a bearer token issued to a TRUE account. Creating an account is free; generating a scoped key takes under a minute from the dashboard.

Does the MCP server support streaming responses? Individual tool calls return synchronous JSON responses. Streaming is available on the Chat endpoint, which uses the MCP tools internally and exposes results as an SSE stream. Use Chat for conversational flows; use MCP for direct tool access.

What happens if a tool is unavailable? The affected tool returns a structured error object with a machine-readable code, a human-readable message, and a retryable boolean. Permanent errors (bad arguments, scope denied) are not retryable; transient errors (upstream degraded) are. The calling LLM can route around the failure gracefully.

How do I know which scope to request for a given tool? The tools/list response includes a requiredScopes field for each tool. Request only the scopes your integration actually uses. Smaller scope sets reduce the blast radius if a key is compromised.

Can the MCP server execute trades or move funds? No. The MCP surface is read-only. Execution requires an explicit user signature via the separate Agentic Trading path.

What is the latency profile? Most tool calls complete in under 300ms from the edge. On-chain tools (memecoin holder queries, Solana RPC calls) can take up to 1.5 seconds under load. Price tools backed by the TRUE Quotes layer are consistently sub-100ms.

Do I need a separate key per client? No, but you should. A key is revocable on its own, so one key per client means you can cut off a laptop you lost without taking your server down with it.

Is there a webhook alternative to polling for price changes? Not through MCP. For live data use the streams instead of polling tools: the perps WebSocket and SSE feed on Realtime. There is no outbound user-registered webhook product today.

Are MCP calls included in my points earning? MCP calls do not earn points. Points are earned through in-app actions — swaps, streaks, referrals — as documented on Points & Rewards.

How do I report a bug in a tool response? Include the trace ID from the response header (X-Trace-Id) in a report to [email protected]. The trace ID links directly to the server-side execution log for the call.

Related features

• Agents — the internal agent system that calls MCP tools to answer chat questions.
• Authentication — OAuth, scoped keys, JWT, and token rotation.
• Rate Limits — per-tool and per-tier quotas in full.