Vepathos

Import deliveries

import_deliveries

Import deliveries into Vepathos so their rows never pass through this chat: a file, a link or pasted rows, street addresses included (it geocodes them, so they skip geocode_addresses). What a row carries besides the address — customer, phone, packages, weight, volume, note, delivery window — survives only here, however few rows. Send one source: file when your host hands attachments to tools (ChatGPT: _meta openai/fileParams); url for a public https link or a Google Drive, Sheets or Docs share link as copied; text for pasted rows or a CSV or JSON file's text (a few hundred rows; larger files go by url). A path on the user's disk is not a url: this server cannot read it. When your host can read local files, send a CSV or JSON file's text as text; for a spreadsheet (.xlsx) ask for a share link or a CSV export, or let the user upload it in their Vepathos account, where it becomes a saved plan (list_plans, then optimize_routes). Do not shell out (curl/gdown/pip), and never parse or convert the file with a script. The stops load into a new plan named after the file, or replace the stops of plan_id. Returns import_id; next get_import_result until plan_id, then optimize_routes with that plan_id.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	No	Public https URL of the file, or a Google Drive, Sheets or Docs share link as copied.
`file`	No	The attachment, filled in by hosts that hand files to tools (ChatGPT file params); never build it by hand.
`text`	No	Deliveries as text: rows the user pasted, or a CSV or JSON file's text.
`plan_id`	No	Load the stops into this existing plan, replacing its stops and keeping its depot, fleet and settings. Omit to create a new plan named after the file.
`filename`	No	Names the new plan; default: the file's.
`timezone`	No	IANA time zone the rows' dates and times are written in.
`depot_country`	No	Country the addresses are in, to disambiguate the geocoding.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No
`status`	No
`plan_id`	No	The plan the stops load into; null until they load (get_import_result).
`import_id`	No
`dataset_id`	No
`expires_at`	No
`account_url`	No	Opens the plan in the user's Vepathos account. Requires signing in; private to the account.
`poll_after_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 25, 2026

TDQS

A4/5.0

Behavior1/5

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

The description discloses significant behavior (geocoding, creating/replacing plans, polling pattern, restrictions), but it directly contradicts the annotation destructiveHint: false because it states 'replace the stops of plan_id', which is a destructive side effect. Per rules, score 1 and flag annotation 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 lengthy but every sentence carries operational weight. It front-loads the core purpose and then systematically covers inputs, exceptions, and the follow-up workflow. It could be trimmed slightly, but the details are essential for a complex tool with multiple input modes and integration points.

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?

Given the tool's complexity (7 params, nested file object, output schema, many siblings), the description is remarkably complete. It covers all input modes, local file handling, conversion limitations, the geocoding behavior, plan creation/replacement, and the async result polling pattern. It also explains when to use other tools (geocode_addresses, list_plans, optimize_routes). Nothing an agent needs to call it correctly 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 coverage is 100%, so baseline is 3. The description adds substantial value beyond the schema: clarifies that file is host-provided and never hand-built, explains when each source (file/url/text) is appropriate, notes that a path is not a url, and explains the filename default and purpose of timezone and depot_country. These add meaningful usage semantics.

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 states a specific verb and resource: 'Import deliveries into Vepathos'. It differentiates from siblings by explicitly noting it geocodes addresses so they skip geocode_addresses, and that row attributes survive only here. This gives the agent a precise understanding of what this tool is for and why it exists.

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 provides explicit when-to-use guidance: describes the three input sources (file, url, text) and conditions for each, including host capabilities and file types. It also directs alternatives for spreadsheets (ask for share link or upload) and states what not to do (shell out, parse with script). It even mentions routing to list_plans and optimize_routes for saved plans, making selection unambiguous.

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?