Service Model
What This Service Is
Section titled “What This Service Is”This is a cloud-hosted remote MCP service. You are connecting to it over HTTPS via OAuth or Bearer token. The service runs on managed cloud infrastructure — you do not have access to the server.
Key facts:
- The server is a multi-tenant cloud service — many users connect simultaneously, each with isolated sessions
- Your FIX trading session runs server-side — you interact with it exclusively through MCP tools
- Sessions are created on-demand when you authenticate and idle-timeout after 30 minutes of inactivity
- State (positions, orders, risk counters) is rebuilt automatically from the broker on each new session
What You CAN Do
Section titled “What You CAN Do”All interaction happens through MCP tools:
| Action | Tool |
|---|---|
| Check connectivity and status | check_health |
| Reconnect TRADE FIX session | reconnect_trade_session |
| Reconnect QUOTE FIX session | reconnect_quote_session |
| Change config (mode, risk, account) | reset_session |
| View positions, orders, quotes | get_positions, get_orders, get_quote |
| Place/modify/cancel orders | place_order, modify_order, cancel_order |
| Access documentation | get_knowledge |
What You CANNOT Do
Section titled “What You CANNOT Do”The user has NO access to the server infrastructure. Never suggest any of the following:
- ❌ SSH into the server
- ❌ Restart processes (PM2, systemd, Docker, etc.)
- ❌ Check or edit environment variables
- ❌ Read server logs or files
- ❌ Modify server configuration files
- ❌ Access Docker containers
- ❌ Run shell commands on the server
- ❌ Check server memory, CPU, or disk usage
- ❌ Access databases directly
The user only has a URL. That is their entire interface to the service.
Troubleshooting Guide
Section titled “Troubleshooting Guide”When something goes wrong, follow this escalation path using only the available MCP tools:
Step 1: Diagnose with check_health
Section titled “Step 1: Diagnose with check_health”Always start here. The response tells you:
fixState: TRADE session status (“ACTIVE” = connected, anything else = problem)quoteSession.state: QUOTE session statusoperatingMode: paper/live/readonlyriskLimits: Current risk configurationkillSwitch: Whether trading is halted
Step 2: Reconnect if needed
Section titled “Step 2: Reconnect if needed”| Symptom | Action |
|---|---|
fixState != “ACTIVE” | Call reconnect_trade_session |
quoteSession.state != “ACTIVE” | Call reconnect_quote_session |
| Both sessions down | Reconnect trade first, then quote |
Common causes of disconnection:
- Weekend market closure (Fri evening → Sun evening)
- Broker maintenance windows
- Network interruptions (transparent to user)
- Session idle timeout (30 minutes without MCP requests)
Step 3: If reconnect fails
Section titled “Step 3: If reconnect fails”If reconnect_trade_session or reconnect_quote_session returns an error:
- Wait 10-30 seconds and try again (broker may be temporarily unreachable)
- Call
check_healthto see the current state - If the problem persists, it is likely a broker-side issue (maintenance, outage)
Tell the user:
- “The broker’s FIX server appears to be unreachable. This is usually temporary.”
- “Markets may be closed (weekends: Friday evening to Sunday evening).”
- “Try again in a few minutes. If the issue persists, check with your broker.”
Step 4: Configuration changes
Section titled “Step 4: Configuration changes”If the user needs to change trading mode, risk limits, broker server, or account:
- Call
reset_session - After reset, instruct the user to go to Settings → Connectors → Disconnect → Reconnect
- The browser will open the configuration form for new settings
Step 5: When nothing works
Section titled “Step 5: When nothing works”If all recovery tools fail and the issue persists:
- Do NOT suggest infrastructure actions — the user cannot access the server
- Tell the user: “The cloud service may be experiencing an issue. Please try disconnecting and reconnecting your MCP connector.”
- If that doesn’t work: “Please try again later. If the issue persists, use submit_feedback to report it.”
Common Scenarios
Section titled “Common Scenarios””Server is not responding”
Section titled “”Server is not responding””→ Call check_health. If it fails, the MCP session may have expired. Tell the user to disconnect and reconnect the connector.
”FIX session is down”
Section titled “”FIX session is down””→ Call reconnect_trade_session. This is normal after weekends or idle periods.
”Quotes are stale or missing”
Section titled “”Quotes are stale or missing””→ Call reconnect_quote_session, then subscribe_quotes or get_quote to refresh.
”Kill switch activated”
Section titled “”Kill switch activated””→ Call check_health to confirm. The user needs to reset_session and reconfigure with different risk parameters or reset the kill switch.
”Wrong mode or risk limits”
Section titled “”Wrong mode or risk limits””→ Call reset_session to trigger re-authentication with new settings.
”Tool calls return authentication errors”
Section titled “”Tool calls return authentication errors””→ Token may have expired. Tell the user to disconnect and reconnect the MCP connector to re-authenticate.