connecta

One MCP endpoint. The integrations you chose. Your agent reaches them by writing code instead of loading a thousand tool definitions.

The mental model

You ask your agent a question that touches a service — Linear, Stripe, an internal API, anything you have connected. Here is what happens:

1. The agent talks to one endpoint, yours, and sees eight tools. Always eight, no matter how many services sit behind it.

2. It writes a short JavaScript program. Connecta runs it in a sandbox next to your integrations. The program can search for tools, call them, chain the calls, and shape the result.

3. Only the answer comes back into the agent's context — not raw pages of API output.

4. If the program wants to change something — create, update, delete — it stops right there, before anything is sent, and hands the agent the exact write. The agent repeats it through resume_execution, which your MCP client can put in front of you first. Approve it and the program picks up where it stopped, without re-reading what it already read. A single write can also go straight through call_destructive_tool.

Credentials never leave the server. The program never sees them, and neither does the agent.

flowchart TB
    Client["Your MCP client<br/>Claude, Cursor, …"]

    subgraph Connecta["Connecta — one endpoint, eight tools, your credentials"]
        Sandbox["execute_code<br/>the agent's program runs here<br/>reads run, writes pause"]
        Explicit["resume_execution · call_destructive_tool<br/>the exact write, visible<br/>your client can ask you first"]
    end

    Integrations["The integrations you chose<br/>Linear · Stripe · Notion · Vercel · your HTTP API · any MCP server"]

    Client -->|"one connection"| Sandbox
    Client --> Explicit
    Sandbox -->|"reads"| Integrations
    Sandbox -.->|"paused write"| Explicit
    Explicit -->|"writes"| Integrations

This is the kind of thing the agent writes, not you:

async () => {
  const { nodes } = await connecta.call("tracker.list_issues", { state: "started" });
  const byOwner = {};
  for (const issue of nodes) {
    (byOwner[issue.assignee?.name ?? "unassigned"] ??= []).push(issue.identifier);
  }
  return byOwner;
}

Fifty issues in, one small object out. Your context window notices.

Related MCP server: mcp-gateway

What you can do with it

• Put every MCP server you use behind one connection. Add or remove services in a config file; your client never changes.

• Wrap any HTTP API by hand. A few lines per tool. No OpenAPI conversion — generated tool sprawl is the problem, not the fix.

• Use maintained connections for Cloudflare, Linear, Mixpanel, Notion, RevenueCat, Stripe, and Vercel: known endpoints, auth defaults, and vetted read/write classifications, imported one at a time. Cloudflare, Notion, and Vercel each let the deployment choose their hand-written API interface or official hosted MCP.

• Let the agent work in code. Search, chain, filter, join, and reduce inside the sandbox instead of round-tripping every call through the model.

• Teach undeclared result shapes by using them. Successful read-only calls retain field names and broad types in bounded runtime memory, never scalar values, so later programs can project a remote MCP result its provider never documented.

• Keep large results usable. Oversized direct calls return a bounded preview with a handle for paging through the rest. For read-only work, the notice also points the agent to reduce or search the result inside a program. Discovery can show compact schemas, exact JSON Schema, or a TypeScript signature to read while writing JavaScript.

• Keep writes deliberate. Only tools marked read-only run in a program unasked. Any other call pauses the program with the exact write, and it runs only once resume_execution repeats it — a visible call your client can gate. A paused run is a journal in storage, not a held program, so it survives a restart; it expires, and a write whose outcome is unknown is never sent twice. Config — and only config — can exempt a cheap, reversible write from asking, per tool or per connector.

• Run it on Node or Cloudflare Workers. The core is shared; each deployment supplies its platform's executor and storage. The Node template also runs unchanged in Docker.

Deployments explicitly compose optional features: operatorUi() from @zackbart/connecta/ui, encryptedCredentialVault() from /credentials, activityHistory() from /activity, artifacts() from /artifacts, and inbound authentication adapters from /auth/*. Omit a module and its implementation does no runtime work. Core keeps connector discovery, execution, invocation, and enforcement together.

The optional UI shows each person's connections and effective permissions. Authentication controls live inside each connection, with optional activity history. The configured connection list loads before downstream checks finish; a slow provider does not hold up the page. Connector selection and access rules remain in deployment code. It also explains which tools can run in programs or need approval, offers a fixed repair prompt for classified failures, and shows client setup commands for the endpoints the signed-in person can use.

One deployment may serve several authenticated people inside the same tenant. Cloudflare Access supplies Worker identity; Node can use Clerk or the optional configured bearer adapter. Connecta owns no accounts or groups and issues no client access tokens. Shared-credential administration and personal connection setup require separate explicit permissions, both denied by default. See inbound auth.

Connecta is not a platform, a marketplace, a policy engine, or a multi-tenant service. Those are decisions, and the ethos records each one and why.

Getting started

Setup is written for an agent. Point yours at AGENTS.md and ask it to set up a Connecta deployment; the documentation covers the architecture, the eight tools, code mode, and inbound auth if you want to go deeper. When upgrading an existing deployment, each changelog release opens with what breaks and what a deployment can ignore.

Status

Built for its author's deployments first and published openly. Breaking changes are expected before 1.0. See the changelog and security policy.