For teams giving AI real access

One door to every tool your AI uses.

Your assistants need to reach real things — your issue tracker, your files, your customer data. connectable.sh gives them one way in instead of ten, and gives you a say in what they may do once they are through it.

Get started Run it yourself

terminal

claude mcp add --transport http connectable \
  https://connectable.sh/mcp \
  --header "Authorization: Bearer $CONNECTABLE_API_KEY"

That is the whole setup, once. Add a tool later and every assistant already connected can use it — nothing to reconfigure, on anyone's machine.

Your fileson your machine
Sentrybuilt for AI
Stripea REST API
Lineara GraphQL API
A changelogjust a web page

your assistant

https://connectable.sh/mcp

key: one — revoke it and every tool stops
tools: 6 — the rest are not exposed
sign-off: 2 — wait for a person

the problem

Ten tools means ten setups. On every machine.

Each one has its own config to paste, its own password to store, its own way of breaking — repeated for every assistant you use and every person on your team. Connect them once here instead, and you have somewhere to stand when you want to change something.

filesSentryStripeLinearchangelog

Ana's laptop

Ben's laptop

The release bot

Your CI

20 configs, 20 keys, and one of them is always the stale one. Rotate a password and you do it 4 times.

connecting things

It doesn't have to be built for AI

A few tools already are. Most of what your team actually uses is a normal API — or a page on the internet. Connect those the same way, and set the same rules over them.

Tools built for AI

on your machine, or remote

Anything that already speaks the standard: a local program or a hosted server.

connectors.json

{
  "name": "sentry",
  "transport": "http",
  "url": "https://mcp.sentry.dev/mcp"
}

Any REST API

from its own docs

Point at the API description a service already publishes, tick the handful of things your assistants may do, and those become tools.

connectors.json

{
  "name": "stripe",
  "transport": "openapi",
  "specUrl": "…/spec3.json",
  "include": ["GetCustomers", "GetCharges"]
}

Any GraphQL API

from the endpoint

The same, for services that use GraphQL. You name the queries; nothing else is exposed.

connectors.json

{
  "name": "linear",
  "transport": "graphql",
  "specUrl": "https://api.linear.app/graphql",
  "include": ["Query.issues"]
}

A web page

no API at all

A changelog, a status page, a wiki. Each page you name becomes one read-only tool that returns the text, not the page furniture.

connectors.json

{
  "name": "docs",
  "transport": "web",
  "pages": [
    { "tool": "changelog", "url": "https://bun.com/blog" }
  ]
}

You pick what gets exposed. Connecting a service exposes nothing by default.

Stripe's API has 589 operations. Handing an assistant all of them would fill roughly twice its working memory before it started on your actual question — so it would do worse than if it had no tools at all. Choosing is also the only real boundary: the same key that reads payments can refund them. Pick the three things it needs. When the service adds something new, it waits for you rather than turning itself on.

staying in control

Decide what your assistants are allowed to do

Handing an AI a real password is easy. Being able to say afterwards what it did with it is the part that takes work. These are the controls that make it a decision rather than a hope.

A list of what each assistant may do
Reading issues, yes. Deleting them, no. Anything not on the list is refused before your password is even reached for.
Nothing changes behind your back
A tool describes itself to your assistant, and that description is really an instruction. We record the one you approved, so a service that quietly rewrites it gets flagged instead of obeyed.
Ask a person first
Send the risky actions to a human. The assistant waits, someone sees exactly what it wanted to do, and the answer is kept alongside the request.
Limits that actually stop it
How often, how much, how many — per assistant and per connection. A loop that goes wrong hits a ceiling you set instead of a bill you did not.
A stop button
Cut off one assistant, one connection, or everything at once. Work already in flight stops too.
A record of all of it
Every action, what it was asked to do, and what happened — kept as long as you choose. When someone asks why an assistant did something, there is an answer.

when something is blocked

A refusal that says which kind it is

An assistant that cannot tell “try again in a minute” from “never” will either give up on things that would have worked, or hammer at a door that is closed for good. Every refusal here is tagged with one of six reasons, so it knows which it just met.

Not allowed: Somebody decided this must not happen.
Not right now: Fine in principle — over a limit at the moment.
Needs a password: A login expired or was revoked.
The service failed: Their end, not yours.
We failed: Ours.
Asked wrong: Fixable by asking again, properly.

Each one also says whether waiting would help, and for how long. A rate limit says retry in 12s. A monthly cap says which day it resets. And when we genuinely do not know what went wrong, it says so — rather than dressing a mystery up as somebody's decision.

The wording is meant for you. The tag beside it is meant for the machine.

using it

Works with the assistants you already use

connectable.sh speaks MCP, the open standard for connecting AI to tools. Whatever your team already has open stays open — it just points at one address now.

Claude Code
Claude Desktop
Cursor
anything else that speaks MCP

The dashboard writes the snippet for you, per client. Files and saved prompts travel through as well as tools, and when a service needs something back from the person at the keyboard, that reaches them too.

.mcp.json

{
  "mcpServers": {
    "connectable": {
      "type": "http",
      "url": "https://connectable.sh/mcp",
      "headers": {
        "Authorization": "Bearer <your-key>"
      }
    }
  }
}

where it runs

On our servers, or entirely on yours

Not a cut-down free version next to a real product. The hosted service is this same code, with the parts a shared deployment has to refuse.

Run it yourself

One process, on your own machines. Your tools listed in a file, your passwords in your own store, nothing leaving your network. Check the file before anything starts, so a typo fails in CI rather than in front of a customer.

terminal

connectable check connectors.json
connectable probe connectors.json
connectable tunnel ./connectors.json my-server

Let us host it

Sign in and get the dashboard: guided setup for each service, a place to try a tool before trusting it, approvals waiting for a decision, spending, and the full record. Scriptable too, if you would rather manage it from the terminal.

terminal

connectable login --url <url> --token cmt_…
connectable endpoints create --name prod --connectors c1,c2
connectable audit list --outcome policy_denied

The hosted version will not run programs from your own computer, because a service that ran whatever a stranger typed would be handing out its own machines. To use something local, run one command and it reaches out to us — never the other way around.

Give your assistants one door.

Connect a service, pick the few things it may do, and hand over a key that is good for nothing else.

Get started Run it yourself

One door to every tool your AI uses.

Ten tools means ten setups. On every machine.

It doesn't have to be built for AI

Tools built for AI

Any REST API

Any GraphQL API

A web page

You pick what gets exposed. Connecting a service exposes nothing by default.

Decide what your assistants are allowed to do

A list of what each assistant may do

Nothing changes behind your back

Ask a person first

Limits that actually stop it

A stop button

A record of all of it

A refusal that says which kind it is

Works with the assistants you already use

On our servers, or entirely on yours

Run it yourself

Let us host it

Give your assistants one door.