> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Integration groups
> Bundle your connected tool servers into a named group, narrow which tools it grants, and attach the whole set to an agent in one move.
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](/manage-your-agents/build/built-in-integrations),
and the ones you register yourself through the
[MCP Gateway](/manage-your-agents/build/mcp-gateway). A group is a list of those servers plus rules
about which of their tools it grants.
| A group has | Meaning |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| A **name** | Unique within your workspace, and the key the group is addressed by. Letters, digits, `_` and `-`, starting with a letter or digit |
| **Member servers** | Which tool servers belong to the group |
| **Allow** and **Deny** | Which of the members' tools the group 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
Go to **Integrations**, then the **Integration groups** section.
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`.
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.
Use the allow and deny lists to trim the members' tools down to the ones this group should grant.
See [Attach a group to an agent](#attach-a-group-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:
| Scope | Effect |
| --------------------- | ---------------------------------------------------------------- |
| **One server** | Pick a single server and choose its tools for this agent alone |
| **Integration group** | The group's servers and tools, shared by every agent bound to it |
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
| Situation | Use a group? |
| ------------------------------------------ | ------------------------------------------------- |
| Several agents need the same tools | Yes — build it once, attach it to each |
| One agent needs one server's tools | No — scope it to that server directly |
| You want a narrower view of a broad server | Yes — a group with a deny list is the tool for it |
| You want an agent to reach everything | No group needed; that is the unscoped default |
## Next steps
Connect the providers whose servers a group bundles.
Register your own servers, then group them.
The two connection paths a group draws from.
Change what a live agent may reach.
## Related topics
- [Concepts & glossary](/get-started/concepts.md)
- [Integrations overview](/manage-your-agents/build/integrations-overview.md)
- [Built-in integrations](/manage-your-agents/build/built-in-integrations.md)
- [MCP Gateway](/manage-your-agents/build/mcp-gateway.md)
- [Klaudia Investigator](/manage-your-agents/build/catalog/klaudia-investigator.md)