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.
--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.
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.
- Your fileson your machine
- Sentrybuilt for AI
- Stripea REST API
- Lineara GraphQL API
- A changelogjust a web page
your assistant
https://connectable.sh/mcp
One address, one key, one place to switch something off. Connect a sixth thing and nobody has to change anything.
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 remoteAnything that already speaks the standard: a local program or a hosted server.
{ "name": "sentry",
"transport": "http",
"url": "https://mcp.sentry.dev/mcp" }Any REST API
from its own docsPoint at the API description a service already publishes, tick the handful of things your assistants may do, and those become tools.
{ "name": "stripe",
"transport": "openapi",
"specUrl": "…/spec3.json",
"include": ["GetCustomers", "GetCharges"] }Any GraphQL API
from the endpointThe same, for services that use GraphQL. You name the queries; nothing else is exposed.
{ "name": "linear",
"transport": "graphql",
"specUrl": "https://api.linear.app/graphql",
"include": ["Query.issues"] }A web page
no API at allA changelog, a status page, a wiki. Each page you name becomes one read-only tool that returns the text, not the page furniture.
{ "name": "docs",
"transport": "web",
"pages": [{ "tool": "changelog",
"url": "https://bun.com/blog", "selector": "main" }] }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.
{
"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, open source under MIT, 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.
$ connectable check connectors.json
$ connectable probe connectors.json
$ connectable tunnel ./connectors.json my-serverLet 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.
$ cbl login --url <url> --token cmt_…
$ cbl endpoints create --name prod --connectors c1,c2
$ cbl audit list --outcome policy_deniedThe 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.