You build little apps with Claude Code: an invoice tracker here, a stock planner there. Each one useful, each one stuck on one laptop. Toolchestrator is where they run for everyone else: shared data, one-click actions, full apps and terminals in the browser, and your tools inside any AI chat. No migration, no rewrite, nothing to deploy, and the app never leaves your machine.
Your apps stay on the machine you built them on. Your team needs only a browser.
AI made building apps easy. It didn't make them usable by anyone else.
Someone builds a genuinely useful tool in an afternoon. It works, for exactly one person, on exactly one machine. Nobody else can see it, use it, or even knows it exists.
Finance has an invoice tracker. So does Ops. So does that one PM. Three versions of the truth, none of them talking, because nobody could see what already existed.
The numbers your team needs live inside a database file on one laptop that goes to sleep at 6pm. Moving it all to “real infrastructure” is a project nobody has time for.
Your AI copilot does the wiring. You just tell it to.
A script, a command-line tool, a little web app, vibe-coded with Claude Code or any AI copilot and running wherever it already runs. Toolchestrator never asks you to move or rewrite it.
Give it your hub address and a personal token from your workspace settings. Your hub serves the full connect guide and the client. Your copilot fetches both and does the wiring.
The tool appears in your workspace: its story, its data, its buttons. Teammates browse the data, run its actions, even open its full app or terminal, all from their browser, or straight from their AI chat, with nothing to install.
The part that makes it infrastructure, not a dashboard. Connect the hub to Claude, or any MCP client, and your AI discovers your team's tools, reads their shared data, and runs their actions, with exactly your permissions. Set it up in a minute.
Every connected tool announces what it is, who built it, and which problem it solves, so the next person searches before they rebuild.
Leave a note on a tool, or pin one to a specific data model: how to run it, what not to touch on a Friday, the gotcha that cost someone an afternoon. Team knowledge that lives next to the tool, not lost in chat.
Tools publish the records worth sharing. Teammates and other tools read them with filters (“open invoices over €1,000”) straight from the hub, even when the source machine is asleep.
Every tool lists the actions it can perform. Pick one, press Run, see the result, executed on the owner's machine and delivered to your screen.
If a tool has a web interface, teammates open it with one click and use it as if it ran on their own machine. A floating switcher hops between your team's apps.
Built a TUI or an interactive command-line tool? Serve it through the hub and a teammate drives it live in their browser, keystrokes and all. The program still runs on your machine, and only the screen travels.
Deploy an app to run on a second machine, a teammate's or a spare box, so it keeps serving when your own laptop is asleep. Your instance stays primary and the other is the standby the hub falls back to, so a single live copy always answers. The app's source and env are sealed to that machine before upload, so the hub stores ciphertext and never sees them.
A live picture of your tool ecosystem: which tools feed which, who reads what and why. Drawn from real usage, not wishful documentation.
When one tool's data feeds another, those fields become a contract. If an AI edit would remove or change one, it's flagged with exactly which teammate's tool breaks, before it happens. amount · read by Reorder Planner
Chain tools into multi-step flows, or let one tool react the moment another's data changes. Orchestration without scheduled scripts to babysit.
Machines sleep. Work queues. When a tool comes back online it picks up whatever was asked of it, and everyone can see, live, what's reachable right now.
Every tool starts private. Its owner decides: keep it personal, share with a department, or open it to the company. One switch governs the data, the actions, and the app.
You ship little tools weekly with your AI copilot. Now each one gets an audience: your team can use it, other tools can build on it, and your copilot warns you before an edit breaks something a colleague relies on.
You don't need to write the tools. You just need to see them. One dashboard shows what exists, who owns it, what data flows where, and lets you run the things you need without asking anyone.
Use the team's tools from a browser like any web app, with no installs and no terminal. The spreadsheet-replacing tracker your colleague built is finally something you can open too.
Connect the hub to Claude and it can list your team's tools, read their shared data, and run their actions, all with exactly the permissions you already have in the dashboard. Two ways to connect, each about a minute.
https://hub.toolchestrator.com/mcp
claude mcp add --transport http toolchestrator \
https://hub.toolchestrator.com/mcp \
--header "Authorization: Bearer tcm_your_token"Your AI sees exactly what you see, never more. It reads shared data and runs actions as you, and you can revoke any connection from Settings at any time.
The whole design starts from one rule: nothing ever connects into your machine.
Your people are building AI tools whether you approved it or not. Toolchestrator gives you the registry, the audit trail, and the access control over what is already running.
Every AI-built tool your team connects announces itself: what it is, who owns it, which data it touches. The invisible scripts on someone's laptop become a registry you can actually read.
Who connected what, who ran which action, who opened whose app or console. A workspace activity log keeps the receipts, and platform admins get a metadata view across every workspace, records excluded by design.
Private by default. Every new member is admin-approved. Sharing is scoped to a person, a department, or the company, and re-checked on every single request.
SSO / SAML is on the roadmap. Today, access is per-workspace accounts with admin approval. Tell us what your rollout needs.
No, that's the point. Your tools keep running exactly where they run today. They connect outward to the hub to share what you choose to share: their description, their data models, selected records, and the actions they can perform.
A tunnel exposes a port to a network. Toolchestrator does the job that sits on top of that: per-user access inside a workspace, the app's data and actions surfaced to teammates, opening the full app or a terminal right in the browser, and a per-user MCP endpoint your AI can call. The reverse tunnel is one feature underneath, not the product.
Those ask you to rebuild the app on their platform, in their builder. Toolchestrator leaves your app exactly where you built it, in your stack, on your machine, and adds the team layer around it. No rebuild, no migration, no re-teaching your tool to a low-code UI.
Nothing inbound is opened. The app dials outward to the hub over a single connection, so there are no ports open on your machine and nothing listening for the public internet. The hub only forwards what your page already serves, and only to people in your workspace. Access is re-checked on every request.
The code and the app never leave it. You choose which data models, records, and actions to expose. Live app traffic is relayed through the hub to authorized teammates, so the hub sits in the request path like a reverse proxy rather than being sealed off from it. Treat it as a trusted relay, and keep real secrets and credentials out of what you sync.
Every tool starts private. Sharing wider is an explicit owner decision, and the copilot workflow warns before company-wide sharing when records look personal. Secrets and credentials are never meant to be synced. The hub is a collaboration layer, not a secret store. Access is re-checked on every request, and joining a workspace requires admin approval.
Not silently. The hub tracks which fields of your data other tools actually read. If an edit would remove or change one of those fields, the change is flagged with exactly which tool depends on it, so your copilot stops and asks instead of quietly breaking a teammate's workflow.
The data it already shared stays available on the hub, so teammates can keep reading it. Anything you ask the tool to do, and the live app itself, needs the machine online, since it is still the one running the app. Actions wait in a queue and run when the tool comes back. For always-on, people run the app on a small dedicated box, like a Mac mini. The dashboard shows live which tools are reachable right now.
Nothing. Teammates use everything (browsing data, running actions, opening tool apps) from the browser. Only the person connecting a tool needs their AI copilot for the one-time setup, and the hub itself serves the copilot the full connect guide and the client, so there is nothing to distribute.
Yes. Every user gets their own MCP endpoint, scoped to what that person can already see in the workspace. Their AI chat can read the connected apps' live and mirrored data and run their actions: read and run, not read-only. The hub enforces visibility on every call, so the AI never reaches past what its user is allowed to see.
It's built for AI coding copilots (Claude Code first), but the connection is a small client library published for both Python (pip install toolchestrator) and Node (npm install toolchestrator), so any assistant (or human) that can run Python or Node can connect an app. The two clients speak the same hub API, so a Python app and a Node app sit side by side in one workspace. Your hub also serves the Python client and a step-by-step connect guide directly.
The client libraries are (MIT, on PyPI and npm), so you can read exactly what connects your app and what it sends. The hub is the hosted, proprietary part. You bring an app with the open client; the hub handles the collaboration, access, and orchestration around it.
While Toolchestrator is early, the hub is hosted for you. On-prem and white-label, for teams that need the hub inside their own environment, are handled case by case, so get in touch if that is a hard requirement.
There is no public pricing yet. It is free while the first teams are onboarding. If you want to put a real team on it, reach out and we will work out the details together.
Anything small and useful: a script that parses invoices, a stock tracker that runs in a terminal, a tiny web app for quotes. If it can run Python or Node next to it, it can join the hub: no rewrite, no framework, no deployment.
Create a workspace, invite your people, and connect the first app with one sentence to your copilot.
Create your workspaceAlready have one? Sign in · New here? Follow the guide