Tools and integrations

Knowledge tells agents what is true, tools let them act

The Knowledge Hub gives agents context. Integrations give them hands. An integration connects a third-party tool, Slack, Gmail, HubSpot, GitHub, Notion, and hundreds more, and defines exactly which of that tool's actions agents are allowed to fire.

The list of tools we support is at nagent.ai/resources/tools-and-integrations.

The operative word is allowed. Connecting a tool on Nagent does not hand agents its full capability. Every action is individually whitelisted, individually scoped, and governed by the trust ladder: what an agent may do with a tool depends on what the agent has earned.

Integrations are managed at nagent.ai/admin/integrations/composio.

How integrations are delivered by tier

• Pro. Integrations run through Composio, giving access to a catalogue of over 1,100 tools with managed authentication and a unified action model.
• Enterprise. Everything in Pro, plus custom integrations built for the organisation, and native integrations through MCP (Model Context Protocol) and REST API for connecting internal systems directly.

MCP integration also works in the other direction: agents built elsewhere can be brought onto the Nagent platform as MCP integrations, placing them under the same governance, approvals, and audit trail as native agents.

The tool catalogue

The catalogue at nagent.ai/admin/integrations/composio/catalog lists every connectable tool, searchable by name, description, or category, and filterable by category, authentication type, and toolkit. Supported authentication types span API key, basic, bearer token, OAuth 1 and 2, server-to-server OAuth, SAML, and no-auth tools.

Each catalogue entry shows the tool's description, its authentication method, and its category tags. Tools in the catalogue are in one of two states from here:

• Connect. Not yet linked. Choosing Connect starts authentication; some tools ask for configuration during the flow, such as a base URL for self-hosted deployments, with a sensible default for standard accounts.
• Whitelist actions and triggers. Already connected. This opens the action whitelist for the tool.

A connected tool carries one of three statuses:

Whitelisting: actions become tools one at a time

Connecting a tool exposes its available actions. Nothing is enabled by default; each action is ticked individually to whitelist it, with Select all and Clear all available for bulk changes. Each action shows its name, its technical identifier, and a description of exactly what it does.

A whitelisted action becomes a tool available to agents at runtime. It fires when an agent, during a chat turn or an autonomous run, decides to call it. Whitelisting alone never causes an action to fire on a schedule; scheduled and event-driven firing is what triggers are for (below).

Autonomy governs firing

Whether a whitelisted action fires immediately or waits for a human depends on two things: what kind of action it is, and the trust level of the agent calling it.

• Read-only actions, fetching, listing, searching, fire automatically for agents at autonomy L1 and above.
• Side-effect actions, anything that creates, modifies, sends, or deletes, queue for human approval when called by an agent below L3. Agents at L3 and above execute side-effect actions directly.

Side-effect actions are labelled as such throughout the whitelist, so it is always visible which actions carry consequences. This is the trust ladder applied to tools: the same whitelisted action is a proposal in the hands of a new agent and an execution in the hands of a proven one.

Scope controls the blast radius

Every whitelisted action also carries a scope. An unscoped action is available to every agent in the tenant, and that breadth is exactly what a workflow's blast radius report will show. Narrowing an action's scope to the agents that actually need it means no other agent can reach it, whatever its own tool list says.

The practice to follow: whitelist narrowly, scope tightly, and widen only when a real workflow needs it.

Triggers: letting events start work

Actions let agents act; triggers let the outside world start agent work. A trigger watches a connected tool for an event, a new email received, a message sent, and initiates agent activity when it occurs.

Each trigger shows its event, its mechanism (such as polling), and what it emits, typically event metadata like sender, recipients, subject, and thread ID. Work started by a trigger is governed exactly like work started by a human: the acting agent's trust level and the action whitelist still apply, so an event can never cause an agent to do something it could not have done anyway.

Dispatch: REST or MCP

Connected tools dispatch actions over one of two mechanisms, selectable per tool:

• REST. Actions fire over the platform's REST execution endpoint. The default.
• MCP. Actions dispatch over the Model Context Protocol.

Managing a connected tool

Selecting a connected tool shows its status, its connection identifier, and its whitelisted action count, alongside:

• Refresh status. Re-checks the connection's health and credentials.
• Disconnect. Removes the connection. Agents immediately lose access to all of the tool's actions.

Expired connections are flagged in the tool list and must be re-authenticated before agents can use them again.

What to do next

With tools connected and actions whitelisted, agents can act on the outside world under governance. Compose that capability into recurring processes in Workflows, and watch it run from Live Ops.