Connections. One CLI, every system.
50+ enterprise systems behind a single tool surface. The agent loads one CLI · not fifty per-system MCPs. Less to audit, less data in context, lower token spend. Built once, inherited by every AI surface your team uses.
Native MCP doesn't scale.
Every system you connect adds another tool surface. Every tool surface adds more tokens to every query. Every query waits for schema discovery before it can begin.
Per-system MCPs
A Salesforce MCP, a Jira MCP, a Snowflake MCP. Each one is a separate tool definition the agent has to load. The math gets worse with every system added.
Schema rediscovery
Tool definitions alone can consume 134K tokens before a single record is read. The agent rediscovers the schema on every query.
Per-system auditing
Every per-system MCP is one more credential boundary, one more log stream, one more thing IT has to scan, scope, and revoke.
One verb. Every system.
Connections fans out from a single CLI to 50+ enterprise systems. Same syntax across databases, warehouses, SaaS apps, and object storage. The agent learns one tool; the workspace handles the rest.
The CLI
Connections exposes a uniform set of verbs · describe, query, download, write · that work across every connected system. The agent loads one tool definition. The workspace routes calls to the right adapter.
connection <verb> <system> · same shape for Salesforce, Snowflake, Jira, Postgres, S3.
The agent doesn't rediscover the schema on every query. Context is initialized once.
One tool definition replaces fifty. Tool-def tokens drop from ~134K to roughly 4K.
One CLI surface for IT to audit, scope, and revoke.
# Same syntax. Different source. Different cost. connection describe salesforce connection query salesforce \ --table Opportunity \ --filter "StageName = 'Closed Lost'" connection query snowflake \ --sql "SELECT * FROM deals WHERE q='Q2'" connection download s3 \ --bucket reports --prefix 2026/ connection write jira \ --issue PROJ-1234 \ --field comment "Update from agent" # The agent loads ONE tool. # The workspace handles 50+ destinations.
One tool surface.
An order-of-magnitude difference.
The same Q2 pipeline analysis · same prompt, same data · costs roughly eight times less when the agent loads one CLI tool instead of fifty per-system MCPs.
~50 tool definitions in context. Schema rediscovered on every query. Cross-system joins string-match account names. Partial answers. User retries.
One CLI tool definition. Schema seeded once at connection time. Joins materialized in DuckDB. Workspace inherits the join for the next user.
150,000 → 2,000 tokens · 98.7% reduction in a single MCP workflow · Anthropic Engineering · Nov 2025
Every system your team actually uses.
Cloud warehouses, databases, SaaS tools, and storage. All accessible through one governed interface.
Don't see your system? We're adding connectors weekly. Request one.
One platform. Three products.
Connections plugs into the same workspace as Sandbox and Cost Plane. Build once, govern by structure, see every token.
Sandbox
A governed runtime where AI does the work. Scoped credentials, audit, SIEM logs, controls enforced by architecture.
Sandbox →Product 03Cost Plane
Token visibility, routing, and cost attribution. See where every dollar goes. Set budgets. Turn the dials.
Cost Plane →PlatformThe Workspace
The runtime, the context layer, the security perimeter. All three products on one architectural foundation.
Platform overview →Common questions about Connections.
How does Connections differ from native MCP servers?
Native MCPs expose one tool per system · each one is a separate definition the agent has to load. Connections collapses all of them into one CLI surface with uniform verbs (describe, query, download, write). One tool definition, not fifty. Schema is seeded once at connection time, not rediscovered on every query.
Can I build a custom connector?
Yes. Connections is extensible · you can author connectors against any system with an API or database driver. For Enterprise customers we also build new connectors on request as part of the engagement.
What's the authentication model?
Credentials live inside the workspace, encrypted at the boundary, scoped per identity. The LLM never sees a token or API key · Connections handles auth at the workspace layer and returns only the data your scope permits. SSO + SCIM cascades govern who can configure connectors and who can run them.
Do you support OAuth-only systems?
Yes. OAuth flows are handled per-user inside the workspace. Refresh tokens stay encrypted; access tokens never enter the model context. Revocation propagates instantly across every AI surface the user has access to.
How are credentials stored?
In your workspace, encrypted with your KMS keys (Enterprise tier) or our managed KMS (Team tier). For VPC deployments, credentials never leave your cloud · we operate the software, you own the data plane.
What happens if a source system goes down?
The CLI surfaces the error to the agent as a structured response. The workspace doesn't retry indefinitely or escalate the bill. You can configure per-connection circuit-breakers and per-team budgets in Cost Plane to bound the blast radius.
How often are new connectors added?
The catalog grows weekly. New connectors are prioritized by customer request frequency. Enterprise customers get custom connectors built into the engagement.
Can I run connectors against my own database?
Yes. Connections supports private databases reachable from inside your VPC · Postgres, MySQL, Mongo, SQL Server, and others · over SSH, private link, or direct in-VPC connection. For air-gap deployments, the entire workspace runs on your hardware.
Same verbs. Every adapter.
Connect once. Inherit everywhere.
Start free. Wire up your first three systems in minutes. The workspace handles the rest.
