Skip to main content
The server checks your credentials before it opens the transport, so almost every problem shows up as a startup line saying what is wrong. Read that line first.

​
Find the log

Everything goes to stderr, because stdout carries the protocol. The file is named after the server as you named it, so look for that if you did not call it parlayx. A healthy start writes one line, then one per call:

​
No tools appear

The line names the variable and its character count, never its value:
Whitespace is trimmed for you, so a wrong count means a truncated or doubled paste.
The values are well-formed but the API rejected the signature. Confirm the key id belongs to the seed you paired it with, and that the key has not been revoked. See Authentication.
The client never launched the server. Check that the command is npx with ["-y", "@parlayx/mcp"], and that both npx and Node 20 or newer are on the PATH the client sees. A GUI client does not inherit your shell’s PATH, so a Node installed through a version manager may be invisible to it.
Clients read their server list at launch. Restart the client.

​
Every call comes back unauthorized

A drifted host clock looks exactly like a bad key, because the signature covers a timestamp the API checks within 30 seconds of its own. The server tells the two apart: on the first rejection it reads the server clock and reports the offset.
Inside the window you get the rejected-key message instead, so the message you receive is the answer. Fix a drifted clock with network time, not a new key.

​
The trading tools are missing

Both halves of the gate have to hold. Call whoami to see whether your key carries trade; if the opt-in is set and the capability is missing, the server says so at startup and serves the read tools alone. Both are read before the transport opens, so a change takes effect on the next restart, never mid-session.

​
Calls fail intermittently

A 429 or any 5xx says the condition is transient. Retry. A read is always safe to retry; a submit is safe only when you pass the same idempotencyKey, because an omitted key is minted fresh every call and a retry becomes a second order.

​
Reproduce it outside your client

It writes the startup line and waits for JSON-RPC on stdin, which is a working server. If that succeeds and your client still shows nothing, the problem is the client’s configuration. To list and call tools against that same configuration, use the MCP Inspector:
Point --config at a file with the same mcpServers shape as the Claude Desktop configuration, so your credentials stay in a file rather than in your shell history.