Connect your own tools

Nodrik investigates with Cloud Logging, Cloud Monitoring, Error Reporting, Cloud Run and (optionally) GitHub. Sometimes the answer to an incident is somewhere else entirely: a queue depth, a feature-flag state, a partner’s status endpoint, a figure only your own service knows.

You can point Nodrik at those, and there are two ways to do it. Both are optional; without either, investigations run exactly as they do today.

The two shapes

An MCP server you host. If you already run a Model Context Protocol server, give Nodrik its address and a credential and it will discover the tools that server offers. This is the better option if you have more than one thing to expose, because you add tools on your side without touching Nodrik.

A single HTTP endpoint. If running a server is more than the question deserves, declare one tool directly: an address, a name, a JSON Schema for its arguments, and a header secret. Nodrik POSTs the arguments as a JSON body and reads the answer.

Either way, the tool runs on your infrastructure, under your own credentials. Nodrik holds a credential you issued and calls an address you chose. Nothing about this changes what Nodrik has in your Google Cloud project: still four read-only roles, still nothing else.

Setting one up

This one needs an admin. Adding, testing and removing a tool source is the only part of configuration that does, and the reason is what it does rather than where it sits: Slack and GitHub are consent screens on apps we registered, where what you approve on somebody else’s page is the boundary. This stores a credential you issued and points Nodrik at an address somebody typed, whose answers land in an investigation transcript. That is closer in consequence to billing than to choosing a channel. Anybody in the workspace can see what is declared. See Your team.

In the console, Settings ▸ Your own tools ▸ Add a tool:

1. Name — what you will recognise it by.
2. Address — must be https:// and publicly resolvable. The credential travels with the request, so plain HTTP is refused, and so are addresses that are not a service of yours: IP literals, localhost, .internal, .local, and anything that looks like a cloud metadata endpoint.
3. Credential header — the header your server reads the credential from. Authorization is the usual answer; anything else works, as long as it is not a header Nodrik sets itself.
4. Credential — stored encrypted in Google Secret Manager, in a container scoped to your workspace alone, and sent only to the address above. It is never shown again and never written into an investigation report.

Then press Test.

Test is not optional, and it is the point

Nodrik only learns what your server offers when you press Test. Nodrik does not ask during an investigation — deliberately: an incident is the worst possible moment to be waiting on a tools/list from a machine that may be part of the incident.

So a source that has never been tested offers nothing, and the console says exactly that. A test reports, without running an investigation:

• Every tool Nodrik will be offered, under the name it will be called by.
• The sentence Nodrik is told about each one (see below).
• Every tool Nodrik will not be offered, and why — a name that cannot be declared, a schema that will not be passed on, or simply more tools than one workspace may declare.
• Whether your server answered at all, in plain words.

Re-test whenever you change what your server offers. Until you do, Nodrik keeps offering what the last test found — which is also what happens if a test fails: a server that is briefly down does not silently shrink what an investigation can look at.

Nodrik writes the tool description, not you

This is the one part of this feature that will surprise you, so it is worth being direct about it.

A tool description is an instruction to a language model. Nodrik already treats your log lines as untrusted input — a log line is data, and a compromised or careless service can put anything in one. A tool description is worse than data: it arrives in the part of the prompt that tells the model what to do.

So Nodrik discards the description your server sends and writes its own, from the tool’s name and its argument schema. What the model is told is a sentence like:

get shop status — this team’s own read-only tool, via Status API. Arguments: shop (string, required).

The console shows you that exact sentence, so there is no gap between what you can see and what the model gets. It is deliberately terse: it rides in the prompt of every step of an investigation, so the read-only-and-capped guarantee is stated once in Nodrik’s instructions rather than repeated on every tool.

What this means for you in practice: the tool NAME is how you tell Nodrik what a tool is for. Name it get_shop_status, not tool_7. Names are lower-case letters, digits and underscores, up to 40 characters, and Nodrik calls them with an ext_ prefix so they can never shadow one of its own tools.

Your argument schema is kept for its shape — types, argument names, requiredness, numeric bounds, short enum values — and stripped of its prose. description, title and examples do not reach the model at any depth.

The read-only guarantee

Three separate things, and all three hold:

Nodrik only ever calls tools. As an MCP client it can send exactly four messages: initialize, notifications/initialized, tools/list and tools/call. There is no code path in Nodrik that can name resources/read, resources/subscribe, prompts/get or sampling/createMessage. Resources and prompts are not “not used yet” — they are not implemented.

Nodrik never runs code you wrote. You declare tools Nodrik calls; you do not upload anything that executes inside Nodrik. That is a permanent line, not a phase — the alternative is a sandbox in the same process as your log lines.

Your tool result is treated like a log line. It is truncated to the same 4,000-character cap as every other tool result, and redacted for credential-shaped strings on the way in, before it reaches the model or the stored transcript.

Whether the tool itself is read-only is, unavoidably, your side of the line. Nodrik will POST to the address you gave it with the arguments the model produced. Point it at something that only reads.

What it costs you, and the limits

There is no charge for this. Your servers run in your own projects on your own bill, and connecting them is included on every tier. What it costs us is the paragraph below — a few hundred extra tokens in each prompt — which is why there are bounds rather than a “more is better” story, not why there is a price:

Limit	Value	Why
Tools declared, per workspace	10	Declarations ride in every prompt
Sources (servers or endpoints)	10	Each is an address Nodrik must call
Calls per investigation	5	An investigation is bounded work
Time spent waiting on your tools, per investigation	20 seconds total, 8 per call	An investigation has a deadline
Response read	64KB, then Nodrik stops reading	Nodrik will not be starved by a stream
Tool result kept	4,000 characters	The same cap as every other tool

Measured, for ten tools of a realistic shape — a readable name, three arguments: a workspace at the full ten adds about 900 input tokens per step, which over a typical investigation is roughly a third of a penny. That is under 1% of what one investigation is allowed to cost, and it comes out of that allowance rather than being added on top of it.

If your server does not answer within its budget, Nodrik says so and continues with the evidence already gathered. A slow tool of yours costs a call; it never costs the investigation.

What Nodrik never does

• Never sends any of its own credentials to your address. The only credential on the request is the one you gave it.
• Never follows a redirect from your address — a redirect is how a checked hostname becomes an unchecked one.
• Never puts your credential in a log line, a report, a Slack message or an API response.
• Never repeats an error body your server returns. If your server answers 500, Nodrik says “your endpoint answered 500” — the page itself is text from a machine we do not run, and it does not reach the model.
• Never keeps a session open between investigations. Each call is a fresh exchange that owns nothing on your side.

A follow-up question cannot reach them

Your tools are offered to an investigation, and to nothing else. When somebody asks Nodrik a follow-up in a Slack thread, the reply uses Nodrik’s own built-in tools only.

The reason is who starts each one. An investigation is started by your alert, in your project — your tool, called on your behalf, about your incident. A follow-up is started by anyone who can type in that Slack channel, and Slack carries no notion of who that is: a guest, a Slack Connect member from another company, and a read-only console user all post the same way.

Since we cannot verify what your tool does (see below), that is not a surface we are willing to point at it. It is enforced in the code rather than promised here: the function that answers a follow-up has no way to be given your tools at all.

What Nodrik does not check, and what that means

A tool you connect is yours. Nodrik calls it; it does not inspect it, run it, or verify what it does.

That sounds obvious and it has a sharp edge, so it is worth stating plainly rather than leaving to inference:

• We cannot tell whether your tool only reads. MCP lets a server declare a readOnlyHint, but a server can declare whatever it likes and nothing on our side can check it against what the code does. So we do not rely on it, and — since 2026-09-10 — we no longer describe your tools to the model as read-only, because that was us vouching for something we had not checked.
• If your tool changes something, it changes. A tool named restart_service that restarts a service will restart it. Nodrik has no way to know from the outside that the name means what it says.
• The credential you gave us is the credential it runs with. Scope it the way you would scope any integration: to the least the tool needs.

What Nodrik does do about this: Nodrik is told these are your tools, that we do not control them, and to prefer its own where either would answer the question — reaching for yours only when the question plainly needs them.

Connect only tools you are content for Nodrik to call, with a credential scoped to exactly what they need. Everything Nodrik promises about being read-only describes the access you granted it on your Google Cloud project — four viewer roles whose calls are all list calls, plus any per-service configuration role you chose to add, whose permissions are all get or list; no writes, and that is checkable. It cannot extend to code we have never seen.

Removing one

Remove in the console — an admin again — stops Nodrik offering its tools and deletes the stored credential. Nothing changes on your side — your server keeps running; Nodrik simply stops calling it. Closing your account deletes both as well.