Read delivery orders, quotes, customers, drivers, manifests, invoices and payment records.
Scored across 17 tools
Tools mostly target distinct resources and actions, and descriptions explicitly state the required lookup key (phone vs customer code vs internal id), which keeps the three customer-lookup tools separable. Minor overlap remains between ecourier_get_manifest and ecourier_list_driver_manifests, and between ecourier_get_driver and ecourier_list_drivers, but descriptions provide enough signal to choose correctly.
Every tool uses the same ecourier_ prefix followed by a verb_noun snake_case pattern (get_, list_, find_, quote_). The few compound names like list_customer_ship_tos and get_driver_orders remain readable and follow the same convention.
17 tools is slightly heavy but justified by the breadth of the domain (customers, drivers, orders, manifests, invoices, payments, fees, skills, quoting). Each tool maps to a concrete resource or sub-resource rather than being filler.
The surface is almost entirely read-only: there is no way to create or update an order, assign a driver, cancel a delivery, or apply a payment, so an agent can inspect and quote but cannot execute the core courier workflow. Read coverage across resources is broad, but the missing write/lifecycle operations are a significant gap for this domain.
Look up a customer by phone number (useful when a caller rings in): id, name and address. GetCustomerInfoFromPhoneNumber.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number, digits (e.g. 7132223333). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value by naming the returned fields (id, name, address), which matters because there is no output schema. It does not say what happens on no-match or multiple-match, which is the main behavioral unknown for a phone lookup.
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?
Core purpose and return fields are front-loaded in one short sentence. The trailing 'GetCustomerInfoFromPhoneNumber' is an internal method name that adds no information for an agent and is mild noise.
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 lookup with no output schema, listing the returned fields covers the essential gap. Still missing is the not-found / ambiguous-match behavior an agent needs in order to interpret an empty or multi-result response.
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 single 'phone' parameter already documents format and length constraints (digits, e.g. 7132223333). The description adds no normalization or formatting guidance beyond the schema, so 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?
A specific verb ('look up') plus resource ('a customer by phone number'), and it lists the returned fields (id, name, address). It implicitly distinguishes itself from ecourier_get_customer and ecourier_get_customer_by_code by keying on phone, though it never names those siblings 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?
'useful when a caller rings in' gives one concrete scenario, which is more than nothing. But it never states when to prefer this over ecourier_get_customer or ecourier_get_customer_by_code, nor what to do when the caller has no phone or the number is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full customer record by internal customer id: contact, address, credit status and limit, balance, billing settings. Card numbers and passwords are never returned. GetCustomerById.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes | Internal customer id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds genuinely useful context beyond them: sensitive fields (card numbers, passwords) are never returned, which affects how the agent should treat and trust the payload. It stops short of stating not-found 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 sentences, front-loaded with the resource and its field contents. The trailing 'GetCustomerById' is a redundant restatement that adds no information, but the rest is tight with no other waste.
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 compensates by enumerating what the record contains (contact, address, credit status and limit, balance, billing settings) and what is excluded. For a one-parameter read tool it is nearly complete; only error/not-found behavior is unaddressed.
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 parameter is documented as 'Internal customer id.' The description repeats essentially the same framing, adding no format, range, or lookup-origin detail beyond the schema, so 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 ('The full customer record by internal customer id') and even enumerates the returned fields, so an agent knows exactly what it gets. The 'internal customer id' qualifier implicitly separates it from the phone/code lookup siblings, though it never names them.
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: the 'internal customer id' phrasing hints that this is the id-based path rather than the code- or phone-based lookups in the sibling set. There is no explicit when-to-use, no exclusion, and no mention of prerequisites such as needing a known internal id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A customer (billing account) by its e-Courier customer code: id, name and address. GetCustomerByCode.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_code | Yes | e-Courier customer code. |
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 return-field information (id, name, address) but provides no additional behavioral context such as authorization needs, not-found behavior, or rate limits.
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 very short and front-loaded with the resource and return fields. The trailing 'GetCustomerByCode' is mildly redundant, but overall it 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?
This is a simple one-parameter read tool with annotations and full schema coverage. Although there is no output schema, the description lists the main returned fields, making it largely complete for an agent to invoke 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?
There is one parameter and schema description coverage is 100%, so the schema already fully documents customer_code. The description restates the same lookup-key concept without adding format, validation, or lookup semantics 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?
The description clearly identifies the resource (customer/billing account) and the lookup key (e-Courier customer code), and lists returned fields. It implicitly distinguishes itself from the phone-based sibling, but does not explicitly differentiate from ecourier_get_customer.
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 by 'by its e-Courier customer code', which naturally contrasts with ecourier_find_customer_by_phone, but the description gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Driver records with their vehicles and file names (never SSN or tax ids). With driver_id or driver_code one driver; with neither, every active and inactive driver. GetDriver.
| Name | Required | Description | Default |
|---|---|---|---|
| driver_id | No | Internal driver id. | |
| driver_code | No | Driver code. |
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: it excludes sensitive fields (never SSN or tax ids) and notes that inactive drivers are included when unfiltered.
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 short and front-loads return contents before the selection rule. The trailing 'GetDriver.' is redundant but causes minimal waste.
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, read-only lookup with full schema coverage, it gives return contents, privacy behavior, and filtering scope. Minor gaps remain around both-identifier precedence and large unpaginated result behavior, but the description is substantially 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?
Schema coverage is 100%, but the description adds conditional selection semantics beyond field documentation: either identifier returns one driver, while neither returns all active and inactive drivers. It does not clarify precedence if both identifiers are supplied.
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?
It names the resource and return contents (driver records, vehicles, file names) and states conditional scope: one driver vs. every active and inactive driver. It does not explicitly contrast with sibling ecourier_list_drivers, 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?
It explicitly says to supply driver_id or driver_code for one driver, and neither for all active/inactive drivers. It lacks explicit when-not guidance or an alternative sibling recommendation such as ecourier_list_drivers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a driver is carrying right now: the open orders on the driver's manifest (customer, pickup and delivery names, delivery zip, ready and due times), found by driver code or by the driver's phone number. Give exactly one. GetDriverInfoFromDriverCode / GetDriverInfoFromDriverPhone.
| Name | Required | Description | Default |
|---|---|---|---|
| driver_code | No | Driver code. | |
| driver_phone | No | The driver's phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine context beyond that: the result is a live snapshot of open orders only (not history), and it is scoped to the driver's manifest. It says nothing about result size or how a driver is resolved when both keys are absent, but for a read-only lookup 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?
The scope statement and field list are front-loaded in a single dense sentence, followed by the exactly-one constraint—efficient and well ordered. The trailing "GetDriverInfoFromDriverCode / GetDriverInfoFromDriverPhone" reads as leaked internal method names, adding tokens without adding actionable meaning for an agent.
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 description carries the return-value burden, and it does describe the shape of a result row. Given only two flat string parameters and read-only annotations, that covers nearly everything needed; minor gaps are how errors surface when the driver is unknown and whether multiple manifests could contribute orders.
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 fields are self-describing, so the baseline would be 3. The description earns an extra point by imposing a constraint the schema does not encode—required is empty and there is no oneOf/anyOf, yet the description mandates exactly one of driver_code or driver_phone, which prevents an ambiguous or empty lookup.
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 concrete verb and resource—the open orders currently on a driver's manifest—and enumerates the returned fields (customer, pickup/delivery names, delivery zip, ready and due times). That framing cleanly separates it from siblings like ecourier_get_manifest and ecourier_list_driver_manifests, which deal with the manifest itself rather than the driver's live order load.
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?
"Give exactly one" tells the agent how to select between the two lookup keys, which is real usage guidance. However, it never states when to prefer this tool over ecourier_get_manifest, ecourier_list_driver_manifests, or ecourier_get_driver, so the agent must infer the boundary from the purpose sentence alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The skills assigned to one driver, by driver id or driver code (give exactly one). GetDriverSkills.
| Name | Required | Description | Default |
|---|---|---|---|
| driver_id | No | Internal driver id. | |
| driver_code | No | Driver code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no note on what happens for an unknown driver, whether an empty list is returned, or any rate/auth context. The one useful clause, 'exactly one', is a parameter constraint rather than behavioral disclosure.
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 with the scope stated first. The trailing 'GetDriverSkills.' merely restates the operation and title, adding no information.
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 read-only lookup with full schema coverage and annotations covering safety, the description supplies enough to call it correctly. Return shape need not be explained since there is no output schema, though a note on empty results would help.
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. The description's '(give exactly one)' is a genuine addition because the schema has no oneOf/required constraint enforcing mutual exclusivity, but it is the only semantic extra and it doesn't clarify the id-vs-code tradeoff.
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 ('skills assigned to one driver') and narrows the scope to a single driver, which separates it from the sibling ecourier_list_skills. It does not name that sibling explicitly, so a reader must infer the boundary.
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 parenthetical '(give exactly one)' gives a usable calling constraint, but there is no statement of when to prefer this over ecourier_list_skills or ecourier_get_driver, and no mention of prerequisites or error cases (e.g. unknown driver id).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The fee lines of one invoice, by invoice id (the id from ecourier_list_invoices). GetInvoiceFees.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes | Invoice id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds only that the result is fee lines scoped to one invoice; it says nothing about empty results, missing-invoice errors, or pagination, which would be the value-add for a remote 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?
One compact sentence that front-loads the resource and scope. The trailing 'GetInvoiceFees.' merely restates the operation name and earns nothing, a minor redundancy in an otherwise tight definition.
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 lookup this is close to sufficient, and annotations cover the safety profile. But with no output schema, the description leaves the shape of a 'fee line' entirely unexplained, and it omits any note on behavior for an invalid or nonexistent invoice id.
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 a single parameter at 100% schema coverage the baseline is 3, but the description goes further by telling the agent where the invoice_id originates (ecourier_list_invoices), which is genuine semantic guidance not present in the schema's bare 'Invoice id.'
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 resource and scope: the fee lines of a single invoice, retrieved by invoice id. This distinguishes it from the nearby ecourier_get_order_fees (order vs. invoice) implicitly through the resource noun, though it never names 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?
The parenthetical '(the id from ecourier_list_invoices)' gives a useful workflow pointer for obtaining the required id, which is real guidance. However, there is no statement of when to use this versus ecourier_get_order_fees or ecourier_list_payments, and no exclusions or prerequisites beyond the id source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One driver manifest (the route a driver runs for a day) with all its job stops: sequence, addresses, status, pieces and weight. GetManifest.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_driver_id | Yes | The ManifestDriverID of the manifest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful return-content context: it specifies that the response includes job stops with sequence, addresses, status, pieces, and weight. It does not describe error behavior or authentication requirements, but it adds meaningful behavioral detail beyond 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?
The description is compact and front-loads the key resource and return contents. The trailing 'GetManifest' is redundant with the tool name and title, but it does not meaningfully impede clarity.
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 a single required parameter, full schema coverage, and read-only annotations, the description is complete enough to call the tool correctly. It also compensates for the absence of an output schema by summarizing the returned manifest contents, though it lacks detail on error cases or pagination behavior.
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?
There is one parameter with 100% schema description coverage, so the schema already documents manifest_driver_id as the ManifestDriverID. The description does not add any meaning or format detail beyond the schema, which matches the baseline for high schema coverage.
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 clearly identifies the resource as one driver manifest and enumerates its job stops and fields, which distinguishes it from ecourier_list_driver_manifests. The retrieval verb is implicit rather than explicit, so it is clear but not maximal.
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 singular 'One driver manifest' implies this tool is for fetching a specific manifest rather than listing them, but there is no explicit when-to-use guidance, prerequisites, or named alternative. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One delivery order with everything e-Courier holds: status (N new, A assigned, X deleted), customer, stops and their pickup/delivery times and POD names, pieces, jobs and drivers, fees, events and notifications. Give exactly one of order_number, order_id, auth (the customer's authorization code) or reference (a piece reference; add customer_code to narrow it). Signature images are not returned. GetJsonOrder.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | No | The order's Auth (authorization) value. | |
| order_id | No | Internal order id. | |
| reference | No | A piece reference / barcode on the order. | |
| order_number | No | The order number shown in e-Courier. | |
| customer_code | No | Customer code; useful together with reference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the description earns credit for adding real behavior: the meaning of the N/A/X status codes and the explicit exclusion 'Signature images are not returned.' It stops short of saying what happens on zero or multiple matches, which matters given no required parameters.
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 sentences, front-loaded with what is returned and then how to address it, with no filler. The field enumeration is long but each item is a distinct return-value category the agent cannot get from an output schema, so it earns its space.
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 thoroughly, including the signature-image exclusion. The remaining gap is error/disambiguation behavior (no-match, multiple-match, or what happens if zero selectors are supplied despite the 'exactly one' instruction).
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 a constraint the schema does not encode: exactly one of order_number, order_id, auth or reference (the schema marks nothing required and declares no oneOf). It also explains that customer_code is used to narrow a reference lookup, which is more than the schema's 'useful together with reference.'
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?
Specific verb+resource ('One delivery order') followed by an explicit enumeration of the payload: status codes with meanings, customer, stops with pickup/delivery times and POD names, pieces, jobs, drivers, fees, events and notifications. The payload listing implicitly separates it from narrow siblings like ecourier_get_order_fees, which only returns a subset.
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 by the 'give exactly one of...' selector clause, which tells the agent how to call it but not when to prefer it over ecourier_get_order_fees or ecourier_get_manifest. No when-not-to-use or explicit alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The fee lines (what was charged for the delivery: base rate, fuel, waiting time and so on) of one order, by internal order id. GetOrderFees.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | Internal order id (the OrderID from ecourier_get_order). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful content-level context by enumerating typical fee components (base rate, fuel, waiting time), which helps interpret the payload in the absence of an output schema, but says nothing about completeness, pagination, or whether zero-fee orders return an empty list.
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?
One compact, front-loaded sentence that leads with the returned resource and ends with the lookup key. The trailing 'GetOrderFees.' duplicates the name and title and earns no space.
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 single-parameter read tool with rich annotations and no output schema, the description says enough to call it correctly and to know what comes back. Only the sibling distinction against ecourier_get_invoice_fees is left unaddressed.
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 parameter is fully documented, including its provenance from ecourier_get_order. The description's 'by internal order id' merely restates the schema, so 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?
Names the specific resource (fee lines of one order) and its scope (a single order, addressed by internal order id), with concrete examples of what a fee line contains. It is clear on its own, but it never acknowledges the closest sibling, ecourier_get_invoice_fees, so an agent must infer the difference between order-level and invoice-level fees.
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 what is retrieved but gives no explicit when-to-use condition, no exclusion, and no named alternative among the many fee/order siblings. The only routing hint, that the id comes from ecourier_get_order, lives in the schema's parameter description rather than in the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The saved ship-to (stop) addresses of a customer, by internal customer id, or one ship-to by its id. Give exactly one. GetCustomerShipTo.
| Name | Required | Description | Default |
|---|---|---|---|
| ship_to_id | No | One ship-to address id. | |
| customer_id | No | Internal customer id: all its saved addresses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the mode-mutual-exclusivity constraint, but says nothing about return shape (list vs. single object), pagination, or behavior when an id is not found — gaps that matter for a lookup tool.
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 sentences, with the resource scope front-loaded before the constraint. The trailing 'GetCustomerShipTo' token is unexplained and slightly wasteful, keeping it from a 5.
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 two-parameter, read-only lookup with no output schema and full schema coverage, the description covers the resource, both modes, and their mutual exclusivity. Only the return shape and not-found behavior are left implicit, which is a minor gap at this complexity.
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, which sets a baseline of 3. The description earns an extra point by supplying the 'exactly one' constraint that the schema alone does not express (required is empty), preventing an agent from passing both or none.
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 the resource (saved ship-to/stop addresses of a customer) and the two retrieval modes (all by customer id, or one by ship-to id), which distinguishes it from siblings like ecourier_get_customer. It reads as a noun phrase rather than a verb, relying on the name/title for the 'list' action, so it falls just short of the top score.
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?
'Give exactly one' is an explicit invocation constraint that tells the agent to choose between the two modes rather than combining them. There are no named alternatives or when-not conditions, but the mode-selection guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The manifests of one driver between two dates, with their job stops. Default status filter is active (A). GetManifestsByDriver.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | No | Only this site. | |
| end_date | Yes | Last day, yyyy-mm-dd. | |
| driver_id | Yes | Internal driver id. | |
| start_date | Yes | First day, yyyy-mm-dd. | |
| manifest_status | No | Manifest status code filter (default A). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm this is a non-destructive, read-only operation, so the description carries less burden. It adds useful behavioral context by noting the default active status filter and that job stops are included, but it does not describe pagination, response size, or other operational 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 description is short and front-loads the core scope before mentioning the default filter. The trailing internal method name 'GetManifestsByDriver' is minor noise but not enough to undermine the efficient structure.
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 five-parameter listing tool with no output schema and no annotations beyond safety hints, the description is only minimally complete. It states that job stops are included but does not explain the response shape, pagination, or how site_id affects results.
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 all five parameters, including formats and the default status filter. The description reinforces the date range and driver scoping but adds no syntax or semantic detail beyond the schema, making the baseline 3 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 clearly identifies the resource (manifests), the scope (one driver between two dates), and the included data (job stops). It is specific enough to distinguish it from singular manifest retrieval, but it does not explicitly name or contrast a sibling tool such as get_manifest.
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 provides no explicit when-to-use guidance, prerequisites, or alternatives. It states the default status filter but does not say when an agent should choose this tool over get_manifest, get_driver_orders, or list_drivers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every active driver: id, code, name and site. Optionally only one site (multi-site accounts). GetDrivers.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | No | Only drivers of this site id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, non-destructive, open-world operation. The description adds that only active drivers are returned and enumerates the returned fields, but it does not discuss pagination, result limits, authentication requirements, or ordering.
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 short and front-loads the key information: active drivers, returned fields, and the optional site filter. The trailing 'GetDrivers.' adds little and reads like an API operation name, but the overall text 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?
For a simple read-only list tool with one optional parameter and no output schema, the description is largely complete: it states what is returned and how filtering works. It could be improved with brief notes on ordering, pagination, or typical result size.
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 site_id parameter is already fully documented in the schema. The description adds minor context by noting its optional nature and relevance to multi-site accounts, but largely restates 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?
The description clearly identifies the resource and scope: every active driver, including id, code, name, and site. It is distinguishable from singular sibling tools like ecourier_get_driver by its all-drivers scope, though it does not explicitly name alternatives.
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 optional site filter is explained as being for multi-site accounts, which gives useful context for that parameter. However, there is no explicit guidance on when to use this list tool versus ecourier_get_driver or other driver-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoices in an invoice date range (invoice_start_date and invoice_end_date are both required, at most 31 days apart: e-Courier rejects anything else). Optionally narrow by customer code and by a last-changed range. GetInvoice.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_code | No | Only this customer. | |
| changed_end_date | No | Last changed to, yyyy-mm-dd. | |
| invoice_end_date | Yes | Invoice date to, yyyy-mm-dd. Required, at most 31 days after the start. | |
| changed_start_date | No | Last changed from, yyyy-mm-dd. | |
| invoice_start_date | Yes | Invoice date from, yyyy-mm-dd. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context — the upstream API rejects ranges wider than 31 days — but says nothing about result volume, pagination, or whether the last-changed range interacts with the invoice range.
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?
Roughly two sentences, front-loaded with the resource and the hard constraint before the optional filters. The dangling 'GetInvoice.' fragment at the end is noise that earns no place.
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?
Read-only list tool with annotations covering safety and a fully documented schema, so the description only needs to frame the query. It does that, though with no output schema an agent still cannot predict result shape or volume — a minor but real gap for a list endpoint.
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 schema already documents each field's format and the 31-day rule, so the baseline is 3. The description restates the date constraints from the schema rather than adding new meaning, and the trailing 'GetInvoice.' token contributes no semantic 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 resource (invoices) and scope (invoice date range) with the two required parameters named, so the agent knows exactly what it retrieves. It lacks explicit sibling differentiation — nothing distinguishes it from ecourier_get_invoice_fees or ecourier_list_payments — but the resource 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?
Gives a hard operational constraint ('at most 31 days apart: e-Courier rejects anything else') and lists optional narrowing filters, which implies when the tool applies. It never states when to prefer this over related list/lookup siblings, so routing 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.
Customer payments received in a payment date range (payment_start_date and payment_end_date are both required, at most 10 days apart: e-Courier rejects anything else). Optionally narrow by customer code, check number or payment id. GetPayment.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | No | One payment id. | |
| check_number | No | Check number. | |
| customer_code | No | Only this customer. | |
| payment_end_date | Yes | Payment date to, yyyy-mm-dd. Required, at most 10 days after the start. | |
| payment_start_date | Yes | Payment date from, yyyy-mm-dd. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. Beyond that, the description discloses a hard server-side failure mode ('e-Courier rejects anything else' for >10-day ranges) that an agent must respect to avoid errors. It says nothing about result volume, pagination or truncation limits, which is the remaining gap.
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-load the required date-range constraint before the optional filters, which is the right ordering. The dangling 'GetPayment.' fragment is unexplained and earns little place, but overall there is minimal waste.
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 filter/list tool with full schema coverage and no output schema, an agent has everything needed: required params, the enforced 10-day ceiling, and optional narrowing fields. Return-value description is not required here, so 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%, so the schema already documents every parameter including the 10-day end-date rule; the description mainly restates which params are required and which are optional narrowing filters. It does not clarify the non-obvious interaction that payment_id still requires a date range, nor what the trailing 'GetPayment' label signifies. 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: customer payments received within a payment date range, plus the three optional narrowing filters. It does not name any sibling (e.g. ecourier_list_invoices) to disambiguate, so the agent still has to infer the boundary between payments and invoices, but the resource itself 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?
Gives explicit preconditions for use: both date bounds are required and the window must be at most 10 days, and it explains what the optional filters do. It stops short of naming alternatives or when-not-to-use cases (e.g. when to prefer ecourier_list_invoices), so it is clear context without routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The master list of active driver skills (for example HAZMAT) with ids. GetSkills.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds one genuinely useful behavioral detail: only 'active' skills are returned, and ids are included. The trailing 'GetSkills.' fragment adds nothing.
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 core sentence is front-loaded and efficient, but the dangling 'GetSkills.' is a meaningless restatement of the name that adds noise without information. Removing it would make this a clean two-clause description.
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, zero-parameter, read-only list tool with full annotation coverage, the description supplies what an agent needs: what is returned (skill names plus ids) and the 'active' filter. Lack of an output schema is mitigated by naming the fields returned.
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; baseline 4 applies. The description correctly implies a no-argument enumeration.
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 resource and scope: 'the master list of active driver skills ... with ids', plus a concrete example (HAZMAT). This distinguishes it in spirit from the per-driver sibling ecourier_get_driver_skills, though it never names 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?
The word 'master' implies an unfiltered enumeration, which implicitly contrasts with ecourier_get_driver_skills, but the description never states when to use this tool versus that one. Usage must be inferred from the word 'master' alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price and availability for a delivery WITHOUT creating it: e-Courier applies the customer's rates to the stops and pieces and returns the order with the quoted amount. Supply a customer code, pickup/delivery stops and optional pieces. Nothing is saved and nobody is notified. QuoteOrder.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | No | Customer authorization / reference code, if the account uses one. | |
| stops | Yes | At least one pickup (P) and one delivery (D) stop, in route order. | |
| caller | No | Name of the person who placed the order. | |
| pieces | No | The items being moved. Each is linked to the pickup stop and the delivery stop. | |
| service | No | Service name configured in e-Courier, e.g. Route or Scheduled. | |
| description | No | Order description. | |
| caller_phone | No | Phone of the person who placed the order. | |
| customer_code | Yes | e-Courier customer (billing account) code the order is for, as in e-Courier. | |
| other_reference | No | Your own reference for the order (PO number etc.). |
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 with concrete consequences beyond the annotations: 'Nothing is saved and nobody is notified'. It also explains the pricing mechanism (customer rates applied to stops and pieces) and that the order is returned with the quoted amount. It does not say what happens when no rate is available or how failures surface, so it stops short of 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?
The core distinction ('WITHOUT creating it') is front-loaded in the first clause, and the remaining sentences each add a distinct fact: the pricing mechanism, the required inputs, and the absence of side effects. Nothing is redundant; the trailing 'QuoteOrder.' is the only non-essential token.
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 9 parameters, full schema coverage, rich annotations and no output schema, the description covers purpose, required inputs, and side effects adequately. It lacks detail on quote validity, failure modes when no rate exists, or how the returned quoted amount is structured, which would matter for correctly consuming the result.
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 every property, including nested stop and piece fields, is documented in the schema. The description only restates the essentials ('a customer code, pickup/delivery stops and optional pieces') and omits parameters that materially affect a quote, notably 'service', 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?
The description opens with a specific verb+resource+scope: 'Price and availability for a delivery WITHOUT creating it'. This immediately separates it from every sibling, which are all get_/list_ retrieval tools, and makes clear it is a dry-run pricing call rather than a booking call.
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 context is explicit — use this when you want a quote and do not want an order created. It gives no explicit 'use X instead' routing (no create/book sibling is present in the list to point at), so it falls short of a full 5, but the when-to-use condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ecourier_find_customer_by_phoneecourier_get_customerecourier_get_customer_by_codeecourier_get_driverecourier_get_driver_ordersecourier_get_driver_skillsecourier_get_invoice_feesecourier_get_manifestecourier_get_orderecourier_get_order_feesecourier_list_customer_ship_tosecourier_list_driver_manifestsecourier_list_driversecourier_list_invoicesecourier_list_paymentsecourier_list_skillsecourier_quote_orderRead rental jobs, projects, late returns, contacts, inventory catalogs, depots and notes.
Read Track-POD orders, routes, drivers, vehicles and proof of delivery; create orders.
Read Shipday orders, carriers and delivery status; create orders and assign drivers.
Read-only access to your Drivara fleet — jobs, drivers, vehicles, fuel, profit & analytics.
Add one secure layer between your agents and this server.
