Connect

MCP tools reference

Once connected (see Connect an AI agent), your agent has these tools. They all operate on your project's schema — entities, fields, and inspection — never on your app's end-user data directly; that happens over the REST API your agent (or your app) calls once the schema exists.

Orientation

whoami — call this first in any new session. Resolves your identity, lists your projects, and returns a default_project_id when your key was minted with one — so most other tools don't need project_id passed explicitly.

list_projects, describe_project — list every project, or get one project's full picture in a single call: its tenancy model, every entity with its fields, the relationships between them, and which query parameters actually filter today.

Projects

create_project — name is the only required field. slug auto-derives from it if omitted. multiTenant and publicSignup default to false — see Multi-tenancy for what that means in practice. The project's data table provisions asynchronously (~30 seconds).

update_project — change name, description, multiTenant, publicSignup, the emailVerification mode (off, optional or required), and the logoUrl and brandColor shown in your end users' verification and reset emails. Doesn't touch the schema or data.

Entities

create_entity — name (the URL slug, e.g. orders) and key (a unique 3-character uppercase prefix, e.g. ORD → record IDs ORD1, ORD2) are required. REST endpoints activate immediately once the entity exists.

list_entities, update_entity — list schemas project-wide or filtered; update an entity's label, description, or allowed HTTP methods. Doesn't touch field definitions.

delete_entity — soft-deletes the schema. Existing data records are not deleted.

Fields

create_fields — add many fields to one entity in a single call. create_entity also accepts a fields list, so a whole entity can be defined in one round trip.

create_field — the one that matters most to get right the first time. Required: entity_id, name (camelCase), type. For any relationship, use type: "reference" with targets — never text or list for a link to another record. multiple: true on a reference models a one-to-many. list is only for arrays of primitives (strings/numbers/booleans), set alongside valueType.

list_fields — every field on an entity, with its validation rules.

update_field — label, description, default_value, required, hidden, min, max, pattern, and values are mutable at any time. type, unique, search, multiple, targets, and valueType are not — the call is rejected atomically if it touches any of them, even mixed with mutable attributes in the same call. See Concepts for the migration path when you need to change one anyway.

delete_field — soft-deletes the field. Existing records keep the data; it's excluded from new validation and from responses going forward.

Spec generation

generate_openapi_spec — generates the OpenAPI 3.0 spec for every entity in a project and returns a presigned S3 URL. Its servers[0].url is your project's real REST base URL — this is how you get it, rather than guessing the slug pattern. Generate it again after adding fields; the spec reflects the schema at the moment you call it.

Functions and custom endpoints

create_function, update_function, delete_function, list_functions — your own Python on an entity's request lifecycle. deploy_functions ships a code bundle and list_deployments shows the history. create_endpoint, update_endpoint, delete_endpoint, list_endpoints attach a function to a non-CRUD route such as POST /orders/summary. See Functions and custom endpoints.

Secrets and variables

set_secret, list_secrets, delete_secret and set_variable, list_variables, delete_variable manage the runtime configuration your functions and notification channels read. Values for secrets are never passed through the agent: set_secret returns a link for a human to enter the value. Both can be set platform-wide for a project and overridden per tenant.

Notifications

set_notification_channel, list_notification_channels, delete_notification_channel and set_notification_template, list_notification_templates, delete_notification_template configure how and what your project sends. See Notifications.

Logs and tracing

list_logs reads request and function logs. get_request_trace takes a request id and returns every request and function execution that shared it, so a failure inside a function traces back to the call that caused it.

Files

upload_file uploads a file into a project's files entity. See File storage.

Support and feedback

file_support_ticket, list_support_tickets, get_support_ticket file and follow a bug against Aaly itself. file_feature_request, list_feature_requests, vote_feature_request request a capability Aaly is missing and vote on others'. add_comment replies on either; it is labelled as coming from an agent and can't change anything else on the record. A ticket or request in the on_hold status has been parked on purpose, and its holdReason says why. They are isolated per customer, and a ticket's request_id joins straight to get_request_trace. These tools are MCP-only by design; the dashboard shows the same records.