MCP Server
Operation tools
Beyond reading your docs, the server exposes one tool per endpoint that performs the real HTTP call. An agent can integrate against your API by calling it, not by imagining it.
Operation tools are not previews or dry runs. A tool call hits your live API with the credentials you configure, and a write endpoint writes.
Point OCTRI_API_BASE_URL at a staging environment while you evaluate, and exclude destructive endpoints in SDK Studio if an agent should never reach them.
They follow SDK Studio
Operation tools are derived from the same configuration as your SDKs, which means they're already curated:
| SDK Studio setting | Effect on operation tools |
|---|---|
| Endpoint excluded | No tool for it. The agent can't call it |
| Method renamed | The tool uses your name |
| Marked deprecated | Surfaced to the agent |
| Base URL | The default target for calls |
An endpoint that doesn't belong in a public SDK usually doesn't belong in an agent's hands either. Excluding it once covers both.
Setup
They need two things beyond the project id: where to call, and what to call with.
{
"mcpServers": {
"my-api": {
"command": "npx",
"args": ["@octri/mcp"],
"env": {
"OCTRI_PROJECT_ID": "YOUR_PROJECT_ID",
"OCTRI_API_BASE_URL": "https://api.staging.example.com",
"OCTRI_API_KEY": "sk_test_...",
"OCTRI_API_KEY_HEADER": "X-API-Key"
}
}
}
}Without a base URL, the tools fall back to the Base URL set in SDK Studio's Output tab. With neither, they return an error rather than guessing.
See Configuration for every credential form.
Scoping what an agent can do
Three levers, in order of bluntness:
Agents are not adversarial, but they are literal. A tool named delete_all_users exists to be called, and "only in an emergency" is not something the tool description can enforce.
Treat the tool list as the set of things you're comfortable happening unattended.