create_function
Define a Function: customer Python that runs on an entity's request lifecycle. This creates METADATA ONLY and deploys nothing — the code comes from the project's bundle, uploaded separately and deployed with deploy_functions.
Read the aaly://platform/functions resource before your first one: it has the payload contract, the repo layout handler paths point into, and runnable examples.
Four axes decide behaviour. trigger_point: before-request can rewrite the payload or reject the request outright; after-request sees the response; endpoint IS the response for a custom-endpoint route (see create_endpoint) rather than wrapping a CRUD operation at all. execution_mode: synchronous blocks the request and shares the trigger's whole-chain budget (2s before, 5s after, 25s for a synchronous endpoint, which stays under API Gateway's 29s timeout); asynchronous is fire-and-forget (5 min budget) with failures visible only in CloudWatch. methods: which HTTP verbs trigger it — irrelevant for trigger_point 'endpoint', where the method lives once on the endpoint record itself. order: Functions on the same trigger run lowest-first in ONE invocation, each receiving the previous one's output.
Metadata edits take effect within 30s with no redeploy — only changing the code bundle requires deploy_functions.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"entity_id": "<entity_id>",
"name": "<name>",
"trigger_point": "<trigger_point>"
},
"name": "create_function"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Lowercase identifier, unique within the project, e.g. 'validate_order'. Immutable once created. | |
| label | No | ||
| order | No | Execution order within the trigger point, lowest first. Default 100, which leaves room to insert ahead of an existing Function. | |
| enabled | No | Defaults to true. Disabling takes effect within 30s with no redeploy. | |
| handler | No | Dotted path into the code bundle, e.g. 'orders.before.validate'. Defaults to '{name}.handler'. | |
| methods | No | HTTP methods that trigger this Function. Defaults to all four. Ignored for trigger_point 'endpoint' — the method lives once on the endpoint record. | |
| entity_id | Yes | What this Function attaches to: an entity record ID (e.g. 'ENT7') for trigger_point before-request/after-request, or a custom endpoint's id (e.g. 'EPT3', from create_endpoint) for trigger_point 'endpoint'. Must resolve to the right kind for the declared trigger_point, and must belong to the same project. | |
| project_id | No | Project record ID (e.g. 'PRJ3'). Optional if whoami returned a default_project_id. | |
| timeout_ms | No | Per-Function ceiling, capped by the trigger's whole-chain budget. | |
| description | No | What this Function does — surfaced to agents reading the project's capabilities. | |
| trigger_point | Yes | Immutable — the payload contract differs entirely between them. 'endpoint' requires entity_id to be a custom endpoint's id, not a real entity's. | |
| error_handling | No | fail aborts the chain and rejects the request; log/ignore continue. Forced to fail for synchronous before-request Functions, which exist to be gates. | |
| execution_mode | No | Defaults to synchronous. Ignored for trigger_point 'endpoint' — set execution_mode on the endpoint itself (create_endpoint/update_endpoint) instead, since a route's sync/async behaviour is one property of the whole route, not of any one attached Function. |