RoboGNSS

NTRIP Caster MCP Server: Skip the Dashboard

Most of what you do in a caster dashboard is a chore: check that the bases are up, hand a login to a new machine, work out why a rover won't fix. RoboGNSS now runs an NTRIP caster MCP server, so you can hand those chores to the AI assistant you already work in — Claude Code, Cursor, VS Code — and get the answer where you are, without opening the dashboard. (MCP is the standard way AI tools plug into outside services; any assistant that speaks it can use yours.)

What you gain today

Every action passes the same ownership checks as the dashboard, and your plan limits still apply: ask for more than your plan allows and you get a refusal naming the limit, not a silent failure.

"Why won't my rover fix?"

The rover says FLOAT, the operator is on the phone, and you are working out which of four things broke: the base dropped, the login is wrong, the mountpoint has a typo, or the connection cap is full. That used to be a dashboard session and a couple of phone calls.

Now it is one question. The agent reads the base's status and flags, then runs test_rover_credential: given one of your stored logins, the caster dials its own public NTRIP endpoint as a genuine rover and reports what a receiver in the field would see: caster unreachable, invalid credentials, mountpoint not found, client limit reached, connected and waiting (the base isn't streaming), or receiving correction data.

That last one is the useful negative: the login and the base are both fine, so the problem is on the rover. The agent can usually tell you in one sentence whether to drive out to the base or re-enter a password.

With RoboDots, most of the setup goes too

A RoboDot has its own local API, so an assistant on your network can drive the hardware and the caster together. On the base: read its surveyed position, create the base station from it, and confirm the stream arrived. On the rover: put the unit in rover mode, point it at the right mountpoint, and watch it reach a fix — the back-and-forth between caster and hardware that usually means a phone call. One step stays manual by design: NTRIP passwords are entered on the device itself, never handed around by an agent.

What it deliberately cannot do

A key that can operate your bases is a key that can be leaked, so four things stay behind a signed-in session: configuring forwarding to Onocoy or any other caster, deleting a base station, applying a PPP result to a declared position, and managing keys — a key cannot make more keys. A leaked key can misconfigure an account; it must not be able to destroy one or start a feed to another caster in your name. If one leaks, revoke it in Settings and anything using it stops immediately.

Which assistants can connect

Claude Code, Cursor, and VS Code with Copilot work today, as does anything else that reaches a remote MCP server with an API key — Zed, Windsurf, Codex CLI. Claude Desktop needs a small local bridge (mcp-remote), because its connector screen expects a sign-in flow rather than a key. claude.ai and ChatGPT cannot connect yet: they reach remote servers directly, so a bridge on your machine doesn't help them, and they accept only a sign-in flow — which we have not built.

Getting connected

Agent access works on every plan, free included; your plan decides what the tools may do, not whether you can connect. Sign in at app.robognss.com/settings, create a key, and copy it once — the connect guide has the full tool list, the configuration for each assistant, and what the common error codes mean. Then ask your agent the question you would have asked support: "which of my bases are healthy, and why can't the new tractor get a fix?"

Start with a free base station.