Skip to main content
Agent sessions are in public beta.Join our beta Slack Channel for feedback and notifications of breaking changes.
Agent sessions are an optimized interface for AI agents to use integrations. Each session has three parts:
  • Tenant — on whose behalf the agent can call integrations
  • Toolset — which integrations and tools it can use
  • Discovery — how it finds and calls those tools
Your backend creates the session and exposes it to the agent as an MCP server. The agent never sees raw credentials, and cannot change the scope of its own session. Example sessions:
  • A sales agent with a user’s personal Gmail & Google Calendar, and a read-only org-wide Salesforce connection
  • A finance agent with a few read-only tools on an org’s accounting system, and read & write access to a team’s Slack
  • A developer agent with a team’s Linear access and a user’s personal GitHub access

Quickstart

1

Create a session from your backend

By default, a session covers every tool on the integrations the tenant has a connection for.To define the tenant, select the connections the agent may use with tag selectors:
Requires an API key with the environment:agent_sessions:write scope. See API key scopes.This returns a ready-to-use session:
2

Pass the MCP server to your agent

Pass the mcp_url to your agent, with the session_token as bearer auth:
The Responses API never stores the authorization value, so send it on every request.
Your agent can now use every tool the session exposes.

Session basics

Creating a session

Create a session with the tools and access your agent needs.
Creation fails if your tenant selectors are not unique, or if a toolset or tool doesn’t exist in your Nango environment. Each session gets a unique session_id and session_token. The token is a scoped access token for that session — treat it as a secret, and keep session durations as short as your use case allows.

Session MCP server

Every session exposes its own MCP server at its mcp_url. It speaks Streamable HTTP and authenticates with the session_token as a bearer token, so any MCP-capable agent or client can connect to it. tools/list returns the enabled meta tools plus the pinned tools, paginated 50 at a time through nextCursor. Searchable tools are callable but not listed, and the agent finds them with the nango_tool_search meta tool.

Terminating a session

Sessions are immutable and cannot be extended. They expire on their own once expires_in is up. Recreate the session with the same parameters if you need it again.

Tenant

The tenant defines on whose behalf the agent may act. For example: use a specific user’s Gmail credentials, but the org-wide credentials for Salesforce. You express this with Connection tag selectors under any, which the session resolves to the right Connections in Nango. Tags within one entry are ANDed, entries are ORed, up to 10 entries. Here, organization_id, workspace, and user_id are Connection tags we set up for our application.
Selectors must resolve to exactly one connection per integration at creation time. The resolved connection is stored on the session, and every tool call the agent makes afterwards uses it.

Resolving ambiguity

If the selectors match two or more connections on the same integration, there is no way to tell which one the session should use. Creation fails with ambiguous_connections, and no session is created:
There are two ways to resolve this:
  1. Add tags to the selector until it matches exactly one connection per integration.
  2. Use pinned to name the connection to use for that integration.
You can only use one pin per integration. A pin must be one of the connections the selectors matched, or creation fails with pinned_connection_not_matched. Pinning a connection that does not exist fails with unknown_pinned_connection. You can also use pinned without any any selectors, if you already know the exact connections you want to use. An integration that matches no connection does not fail creation. It appears in the toolset as connected: false, and its tool calls fail with a missing authorization error.
Currently there is no way for the agent to ask the user to connect an unconnected integration. Let us know on the Beta Slack channel if you need this and we are happy to prioritize it.

Toolsets & tools

toolset defines which tools are available to the agent. The toolset is a subset of the Integrations that are enabled in your Nango environment.
You can use the following selectors:
  • "*" on an integration means every action function on it
  • allow makes the integration an allowlist, where "*" means every tool
  • deny always subtracts from whatever allow gave
  • To deny an integration entirely, leave it out of the toolset
  • toolset: "*" at the top level means every integration in the environment
  • Leaving toolset out entirely means every integration the tenant resolved a connection for, which is narrower than "*"
Only action functions can be tools. Naming a sync fails with unsupported_function_type, an unknown integration with unknown_integration, and an unknown tool with unknown_tool. Any error fails creation, so a session is either fully valid or not created.

Pinned tools

By default, everything in the toolset is searchable with the nango_tool_search meta tool, but none of it is listed in the MCP server’s tool list. This keeps a large toolset from filling the agent’s context with hundreds of definitions it will never call. pinned_tools exposes specific tools in that list, so they are in context as soon as the agent loads the server:
A pinned tool must be in the toolset, otherwise creation fails with tool_not_in_toolset.

Meta tools

Meta tools are Nango’s own tools. They are always pinned to the MCP server’s tool list. Both default to true. You can disable them on session creation with meta_tools:
Takes a plain-language query describing what the agent wants to do.
The result carries guidance for the agent, matches for the best hits, and related tools for weaker matches to narrow down. Each match names the tool to pass to nango_execute, its integration, action, and provider, whether it is listed, and its connection status. Only a best match includes input, its argument schema — a weak match is a lead, not something to call yet.

nango_execute

Runs one of the session’s tools by name, on the connection the session resolved for that integration.
Execution is synchronous and goes through the same path as triggering an action function, so it is capped by the synchronous execution limit and appears in Nango logs like any other function run.