Vepathos

Manage saved vehicles, depots and fleets

manage_catalog

DestructiveIdempotent

Add or change a vehicle, a depot or a fleet saved in the account: master data that stays after this conversation. Call it only when the user asks to add, save, rename, move or edit one ('add a 1,500 kg Sprinter', 'make a fleet called norte with 6 vans'). Not for one plan: how many vehicles a run uses, a capacity or a depot for today only are plan settings: pass them to optimize_routes and save nothing. 'Use 25 vehicles' is a plan setting, never 25 new vehicles nor a fleet of 25. resource=vehicle takes name, max_weight_kg and max_volume_m3: one vehicle per call, it is a type with its capacity. resource=depot takes name, latitude and longitude: an address goes through geocode_addresses first; tell the user the matched address and never invent coordinates. resource=fleet takes name and vehicles: a vehicle_id from list_fleet and the units the fleet owns standing. It groups vehicles already saved: save the vehicle first and use the id it returns; on update, vehicles replaces the whole list. action=create needs the name (coordinates for a depot, vehicles for a fleet); a name the account already has returns that row (outcome=already_existed) when the values match and NAME_TAKEN when they differ: ask whether to update it or use another name. action=update needs resource_id (a vehicle_id, depot_id or fleet_id from list_fleet) and the fields to change; what is omitted stays as it is. Say what will be saved and get a yes first. Does not consume plan stops.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	What the user calls it, e.g. 'Sprinter' or 'Barracas'. Required to create.
`action`	Yes	create saves a new one; update changes one the account already has.
`latitude`	No	Depot only. Decimal degrees (WGS84). From geocode_addresses when given an address. Required to create a depot.
`resource`	Yes	vehicle saves a vehicle the account owns; depot saves a place routes start from; fleet groups saved vehicles under one name.
`vehicles`	No	Fleet only. What the fleet holds. Required to create one; on update it replaces the whole list.
`longitude`	No	Depot only. Decimal degrees (WGS84). Send it with latitude.
`resource_id`	No	For update: a vehicle_id or depot_id from list_fleet.
`max_volume_m3`	No	Vehicle only. Cargo volume in cubic meters. Omit when the user did not give one.
`max_weight_kg`	No	Vehicle only. Payload capacity in kilograms. Omit when the user did not give one: never invent a capacity.

Output Schema

TableJSON Schema

Name	Required	Description
`depot`	No	The saved depot, when resource=depot.
`fleet`	No	The saved fleet and what it holds, when resource=fleet.
`outcome`	Yes	created, updated, or already_existed: the account had this exact one, so nothing was written. Say which to the user.
`vehicle`	No	The saved vehicle, when resource=vehicle.
`resource`	Yes	Which kind of row was written.
`account_url`	No	Opens the account's saved vehicles and depots in the Vepathos dashboard. Requires signing in.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 25, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare destructiveHint and idempotentHint, but the description adds substantial behavioral detail: duplicate creation returns already_existed or NAME_TAKEN, update replaces the whole fleet list, omitted fields remain unchanged, and the agent must say what will be saved and get a yes first. It also clarifies that the tool does not consume plan stops. No contradiction with annotations.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, call conditions, exclusions, resource-specific constraints, action-specific behavior, and confirmation requirement. It is logically ordered and front-loads the core distinction between catalog data and plan settings.

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 a tool with 9 parameters, two enums, and an output schema, the description covers all resource/action combinations, required fields, duplicate-name outcomes, update semantics, and user confirmation. The output schema handles return-value documentation, so no important guidance is missing.

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 description coverage is 100%, so the schema already documents each parameter. The description adds meaningful cross-parameter workflow beyond the schema: which resource accepts which fields, that depot coordinates must come from geocode_addresses, that fleet vehicles must already be saved and referenced by id, and that update requires resource_id. This justifies above-baseline but not the top score since field-level descriptions are already in the schema.

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 pair ('Add or change a vehicle, a depot or a fleet saved in the account') and distinguishes persistent master data from transient plan settings. It explicitly differentiates from sibling tools like optimize_routes and geocode_addresses, so an agent can route correctly without opening schemas.

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?

It gives explicit call conditions with concrete user phrases ('add a 1,500 kg Sprinter', 'make a fleet called norte with 6 vans') and states clear exclusions: plan-level capacity, depot-for-today, and 'use 25 vehicles' are plan settings to pass to optimize_routes, never catalog mutations. It also names the sequencing dependency on geocode_addresses and list_fleet.

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

All Vepathos tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?