@youspot/mcp

The YouSpot MCP server, for clients that cannot reach it directly.

YouSpot runs a remote MCP server over streamable HTTP at https://youspot.com/mcp/v1. Modern clients connect to that URL and need nothing installed. Plenty of clients still only launch a local process and talk to it over stdin and stdout, and for those this package is the server: it reads newline-delimited JSON-RPC from stdin, forwards each message to the remote endpoint, and writes what comes back to stdout.

npx @youspot/mcp

Configure a client

{
  "mcpServers": {
    "youspot": {
      "command": "npx",
      "args": ["-y", "@youspot/mcp"],
      "env": { "YOUSPOT_TOKEN": "..." }
    }
  }
}

If your client speaks streamable HTTP, skip this package and point it at https://youspot.com/mcp/v1 instead. One less moving part.

Credentials

initialize, ping, tools/list and resources/list answer without one, so a client can handshake and read the whole tool surface before anyone signs in. tools/call needs a bearer token in YOUSPOT_TOKEN.

Mint one at https://youspot.com/user/mcp, or run the OAuth 2.1 flow, which is walked through with runnable requests at https://youspot.com/auth.md.

Other servers

| Flag | Endpoint | What it is | | ------------------ | -------------- | --------------------------------------------- | | --server=product | /mcp/v1 | one member's own CRM, the default | | --server=docs | /mcp/docs | the public documentation, no credential | | --server=sandbox | /mcp/sandbox | the read tools over a demo account, no signup |

--url <endpoint> points at anything else, for a staging deploy.

Notes on the transport

Three things this has to get right, and each one is a way a naive bridge breaks:

• stdout carries protocol messages and nothing else. Every diagnostic goes to stderr. A stray log line on stdout is a parse error in the client.
• A notification gets no reply. The remote answers 202 with no body for any message without an id, and writing anything back for those desyncs the client.
• Replies may arrive as an event stream. The remote may answer text/event-stream rather than a single JSON object, so data: frames are unpacked and each message is written on its own line.

Requests are forwarded one at a time in the order they arrive, and any Mcp-Session-Id the server issues is carried on every later request.

A request that cannot reach the server comes back as a JSON-RPC error rather than silence, so a client waiting on an id is never left hanging.