Tools
Functions an AI agent can call, with typed parameters, permissions and structured results.
Open protocol · SDK · Station · CLI
Agent Apps are applications designed for AI agents. They give agents tools to act, interfaces to present information, and a full runtime to manage their lifecycle: install, configure, authenticate, run, and scale.
npm create @agentappsThe gap
Agents have had function calling (the model picking one of your functions and filling in its arguments) for years. What they never had was somewhere to put a screen, keep state, hold a credential, or hand work to another app. That is the whole point of this protocol.
standalone, cluster or on-demand. One instance per user if you need it.Gateway
Agent Apps speak their own protocol. Gateway is the bridge that re-exposes them as MCP tools. MCP, the Model Context Protocol, is the standard your client already speaks to discover and call tools, so it sees all +80 apps as native tools. No fork, no plugin, no change to a single app.
Notion, GitHub, Playwright, Calendar. Each one a manifest, tools and permissions.
One endpoint. Spawns, proxies, restarts and idles instances.
Speaks the protocol on one side, MCP on the other. That is the whole trick.
Teros, Claude Code, Cursor, Windsurf, VS Code, Zed. Unmodified.
What it looks like on the wire
You say "am I free Thursday afternoon?". The agent picks the tool. The app answers with structured data, not prose. Later, someone else moves a meeting and the app tells the agent, unprompted.
calendar_updated event, pushed, without being asked.The catalogue
The protocol is not a proposal waiting for adopters. The repo ships +80 apps across 22 categories, every one of them declaring its tools and its permissions in a manifest that validates today.
What an Agent App provides
An Agent App can be a single tool, or a full product with screens, storage, app-to-app calls and its own embedded AI agent. Everything below is declared in the manifest and enforced by the protocol. None of it is inferred.
Functions an AI agent can call, with typed parameters, permissions and structured results.
Visual UI rendered natively by the host: cards, tables, charts, forms, images. Falls back to text or markdown.
Install, configure, authenticate (OAuth / API key), start, stop, health checks.
Real-time notifications from the app to the agent: webhooks, state changes, alerts.
Granular grants over which tools, which data and which UI surfaces. Requested by the app, approved by the user. Tool hints like destructiveHint are declared, never inferred.
App-to-app communication. One app can invoke another's capabilities, through a binding the user controls.
And when the app grows into a product
Architecture
A host connects to a single station endpoint. The station spawns, routes, restarts and idles your app instances. Your code never deals with transports.
An IDE, assistant or agent runtime that discovers, installs and uses Agent Apps on behalf of its users.
One endpoint for hosts. Spawns, proxies, restarts and idles instances. Four runtime adapters, crash detection, graceful shutdown and sharding.
Your code. A self-contained application with tools, interfaces and logic. Runs standalone, cluster or on-demand.
Manages the app's lifecycle: spawns, routes, restarts and idles instances. Exposes a single endpoint for hosts to connect to. Transport-agnostic.
The AI platform (IDE, assistant, agent runtime) that discovers, installs and uses Agent Apps on behalf of its users.
A bridge that exposes Agent Apps to tool protocols like MCP, so they work in Teros, Claude Code, Cursor, Windsurf, VS Code and Zed with no changes.
Building one yourself
If you want to write one instead of using one: a REPL and CLI to run apps locally, a test harness for your suite, and a scaffolder that gets a new app to its first tool call in a single command.
The manifest
Every app ships an agentapp.json that has to pass safeParseAppManifest() from the protocol package. If it does not validate, it does not install. No optional-field drift, no undocumented behaviour.
Required fields
app.notion"id": "app.notion",
"version": "2.0.0",
"tagline": "Manage Notion pages, databases, and content",
"license": "MIT",
"category": "productivity",
"entrypoint": {
"type": "module",
"path": "src/app.ts",
"export": "factory"
},
"runtime": {
"transport": "stdio",
"command": "tsx"
},
"auth": {
"type": "oauth2",
"scopes": ["read_content", "update_content"],
"pkce": false,
"systemSecrets": ["CLIENT_ID", "CLIENT_SECRET"],
"userSecrets": ["ACCESS_TOKEN", "REFRESH_TOKEN"]
}Packages
Take the protocol alone to implement your own host. Take the SDK to write an app. Take the station to run them.
Elsewhere
Serve your installed apps, then point Teros, Claude Code, Cursor or Windsurf at them. Six clients, one config block each.
Read it→CreatorFounder, startup advisor, and the person building this. Software architecture, cybersecurity and scaling systems.
Read it→Get started
Scaffold it, run it in the REPL, then expose it to Teros, Claude Code, Cursor, Windsurf, VS Code or Zed through Gateway MCP, without changing a line.
npm create @agentapps