Skip to main content

​
Client shows no tools / server fails to connect

1

Register through the CLI

Use yellow-pro setup claude-code (or claude mcp add directly) rather than editing config files by hand. Claude Code reads MCP config from ~/.claude.json, not ~/.claude/settings.json.
2

Check the PATH

The client spawns the server without loading your shell profile, so yellow-pro-mcp must be on the client’s PATH. Check with which yellow-pro-mcp. If the installer printed a PATH hint, add that directory to your profile and restart the client.
3

Restart the client

Servers connect at session start, so restart the client after changing any MCP config.
4

Verify the server starts

Confirm the server itself runs:
A healthy response contains a serverInfo block and exits cleanly.

​
Some tools are missing

Check YELLOW_PRO_MODULES character by character. Unrecognised names are silently dropped with no warning, so a plural typo like markets,account leaves you with account-only tools. The only accepted tokens are market, account, and trading. If trading tools specifically are absent, YELLOW_PRO_ENABLE_TRADING is not set to true.

​
Authentication errors

invalid_api_key Private tools need all three of YELLOW_PRO_API_KEY, YELLOW_PRO_API_SECRET, and YELLOW_PRO_APP_SESSION_ID, and they must match the environment you are hitting. Staging keys do not work on production, and vice versa. If you registered with yellow-pro setup hermes, the credentials were almost certainly not written — see the hermes caveat. invalid_timestamp Your machine clock is more than a few seconds off the exchange’s. Sync it:
Permission / 403 errors on a tool that otherwise works The API key is missing a scope. Check it against the scope table — reads and trades are separate scopes, and spot and futures are separate again.

​
Trading commands fail with “trading is disabled”

Set YELLOW_PRO_ENABLE_TRADING=true in the MCP client’s env config. This is intentional.
Do not work around this by calling the REST API directly. The flag exists so that order placement is a deliberate action. Read Risk and safety first.

​
Empty results instead of data

Almost always a timestamp unit mismatch. The three formats in use — milliseconds, Unix seconds, and RFC3339 — vary per tool, and the wrong one returns an empty set rather than an error. See the timestamp table.

​
Error behaviour worth knowing

Rate-limit responses are thrown straight away — there is no retry and no backoff. Lowering YELLOW_PRO_RATE_LIMIT_MS therefore converts throttling into hard failures rather than slower requests. The default is 100 ms.
There is no configurable timeout.
The exchange sometimes returns an error body with a 200 status. The client converts these into thrown errors, which is the right behaviour but will look different from raw curl output if you are comparing the two.
If the perpetual side is unavailable, get_markets returns {"perp":{"unavailable":"..."}} rather than erroring — so an agent may report that no perpetual markets exist. Check for that key before believing an empty list.

​
Still stuck

Contact support, or open an issue on github.com/layer-3/yellow-pro-mcp. Include the serverInfo.version from the handshake above so the version you are running is unambiguous.