Integration groups

An integration group is a named bundle of tool servers that you attach to an agent as a set. It exists so that scoping an agent’s reach is one decision instead of a dozen, and so that several agents can share exactly the same tool surface.

​

What a group is

The Komodor Agentic Operation Platform (KAOP) reaches external systems through tool servers — the ones stood up behind your built-in integrations, and the ones you register yourself through the MCP Gateway. A group is a list of those servers plus rules about which of their tools it grants. Groups are found under Integrations → Integration groups. In the product’s own words, a group bundles servers behind a per-agent gateway endpoint: each group has its own endpoint, and binding an agent to the group is what points the agent at it.

​

Create one

​

How allow and deny narrow the set

A group’s rules layer on top of the rules each member server already has, and they can only ever narrow. Two consequences follow, and both are worth stating plainly:

• A tool that the owning server denies stays denied. A group cannot grant back what the server refuses.
• Deny wins. If a tool is on both lists, it is denied.

This is what makes a group safe to hand to more than one agent: adding an agent to a group can never widen what that group’s servers permit.

​

Attach a group to an agent

A group reaches an agent from the agent’s own tool configuration. In the agent’s MCP tools step, choose the scope: Once a group is selected, the step lists the tools the group grants as a read-only summary — those tools belong to the group, so you change them by editing the group, not the agent. An agent belongs to at most one group. If an agent needs the union of two groups, make a group that covers both rather than trying to attach two.

​

When to use a group

Example. Say three agents all take part in incident response: one summarizes the alert, one digs through logs and metrics for a root cause, one posts status updates. All three need the same read access to PagerDuty, Datadog, and Slack, but none of them should be able to, say, resolve the incident or delete a monitor. Rather than scoping each agent by hand and keeping the three copies in sync, create one incident-response group — member servers PagerDuty, Datadog, and Slack, with a deny list that strips write actions like acknowledge, resolve, and delete — and attach all three agents to it. Widening or narrowing what the trio can do is then one edit to the group instead of three edits to three agents.

​

Next steps