Skip to content
Hlebourg
Integration

Every product speaks MCP, so integration stops being a project

Every product has its own MCP server, and you should never install them all at once. Any agent that speaks the Model Context Protocol can drive any of them with no adapter to write, no API key pasted into a prompt, and no separate integration per assistant your organisation adopts next year. The constraint that shapes everything below is that an agent's judgement degrades as you hand it more tools.

See the catalogueAsk for the schemas
The premise

The integration problem changed shape

For twenty years, connecting two business systems meant writing an adapter for that specific pair. Ten systems and four tools that wanted to reach them produced forty integrations, each with its own auth, its own error semantics, and its own maintainer who left.

The Model Context Protocol collapses that into one interface. A product describes its capabilities once, in a form a language model can read, and every conforming agent can use it. The adapter count goes fromn×m ton+m.

That is genuinely useful and also genuinely dangerous, which is why the interesting part of this page is not the protocol but what we do around it.

It is worth saying plainly that shipping a server is no longer remarkable. Across the markets these products serve, most established vendors now describe permission inheritance and an audit trail in roughly the words we use above, because those are the obvious things to say. A buyer comparing vendors on whether an MCP server exists will find the answer is yes everywhere and learn nothing.

So the question this page tries to answer is the one after that: what the server refuses, how many tools it exposes, what happens when an agent asks for something the operator cannot do, and whether any of it works with no connection to the vendor at all. Those answers still differ, and in the offline lines — work done with no connection to a vendor — we could not find an incumbent shipping a server at any quality.

What an agent gets on connect
hlebourg-signal
├── tools        7  read 4 · write 2 · act 1
├── resources    4  instruments, methodology, policy
└── auth         operator: m.haddad@acme.example
                 scope:    inherited, read-only

signal.explain_score
  → why is this number what it is
  args: { subject_id, signal, window? }
  errs: E_NOT_PERMITTED — names the missing grant
Tool kinds

Three effects, separated on purpose

Every tool in every server declares which of three things it does. The distinction is visible before installation, not discoverable afterwards in a log.

read

37 tools

Returns data and changes nothing. Grant follows the product's own agent policy: on most servers read can be granted broadly, because the worst outcome is that an agent learns something its operator was already entitled to know.

write

22 tools

Changes state inside the product — schedules a round, records an intervention, updates a status. Granted per tool, and every call names the operator and the agent.

act

11 tools

Has an effect outside the product: sends, exports, notifies. Off by default on every deployment, and enabled only against a written policy.

The ceiling

Why no server here exposes more than eight tools

This is the part of agent integration that vendors leave out of the datasheet, and it is the part that decides whether your deployment works.

Tool definitions are always-on context. Each one costs roughly a hundred to five hundred tokens before the user has said anything, and the cost is paid on every single turn. Seventy tools can consume fifteen thousand tokens of an agent's attention before it reads the question.

The worse problem is accuracy. Selection quality falls off sharply somewhere around forty tools on current frontier models, and published benchmarks in this space agree on the shape of the curve: near-perfect selection at twenty tools, total failure well past a hundred. Practical deployments settle at five to nine concurrent servers, not because anyone chose that number but because past it agents start picking the wrong tool.

So the honest framing of our catalogue is not that it offers 70 tools. It is that no single server exposes more than 8, that you install the two or three your agents actually need, and that a vendor encouraging you to connect all nine at once would be selling you a degradation.

What this costs us to admit

  • We do not ship one tool per API endpoint. Generated servers are how a catalogue reaches sixty tools and gets uninstalled.
  • Tool names are unique across all nine servers. Four different products offering search is the single most common reason an agent calls the wrong one.
  • Where a product needs breadth, it gets one tool with a richer schema rather than six near-duplicates — and the schema rejects unknown arguments instead of ignoring them.
  • We will tell you during evaluation which of our servers you should not install — a conversation that saves you a failed rollout.
Guarantees

Eight properties we hold to across all nine servers

An agent interface is a permission surface. These are the rules that make it one we are willing to ship.

An agent inherits, never exceeds

A tool call runs under the permissions of the human account that authorised the agent. There is no service account with a superset of anyone’s rights, because that account would immediately become the most valuable credential in your estate.

Every call is attributable

One audit record per call, carrying the human identity, the agent identity, the timestamp, the tool, the arguments, which policy authorised it, the lineage back to the model request that triggered it, and the outcome including retries. Secrets are redacted before the record is written, not after. "The AI did it" is not a state this system can be in.

Read-only is a property of the credential

A read-only agent is read-only because its credential says so and the server refuses anything else — not because a client passed a flag or because a tool declared itself harmless. MCP tool annotations are hints, and a server that wanted to lie about one could. Ours are checked at dispatch against the token, where a lie has nothing to act on.

Effects are opt-in, not opt-out

Tools that touch the outside world ship disabled. Turning one on is a deliberate configuration change with a named owner, not a default someone discovers in month four.

Schemas are the documentation

Tool descriptions, argument schemas and error messages are written for a model to read. An agent that calls a tool wrongly gets told what would have been correct, rather than a stack trace.

Rate limits you can plan against

Per-operator and per-agent limits are enforced in the server, and every response carries the remaining headroom and the reset time. An agent that can only discover a limit by hitting it will hit it in parallel, and a bare Retry-After is not enough to budget a multi-call task.

Standard authorisation, strictly applied

OAuth 2.1 resource-server behaviour: protected-resource metadata published, PKCE, exact redirect matching, and strict audience validation — a token whose audience is not this server is rejected even when it is signed and unexpired. Clients send resource indicators naming the server they mean. As shipped, we never forward your bearer token to an upstream API, which is the standard way this class of system becomes a confused deputy.

Streamable HTTP, one endpoint

Servers speak Streamable HTTP on a single path and hold no session state, so you can load-balance them round-robin with no sticky sessions and no shared session store. stdio remains available for local development and for single-machine air-gapped installations, which is what it is good for.

Worked example

One question, four tool calls, no custom code

A delivery lead asks their assistant to plan the next two weeks. The assistant has been granted read access to three servers under the lead's own account. Nothing here required an integration to be built.

  1. 01flow.list_commitmentsread

    What has already been promised to customers in this window, and which of those dates have slack.

  2. 02signal.get_team_profileread

    Aggregate load for the team. Returns a distribution, with the three-person sub-team suppressed — the agent is told it was suppressed rather than given a silently smaller number.

  3. 03watch.list_dueread

    Obligations falling due in the window that nobody has picked up, including the two that are already overdue.

  4. 04signal.explain_scoreread

    The team profile came back amber. Rather than reporting a colour, the assistant asks what drove it and finds a six-week recovery-ratio decline concentrated in on-call weeks.

The assistant then proposes moving one commitment and rotating on-call. It does not execute either: both would bewrite calls it has not been granted. The lead approves the change, andsignal.record_intervention logs it so that in six months the effect can be measured rather than remembered.

Catalogue

All nine servers

Nocturne · Confidential document control

Cadence · Workforce sustainability

Harbour · Offline-first operations

Limits

What integration is not

  • It is not autonomy. An agent can read widely and change little, and the things it can change are named in a configuration file somebody signed.
  • It is not a replacement for the product UI. Humans still need to see a chart, and a manager conversation does not happen through a tool call.
  • It is not a bridge between your products and ours. Each server exposes its own product. Cross-product reasoning happens in your agent, where you can see it, not in a hidden orchestration layer of ours.
  • It does not make an agent trustworthy. It makes an untrustworthy agent auditable and bounded, which is a different and more achievable goal.
Request the full tool schemasHow we roll this out