CXT Software MCP by usefulapi

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds useful behavioral context beyond annotations: the required XDISPATCH user type and a cost of 1 API credit with the vendor. It does not describe error cases or response shape in depth, but the added auth and billing details are valuable.

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

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

The description is a single front-loaded sentence followed by a short endpoint reference. Every element is useful: returned fields, user context, auth requirement, cost, and HTTP path. No filler or repetition.

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

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

For a one-parameter read tool with rich annotations and no output schema, the description is complete enough to invoke correctly. It covers the required user type, cost, endpoint, and the main fields returned, which compensates for the absent output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single parameter is already documented as 'CXT on-demand order id.' The description reinforces that this is an on-demand order through the endpoint path, but adds no new format, range, or constraint details beyond the schema. The baseline of 3 applies when the schema carries parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('One on-demand order with itemized charges') and scopes it to an 'OPERATIONS APP (X Dispatch) user.' This distinguishes it from the sibling cxt_get_order by user perspective and lists the returned content, so an agent can identify its role without opening the schema.

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

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

It gives clear context for when to use this tool: when the caller needs the order as an Operations App user and can sign in with user type XDISPATCH. However, it does not explicitly name cxt_get_order as the alternative or state when not to use this tool.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered. The description adds genuinely non-obvious context: an authentication prerequisite (user type INET), a per-call vendor cost of 1 API credit, and the underlying GET endpoint, all of which affect agent behavior.

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

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

Front-loads the resource and its contents, then the audience constraint, then the alternative and cost. Dense but every sentence carries signal; the endpoint string is mildly redundant with routing info already given.

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

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

No output schema exists, and the description compensates by enumerating the payload facets returned. With auth requirements, cost, alternative tool, and optional-param behavior all stated, an agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented. The description restates the optional itemized charges flag and the endpoint template hints at path composition, but adds no format, default-behavior, or failure semantics beyond the schema — baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (retrieve one on-demand order) and enumerates the returned facets: status, confirmation, pickup, delivery, proof-of-delivery. It explicitly distinguishes itself from the sibling cxt_get_dispatch_order by naming the audience (INTERNET user vs Operations App).

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

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

Gives an explicit routing rule: Operations App users should use cxt_get_dispatch_order instead, and the caller must be signed in with user type INET. It does not mention cxt_list_recent_orders or cxt_search_shipments as ways to discover an order id, which keeps it short of a full when/when-not map.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds genuinely useful context beyond that: the required permission scope, the GET endpoint path, and the capacity formula for maxAllowedStops. It does not say what happens on a permission failure, but for a trivial read this is solid.

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

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

Two short, front-loaded sentences with zero filler: the returned fields come first, then the auth requirement and endpoint. Every clause carries information an agent can act on.

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

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

With no output schema, the description must carry the return value, and it does by naming the three limit fields explicitly. It stops short of stating value types/units or the failure mode when the permission check fails, which keeps it just below complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description instead spends its words on the returned fields, which is the right choice here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names the exact resource (itinerary planning limits) and enumerates the three values returned, including the derived semantics of maxAllowedStops (shipments x 2). This is clearly distinguishable from the sibling plan/save/optimize tools, which mutate plans rather than read settings.

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

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

States a hard prerequisite (an Operations App user with ITINERARY_PLANNING_ACCESS) but never says when to call this versus the sibling planning tools, nor what to do when the permission is missing. Usage is implied by the read-only settings nature of the endpoint rather than explained.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true. The description adds genuinely new behavioral facts: the vendor cost of 1 API credit and the underlying POST /v2/Shipments/Summaries call, which matter for budgeting on a read-only tool that uses POST.

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

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

A single tight sentence that front-loads the scope and appends cost and endpoint. No filler, though the phrasing 'the orders of their account' is slightly redundant with the preceding clause.

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

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

For a one-parameter, read-only listing tool with safety annotations and no output schema, the description covers scope, cost and endpoint adequately. It could have noted the default result size or the shape of a shipment summary, but nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'count' parameter is fully documented with range and default, so the schema does the work. The description's only nod to parameters is the vendor-side name 'numRecentOrders', which adds little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('most recent orders') and narrows scope precisely to 'the signed-in INTERNET user (user type INET; the orders of their account)', which clearly separates it from cxt_get_order or cxt_search_shipments.

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

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

The scoping to the signed-in INET user implies when this is appropriate, but it never explicitly says when to prefer it over siblings like cxt_search_shipments or cxt_get_order, nor does it state exclusions.

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

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

"proposal only: nothing is dispatched until cxt_save_order_plan" explains why readOnlyHint=true despite an optimization operation — context annotations cannot convey. It also discloses the required ITINERARY_PLANNING_ACCESS scope and the backing endpoint. It does not say whether the proposal is returned in the response or persisted server-side.

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

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

A single tight sentence with the key constraint (proposal only) front-loaded in the parenthetical. The trailing endpoint is slightly incidental but still useful for tracing. No filler.

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

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

With 8 parameters, required auth, and no output schema, the description covers permissions and the commit boundary but says nothing about what the call returns (an optimized plan object, an id, a diff). An agent knows how to invoke it safely but not what to expect back.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all 8 parameters including both enums are already documented inline, setting the baseline at 3. The description adds no guidance on the non-obvious distinction between plan_order_ids and all_input_order_ids, which is the main semantic risk in the payload.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Re-optimize a single driver's plan" names a specific verb and scoped resource, and the "single driver" qualifier implicitly separates it from the broader sibling cxt_optimize_route_plan. The sibling is not named explicitly, so the differentiation relies on inference.

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

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

"after manual changes" gives a clear trigger condition, and the parenthetical explicitly names cxt_save_order_plan as the follow-up commit step. It stops short of stating when to prefer this over cxt_optimize_route_plan or cxt_plan_orders.

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

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

The annotations declare readOnlyHint=true and destructiveHint=false; the description reinforces this by explaining the mechanism ('proposal only: nothing changes until cxt_save_route_plan'), which is exactly the context an agent needs to trust that re-optimizing is non-persistent. It also adds the required ITINERARY_PLANNING_ACCESS scope and the underlying endpoint, which annotations do not convey. It stops short of describing the returned proposal's shape or failure modes.

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

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

Three short clauses, front-loaded with the action and its precondition, then the safety caveat, then auth and endpoint. Zero filler for an 11-parameter tool.

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

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

For a complex planning tool with no output schema, the description covers the two things an agent most needs beyond the schema: that the result is a non-persisted proposal and what permission is required. What's missing is any hint about what the proposal contains or how the optional inputs (input_route_ids, excluded_stop_ids) affect the outcome.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high (82%), so the schema already documents route_id, post_date, start_time/end_time, goal, enhanced_routing, and the ID arrays. The description adds only the {postDate} path placement and no semantics for the undocumented fields (is_placeholder, excluded_stop_ids), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Re-optimize a single route') with a clear scope qualifier ('after manual changes') that separates it from the bulk planner siblings like cxt_plan_routes and from the order-level cxt_optimize_order_plan. It never names those siblings explicitly, so the distinction is inferred from wording rather than stated.

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

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

The phrase 'after manual changes' gives a concrete trigger condition, and '(proposal only: nothing changes until cxt_save_route_plan)' routes the agent to the follow-up save tool. No explicit when-not guidance or discussion of choosing between route-level vs order-level optimization is given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by stressing the plan is only a proposal until cxt_save_order_plan. It also adds non-structured context: the ITINERARY_PLANNING_ACCESS permission requirement and the prerequisite call to cxt_get_planning_limits. Missing rate-limit or planning-window constraint details keeps it from a 5.

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

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

Front-loads the proposal semantics and the 'only PROPOSES' warning, then layers permissions, prerequisite, and endpoint. No filler sentences; each one adds a distinct operational fact.

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

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

With no output schema, the description compensates by outlining the returned itinerary contents (sequenced stops, times, distance, unassigned stops), and it covers auth scope and the prerequisite limits call. An agent has everything needed to invoke this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 88%, so nearly every parameter is documented in the schema, and the description adds no syntax or format detail beyond it. Its mention of 'pickup and delivery stops in sequence, with times, distance and unassigned stops' describes the response rather than parameter semantics. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Generate a proposed itinerary that assigns on-demand orders to drivers', and enumerates the output shape (sequenced stops, times, distance, unassigned stops). This lets an agent distinguish it from cxt_plan_routes and cxt_optimize_order_plan without opening any schema.

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

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

Explicitly states the tool only proposes and that nothing is dispatched until cxt_save_order_plan is called, and it directs the agent to call cxt_get_planning_limits first. It does not contrast with cxt_plan_routes or cxt_optimize_order_plan, so the sibling-selection guidance is incomplete but otherwise clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces and explains this by framing the call as a proposal with an explicit save step, and discloses the access scope and underlying endpoint. It adds real value on side-effect boundaries but says nothing about cost, latency, or limits on large route sets.

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

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

Three dense sentences: purpose first, then the side-effect boundary and follow-up tool, then the access and endpoint. No filler, and the most decision-relevant facts are front-loaded.

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

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

For a 12-parameter, five-required planning call with no output schema, the description covers the intent, the mutability contract, and the shape of the result well enough to invoke correctly. Minor gaps remain around the sizing parameters (num_placeholders, max_stops_per_route) that carry no schema description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 83% schema coverage the baseline is 3, and the description earns an upgrade by explaining the otherwise ambiguous relationship between input_route_ids and output_route_ids ('stops move between the output routes'). It also names the result payload components (times, distance, unassigned stops) that correspond to the planning inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Generate a proposed re-sequencing of the stops of existing routes for one route date' — and clarifies the distinctive mechanic that stops move between output routes. It does not explicitly contrast with the sibling cxt_optimize_route_plan, so an agent must infer the difference from the word 're-sequencing' versus optimization.

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

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

Gives clear context: this is a proposal, 'nothing changes until cxt_save_route_plan is called', which names the follow-up sibling and establishes the plan/save workflow. Also states the required scope ITINERARY_PLANNING_ACCESS as a precondition. It stops short of naming when to prefer this over cxt_optimize_route_plan or cxt_plan_orders.

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

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

Beyond the annotations, it discloses real consequences: drivers receive work in the app, customers may be notified via status rules, success returns an empty 204, and ITINERARY_PLANNING_ACCESS is required. It does not warn that the call is non-idempotent (annotations say idempotentHint=false), so a repeated call could dispatch twice, and it says nothing about the driver_pay_locked_status branch effects.

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

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

The commit/dispatch effect is front-loaded in the first clause, and the approval precondition follows immediately. It is dense but well ordered; only the trailing permission and endpoint notes are slightly less essential than the behavioral warnings that are absent.

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

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

For a destructive, non-idempotent, open-world mutation with no output schema, the description covers the effect, the sequencing prerequisite, the required parameter shape, the permission, and the empty 204 response. An agent has enough to call it correctly and only once.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%. The description restates the stop fields (id, type, sequence, from) which are already fairly well documented in the schema, and adds the useful instruction to copy `from` from the plan reply. It adds nothing about `confirm` or `driver_pay_locked_status`, which the schema already explains, so the net value over the schema is modest.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ('COMMIT an order plan') and immediately states the concrete effect: orders are assigned to drivers and dispatched. This is clearly distinguishable from the sibling planning tools (cxt_plan_orders, cxt_optimize_order_plan), which are named as prerequisites rather than equivalents.

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

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

Explicitly gates usage: 'Use only after the user has seen and approved the plan from cxt_plan_orders / cxt_optimize_order_plan.' That names both the alternative tools and the condition that selects this one over them, leaving nothing to inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the description's job is to add context, which it does: it discloses the real-world dispatch to drivers, the required ITINERARY_PLANNING_ACCESS permission, the empty 204 response, and the endpoint. It does not explain consequences of the driver_pay_locked_status choice (what locked pay means or whether unlocking is reversible), which is the main remaining gap for a destructive mutation.

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

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

Compact and front-loaded: the mutating effect is stated first, followed by the prerequisite, parameter provenance, response and auth details. Every sentence carries information; slight loss from terse phrasing like 'as in the plan' and 'copy `from` from the plan reply' which requires the agent to already know the plan shape.

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

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

No output schema exists, and the description correctly states the response is empty on success (204). With auth requirements, endpoint, prerequisite tooling and parameter provenance all covered, an agent has what it needs to call this correctly; only the pay-lock enum's operational meaning is left entirely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so the schema already documents most parameters, including the const `confirm` and `driver_pay_locked_status`. The description adds useful provenance guidance for the stops fields (id, sequence and from come from the plan reply), but says nothing about the plans/routeId structure or when to use UNLOCK_AND_DISPATCH vs KEEP_LOCKED_AND_DISPATCH, so it does not fully compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (COMMIT/save), resource (route plan for one route date) and concrete effects: moves and re-sequences route stops and dispatches the changed routes to drivers. It explicitly names the sibling tools (cxt_plan_routes / cxt_optimize_route_plan) it pairs with, so an agent can tell it apart from the read/planning tools.

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

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

Gives an explicit precondition: use only after the user has seen and approved a plan produced by cxt_plan_routes or cxt_optimize_route_plan. That names both the alternative tools and the condition that selects this one, leaving nothing to inference.

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

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

Beyond the readOnly/openWorld annotations, it discloses result volume (up to 1000 per page), vendor cost (1 API credit), and a non-obvious auth caveat: an Operations App login calls this without credentials, limiting results to internet/anonymous-visible data. Those are exactly the operational details an agent cannot 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.

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

Content is front-loaded: the search capability and tracking_type contract come first, with pagination, auth, and cost notes trailing. It is dense but every sentence carries information; only the trailing endpoint/cost line is slightly tacked on.

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

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

With no output schema, the description correctly states what is returned (shipment summaries, page cap) and the schema covers pagination mechanics. Auth limitations and cost are disclosed, leaving only minor gaps like the fields present in a summary record.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by enumerating what each tracking_type value matches (Location = origin/destination or stop name, Postal = zip or zip+4, Tracking = references/barcodes) and clarifying that DateOnly takes no criteria. This goes beyond the terse schema enum descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb (search) and resources (orders and route stops) plus the searchable dimensions, so an agent immediately knows this is a multi-field summary search. It doesn't explicitly name which sibling to prefer (e.g., cxt_track_shipments vs cxt_list_recent_orders), but the summary-search framing differentiates it adequately.

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

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

The description clearly explains how tracking_type drives search_criteria, including the DateOnly case where criteria is omitted and the date range is used. That is strong context for correct invocation, but it offers no explicit exclusions or guidance on when to pick a sibling like cxt_track_shipments instead.

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

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

Although annotations already declare read-only, open-world, and non-destructive behavior, the description adds meaningful operational context beyond them: INET login yields the most detail, Operations App login calls without credentials and returns only the limited public view, and each call costs 1 API credit.

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

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

The description is front-loaded with the core purpose and stays compact, with no obvious filler. The first sentence is dense with several semicolon-separated clauses, which slightly reduces readability, but overall the structure is efficient.

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

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

Given the fully described six-parameter schema and no output schema, the description covers the key behavioral nuances: what is matched, what is returned at a high level, and how authentication affects visibility. It could say a bit more about response pagination or error handling, but the schema carries much of that detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds specific meaning to the tracking_numbers parameter by naming Reference1/Reference2 of orders or route stops, which goes beyond the schema's generic 'references or barcodes' wording, though it says little about the date or pagination parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Track orders and route stops by tracking number') and explains the matching semantics (parcel reference, item barcode, Reference1/Reference2). It does not explicitly differentiate itself from the sibling cxt_search_shipments, so it falls short of a 5.

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

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

The description gives clear context for when the tool applies: tracking numbers, references, or barcodes, with permission-dependent detail levels. It does not explicitly state when to use this versus cxt_search_shipments or name any exclusions, so it is not a 5.

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

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

The description adds meaningful context beyond the annotations: it states the required ITINERARY_PLANNING_ACCESS permission and names the underlying POST endpoint, and clarifies that it checks vehicle, HR, and capability violations. It reinforces the read-only profile with 'Changes nothing', but does not describe the response shape or error behavior.

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

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

The definition is compact and front-loaded: the core action and scope come first, followed by the permission and endpoint details. Every fragment adds useful information with no wasted prose.

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

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

For a simple two-parameter validation tool with no output schema, the description provides the key context an agent needs: what is checked, that no changes occur, the required permission, and the endpoint. It could go slightly further by indicating what the returned validation result looks like, but the violation categories give a useful indication.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both driver_id and order_ids are already documented in the schema. The description adds the conceptual framing ('one driver', 'specific orders', violations to check) but no format, limits, or syntax details beyond what the schema provides; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource combination: checking one driver against specific orders, and enumerates the violation categories (vehicle, HR, capability). It distinguishes itself from the plural sibling implicitly through 'one driver', but does not explicitly name or contrast with cxt_validate_drivers.

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

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

The phrase 'Check one driver against specific orders' implies when to use it, but there is no explicit guidance on when to prefer it over cxt_validate_drivers or other validation/planning siblings, nor any exclusions or prerequisites beyond the auth requirement.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so 'Changes nothing' is reinforcement rather than new information. The description does add real behavioral context beyond the annotations: the required access scope and the underlying POST endpoint, plus the shape of the violation payload.

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

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

Front-loads the purpose, then the return content, then the side-effect guarantee, permission requirement, and endpoint in three compact fragments. Nothing is padded and no sentence is redundant with the tool name.

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

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

There is no output schema, and the description compensates by describing the returned violation kinds and the isBypassable flag. Combined with permission scope and the no-side-effects guarantee, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is a single required array parameter, so the schema already carries the semantics. The description's 'for each driver id' confirms batch semantics but adds no format, bound, or ordering detail beyond what maxItems/minItems already state.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb ('Check whether drivers are available to be planned') and resource (drivers), and states concretely what comes back (vehicle violations, HR violations, isBypassable). It does not differentiate itself from the very similarly named sibling cxt_validate_driver_for_orders, which is the only thing keeping it from a 5.

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

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

The phrase 'available to be planned' implies the pre-planning context, and the required ITINERARY_PLANNING_ACCESS scope is stated, but there is no explicit when-to-use/when-not guidance and no mention of when to prefer the singleton cxt_validate_driver_for_orders or how this relates to cxt_plan_orders.

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