OPEN SOURCE · SELF-HOSTED · AGENT READY
UNIVERSAL CAPABILITY LAYER FOR AGENTS
tool-bridge turns MCP, HTTP APIs, context, devices, and remote gateways into one coherent access layer. Agents discover what exists, inspect the live contract, and call it within their identity boundary.
AGENT ENVIRONMENTS
REAL CAPABILITIES
POST /system/status/getDEMOOne route across environments
Contracts from the live instance
Capabilities follow identity
One meaning, many clients
Wherever the agent runs
BUILT FOR REAL WORK
Discover, invoke, deliver, and manage. Turn an agent experiment into a workflow that keeps running.
YOUR DAILY WORKSPACE
Search tools, pin favorites, and return to recent calls. Follow a new tool through authorization and first use, with dedicated spaces for browsing and administration.
Explore the new Dashboard↗Favorites☆
Recently used
DURABLE DEVICE DELIVERY
Choose persistent delivery and let devices claim work when they return. Track operation state and completion receipts across the offline boundary.
~delivery: mailboxExplore device delivery↗CONTEXT THAT PERSISTS
Manage objects and uploads through the default Store. Organize knowledge with platform Context. PostgreSQL keeps metadata; S3-compatible storage keeps bytes.
01 / ONE BRIDGE, EVERY RUNTIME
Models change. Runtimes move. Tooling keeps growing. Separate the capability layer so agents can keep working across environments without rebuilding every integration.
Agent product teams
Agents read the tools, parameters, and guidance visible to them from the target instance. Prompts stay lean and boundaries stay explicit.
Platform and security teams
MCP, HTTP, object storage, and local devices share path-and-action policies. Real credentials remain in their own SecretStore.
Tool and service providers
Continue shipping your MCP server, REST API, or plugin. tool-bridge handles projection, discovery, authorization, and consistent semantics.
02 / RUNTIME-NATIVE
Agents follow a stable loop: discover the paths visible to the current identity, inspect the live contract, then call the same path. Capabilities can evolve without republishing every client.
illustrative sessiontb tree --depth 2/
├── tools/
│ ├── github/
│ └── linear/
├── ctx/
│ └── briefs/
└── system/
└── statusscope appliedInvisible paths never enter the result.
tb help system/status/get --json# system/status/get
Gateway health and summary.
{}readhealthy · version · nodeCountruntime truthMarkdown, Help DSL, and JSON come from the same live instance.
tb call system/status/get{
"healthy": true,
"version": "<runtime version>",
"nodeCount": 12
}200 · allowedThe caller SK is never forwarded upstream.
~help and JSON Schema reflect the path, identity, and mounted capabilities.
Discovery and calls share one decision; denied paths reveal no existence.
HTTP, CLI, Dashboard, and MCP share one tree and one node model.
03 / BEYOND PROTOCOL ADAPTERS
An adapter answers “how do I call this?” tool-bridge goes further: what can this identity see, where does the contract come from, who may call it, and how are credentials isolated?
Explore the product model↗tools/Mount MCP, declarative HTTP, built-ins, or plugins.
↗ctx/Access platform Context and S3-compatible objects through one capability model.
↗device/Devices connect outbound; structured commands can queue durably while offline.
↗teams/Mount another tree as a subtree while isolating both identities.
↗04 / SECURITY IS STRUCTURAL
Every discovery and call enters the same tree with an identity. Configuration stays manageable, real credentials stay in SecretStore, and providers and remotes use isolated outbound identities.
Read the security boundaries↗tools/github/issuescall allow200tools/github/adminread deny404device/macbookregister no scope404Denied paths do not reveal whether a node exists.
When allow and deny both match, deny always takes precedence.
Nodes store authRef values and never expose real credentials.
Caller keys are never forwarded to providers or remotes.
05 / RUN IT YOUR WAY
Start with Node, PostgreSQL, and S3 on your own infrastructure. Scale with Kubernetes or embed the capability layer in your application.
START HERE
A complete stack with Node, PostgreSQL, and S3-compatible storage. No hand-written .env; finish installation through local pairing.
$ docker compose up -d
Run from the cloned repoPersist data volumesComplete local pairing
GROW WITH YOUR TEAM
Deploy the Node service with Helm and external PostgreSQL and S3. Replicas share initialized bootstrap state, with Redis routing real-time device calls.
$ helm show values ./deploy/helm/tool-bridge
Inspect chart valuesPair and initializeConfigure readiness
BUILD YOUR OWN
Embed the app through the Node SDK root. Use neutral client, store, and device entries across runtimes. Your host supplies stores and domain repositories.
$ import { createToolBridge } from '@tool-bridge/sdk'
Inject host dependenciesSupply domain repositoriesMount your providers
Not sure yet? Compare every deployment path↗
06 / DOCUMENTATION
Complete the first loop, connect existing capabilities, deploy to production, or establish security governance. Every route begins with real work.
Browse all docs↗Start, authenticate, discover, and make one real call.
Reuse MCP, HTTP APIs, devices, and storage.
Choose a host and establish production acceptance and recovery.
Least privilege, secret isolation, feedback, and diagnostics.
BUILD BEYOND THE DEMO
The next generation of software will not trap agents in one environment. Connect one real capability today, then keep expanding the frontier.