MCP (Model Context Protocol) is how an AI assistant like Claude — running in Claude Code, Claude Desktop, or any other MCP client — builds directly against your org's real schema and config, instead of you copy-pasting instructions into a chat window. Connect once, then ask the assistant to create an entity, wire up an automation, or generate a Logic Block, and it calls the real platform APIs on your behalf.
Connecting
MCP auth is a single, static, per-org API key — not the same login you use for the console app. Mint one from Org Settings, then point your MCP client at the server endpoint with that key as a bearer token. The key carries your real identity: every tool call is checked against *your* actual role and permissions, not blanket "anyone with a key" access.
Development environment only
An MCP key can never reach your org's Production environment, regardless of your role. It's a build/config tool for the environment you're actively developing in — production changes go through the console app once you're ready to promote (see Deployments).
Build in this order
Define your entities first (every entity gets create, get, list, update and delete routes automatically), then your logic blocks for business logic, then point your app at the app API. A Glyph is a code step used inside a logic block or schedule, not a place to keep data. MCP rejects a tool call that includes an argument the tool doesn't define, and a logic block with an unknown step type is refused when you save it, with the list of valid types.
Two things the assistant now handles for you: it picks the default access for new app users from your business (a shopper, a student) with set_default_member_access and tells you what it chose, and after it adopts a connector or AI provider it returns the exact Tenant Settings steps for entering the credentials (get_tenant_readiness shows what each tenant is still missing). Credentials are always entered by a tenant or organization admin in the console, never through MCP.
What you can build
| Area | What it does |
|---|---|
| Entities | Full schema authoring — fields, keys, views, indexes. |
| Events & automations | Wire up what happens when data changes — connector automations are saved with the connector's auth details, and list_event_deliveries shows whether each fire succeeded. |
| Logic blocks | Multi-step custom API pipelines. |
| Crews | Multi-agent automation graphs — create and edit them, and move a crew through draft → staged → active with the status field (only an active crew can be invoked; status delete is the soft delete). Tools you leave without requiresApproval get the catalog default. |
| Connectors | Adopt and configure prebuilt third-party integrations. |
| AI providers | The org's AI-provider catalog for logic blocks/agents to use. |
| Roles & ACL | The role → permission catalog, and per-user grants for tenant apps. |
| Org info & domain settings | get_org_info says which org and environment the key is aimed at (check it first in every session) and gives the full app API base URL and WebSocket endpoint your running app should call, plus the org's tenancy mode; the domain tools set Allowed Domains and the App URL. |
| Run & verify | invoke_glyph runs a Glyph for real as a chosen tenant; test_logicblock test-runs a Logic Block (a dry run: writes, AI and connector steps return stubs) and polls a background run by job id; import_metadata validates (dry run by default) and creates exported items; get_usage shows plan usage before a large load. |
| Schedules | Run a Logic Block, Glyph, connector action, crew or automation for a tenant on a timetable: create_schedule, list_schedules, update_schedule (also pause and resume), delete_schedule, run_schedule_now and list_schedule_runs. A paid-plan feature — a Free plan gets an upgrade message. See Schedules in the Automation docs. |
| Feature flags | list_feature_flags, describe_feature_flag, create_feature_flag, update_feature_flag and delete_feature_flag define the org's flags; list_tenant_feature_flags, set_tenant_feature_flag and clear_tenant_feature_flag_override manage one tenant's overrides. |
| Tenant settings & email templates | list_tenant_settings, set_tenant_setting and delete_tenant_setting manage one tenant's general, ui and notifications settings; list_email_templates and set_email_template manage org-level email templates shared by every tenant, and list_tenant_email_templates, set_tenant_email_template and delete_tenant_email_template a tenant's own overrides. Tenant tools need a tenant code (list_org_tenants lists them). Secrets, connector credentials, AI keys and SSO are never available through MCP. |
| Connector operations | get_connector_webhook_info, list_connector_logs, invoke_connector_action (runs one action for real, nothing is a dry run), get_tenant_connector_settings and set_tenant_connector_settings (non-secret values only). |
| Descriptions & export | get_asset_descriptions and set_asset_description keep plain-language descriptions on your assets; export_metadata bundles definitions for portability and import_metadata reads that format back. |
| Users & access (revoke) | assign_user_acl adds policies to a tenant user, keeping what they already hold; revoke_user_acl removes named policies and leaves the rest. |
| Users & access (approve, remove) | approve_tenant_user lets in someone waiting for approval (they get the workspace's default access); remove_tenant_user takes a person out of a workspace, or declines one waiting. Their account stays, and the last admin cannot be removed. |
What you can't build: actual data
MCP shapes data — it never touches it
There is no way to create, read, update, or delete a row of your application's data through MCP. It's a schema/config tool, full stop. This was tried once and deliberately removed, because a data-editing tool couldn't cleanly target one specific tenant in a multi-tenant org. If you want to seed or edit real records, use your org's own REST API directly. To load a batch of starter records without signing in as an app user, run a Glyph that calls ctx.app_db.batchCreateEntities (Python: batch_create_entities) with invoke_glyph for the tenant you choose. Each record is still a real write and counts toward your plan's API calls. A running app never calls MCP: it calls the app API at the base URL get_org_info returns.
A useful mental model: MCP defines what a "customer" entity *looks like* and what happens *when* one changes. It never creates a customer for you.
Custom connectors aren't supported
MCP can adopt and configure any connector already in the platform's catalog (Stripe, Slack, and dozens of others), but it can't define a brand-new, custom connector type — that's a code-level concept, not something schema/config tools can express.