Skip to main content
Glama

Logistics: Create freight order

logistics_create_freight_order
Destructive

Create a freight order (заявка) — a customer's request to move cargo. 'customer', 'plan_tons', 'load_point' and 'unload_point' are the minimum; 'rate_per_ton' is what we pay, 'customer_rate_per_ton' what we charge (the two sides of the margin). Resolve 'cargo_id' with logistics_list_references first when the cargo matters. The order number (RQ_…) is assigned by the server — never invent one. Starts in status New. Requires confirmation before it runs. CONFIRMATION: this tool is PROPOSED, never performed directly. You get status='confirmation_required' with an action_id and a plan_token, and the write happens only after confirm_action.

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": {
      "customer": "<customer>",
      "plan_tons": "<plan_tons>"
    },
    "name": "logistics_create_freight_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNo
cargo_idNo
customerYes
end_houseNo
end_phoneNo
end_placeNo
load_dateNoISO date (YYYY-MM-DD) or datetime.
load_typeNoVehicle body type. Prefer a code from the company's «Тип машини» book (Grain, Dump, Tent, Reefer, Flatbed, Container, Tanker) — loss-norm resolution matches this against the norm's transportType.
plan_tonsYes
end_regionNo
end_streetNo
load_pointNo
order_dateNoISO date (YYYY-MM-DD) or datetime.
distance_kmNo
end_contactNo
end_countryNo
start_houseNo
start_phoneNo
start_placeNo
unload_dateNoISO date (YYYY-MM-DD) or datetime.
end_districtNo
end_latitudeNo
end_localityNo
loss_percentNo
rate_per_tonNo
start_regionNo
start_streetNo
unload_pointNo
end_longitudeNo
start_contactNo
start_countryNo
start_districtNo
start_latitudeNo
start_localityNo
vehicles_countNo
freight_rate_idNo
start_longitudeNo
customer_rate_per_tonNo
estimated_cost_per_tonNo
customer_organization_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=false), the description discloses the two-phase proposal protocol: the call returns status='confirmation_required' with an action_id and plan_token and no write occurs until confirm_action. It also states the initial status (New) and that the order number is server-assigned and must never be invented — behavior an agent could not infer from structured fields.

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?

Front-loaded with the definition, then required fields, then field semantics, then the confirmation protocol — the most consequential information (nothing is written without confirm_action) is stated twice and cannot be missed. No filler sentences; the parenthetical glosses (заявка, 'what we pay'/'what we charge') each carry meaning.

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

Completeness4/5

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

For a 40-parameter mutation with no output schema, the description covers the essentials an agent needs to call it correctly: minimum required fields, the margin semantics, reference resolution, and the confirmation gate. The remaining gap is breadth of per-field meaning, which is only partly mitigated by the schema's sparse 10% coverage.

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 description coverage is only 10% across 40 parameters, so the description must compensate, and it does add real meaning for the highest-stakes fields: rate_per_ton vs customer_rate_per_ton as the two sides of the margin, and cargo_id requiring reference resolution. However, the other ~33 parameters (addresses, dates, geo, loss_percent, vehicles_count, freight_rate_id, customer_organization_id) get no semantic help from either schema or description.

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 ('Create a freight order') and defines the domain object inline ('a customer's request to move cargo'), including the local-language synonym (заявка). It is clearly distinct from logistics_get_freight_order / logistics_update_freight_order by naming the creation act and the server-assigned RQ_ number.

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?

Gives concrete pre-call guidance: resolve 'cargo_id' via logistics_list_references 'when the cargo matters', and enumerates the minimum field set. It also routes the agent through confirm_action for the actual write. It stops short of explicitly saying when to use update_freight_order instead of create, so it is not a full when/when-not pair.

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