MCP, in both directions.
Your AI builds and runs your project over MCP. Then the app you built can expose its own tools, so other agents can operate it. Both halves are the platform's job, not yours.
Most platforms speak this one way.
An AI that can write your app is useful. An app your AI can keep operating afterwards is a different thing entirely, and it needs the protocol pointed both ways.
Your AI operates the platform
The assistant you already use connects once and gains a working set of tools: create the project, write files, run migrations, deploy, read logs, query the database. Building and running your app happen in the chat you already have open.
Agents operate your app
Your deployed app can publish its own tools. Add a file per tool, deploy, and your project has an MCP endpoint of its own, with authorization and the protocol handled. Your app stops being a UI people click and becomes something agents can drive.
One file per tool. That is the whole server.
No protocol code, no transport to implement, no process to host. Turn it on in your project config, add a file per tool, and deploy.
[mcp]
enabled = true
// who may call this tool
export const access = 'member';
export default {
name: 'list_deals',
description: 'List deals, newest first.',
inputSchema: {
type: 'object',
properties: {
stage: { type: 'string' },
},
},
async handler(args, ctx) {
const { rows } = await ctx.db.query(
`SELECT id, name, stage, value_cents
FROM deals
WHERE ($1::text IS NULL OR stage = $1)
ORDER BY id DESC`,
[args.stage ?? null],
);
return { deals: rows };
},
};
The protocol work, already done.
Everything between "I have an idea for a tool" and "an agent somewhere is calling it safely."
No server to run
Your project gets its own MCP address when you deploy. The platform terminates the protocol, so there is no transport code in your project and no process of yours to keep alive.
Your app's tools are online for as long as your app is.
Locked by default
Every request must carry a valid token, including the opening handshake. Tokens are issued per app and cannot be replayed against another one, and you can revoke access from the console at any time.
Connecting an agent is a deliberate grant, not an open door.
Each tool says who may call it
A tool is declared for the owner, for collaborators, or for your app's signed-in users. The platform resolves the caller and enforces the rule before your handler runs.
Read tools open to your users, destructive ones kept to admins.
Your tool list is read, not run
Tool names and schemas are extracted from your files at deploy without executing your code. The contract an agent sees is fixed and inspectable, and a malformed tool fails the deploy instead of failing in front of a caller.
Broken tool definitions get caught before anything is live.
Private app, reachable tools
The MCP endpoint authorizes on its own token, independent of whether the app itself is published. An app nobody on the open web can reach can still be operated by an agent you authorized.
An internal ops tool your team's agents run, invisible to everyone else.
Your agent gets the manual
The platform hands your AI a written pattern for every capability, plus a live description of your project: its tables, its routes, its schedules. It builds against what your app actually is.
Ask for a tool and it already knows the file shape that deploys.
The spec sheet, in plain terms.
mcp/, each declaring a name, a description, an input schema, and who may call it.Numbers current as of August 2026.
Say it like this.
You do not write protocol code. You describe the tool you want your agent to have.
Asked and answered.
What is MCP?
MCP, the Model Context Protocol, is an open standard for connecting AI assistants to outside tools and data. An MCP server offers a list of tools, and any AI client that speaks MCP can call them. It is the reason an assistant can do things rather than only describe them.
Which AI tools can connect?
Any client that speaks MCP. There are step by step guides for Claude, Claude Code, ChatGPT, Cursor, Codex, and Antigravity, and the same endpoint works with anything else that implements the standard.
Do I have to host an MCP server?
No. You write a small file per tool inside your project and deploy. The platform serves the endpoint, handles the protocol, and manages authorization. There is no server process of yours to run, scale, or keep alive.
Is my app's MCP server secure?
Every call must carry a valid token, including the opening handshake, so an unauthenticated client cannot even enumerate your tools. Tokens are issued per app and cannot be replayed against a different one, each tool declares who is allowed to call it, and access is revocable from the console at any time.
Does my app have to be public?
No. The MCP endpoint authorizes on its own token, independent of whether the app is published to the open web. A completely private app can still be operated by an agent you have authorized.
Can I file work for my agent to pick up later?
Yes. You can write a plain-English task against a project from the console, and the next time your agent connects it can list open tasks, do the work, and report back. Useful for the ideas that arrive when you are not at a keyboard.
Ready to connect? Pick your AI tool. Building tools? The MCP reference has the details.
Connect it once.
Point the AI you already use at Hatchable, and build apps it can keep running long after they ship.
Want the technical surface? The MCP reference covers tools, tokens, and scopes.