Connect

Two ways in: an HTTP endpoint, or a local server.

There are two transports and both are live. Choose by whether your agent can start a local process.

1. Over HTTP, nothing to install

POST JSON-RPC to https://swapmos.com/mcp. This is the streamable-HTTP transport: one request, one response, no handshake to open first and no state kept between calls. It is the only workable shape for a hosted agent, a serverless function or a script, none of which can spawn a subprocess.

List the tools

curl -X POST https://swapmos.com/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Call one

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "list_markets",
    "arguments": { "search": "eth" }
  }
}

The reply is a JSON-RPC result whose content is one text part holding the JSON the tool produced. A failure comes back the same way with isError set, rather than as a transport error that would lose the reason.

A failure, which is still a valid reply

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "isError": true,
    "content": [{ "type": "text", "text": "{\"error\":\"...\",\"code\":\"unauthorized\",\"retryable\":false}" }]
  }
}

initialize is answered if your client sends it, but it is not required. You may call tools/call first.
ping returns an empty result, which makes a cheap health check.
resources/list and prompts/list return empty lists rather than an error, so a client that probes for them is not left interpreting a failure.
An unknown method comes back as JSON-RPC error -32601, naming the methods that do exist.

Open https://swapmos.com/mcp in a browser. A plain GET returns the whole surface as JSON: every tool, its schema, the server instructions and the full error catalogue. It is the fastest way to see what is here without writing a client first.

2. As a local server over stdio

A desktop client launches an MCP server as a subprocess and talks to it over standard input and output. The mcp/ folder in the Swapmos repository is that server. It is backed by the same tool definitions as the HTTP endpoint, so a tool cannot exist in one and be missing from the other.

1Build it. In the repository: cd mcp, then npm install, then npm run build.
2Add the block below to your MCP client's config file, with the absolute path to the built file.
3Restart the client. The Swapmos tools appear in its tool list.

Client config

{
  "mcpServers": {
    "swapmos": {
      "command": "node",
      "args": ["/absolute/path/to/swapmos/mcp/dist/index.js"],
      "env": {
        "SWAPMOS_API_URL": "https://swapmos.com"
      }
    }
  }
}

That is read-only. To trade, add the two credentials on the next page as environment variables in the same block.

Which one to use

	HTTP	Local server
To install	Nothing	Node, and one build
Credentials	Headers, per request	Environment, once
Suits	Hosted agents, scripts	Desktop clients
Without a key	Trading tools listed, and refused	Trading tools not listed

That last row is the only real behavioural difference. Over HTTP a client lists the tools once and may call them much later with different headers, so every tool is always listed and a credentialed one fails clearly when called without them. The local server knows at startup whether a key is configured, so it does not register tools it could never run.