Connecting your own MCP server
Give Sentinel-Q tools from a system you already run — ticketing, RMM, backup, a wiki — without waiting for a connector. Every tool arrives disabled, and here is why.
The connector catalogue is a fixed list, and it will never contain the ticketing system your managed service provider built in-house, the remote-monitoring product you happen to use, or your internal wiki. If any of those already speaks the Model Context Protocol — or you can put a small server in front of it that does — you can register it here and Sentinel-Q will be able to use its tools.
The page is Integrations › MCP servers at /integrations/mcp. The console's own description of the trust model is worth quoting in full, because the rest of this article is an expansion of it:
Point Qorionix at an MCP server you already run and Sentinel-Q can use its tools without waiting for us to build a connector. An external server is untrusted: its tools are namespaced so they cannot impersonate a Qorionix capability, its descriptions are quoted to the model as data rather than instruction, and every call is checked against your own permissions.
The four permissions
None of these is granted to any built-in role except admin. That is deliberate: registering a server means naming an address the platform will make outbound requests to, on your behalf, holding a credential you supplied.
| Permission | Lets you |
|---|---|
ai:external_tools.read | List servers, see one, list the tools it advertised. |
ai:external_tools.write | Register a server, edit it, run tool discovery, enable or disable an individual tool, store or replace the auth header value. |
ai:external_tools.delete | Remove a server, or remove its stored credential. |
ai:external_tools.invoke | Gates no page and no route. It is a floor checked when the assistant actually calls an external tool, in addition to whatever permission you declared for that tool. |
That last row is the mechanism that stops this feature becoming a privilege-escalation route, and it is worth being explicit about. A caller must hold both the permission you declared for a tool and ai:external_tools.invoke. The console says it plainly: a caller must hold that AND [the floor], so an external tool can never let someone do something they could not do here.
Registering a server
Four fields, two of them optional, and two of the four cannot be changed afterwards.
- Name
- Used to namespace every tool the server offers, as
ext.<name>.<tool>. It cannot be changed afterwards, because renaming it would rename every tool. Names are unique within your organisation; a clash returns409. - Endpoint URL
- Must be
httpsand must resolve to a public address. Loopback, link-local and private ranges are refused, the check is repeated on every redirect, and it is enforced on the address actually dialled rather than on the text of the URL. So a hostname that resolves to10.0.0.5, or a public hostname that redirects to169.254.169.254, is refused at the moment of dialling. - Auth header name (optional)
- Letters, digits, underscore and hyphen only, up to 64 characters. Supplying a value without a name is refused — there is nowhere to put it.
- Auth header value (optional)
- Sealed with the same envelope encryption as privileged credentials. There is no read path: registering it is the only moment it exists outside the vault, and replacing it is the only way to change it.
A caveat on the credential: if the deployment has no encryption wrapper configured, storing one is refused rather than falling back to plaintext. The refusal names itself: no encryption wrapper configured; refusing to store a credential. And if external MCP servers are not configured on the deployment at all, every route here answers 503 with external MCP servers are not configured on this deployment.
Discovery, and why nothing works immediately
Registration does not turn anything on. The console tells you so in the confirmation: Registered and left disabled. Run "Discover tools" to see what it offers; nothing reaches the assistant until you enable a tool.
Discover tools performs the protocol handshake and a tools/list, and stores what your server advertised. It is also the closest thing to a test button — there is no separate health or test route, and a failure is reported as 502 with your server's own error text. It requires write rather than read, because it makes an outbound request on your behalf and could otherwise be used to probe.
Everything discovered arrives disabled: Found N tool(s). All arrive disabled — enable them one at a time. You then enable each tool individually and, at that point, declare two things about it.
| Declaration | Effect on how Sentinel-Q may use it |
|---|---|
| Reads only | Low blast radius, read class. It may run inside an autonomous investigation. |
| Changes something | High blast radius, recommend class. A human must approve every plan that uses it, and it can never run unattended — whatever your autonomy tier says. |
| Equivalent to — a permission | The permission a person would need to do the same thing in the console. A caller must hold it, plus ai:external_tools.invoke. Leave it undeclared and the tool falls back to the administrator-only floor. |
The declared permission must be one that actually exists in the platform's permission catalogue; an invented string is refused with 422. That is a small guard with a real purpose: a permission nobody holds and nobody can grant would make a tool permanently uncallable in a way that looks like a bug.
Namespacing and quarantine
Two defences against a server that misbehaves, deliberately or through a compromise upstream of it.
Names are reconstructed, not accepted. Whatever your server calls a tool, the assistant sees it as ext.<your-server>.<tool>. The console shows the original alongside as advertised as …. A server cannot present a tool called pam.rotate_credential and have the model believe it is talking to the vault.
Impersonation and prompt injection are quarantined. A tool whose advertised name reaches for a first-party namespace — pam, iam, xdr, siem, sentinelq, qorionix, zentryq, and with a dot or double underscore also ai, compliance, evidence — is quarantined. So is a tool whose description contains text aimed at the assistant rather than describing what the tool does. The console reports it:
N of them were quarantined: the metadata this server sent contains text aimed at the assistant, not a description. They cannot be enabled.
Cannot be enabled is literal — the refusal is enforced in the application and again as a database constraint, so there is no path that turns a quarantined tool on. If a tool you need has been quarantined, fix the description on your own server and run discovery again.
Results coming back from your server get the same treatment as any untrusted text: they are scanned, and on a hit the content is kept and marked rather than dropped, with the recorded effect that it cannot authorise, exempt or close anything. Every result is also wrapped with its provenance — which server, which tool — so a model summarising it cannot present it as a platform finding.
The bounds
| Limit | Value |
|---|---|
| Servers per organisation | 8 |
| Tools per server | 32 — beyond that the list is cut off, and the console says so |
| Discovery timeout | 15 seconds for the whole handshake and all pages |
| One tool call | 10 seconds |
| Response size | 256 KiB |
Pages of tools/list | 8 |
| Advertised description length | 512 characters |
| Advertised name length | 128 characters |
| Advertised input schema | 8 KiB |
| Consecutive failures before auto-disable | 5 |
There is no rate limit beyond those. The protocol revision the platform speaks as a client is 2025-06-18, and it accepts either a JSON or a server-sent-events response body.
When your server misbehaves
The failure behaviour is designed around one principle: a third-party server having a bad afternoon must not break a conversation with the assistant.
- A failing server contributes zero tools rather than failing the turn. If discovery or a listing cannot be completed, the assistant proceeds without those tools. You will notice a capability missing; you will not see an error in the middle of an investigation.
- Five consecutive failures disable the server automatically, with a message that tells you it was us and that nothing on your side changed:
Qorionix disabled this server after 5 consecutive failures. The last one was: … Fix the server and re-enable it here; nothing was changed on your side.One success resets the counter. - Disabling takes effect on the next call, not the next cache expiry. The server row is re-read immediately before every invocation, so turning something off is immediate even though the tool list itself is cached for thirty seconds.
- Your server's response body never appears in an error. A non-2xx becomes
server answered HTTP <code>and nothing more, because a body from an untrusted endpoint has no business being rendered as our error text.
The health fields on the server record are where you look: last_discovery_at, last_error, last_error_at, consecutive_failures and disabled_reason.
Removing a server
The console asks first, and the consequence is immediate: Remove this server? Every tool it contributed stops being available to the assistant immediately. The stored credential goes with it.
If you only want to rotate the credential, that is a separate action — replace the auth header value, which is the only way to change it, or delete just the credential and leave the server registered.
Is this the right tool for what you want?
Worth a short honest section, because the answer is often no.
- If you want alerts delivered somewhere, use a notification route or an outbound webhook instead. See Where notifications go and Outbound webhooks. This feature is for the assistant to read from and act on your systems, not for us to push events to them.
- If the system you want is in the connector catalogue, use the connector. See The connector catalogue, including its honest account of which rows are complete.
- If the system is inside your network, this will not reach it, as above.
- If you want the assistant to open tickets in your service desk, look something up in your asset database, or check whether a machine has a recent backup — that is exactly what this is for, and it is worth the afternoon.
What to read next
- Connecting your own AI client over MCP — the other direction, and the tools we expose.
- The connector catalogue — check whether what you want already exists.
- What Sentinel-Q is allowed to do — why a tool with no undo handle can never run unattended.