OrgLines

Logistics: Create driver

logistics_create_driver

Create a driver profile (водій). The name is stored in three parts — 'last_name', 'first_name' and 'patronymic' are all required. 'phone1' and 'driver_license' are what a dispatcher actually needs; 'carrier_id' ties the driver to a carrier, 'default_vehicle_id' to their usual tractor, 'user_id' to an existing cabinet login when they have one. Requires confirmation. 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": {
      "last_name": "<last_name>",
      "first_name": "<first_name>",
      "patronymic": "<patronymic>"
    },
    "name": "logistics_create_driver"
  }
}

Input Schema

Name	Required	Description
`phone1`	No
`phone2`	No
`phone3`	No
`rating`	No
`status`	No	One of: Free, OnTrip, DayOff.
`user_id`	No
`last_name`	Yes
`birth_date`	No
`carrier_id`	No
`first_name`	Yes
`patronymic`	Yes
`birth_place`	No
`passport_type`	No	One of: Booklet, IdCard. Booklet has a series; an ID-card has an expiry and a УНЗР record number.
`tax_id_number`	No
`driver_license`	No
`passport_number`	No
`passport_series`	No
`default_vehicle_id`	No
`license_categories`	No
`passport_authority`	No
`passport_issued_at`	No
`medical_certificate`	No
`passport_expires_at`	No
`registration_address`	No
`passport_record_number`	No
`driver_license_authority`	No
`driver_license_issued_at`	No
`driver_license_expires_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well beyond annotations by disclosing the two-phase write protocol: the tool is 'PROPOSED, never performed directly', returns status='confirmation_required' with an action_id and plan_token, and only commits via confirm_action. That return-shape and gating behavior is exactly the kind of context annotations (readOnlyHint=false, destructiveHint=false) cannot convey.

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?

Purpose is front-loaded, field semantics follow, and the confirmation protocol closes it out — a sensible order with no filler sentences. The only redundancy is 'Requires confirmation.' immediately preceding the longer 'CONFIRMATION:' block, which restates the same idea.

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

Completeness3/5

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

For a 28-parameter creation tool with no output schema, the description nails the workflow that an agent would otherwise get wrong (the proposal/confirm_action cycle) but under-documents the bulk of the payload. An agent knows how to call it safely, yet not what most parameters mean or how they interact.

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 coverage is only 7% across 28 parameters, so the description must compensate; it does so for the highest-stakes ones by assigning roles to carrier_id, default_vehicle_id and user_id and flagging the dispatcher-critical phone1/driver_license. It leaves roughly twenty identity, passport and licence-date fields (passport_*, driver_license_*, tax_id_number, medical_certificate, rating, status) entirely uninterpreted, which is a real gap for a tool of this width.

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 driver profile (водій)') and immediately scopes it by the identity fields that define a profile (last_name, first_name, patronymic). An agent can tell this apart from logistics_update_driver or logistics_list_drivers purely from the verb and the 'create a profile' framing.

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 rather than stated: the description explains what a dispatcher 'actually needs' (phone1, driver_license) and when to supply user_id ('when they have one'), which guides field-level decisions. However, it never says when to use this rather than logistics_update_driver or when a driver should be created without a carrier, so tool-selection guidance remains inferred.

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

All OrgLines 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?