Use case · MCP
MCP gave your agent tools. Something still has to say who may use them.
The protocol solved discovery and transport: a server lists its tools, a client calls them. What it deliberately leaves open is everything after that — which caller may see which tool, what happens before a destructive one runs, and where the record of it goes. Connect an MCP server to CoreBase and it becomes a source with the same rules as any other.
What's missing when you wire one up directly
Point a client at an MCP server and you get every tool it lists, for every caller, with no distinction between reading a page and deleting one. That is fine on your laptop. It stops being fine the moment the agent is serving other people, because three questions have no answer:
- Who is this for? One token authenticates the integration, so every user of your product shares whatever it can reach.
- Which of these change things? Most servers don't say, so a careful client has to hide everything and a careless one runs everything.
- What just happened? The call and its result live in a transcript, not in a record anyone can query six months later.
Connected as a source, governed like everything else
An MCP server is a URL that lists tools and needs credentials — the same shape as an API connection. Treating it as one means nothing had to be invented for it: every control that already existed applies on the day it's connected.
Per-caller tool lists
The tools from this server are added to a request only when that caller may reach this source. Someone scoped elsewhere never sees them at all.
Read-only enforced by declaration
With writes off, only tools annotated read-only are exposed. Undeclared counts as a write — fail-closed, and the connection test tells you exactly how many tools were hidden and why.
Rules on real tool names
“Refunds over $100 need approval” or “never call this one” are written against the tool the server actually publishes, and evaluated with the arguments the model produced, before the call goes out.
Held for a person, bound to the call
A held action is stored whole. Approving runs exactly what the reviewer saw — the model is never asked to try again, so it can't come back with different arguments.
Both halves audited
What ran and what was stopped, each stamped with the version of your rules in force at the time.
About that read-only rule
It is worth being blunt about the trade this makes. MCP has an annotation a server can use to mark a tool as read-only. Many servers don't set it. When writes are off, we expose only the tools that declare it — which means some genuinely harmless reads stay hidden, and you will notice.
The alternative is guessing from names, and the failure modes aren't symmetric: hiding a read is an inconvenience you can see, and running an undeclared write is a thing you find out about afterwards. So the panel says plainly how many tools were hidden and that the server is the one that has to declare them.
What isn't supported yet
Servers that accept a bearer token or custom headers work today. OAuth-protected servers don't — the connection test detects it and says so, instead of letting you debug a token that was never going to be accepted. Local and stdio servers are out by design; for systems inside your own network, the open-source CoreMCP bridge runs there and connects outward.
Questions people ask
How do you decide which MCP tools are read-only?
By what the server declares. MCP lets a tool carry a readOnlyHint annotation; when writes are off, only tools that declare it true are exposed. A tool that says nothing counts as a write and stays hidden — including some that are genuinely reads. That's deliberate: an annotation is a fact, a tool name is a guess, and guessing in the permissive direction is how an agent ends up deleting something.
Does the MCP server see who is asking?
It can. A connection's headers accept the verified end-user identity as a template, so each request carries the person it is for, and any identifying argument can be pinned server-side and hidden from the model. What the server does with that is up to it — most public MCP servers today authenticate the integration, not the individual, which is exactly why an org-level token is fine for an internal assistant and wrong for a customer-facing one.
Do you support MCP servers that require OAuth?
Not yet. Servers that accept a bearer token or custom headers work today. If a server answers with a 401 pointing at protected-resource metadata, the connection test says so plainly rather than leaving you hunting for a typo in a token that was never going to be accepted.
What about stdio or local MCP servers?
Not supported, on purpose — a hosted tenant shouldn't be able to point the platform at a local process. For anything inside your own network, the open-source CoreMCP bridge runs there and connects outward instead.
Can I turn individual tools off?
Yes. A connected server's tools are listed and can be enabled or disabled one by one, and rules can name a specific tool — so "notion__delete_page needs approval" is written against the real name, not a category.
Connect one and see what it exposes
Add an MCP server, leave writes off, and look at what survives the read-only gate. Free to start, no card.