Tools and MCP servers
Connect Rikoo to your systems through the Model Context Protocol, authenticated by a vault secret or by OAuth 2.1, and narrowed tool by tool.
Tools are what turn an agent from something that answers into something that acts. Rikoo speaks the Model Context Protocol: an MCP server reachable over HTTP, yours or a vendor's, is declared once in a project and then granted to the agents that need it.
Declaring a server
On the MCP Servers screen, Add a server asks for its address, its transport and its authentication, and Browse the library starts from a list of known servers. Test connection queries the server and fills the list of the tools it exposes. That list is refreshed only when you ask for it, and each discovery records what was added, removed or changed since the previous one.
| Transport | When to use it |
|---|---|
| Streamable HTTP | The default, and the transport of the current MCP specification (/mcp endpoint). |
| Legacy SSE | A server that still follows the 2024-11-05 specification (/sse endpoint). |
| Bare JSON-RPC | A tolerant server that answers JSON-RPC without the MCP handshake. |
A third-party stdio server cannot be declared: running it would mean letting the worker start a binary supplied by a tenant.
Authentication
| Method | How it works | When to use it |
|---|---|---|
| None | No credential is sent | A server on your network that does not authenticate its callers |
| Vault secret | A bearer token or an API key stored in the secret vault and attached to each call | An internal server, or a vendor that issues long-lived tokens |
| OAuth 2.1 | Authorization code with PKCE (S256 only), or client credentials when the server offers them. The tokens are sealed with the same envelope as the vault, kept with the server, and refreshed automatically | Hosted servers that accept only OAuth, such as Notion, Linear or GitHub |
For OAuth, Rikoo discovers the authorization server from the metadata the MCP server publishes and registers a client automatically, unless you enter a pre-registered client_id. The code is exchanged for tokens by the worker, never by the API server.
Narrowing the tools
Two levels restrict what can run:
- On the server, for the whole project. The tools ticked on the server's page are the project's ceiling. With every tool ticked there is no restriction, including for tools discovered later.
- On the agent's grant. Unticking a tool forbids it to that agent. As soon as one tool is unticked, the grant carries an explicit list, so a tool the vendor adds later stays blocked for that agent until someone allows it.
A grant with no restriction gives the agent every tool the project allows on that server.
In the Enterprise edition, a tool can also be configured to require human approval: the run waits for the decision before anything is sent. See Enterprise license.
Hiding a tool from the model is a usability choice, not a security control. The worker checks the agent's restriction again at the moment it opens the call, so a model that invents the name of a tool it was not granted gets a refusal, not an execution.
Health and large outputs
Each server has a Health probe, whose cadence can be set per server or turned off, and the Studio shows its last successful contact. After 3 consecutive failures, a circuit breaker stops calling the server for 1 minute, and longer (up to 10 minutes) if it stays down, so a dead server does not cost a timeout on every call. Call and connection timeouts can be set per server.
A large tool output does not fill the model's context. Beyond a size threshold, the full output moves to object storage, and the model receives a preview with the reference it needs to read the rest (read_tool_result).
Images and other media
Some servers return images or audio: a screenshot, a chart, a recording. By default these files are neither stored nor displayed. The switch Allow media (images, audio) from this server is set on the agent's grant, server by server. Once it is on, each file goes through the same admission policy as an attachment (type checked on the bytes, size limits), is stored, and is displayed in the agent's conversations. The model never receives the file itself, only a reference to it. The setting is frozen when a run is created.
The embedded servers
Every project comes with 2 servers that need no installation and no address:
- Workspace: list, read (page by page) and write files, run Python (
run_python) or a command (run_command). It has no network access. - Browser: navigate, read a page, fill a form. Its traffic leaves through a dedicated egress proxy that applies the same anti-SSRF guard as the rest of the platform.
They are off by default. An agent gets them through a grant, like any MCP server, and the tool restrictions, the circuit breaker, the health probe and the trace apply to them unchanged.
The workspace belongs to the conversation, not to a single run. Files the user attached appear under uploads/, which the agent can read but not modify; the agent works in work/ and puts what it returns to the user in outputs/. What it writes in both is saved to object storage as attachments of the conversation, at the end of each run. Each workspace runs under its own unprivileged user, in a directory no other conversation can read, with time, disk and process limits.
The workspace also requires a user identified by the surface the message came through: an anonymous widget visitor never gets it. On the widget it is closed by default, and the operator opens it deliberately by setting WORKSPACE_SURFACE_WIDGET to true. On the API, Slack and the Studio it is open.
A web page, a file, a vendor's API response: none of it is an instruction. The output of HTTP, MCP and knowledge tools and the descriptions of third-party MCP tools are framed as untrusted data before they reach the model, in one place for the whole platform. Framing lowers the risk of indirect prompt injection without removing it, which is why an agent served to the public loses its riskiest capabilities (see Guardrails).