Skip to main content
Glama

Prepare an automation

create_automation
Idempotent

Prepare a rule that routes deliveries on a schedule. template_plan_id (from list_plans) is COPIED for its depot, vehicles and settings, so editing that plan later does not change the rule. Say where the batch comes from: use_plan_stops for a route that repeats, or integration_account_id for a connected store. Say when it looks: looks_at for one time a day, or window_from/window_to with every_minutes. Send your own operation_id; the same one twice returns the same rule, never a second. It is always created SWITCHED OFF and decides nothing: only the user turns one on, in the dashboard, because a rule that is on spends their stops unattended. Say what it would do, give them account_url, and never say it is running. missing lists what a run would still lack. It costs no plan stops.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoDays it looks, 0 = Sunday … 6 = Saturday.
lookNoclock looks at a time of day; fill looks when enough orders wait; both does either.clock
modeNosuggest: it works the routes out and asks. auto: it routes on its own once switched on.suggest
nameYesWhat to call the rule, e.g. 'Reparto de la mañana'.
fill_byNoWhat fill_percent counts before a run is worth starting.orders
looks_atNoOne time of day, HH:MM: it looks once, then. Use this for 'every day at 8'.
timezoneNoIANA time zone the schedule is read in.UTC
max_unitsNoVehicles the user can actually put on the street.
window_toNoEnd of that window.
match_tagsNoOnly orders carrying these tags, e.g. ml:flex, ship:envio-a-domicilio.
min_ordersNoFewer waiting orders than this and the slot is skipped.
window_fromNoStart of a window it looks inside.
fill_percentNoShare of the fleet's capacity that makes a run worth it.
min_packagesNoFewer waiting packages than this and the slot is skipped.
operation_idYesYour id for this attempt. Sending it twice returns the same rule instead of a second one.
every_minutesNoHow often it looks inside the window.
use_plan_stopsNoTrue for a route that repeats: the plan's own stops are the batch. False when a store feeds it.
vehicle_type_idNoTemplate vehicle entry. Omit for a single type; otherwise choose in the dashboard.
template_plan_idYesA saved plan (list_plans) to copy the depot, the vehicles and the optimizer settings from. It is copied once, not linked: editing or deleting that plan later does not touch the rule.
stops_per_vehicleNoStops each vehicle takes.
integration_account_idNoA connected store to take orders from (from list_automations `stores`).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
enabledYesNew rules are off. A replay preserves the current state, including a user activation.
missingNoWhat a run would still lack (depot, fleet). Empty: the user only has to switch it on.
replayedNo
automationYes
account_urlNoOpens the plan in the user's Vepathos account. Requires signing in; private to the account.
vehicle_optionsNoTemplate vehicle choices. Select in the dashboard; replay never edits the rule.

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 annotations. The description explains idempotency ('the same one twice returns the same rule'), the always-SWITCHED-OFF state, that it costs no plan stops, and gives guidance on how to describe it to users ('never say it is running', 'give them account_url'). This adds substantial behavioral context not present in annotations. No contradiction.

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?

The description is a dense paragraph of about 150 words, but every sentence adds essential information. It is front-loaded with purpose and then logically organizes parameter decisions, behavioral notes, and user-facing guidance. While long, it is not verbose given the tool's complexity.

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?

With an output schema present, return values are covered. The description addresses core invocation decisions (batch source, schedule, idempotency), operational constraints (switched off, no cost), and user communication hints. It is complete for an agent to call this tool correctly without additional external knowledge.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds meaning by explaining parameter relationships (e.g., choice between use_plan_stops and integration_account_id) and the significance of template_plan_id being copied. It doesn't cover every parameter, but the added context for key decisions is valuable.

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?

The description opens with a specific verb+resource: 'Prepare a rule that routes deliveries on a schedule.' It clearly distinguishes this from siblings like list_automations or optimize_routes, and the subsequent detail on template copying and schedule definition reinforces the unique purpose.

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

Usage Guidelines4/5

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

Provides clear context on how to use the tool: where the batch comes from (use_plan_stops vs integration_account_id), when it looks (looks_at vs window_from/window_to with every_minutes), and the idempotency of operation_id. It doesn't explicitly name alternatives or state when not to use it, but the guidance is sufficiently clear for an agent to select it appropriately.

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