Skip to main content
Glama
Anandb71

CargoMind MCP Server

by Anandb71

assign_vehicle

Assign an own-fleet vehicle to a shipment by validating capacity and maintenance status; returns warnings and alternative suggestions for conflicts.

Instructions

Assign an own-fleet vehicle to a shipment. Checks capacity and maintenance status; idempotent.

Args:
    shipment_id: Shipment ID such as "SHP-1007".
    vehicle_id: Vehicle ID such as "TRK-105".

Returns:
    {"status": "ok", "warnings": [...], "vehicle": {...}} - warnings flag soft issues (vehicle in another
    city, driver near the 10h limit, low fuel, cold-chain mismatch). Errors suggest alternative vehicles.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vehicle_idYes
shipment_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses validation behavior (capacity and maintenance checks), idempotency, warning semantics (cross-city vehicle, driver hours, fuel, cold-chain mismatch), and that errors propose alternatives. It stops short of stating permission requirements or whether a failed validation rejects the assignment outright.

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 purpose, then compact Args and Returns blocks. The Returns block is somewhat redundant given an output schema exists, but it is short and information-dense rather than padded.

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?

Covers purpose, parameters, validation behavior, warning categories, and failure behavior. Since an output schema exists, the return explanation is a minor duplication rather than a gap; only explicit permission/precondition details are 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 0%, but the two parameters are named clearly and the description compensates with concrete example formats ("SHP-1007", "TRK-105") that the bare string schema lacks. More than adequate for a two-parameter tool.

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 ('Assign an own-fleet vehicle to a shipment') and scopes it to own-fleet, which implicitly separates it from the carrier-related siblings (list_carriers). An agent can distinguish this from track_shipment or list_vehicles immediately.

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

Usage Guidelines3/5

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

Usage is implied by the verb and the own-fleet scoping, but there is no explicit when-to-use or when-not guidance, and no routing to an alternative for non-own-fleet assignments. It never says what to do when capacity or maintenance checks fail beyond 'errors suggest alternative vehicles'.

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