MCP server
Each environment of an app is an MCP server: its models, records, actions, files and event log as tools, for a coding agent building the app or an assistant working with its data.
Connect
The server for an environment is at https://api.inferencebureau.com/v1/apps/<app>/environments/<env>/mcp (Streamable HTTP, no sessions). The app's Settings → API keys page shows the command with the app filled in.
claude mcp add --transport http reviews-dev https://api.inferencebureau.com/v1/apps/reviews/environments/development/mcp
# then /mcp in Claude Code and choose AuthenticateUse one server per environment, named so you can tell them apart (reviews-dev, reviews-prod).
Production's server writes the live app's data. Connect development's for building and testing.
Signing in
No key goes into the client's config. Without credentials the server answers 401 with standard OAuth metadata, and the client signs you in the way ib-apps login does: your browser opens the dashboard, you approve and pick the team, and the client receives a session that acts as you. Only clients on your own computer (loopback redirects) are accepted.
The server also accepts the same credentials as the records API: a key linked to the app, a key with Apps Permissions, or the environment's own token, which reaches only that environment (for an agent the app itself runs).
Tools
Tool descriptions are written from the environment's schemas when the client connects, so they name the app's real models and vector fields.
| Tool | Does |
|---|---|
get_reference | The environment's API reference as Markdown, whole or for one model: how to call it, every model's fields with their filters and descriptions, who may read it, every action with its params. An agent reads it once at the start of a task. |
list_models | The models and their fields: types, descriptions, required and writable, the filter operators each takes, whether it sorts, enum options and defaults, and which roles may read the model. |
list_actions | Every action, a model's and the global ones: what it does, its params as JSON Schema, whether it works on a record and takes a store, whether its result comes back, which roles may call it, and the webhook or schedule that queues it. |
find_records | A page of a model's records, with search (words in its text fields), filter, sort, first, after or skip, and select (fields and related records). |
get_record | One record by id, with its vector fields, or what select names. |
count_records | How many records match a filter. |
aggregate_records | Counts, sums, averages, least and most over a model's records, in groups by fields or date buckets. See Aggregates. |
search_records | Records nearest to some text or a vector field's vector by meaning, with _distance. |
create_record | Create from field values, or several from a list of them (up to 250; the answer names which were refused and why); runs the model's create action when it has one. |
update_record | Change fields; runs update when it has one. |
delete_record | Delete; runs delete when it has one. |
run_action | Run a model action (with id for one that works on a record) or a global one (leave model out), with params and an optional shop. Its schema names the actions; list_actions has each one's params. |
list_events | The newest events, optionally only one type or only failures, for working out what happened. |
list_stored_files | The app's own files in storage (what its code wrote with api.files), under a prefix or all of them, each with its size and a URL. See The app's own files. |
Building the app
Development's server also has the tools an agent needs to build the app, not only use it: the same ones the Apps assistant has. Production's files change only by a deploy, so production's server has the reading ones alone. A caller needs Edit on the app for the writing tools; variables and deploys take a team owner or admin, or a key with Apps Permissions.
The server's instructions tell the agent to read the app's AGENTS.md with read_file, then the skill for the area in .agents/skills/ before changing code (see Coding agents), so an agent on the server follows the same rules as one in a checkout. The app's tests are the one thing it can't run; those take a checkout and ib-apps test.
| Tool | Does |
|---|---|
list_files, read_file, search_files | The app's code: files with their sizes, a file's text with line numbers, a search by regular expression. |
write_file, edit_file, delete_file | Create or replace a file, replace an exact piece of one, or delete it. Each write names the copy it read, so a file changed meanwhile comes back as a conflict instead of being overwritten; a change goes through the same path as a dashboard save, so the generated client types follow and development's dev server hot-reloads it. |
get_problems | What's wrong in the code right now: type errors from the dev server's last check, a few seconds after each save. |
create_model | Writes api/models/<name>/schema.ib.ts from a name, a description and its fields (the schema's keys, plus required, unique, range, stringLength and regex at the top level, and parent, children, child and through as a model's name), with a storage key per field, and the built-in action files when asked. Answers with the model as the reference describes it. |
add_field, change_field | Add a field, rename one (its storage key stays, so its values follow), change its definition, or remove it. Both answer with what the change does to the records that exist: a new required field's empty records, a retype's unreadable values. |
create_action | Writes an action file, a model's or a global one, with params and options as plain literals, a run body when given, and onSuccess when asked. Answers with the action as the reference describes it. |
grant_role | Changes what a role may do in accessControl/permissions.ib.ts: a model's reads and actions (true or { filter }), its default, and global actions; the role is created when new. Answers with the role's grants. |
list_env_vars, set_env_var | The app's variables (secrets' values hidden), and setting a plain one: development's dev servers restart with it, production gets it on its next deploy. Credentials are refused; those are added as secrets in Settings. |
deploy | Deploys the environment's files to production and builds it. Only when the person asked for a deploy. |
Writes, errors and Logs
- Writes go through the model's actions exactly as the REST routes do.
- A refused write comes back as a tool error with each field's problem; a failed action with its message, its event id and its logs, so the agent can fix and retry.
- Every call is an
mcpevent in the environment's Logs; writes and runs also log their ownactionevents. - Vector searches by text and sourced vector fields embed as the caller's key, or as the team's Apps key for a sign-in or an environment token.