MCP server

Pipsocket's MCP server lets an AI app read and trade your MT5 accounts, and set up TradingView hooks, through tools. You add one URL to the app, sign in to Pipsocket in your browser, and tick what it may do in each workspace. There's no API key to paste: the app signs in with OAuth.

https://mcp.pipsocket.com/mcp

It's a remote server (Streamable HTTP), so it works from apps on the web, like Claude and ChatGPT, as well as from desktop and command line apps. MetaTrader 5's own MCP server is local: it runs with the terminal on your computer. Pipsocket's is hosted, for the terminals Pipsocket runs for you, so apps on the web can reach it and your computer can be off.

Pass-through, like the APICopy Anchor Link

The trading tools are the REST API, one tool per call:

• A tool sends exactly one REST request, with your arguments as they are. Nothing is adjusted, split, retried or confirmed on the way, and Pipsocket sets no risk limits of its own: the call does what it says, on accounts that may be live.
• The answer is the REST answer: its status, its Retry-After and its body. A 2xx never means filled: the body's state says what happened. See MCP tools.
• Trades are safe to retry with an idempotency_key, by the same rules as the REST API's Idempotency-Key. See retries and errors.

Pipsocket doesn't ask you to confirm a trade: tools that change things are marked so, and your app decides whether to ask you first. Check its permission settings before you let it trade.

Connect an appCopy Anchor Link

You need a Pipsocket account with a confirmed email address, in at least one workspace. Then add the server in your app.

The dashboard's sign-in page opens in your browser. If you're new, sign up from there; you can approve once your email address is confirmed.

Approve workspaces and scopesCopy Anchor Link

The approval page shows the app's name, marked Unverified app (any app can register itself), and the host its answers go to, in large type. Check that host before you allow anything.

Below it is a grid: one row per workspace you're in, one column per scope the app asked for. Tick the workspaces it may use and what it may do in each:

• Read comes first. Ticking trade or manage ticks read in that row; unticking read clears the row.
• Members read only. In a workspace where you're a member, trade and manage are greyed out.
• Nothing is ticked to start with, unless the app already has a connection: then its current ticks are shown, with a notice that this replaces it. Anything you untick loses access.
• Up to 20 workspaces in one connection. Workspaces you make later aren't added: connect again to add one.

Then choose Allow. Deny sends the app away with nothing.

One connection is one app for one person, across the workspaces you ticked. Its rights are what you ticked, cut to your role as it is now: if you're made a member of a workspace, the app can only read there from its next token on. Connecting the same app again replaces the old connection once the new one is in use.

Getting more laterCopy Anchor Link

The app sees every tool your best role across its workspaces allows, whatever you ticked, and each tool's description says the scope it needs and where. A call the connection can't make is refused with the workspace and scope it needs (see errors): connect again from the app and tick that box. Lowering or removing is done in Connected apps, without the app.

Connected apps and revokingCopy Anchor Link

Your connections are under your name at the bottom of the dashboard's sidebar, in Connected apps: each app, its host, when it connected and was last used, and its workspaces with their scopes. For each workspace you can stop trade or manage, or remove the workspace; Revoke disconnects the app everywhere.

A workspace's Settings list its connections too. Owners and admins see everyone's and can take the workspace out of anyone's connection (not revoke the whole connection, which may cover workspaces they don't run). Members see their own, and can take the workspace out of them.

A connection ends, for good, when:

Account and hook tools stop at once. Trading tools can keep working for up to 5 minutes, the life of an access token, and that includes lifting the kill switch. Calls already sent when it ends may complete. To use the app again, connect it again.

Ending a connection doesn't touch what it set up:

• Hooks it made keep trading when alerts arrive, and a hook URL it was given keeps working. Pause or delete the hook in the dashboard, or rotate its URL, to stop them.
• Trades it placed stay open. To stop trading on an account at once, engage the kill switch from the dashboard or the API, and revoke the connection too: until its token runs out, an app with trade could lift it. The kill switch blocks new exposure, then closes and cancels what it can; read the account afterwards to see what's left.

What isn't over MCPCopy Anchor Link

For app buildersCopy Anchor Link

Everything a standard MCP client needs is discovered from a first, unauthenticated call:

• Protocol: MCP 2026-07-28, and for apps that open with initialize, 2025-11-25 and 2025-06-18. Every request is a POST /mcp with its own access token, in either era; there's no session, and answers are JSON (no event streams). A request carrying 2026-07-28 request metadata is served as that version. An initialize gets the version the app asked for when it's one of those two (otherwise 2025-11-25), the tools capability, and no Mcp-Session-Id; every later request must carry MCP-Protocol-Version. 2025-03-26 and its batches aren't served, so a request without that header is refused 400. GET and DELETE answer 405. server/discover lists every version above, and an unknown version is refused 400 with UnsupportedProtocolVersionError listing them too. No tool asks the app for input mid-call (multi round-trip). Apps on 2025-11-25 or 2025-06-18 get tools and ping only: resources, prompts, logging and completions aren't offered there, and a call carrying inputResponses or requestState is refused as invalid params. A request with an Origin header is refused 403, so the server can't be called from a web page.
• Discovery: a call without a token answers 401 with WWW-Authenticate: Bearer resource_metadata="https://mcp.pipsocket.com/.well-known/oauth-protected-resource/mcp", scope="read trade manage offline_access". That metadata names the authorization server, https://app.pipsocket.com/api/auth, whose own metadata is at https://app.pipsocket.com/.well-known/oauth-authorization-server/api/auth.
• Registration: dynamic client registration (/api/auth/oauth2/register), with token_endpoint_auth_method none, client_secret_basic or client_secret_post. Client ID metadata documents aren't accepted yet.
• Authorization: authorization code with PKCE (S256), naming resource=https://mcp.pipsocket.com/mcp exactly. Ask for read trade manage offline_access: the person picks per workspace. prompt=create isn't offered.
• Tokens: access tokens are JWTs (typ: at+jwt) for that resource, and live 5 minutes. Refresh tokens live 30 days and rotate on every use, with no grace period: refresh one at a time, since a refresh token used twice ends the connection. Bearer tokens only, sent in the Authorization header; DPoP isn't offered.
• Revoking: /api/auth/oauth2/revoke (RFC 7009) with either token ends the connection.
• When the token route fails: a 503 (temporarily_unavailable) to a code exchange means the code is spent: start the authorization again. A 503 to a refresh may come before or after the refresh token was used up: send the same refresh token once more, and if that answers invalid_grant, connect again. invalid_grant always means connect again. An HTTP 503 from /mcp itself is never the token's fault: try again, without refreshing.

The token is checked on every request. The workspaces and scopes it carries are cut to the person's role when it's issued, and account and hook tools also check the connection as it is now, so a lowered scope or a removed workspace takes effect at once there.