Skip to main content
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. This page covers what a group contains, how its allow and deny lists narrow it, and what happens when an agent has no group at all.

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

1

Open Integration groups

Go to Integrations, then the Integration groups section.
2

Add the group

Press Add integration group and give it a name that says what it is for — buildkite-triage reads better in an agent’s configuration than group-2.
3

Choose member servers

Pick the tool servers the group covers. A server can belong to several groups, so you can build a broad group and a narrow one over the same connections.
4

Narrow the tools, if you need to

Use the allow and deny lists to trim the members’ tools down to the ones this group should grant.
5

Attach it to an agent

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.
An agent with no integration group is not scoped to nothing — it is unscoped, which means it can reach every tool server in the workspace. Unscoped is the common starting state, not an edge case, so if an agent should only reach a subset, it needs a group. Attaching one is how you narrow it.

Change or remove a group

Editing a group takes effect for every agent bound to it, which is the point of grouping in the first place — add a server once and every agent in the group gains it. Deleting a group is different, and the confirmation says so: every agent scoped to that group loses its entire tool set. Recreating a group with the same name does not restore those bindings — each agent has to be re-scoped by hand. Repoint the affected agents first, then delete.
Removing a tool server that a group still holds is refused rather than silently breaking the group. Take the server out of its groups first, or detach it explicitly as part of the removal.

When to use a group

Next steps

Built-in integrations

Connect the providers whose servers a group bundles.

MCP Gateway

Register your own servers, then group them.

Integrations overview

The two connection paths a group draws from.

Manage a deployed agent

Change what a live agent may reach.