Skip to main content
Glama

create_endpoint

Write-only schema tool: creates one route DEFINITION record in the project's schema. It does NOT call any API, send any HTTP request, or read or write application data — method below configures which verb the route being defined will answer, it is not a verb this tool performs. Use list_endpoints to read routes back.

What it defines: a custom, non-CRUD REST route attached to an entity, e.g. POST /orders/summary. This record IS the route's identity — its action word, HTTP method, auth mode and execution mode. It runs no code by itself: attach one or more Functions to it via create_function(entity_id=<this endpoint's returned id>, trigger_point='endpoint') — an endpoint's own id, not the entity's, is what a Function's entity_id must reference for that trigger point. Read the aaly://platform/functions resource before your first one.

auth: 'required' (default) behaves exactly like ordinary CRUD — callers need a valid token. 'public' accepts requests with NO Authorization header at all — there is no caller identity for its Functions to act as, so they typically call back into the project's own REST API using an API key stored via set_secret rather than an inherited token. There is no per-endpoint permission scoping yet: a public route is exactly as powerful as whatever key its Functions use, so treat a stored key backing a public route as a full-privilege service account and validate its input defensively (create_field with entity_id set to this endpoint's id, location 'body'/'query', turns on real request validation instead of accepting free-form JSON).

No nested paths: the URL is always /{entity}/{action}, exactly one path segment after the entity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
authNoDefaults to 'required'. See the tool description above.
labelNo
actionYesURL path segment after the entity, e.g. 'summary' for /orders/summary. Lowercase letters, digits and hyphens, starting with a letter.
methodYesConfiguration only — the single HTTP method the route being defined will respond to when a client later calls it. This tool sends no request of its own. Create a separate endpoint for another method on the same action.
entity_idYesThe entity this route is attached to (e.g. 'ENT7'). The URL becomes /{entity}/{action}.
project_idNoOptional if whoami returned a default_project_id.
descriptionNoWhat this route does — surfaced in the generated OpenAPI spec.
execution_modeNoDefaults to 'synchronous': the attached Functions' final output becomes the HTTP response. 'asynchronous': the caller gets an immediate 202 acknowledgement and the Functions run in the background.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations. Annotations only say non-readOnly/non-idempotent/non-destructive; the description explains that the record is metadata-only, that method is configuration not execution, that public routes have no caller identity and typically run as a full-privilege service account via a stored key, and that there is no per-endpoint permission scoping. These are exactly the behavioral risks an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the write-only/definition-only distinction, then structured into 'What it defines', 'auth', and 'No nested paths' sections. A few clauses are dense and reference sibling tools, but nothing is filler; the length is justified by the behavioral risks it must convey.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-param, non-idempotent create with no output schema, the description covers what the record is, how it is wired to functions, auth implications, request-validation technique, and path-shape constraints. An agent has everything needed to call it correctly and safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (88%) and every parameter already has a description, so the schema carries the semantics. The description adds real value for auth and method (explaining they are config, not actions) and for function-attachment wiring, but the remaining parameters (label, project_id, description) get no added meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('creates one route DEFINITION record in the project's schema') and immediately distinguishes what it is NOT ('does NOT call any API, send any HTTP request, or read or write application data'). This disambiguates it from runtime/call siblings and from create_function, which a naive reader might confuse with route definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing: use list_endpoints to read routes back, use create_function with trigger_point='endpoint' to attach execution, use create_field for request validation, and read the aaly://platform/functions resource before the first function. It also names the auth mode tradeoffs ('required' vs 'public') so the agent knows which to pick when.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources