Track-POD MCP by usefulapi

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

Annotations already declare non-read-only, destructive, non-idempotent, open-world behaviour, so the description only needs to add side-effect detail. It does: the customer may later receive SMS/e-mail updates depending on account notification settings, and the server geocodes the address unless address_lat/address_lon are supplied. It does not address duplication/idempotency of the same order number, which is the one meaningful remaining unknown.

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?

Four sentences, purpose and scope front-loaded before side effects and the confirmation instruction. Each sentence carries distinct information, though the closing restatement of address/client being required duplicates the schema's required array.

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 25-parameter mutation tool with rich annotations, the description covers scope, side effects, and the confirmation workflow well. Because there is no output schema, it could usefully say what comes back (e.g. an order id) and whether resubmitting the same order number creates a duplicate, but the critical calling information is present.

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 baseline is 3; every one of the 25 fields, including the goods line object, is already documented in the schema. The description adds only two things beyond it: which fields are required (already in the schema's required list) and the geocode-skip behaviour of address_lat/address_lon (already stated on those properties). Marginal added value.

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 ('Create ONE REAL unscheduled order in Track-POD') with the backing endpoint (POST /Order), and explicitly delimits scope by saying it does not create or optimise routes. An agent can distinguish this from route tools and all read-only siblings 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?

Gives an actionable precondition ('Confirm the details with the user first') and situational framing ('ready to be planned into a route by a dispatcher'). No alternative tool is named, but there is no sibling create tool to route against, so the omission is minor.

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, idempotentHint, openWorldHint and non-destructive, so safety is covered; the description usefully adds the behavioral cap of 25 results, which neither annotations nor schema disclose. It stops short of saying what happens when more than 25 matches exist (pagination/truncation), so it is strong but not complete.

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 compact sentences, front-loaded with the core behavior and the result cap, followed by the disambiguating trigger. 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?

For a low-complexity, one-required-param read tool with full schema coverage and no output schema, the description supplies purpose, trigger, result cap and the sibling alternative. The only real gap is behavior when matches exceed 25, which is minor.

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% and the 'detail' enum is fully described in the schema itself, so the baseline of 3 applies. The description adds no parameter-level detail beyond what the schema already provides (e.g. it never mentions the summary/full toggle).

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 (list), resource (orders sharing one order number), scope (last 25, re-deliveries/repeated jobs), and even the underlying endpoint. It explicitly distinguishes itself from trackpod_get_order, so an agent can pick correctly without opening either 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?

Gives an explicit trigger ('when an order number was reused') and names the alternative (trackpod_get_order) plus the condition that signals the switch ('returns only one of them'). Nothing is left 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description's added context is limited to the underlying REST endpoints and the single-key rule; it says nothing about error behavior for a missing or unknown driver.

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 sentence that front-loads the action, the identifier options, and the constraint in that order. Nothing is wasted; the parenthetical endpoint detail is compact and tied to the two lookup modes.

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, so the description is not obliged to explain the return payload, and annotations carry the safety profile. The only gap is that it never states what a caller should do when neither identifier is known or what a failed lookup returns.

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% and both parameters are documented there, but the schema marks neither as required, so the description's 'Pass exactly one' supplies the mutual-exclusivity rule the schema does not express. That is genuine added meaning beyond the structured fields.

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 ('Get one driver') and the exact resource, plus both lookup keys (Track-POD UUID and username). This distinguishes it from the sibling trackpod_list_drivers without needing to name it, since 'one driver' versus a list is unambiguous.

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?

'Pass exactly one' gives an explicit operating rule for selecting a lookup mode, which is real usage guidance. It stops short of saying when to prefer this tool over trackpod_list_drivers or what to do when the identifier is unknown, but the context is 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 cover the safety profile (readOnly, idempotent, non-destructive), so the description is not obligated to restate it. It adds genuine behavioral context beyond the schema: the one-of-three identifier constraint and the HTTP 410 response for a removed order, which also discloses who removed it. It stops short of describing pagination or auth requirements, which is acceptable for a single-record read.

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 dense sentences, front-loaded with the return payload and followed by the invocation rule and the error case. The field enumeration is long but earns its place by substituting for the absent output schema.

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 carries the return-value burden and does so by listing the returned fields, plus it documents the identifier constraint and the 410 removed-order case. Nothing essential for correct invocation 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 coverage is 100% and each parameter is well documented, so baseline would be 3. The description adds real value the schema cannot express: the mutual exclusivity of number/order_id/track_id (no oneOf/anyOf is present in the schema) and the underlying endpoint mapping (Order/Number|Id|TrackId).

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 ('Get one order') and immediately distinguishes it from the list/find siblings by enumerating the full single-order payload (client, address, goods lines, route, driver, status, ETA, signature links). An agent can tell this is the full-detail single-record fetch rather than a search.

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 a concrete invocation rule ('pass exactly one of number, order_id or track_id') but never says when to choose this tool over trackpod_find_orders_by_number or trackpod_list_orders, nor what to do if the identifier is unknown. Usage is implied by the identifier vocabulary rather than stated.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, and the description still adds non-obvious behavioral facts the annotations cannot: signature/photo links expire in 24 h and the PDF delivery note (ReportUrl) in 1 h. It does not mention permissions or rate limits, keeping it short of 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-loaded with the tool's purpose, then a dense but purposeful enumeration of the returned fields, closing with the invocation constraint. Single-sentence density is high but every clause carries information; nothing reads as 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 no output schema, the description must describe the return payload, and it does so comprehensively — status plus status time/GPS, signatory, signature and photo links with TTLs, driver comment, reject reasons, quantity comparison, cash, feedback, and the delivery-note link. Nothing an agent needs to call or interpret this result 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%, so the baseline is 3, but the description adds a real semantic constraint the schema does not express: the three identity parameters are mutually exclusive and exactly one must be supplied. It adds no format detail for individual fields, which is fine since the schema handles that.

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 and resource ('Get the electronic proof of delivery (ePOD) of one order') and immediately distinguishes itself from trackpod_get_order by enumerating the artifact it returns: signatures, photos, delivered vs ordered quantities, cash collected. An agent can tell what this tool produces 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?

The description states the scope ('of one order') and gives a genuine invocation rule — 'Pass exactly one of number, order_id or track_id' — but never names an alternative tool or explains when an agent should choose this over trackpod_get_order or trackpod_find_orders_by_number. Usage is implied rather than routed.

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, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds the mutual-exclusion rule for the two identifiers, but says nothing about freshness of GPS, auth scope, 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?

Two tightly packed sentences, front-loaded with the payload summary followed by the identifier rule. The parenthetical pseudo-path (GET /Route/Code|Id/{…}) is slightly cryptic but not wasteful.

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, yet the description enumerates what will be returned, which is the main completeness requirement. It omits guidance on identifier choice and result freshness, minor gaps for a read-only fetch.

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 schema itself documents route_id, route_code and include_orders with enum meanings. The description restates the exactly-one-of constraint, adding a small amount of value but no detail the schema lacks.

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 ('Get one route') and enumerates the returned payload (status, driver, vehicle, timings, distance, cost, GPS, orders), clearly distinguishing it from list_routes and get_route_track.

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 the key usage constraint (exactly one of route_code or route_id) but never explains when to choose route_code vs route_id, nor when to prefer get_route_track or list_route_orders 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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds material behavior beyond that: results are paged with offset/limit and a hard cap of 1000 points per call, which is essential context for a read that may return large datasets.

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 compact sentences, zero filler: identity and payload first, then the parameter rule, then the paging constraint. Nothing is repeated from the schema or annotations, and the most important scoping information is 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?

With no output schema, the description usefully enumerates the returned point fields and units, and covers pagination, so an agent can call and consume it correctly. It omits ordering of points and total-count information, which would help an agent page reliably.

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 goes beyond the schema by stating the mutually-exclusive usage of route_code and route_id — a constraint the schema itself does not express (no oneOf/anyOf) — plus the units and paging cap in prose.

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 ("Get the driver's recorded GPS track of a route") and enumerates the payload fields (latitude, longitude, speed in m/s, time). It also names the underlying endpoint, making it clearly distinguishable from the sibling trackpod_get_route, which returns route metadata rather than GPS points.

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 selection rule for the two identifiers: "Pass exactly one of route_code or route_id," which removes ambiguity in invocation. It does not, however, say when to prefer this tool over siblings such as trackpod_get_route or trackpod_list_route_orders, so the guidance is clear but not exhaustive.

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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only the underlying endpoint (GET /Vehicle/{id}) and the id provenance, but says nothing about not-found behavior, permissions, or rate limits that would go beyond the structured data.

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 sentence that front-loads the action and resource, then supplies the identifier source and the endpoint. Nothing is redundant and nothing needed for invocation is buried.

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 getter whose annotations cover the safety profile and whose schema documents the lone parameter, the definition is nearly sufficient. The only gap is that, with no output schema, it never hints at what a vehicle record contains, though the return shape is largely implied by the tool name.

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 genuinely new information beyond the schema: that the id is an integer sourced from trackpod_list_vehicles, which tells the agent how to obtain a valid value. It does not add constraints such as valid ranges, though the schema already encodes those.

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 ('Get one vehicle') and scopes it to a single record by Track-POD id, which cleanly distinguishes it from the sibling trackpod_list_vehicles. The HTTP endpoint mapping is an extra anchor that leaves no ambiguity about what the tool retrieves.

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 tells the agent the precondition for use by pointing to trackpod_list_vehicles as the source of the id, which is exactly the routing information needed to pick this tool over the list tool. It does not state exclusions (e.g. what to do if the id is unknown), so it stops short of a full when/when-not statement.

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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds the pagination trait ('Paged here') and the returned field set, which is modest extra context but no detail on rate limits or paging mechanics.

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 compact sentences, front-loaded with the resource and its fields, with the endpoint and paging note trailing. No filler, though the field list reads slightly like boilerplate.

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, naming the returned fields (name, username, phone, vehicle, depot, zone, teams, active flag) usefully describes the result shape, and paging behavior is acknowledged. It is largely complete for a simple read-only list tool.

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 limit, offset, search and active_only are fully documented in the schema itself, including defaults and the next_offset pattern. The description adds nothing param-specific beyond the general 'paged' hint, 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 and resource ('List the account's drivers') and enumerates the fields returned plus the underlying endpoint (GET /Driver). This clearly separates it from the singular trackpod_get_driver, though it does not name that sibling explicitly.

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?

There is no statement of when to use this versus trackpod_get_driver or how it relates to other list endpoints. 'Paged here' hints at iteration but is not framed as guidance, so usage must be inferred.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavior: Track-POD returns the whole day in one payload while this tool pages it via offset/limit and reports a total, plus that times are the account's local times. Rate limits and partial-failure behavior remain unstated.

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 dense sentences, purpose front-loaded, then paging behavior and the timezone caveat. No filler, and the parenthetical endpoint paths give concrete grounding without bloating the text.

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 read-only listing tool with no output schema this covers the essentials: scope (one day), two endpoint modes, filter dimensions, paging mechanics and total reporting. The absence of any return-shape hint is the only real gap, and the schema's detail enum partly compensates.

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 100% schema description coverage the schema already documents all 8 parameters, so the baseline is 3. The description adds value beyond it by framing date semantics against the two endpoints and noting times are in the account's local timezone, which the schema never states.

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 ('List the orders of one day') and immediately scopes it to the two backing endpoints (by order date vs. planned route date). This distinguishes it cleanly from siblings like trackpod_list_orders_changed_since and trackpod_list_route_orders without needing to open 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?

The description makes the core selection context explicit: one specific day, with the order-date vs. route-date choice that drives date_type. It does not, however, name sibling alternatives (e.g. find_orders_by_number, list_route_orders) or state when this tool is the wrong choice, so routing is clear but not fully disambiguated.

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 readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context: the hard 'no earlier than UTC now − 1 day' API limit and the fact that results are paged here via offset/limit.

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 tight sentences: scope and time bound first, use case second, pagination note last. No filler, and the most important constraint (24-hour window) is 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?

With no output schema, the description still conveys the essential constraints (time window, paging, endpoint) and the detail parameter in the schema covers return richness. It stops short of describing the response shape or ordering of results, which is a minor gap for a list tool.

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 schema already documents limit, offset, since, detail and the status enum with defaults and ranges. The description only restates the paging mechanic and the 24-hour bound already given in the 'since' schema description, adding little beyond the structured fields.

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 (List) and resource (orders) plus the distinguishing scope: only orders whose delivery status changed within the last 24 hours. It even names the backing endpoint (GET /Order/Status/Date/{date-time}), so the agent can separate this from the broader trackpod_list_orders without opening either 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?

Gives a concrete use case ('what was delivered / failed since this morning'), which makes the intended scenario clear. It does not, however, explicitly say when NOT to use it or point to trackpod_list_orders for the unfiltered case, so the routing guidance is implied rather than stated.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds only that this is an account-scoped GET returning categorized reasons, with no detail on auth needs, caching, or result volume. No contradiction with annotations.

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 compact sentence that front-loads the verb and resource, then appends the category scope and endpoint. Nothing is redundant and no filler is present.

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 zero parameters, no nested objects, and no output schema, the description's remaining job is to say what the list contains, which it does by naming the four reason categories. It stops just short of describing the shape of each returned reason entry.

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 the description has no parameter semantics to explain and the baseline of 4 applies. It correctly conveys that the entire account's reason set is returned without filter arguments.

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 (List) and resource (reject reasons), then enumerates the scope of those reasons: site, order, goods and scanning issues. It also names the underlying endpoint (GET /RejectReason), making it trivially distinguishable from the order/driver/route/vehicle listing siblings.

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 purpose implies usage (look up the account's standardized reject reasons), but there is no explicit when-to-use guidance, no prerequisites, and no mention of alternative tools. Usage is inferable rather than stated.

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 the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description's main addition is the pagination model via offset/limit and the route-ordered output. It does not mention return payload shape, ordering guarantees beyond 'route order', or any rate/auth considerations, so it adds only modest context over the structured data.

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 tight sentences with the core purpose front-loaded and no filler. The trailing '(offset/limit)' and endpoint path are mildly redundant against the schema, which already documents both pagination parameters and their defaults, but the net length is well controlled.

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 read-only paged list tool with a fully documented five-parameter schema and annotations covering safety, the definition covers the essentials: scope, key parameter, and pagination. The absence of an output schema means a sentence on what 'route order' guarantees or what the response contains would help, but the schema's detail enum partially fills that gap.

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%, with every parameter (limit, offset, detail, status, route_code) fully documented, including defaults, bounds, enum meanings, and pagination continuation advice. The description's mention of 'by route code' and 'Paged here (offset/limit)' merely restates what the schema already carries, so 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?

The description gives a specific verb (list), a precise resource (orders on one route), and a scoping key (route code), plus the ordering semantic ('in route order') and the backing endpoint. This implicitly separates it from the broader trackpod_list_orders, but it never names that sibling, so an agent must infer the distinction from scope alone.

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?

Usage is only implied: it tells the agent this is for orders on one route addressed by route code, so an agent with a route_code in hand can infer it applies. There is no explicit when-to-use versus trackpod_list_orders or trackpod_find_orders_by_number, and no preconditions are stated.

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 readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds real context beyond that: the paged nature of the endpoint, the fixed status vocabulary, and the fact that 'full' order inclusion produces a large payload — useful operational signal not present in the annotations.

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 dense sentence that front-loads the verb, resource, and scope before listing fields and the paging note. No filler, though the field enumeration plus parenthetical endpoint makes it slightly heavy for one sentence.

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 helpfully enumerates returned fields (status, driver, vehicle, timings, distance, cost, GPS, order counts) and covers paging and filtering, so an agent can call it confidently. Minor gaps like auth expectations or default sort order keep it short of a 5.

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 schema already documents date, limit, offset, status, and include_orders fully. The description only echoes paging ('offset/limit'), adding essentially no semantics beyond the structured fields, which is the baseline 3 case.

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 ('List the routes of one day') plus the underlying endpoint, and enumerates the returned fields so an agent knows exactly what it gets. It is clearly distinguishable from get_route (single route), list_route_orders (orders of a route), and list_orders.

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?

Usage is implied — enumerate all routes for a given date, optionally filtered by status — and paging is mentioned, but there is no explicit when-to-use/when-not or routing to siblings such as get_route for a single route. Adequate but leaves the agent to infer alternatives.

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 readOnly/idempotent/non-destructive/openWorld, so the bar is lower. The description adds meaningful behavior beyond them: the photo links expire after 24 h and the exact content of a check record. It does not discuss pagination semantics, though limit/offset are documented in the schema.

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 what a check is, then enumerates the date/vehicle_number combinations compactly. The GET endpoint strings are somewhat redundant noise, but the rest is dense and waste-free.

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 usefully enumerates the returned fields and the parameter-driven behavior variants. It omits return shape details like pagination wrappers, but it is sufficient for an agent to call the tool 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 individual params are documented, but the description adds the critical cross-parameter semantics the schema cannot express: the same two parameters produce three distinct result sets depending on which are supplied. This genuinely extends meaning 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+resource: listing driver vehicle inspections with the field set returned (checklist items, pass/fail, notes, photo links, odometer, signature). It is clearly distinguishable from siblings like trackpod_get_vehicle, trackpod_list_vehicles, and the order/proof-of-delivery 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?

Clearly spells out the three invocation modes: date only → all checks that day; date + vehicle_number → that vehicle's checks for the day; vehicle_number only → that vehicle's last check. That is strong usage context, though there are no sibling alternatives named since no other vehicle-check listing tool exists.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that results are paged and what fields come back, which is useful context beyond the annotations, but it says nothing about rate limits, auth, or ordering guarantees.

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 front-loaded sentence that opens with the verb and resource before enumerating fields. Dense but every clause carries information; the parenthetical API path is the only arguably extraneous bit.

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, so the field enumeration in the description is doing real work by telling the agent what a vehicle record contains. Combined with the pagination hint and full param schema, the definition is complete enough to call correctly, missing only explicit sibling routing.

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%, with limit, offset and number fully documented in the schema itself, so the baseline is 3. The description's only parameter-related content is the 'optional plate-number filter', which restates the number param without adding syntax or format detail.

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 ('List the account's vehicles') and enumerates the fields returned (plate, driver, depot, capacity, costs, type, carrier), so an agent knows exactly what it gets back. It is clearly distinguishable from get_vehicle by the list-vs-single framing, but it never names the sibling to remove ambiguity.

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 'optional plate-number filter' implies you may narrow the list, and 'Paged here' implies pagination, but there is no explicit when-to-use guidance and no mention of when to prefer get_vehicle or another sibling. Usage is only implied.

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