Accounts vs MCP

Superagent provides two distinct ways to give agents access to external services: Connected Accounts and Remote MCP Servers. Each model serves different use cases and has different security properties.

Connected Accounts (OAuth via Composio)

Connected accounts let agents interact with standard SaaS APIs — Gmail, Slack, GitHub, Salesforce, and dozens more — through a secure proxy that handles OAuth tokens on the agent's behalf.

How it works:

1. You authenticate with a service through an OAuth consent flow (e.g., "Sign in with Google").
2. Superagent stores the resulting connection via Composio, an OAuth integration platform.
3. When an agent needs to call that service's API, it sends the request through Superagent's proxy. The proxy injects the real OAuth token into the request and forwards it to the upstream API.
4. The agent never sees the OAuth token. It authenticates to the proxy using a synthetic token that is only valid for that agent.

Key properties:

• Token isolation — Agents never receive OAuth credentials. The proxy injects auth headers server-side.
• Host allowlisting — Each provider has an explicit list of allowed API hosts. Requests to other hosts are rejected.
• Scope-level policy control — You can allow, review, or block specific API scopes per account. See Scope Policies.
• Audit logging — Every proxied request is recorded with the agent, account, method, path, matched scopes, and policy decision.
• 40+ supported providers — Google Workspace, Microsoft, Slack, GitHub, Notion, Linear, HubSpot, Stripe, and many more.

Best for: Standard SaaS integrations where you want managed OAuth, token brokering, and scope-level access control.

Remote MCP Servers

Remote MCP servers let agents call tools exposed by any server that implements the Model Context Protocol (MCP). MCP is an open standard for exposing discrete tools to AI models over HTTP.

How it works:

1. You register an MCP server by providing its URL and authentication credentials (bearer token, OAuth, or no auth).
2. Superagent connects to the server, performs the MCP handshake (initialize, notifications/initialized), and discovers available tools via tools/list.
3. When an agent invokes a tool, it sends a JSON-RPC tools/call request through Superagent's MCP proxy, which injects the real access token and forwards it to the remote server.
4. As with connected accounts, the agent never sees the real authentication credentials.

Key properties:

• Tool-based model — MCP servers expose named tools with typed input schemas, not raw HTTP endpoints. The agent calls search_contacts or create_issue, not POST /api/v2/contacts.
• Per-tool policy control — You can allow, review, or block individual tools. See MCP Tool Policies.
• OAuth and bearer token support — Servers can require OAuth (with automatic token refresh) or a static bearer token.
• Protocol-level calls are unblocked — Handshake and discovery methods (initialize, tools/list, ping) bypass policy enforcement since they carry no data.
• Audit logging — Every tool call is recorded with the agent, server, tool name, duration, and policy decision.

Best for: Custom internal services, specialized capabilities, or any tool server that speaks MCP.

Comparison

Using Both Together

Many agent setups use both integration types. For example, an agent might use a connected Gmail account to read and send emails (via the proxy), while also connecting to a custom MCP server that provides company-specific tools like search_knowledge_base or create_support_ticket.

Both connected accounts and MCP servers are mapped to agents individually — you control exactly which integrations each agent can access. See Mapping Accounts to Agents for details.