Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
Eight testers, one repo, one staging environment. Right now everybody has stdio in their editor and their own checkout. It works, but nobody can ask about a run somebody else did, and the answers people get differ depending on how stale their branch is.
Is there a reason not to just host one server and point everyone at /mcp?
Accepted answer
We run both and they are not really alternatives, they answer different questions.
The hosted server owns the shared history: runs, artifacts, schedules, insights. That is what you want everyone pointed at, and it is the half your current setup is missing — a stdio server reads the runs in that person's .sdods/ and nothing else.
The local stdio server owns the working tree: the features on your branch, the steps you just wrote, lint against your changes. That cannot be hosted, because the files are not there.
So: register both. The catch is that install always writes the key sdods, so running it twice just overwrites the first entry — you get one server, not two. Let the installer write the local one and add the hosted one by hand under a different name:
sdods mcp install claude -p demo-shop -e staging --fileclaude mcp add -s project --transport http sdods-hosted https://sdods.example.com/mcp --header "Authorization: Bearer $SDODS_TOKEN"sdods mcp install claude --http-url https://sdods.example.com/mcp --print gives you the same snippet if you would rather paste it into .mcp.json and rename the key there.
Give the hosted one read scopes only. The local one is you, on your machine, and can do what you can do.
Do not use sdods mcp --http for the shared one. That mode takes a single bearer token and has no notion of who is calling or what they may reach; it exists for a development box.
The web server is the multi-user path: it serves MCP at /mcp, checks real tokens, and filters the tool list by the token's scopes.
sdods serveEverything else — the dashboard, run detail, the scheduler — comes with it, which is usually the point at which a team stops thinking of it as an MCP endpoint.
One thing we got wrong at first: we pointed the hosted registration at the wrong project and nobody noticed for a week, because the tools were all there and the answers were merely about a different suite.
Put -p and -e in the registration and then check them from inside the client once — project_list and project_get_config will tell you what the server thinks it is serving.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.