Build internal apps. Deploy them yourself.

Full applications delivered over MCP: a backend your team writes, an interface Synapse renders from it, running on your own infrastructure.

Synapse

Build and deliver MCP apps with Synapse.

The framework that turns an application's tool schema into its interface, running inside your own agent rather than beside it.

Read the Synapse docs
Simple to build

Write the server. Synapse draws the rest.

Writing the logic takes a week. The screen around it takes a quarter, and somebody maintains that screen every time the logic moves. Synapse renders the interface from the schema instead, so a new parameter arrives with its own field.

  • Python or TypeScript An MCP server is a small program. Use the language your team already ships in.
  • The schema is the spec What a tool takes and returns is the contract, and the only thing to keep true.
  • Days, not a quarter The capability and something to look at land together.
A tool schema on the left declares three properties: a customer ID string, an amount number, and an approved boolean. On the right, the controls rendered from it are a text field, a number field and a toggle, in the same order, above the button that calls the tool.
Runs where you run

The app executes inside your boundary.

It runs in your own runtime, beside the agent, on infrastructure your team already operates. We sit outside the request path, so an internal app reaches an internal system and neither one leaves your network.

  • One deployment The interface ships with the application, so there is no second thing to run.
  • Self-hosted or managed The same runtime either way. You choose whose machine, and keep the features.
  • Reaches private systems An app inside your network talks to services that never touch the internet.
Your infrastructure: Agent runtime, MCP app, Your database, connected to each other. NimbleBrain sits outside that boundary with no connection into it. Outside the request path. Nothing crosses this line.
Governed like everything else

An app you built gets no special privileges.

An app your team writes installs, scopes and audits the way any other does: one workspace's namespace, that workspace's credentials, the same run record. A reviewer checks one path instead of asking which apps skip it.

  • One workspace at a time The same namespace wall as every other tool, including code you wrote.
  • Credentials stay owned Held by the workspace or the person. Never pooled, and never held by us.
  • On the same record Calls, inputs and output attributed to a person and a workspace, per run.
How isolation works →
The MCP app directory inside a workspace, listing installable apps alongside ones built in-house.

What teams build

Three shapes cover most of what gets built first.

Pick the one your team has been putting off.

The screen nobody funded

Every company runs a process through a spreadsheet because the tool to replace it never cleared the roadmap. An app wraps the systems that process touches and Synapse gives it a surface, so the team that needs it can build it.

Read the Synapse docs

Vendor onboarding

Collect, check and file the paperwork against the systems that already hold it.

Account review

One view assembled from billing, tickets and the CRM, without a data warehouse.

Approval queues

The request, the context behind it, and the button, in the same place.

MCP apps

Questions teams ask before they build

What does it actually take to build one?
An MCP server: a program in Python or TypeScript that exposes what your app does as tools, with a schema saying what each one takes and returns. Write the schema well and the interface comes free, because Synapse renders it from there. Build a custom surface when the generated one runs out of road.
Where does the app run?
Inside your own runtime, beside the agent, on infrastructure your team operates. We sit outside the request path and there is nothing extra to stand up, which is also how an internal app reaches an internal system without either leaving your network.
Can we keep our apps private?
Yes. An app can live in your own repository and never be published anywhere. Deploying from the built-in directory, from the mpak registry, or from a private repo of your own is the same operation on the same terms.
Will an MCP server written for another host work here?
Yes. Synapse reads the Model Context Protocol rather than a NimbleBrain manifest, so a server built for any compliant host installs and presents its tools on the same terms as anything else. An app you write here travels with you if you leave.
Does an app we build get more access than an installed one?
No. It lands in one workspace's tool namespace, runs under that workspace's credentials, and writes to the same run record. First-party code takes the same path as everything else, which is what lets a reviewer check the path once.
How do we roll one out across teams?
Apps deploy per workspace, so a platform team builds once and each team adopts on its own schedule. Ship a skill alongside the app to carry guidance on when to reach for it.

More of the platform

Each capability has a page. These are the ones nearest this.

See the whole platform

Build your first MCP app, or have us build it with you.

Start with discovery

Read the docs