Bring your own assistant, through the same door as everyone else
If your team already works with an AI assistant, it can work with Rutba through the Model Context Protocol, on your organization’s own key. It gets six tools, meets the same three checks, and can propose a change but never make one.
· 3 min read
Plenty of teams will not wait for us. They already have an assistant they like, on their laptops or in the tools they write in, and what they want is for it to be able to read their business — not for us to hand them a second assistant with a second habit to learn.
The Model Context Protocol is the standard way to give an assistant tools, and Rutba’s suite has a server for it. What matters is not that the server exists. It is that it is not a second way in.
Six tools, and what each one may do
| Tool | What it does |
|---|---|
list_agents | The named agents — one per app, one per area — and whether this key reaches each, with the reason for any that is closed |
search_endpoints | Finds calls the key’s holder may make, using the same filter the suite’s own assistant uses |
describe_endpoint | One call’s description, its arguments, and whether it reads or changes something |
read | Makes a read-only call as the key’s holder |
propose_change | Writes nothing. Files a plan whose steps show the exact request each would send, for a person to approve |
list_proposals | The proposals this key has filed — waiting, approved, run, or stopped and why |
The key is the control
The server works on your organization’s own key, and the key’s scopes are the limit nothing in the server can get around. Every call goes out with the key holder’s authority and meets the same three checks a browser meets — is the organization licensed, may this holder do it, does it exist. The first post in this series explains those checks; the point here is that an outside assistant meets them in exactly the same place.
Searching is filtered the same way. A call the key’s holder could not make is never listed, so an outside assistant cannot talk itself into trying one. And naming an agent narrows the search to that part of the suite — it never widens what the key may do.
Read-only means the tools are not there
Connect it read-only and propose_change and list_proposals are not refused. They are not registered. A tool that is not there cannot be argued with, and an assistant that has been told “you may not use this tool” is an assistant being asked to behave — which is a request, not a control.
That property, and the two beside it — the credential is the real control, and changes are drafts unless somebody says otherwise — were not invented for the suite. They are copied from the protocol server Rutba Relay already runs, which lets an assistant draft and schedule posts with the same permissions a person has.
A proposal, not a change
Connected with changes allowed, an outside assistant still cannot change anything. It can propose. A proposal is a plan — every step with its exact request — and it lands in the same place Rutba Assistant’s own plans land, with the same approval screen and the same audit rows. A person approves it, request by request, and only then does a worker run it under the rules every plan follows.
There is deliberately no second write path.
That is the whole design in one line. Two ways to change records would be two sets of rules to keep in step, and the day they drifted, whichever assistant was on the looser one would be the one that mattered.
