Locate2u MCP by usefulapi

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

The description adds meaningful context beyond the annotations: it identifies the operation as a write, discloses the side effect that each call adds a new note, and warns against blind retries. It also names the underlying POST endpoint, though it does not explain permissions, failure behavior, or why destructiveHint is true for an additive note.

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

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

The description is front-loaded with the operation type and action, followed by the key non-idempotency warning and endpoint. It is short, structured, and every sentence contributes 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 three-parameter mutation tool with no output schema, the description covers the essential action, side effect, and endpoint. The main remaining gap is the lack of routing guidance relative to add_stop_note, but otherwise it gives enough context to invoke 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 moderate at 67%, and the description clarifies that the note is text, is attached to a shipment, and may optionally be tied to one of the shipment's stops. This adds useful relationship context beyond the field-level schema descriptions, though it does not mention the note length limit or explicitly map all parameters.

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

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

The description states a specific verb and resource: add a text note to a shipment, optionally tied to a stop. It clearly distinguishes this as a write operation, but it does not explicitly differentiate itself from the sibling locate2u_add_stop_note tool.

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

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

It gives useful guidance against blind retries because each call adds a new note, but it does not explain when to use this tool versus locate2u_add_stop_note or locate2u_list_shipment_notes. Usage is implied by the write verb and endpoint rather than fully specified.

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

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

Beyond the destructiveHint annotation, the description explains why retries are dangerous (each call appends a new note, so duplicates accumulate) and who can see the note. It also names the underlying endpoint, POST /stops/{id}/notes, which is concrete behavioral context the annotations do not provide.

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 short sentences, front-loaded with the operation class and the key caution. Nothing is repeated from the title, and the endpoint reference is compact and useful.

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 write with minimal annotations and no output schema, the description covers visibility, idempotency risk, and the API path. It does not say what the call returns (the created note or its ID), which an agent might want, but the essentials for correct invocation are 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 coverage is 50%: 'note' is documented in the schema, and stop_id is self-evident but undocumented. The description implies the two inputs (a stop and note text) but adds no format, length, or ID-source detail beyond the schema, which is the expected baseline at this coverage level.

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 and resource ('add a text note to a stop'), and the WRITE prefix signals the operation class immediately. It is clearly distinguishable from sibling readers like locate2u_list_stop_notes and from the shipment-scoped locate2u_add_shipment_note.

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 states the useful context — the note is visible to the team and the driver — and gives an explicit caution against blind retries. It stops short of naming alternatives (e.g., list_stop_notes for reading existing notes), so it is clear but not fully comparative.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the underlying endpoint (GET /orders), but omits behavior that matters here: whether a miss returns empty/null or an error, and the fact that the three optional-looking parameters are actually an either/or (order_number OR source+source_reference). That pairing rule is the one behavior an agent most needs and it is only hinted at.

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, zero filler, with the primary lookup strategy front-loaded before the secondary one. Nothing is wasted.

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 0% schema coverage, no output schema, and only a readOnly annotation, the description carries most of the burden but supplies little beyond the verb. It says nothing about the return shape, not-found behavior, source values, or the required parameter combination — all of which an agent needs to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it partially does: it names all three parameters and explains that source and source_reference form a pair. It still gives no format, no allowed values for source, and no statement of which combination is required, so the compensation is incomplete.

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 (find) and resource (order) plus the two lookup strategies: by order_number, or by a source/source_reference pair. It is clear what the tool does, but it never distinguishes itself from the sibling locate2u_get_order or locate2u_search_orders, which an agent will have to disambiguate on its own.

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 lookup keys imply when to reach for this tool (you already hold an order number or a source reference), which is useful context. However, no exclusions are given and no alternative is named, despite locate2u_get_order, locate2u_search_orders, and locate2u_list_orders_created being obvious overlaps.

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, so the safety profile is covered externally. The description adds the underlying HTTP mapping (GET /customers/{id}), which is mildly useful context, but says nothing about lookup failure behavior (e.g., 404 on unknown id) or the shape of what comes back.

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 terse sentences, purpose front-loaded, with zero filler or redundancy. Nothing could be removed without losing 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 single-parameter read with no output schema, the definition is minimally sufficient to trigger a correct call, but an agent gets no sense of the returned customer object or error semantics. Adequate rather than 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 description coverage is 100% and the customer_id field already documents its provenance ("from locate2u_list_customers"). The description only restates "by id" and adds no format or constraint 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 ("Get one customer by id") and the singular "one" distinguishes it from the list/search siblings. It does not name any sibling explicitly, but the read-one-by-id purpose 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?

Usage is only implied: use it when you have a customer id. There is no statement about when to prefer locate2u_search_customers or locate2u_list_customers instead, nor any note about what happens if the id is unknown.

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 readOnlyHint annotation already establishes that this is a safe read operation. The description adds the scoping constraint of a single team member and day, plus an optional status filter, but it does not describe return behavior, empty results, or other operational details beyond the endpoint path.

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 two tight sentences with the core purpose front-loaded and the API endpoint provided as supporting detail. There is no unnecessary repetition or 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 four-parameter tool with no parameter descriptions and no output schema, the definition is incomplete. It leaves include_lines undocumented and provides no return-shape context, which matters because no output schema exists.

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 0%, so the description must compensate for four undocumented parameters. It partially explains publicUserId, tripDate, and the optional status filter through the endpoint template and text, but it completely omits include_lines and does not clarify status values or date format.

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 states the verb and resource: getting one team member's trip on a specific day. The 'one team member on a day' phrasing distinguishes it from broader team-trip listing tools, but it does not explicitly differentiate it from the close sibling locate2u_get_trip.

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 implies when to use it by specifying 'one team member on a day' and an optional status filter. However, it does not name alternatives such as locate2u_get_trip or locate2u_list_team_trips, nor does it state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is fully covered and the description shoulders little burden. Beyond the endpoint string 'GET /items/{id}', it adds nothing an agent couldn't infer — no not-found behavior, no statement about what an item record includes, no auth or rate-limit context.

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

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

Two short front-loaded sentences with no filler; the verb and resource come first. The second sentence, the raw endpoint reference, borders on redundant but earns a small place as traceability for the underlying API.

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

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

For a one-parameter read tool with a readOnlyHint annotation and no output schema, this covers the essentials. It leaves open what the returned item contains and how a missing id is reported, which are meaningful gaps for the only get-single-item tool in the set.

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 0%, so the single 'item_id' parameter is undocumented in the schema. The phrase 'by id' does confirm that the id refers to the item being fetched, which is the minimum needed to compensate, but it adds no format, source, or validity detail beyond 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?

States a specific verb ('Get') and resource ('one inventory item') with the lookup key ('by id'), which clearly distinguishes it from the sibling list/search tools like locate2u_search_items. It stops short of naming the sibling it complements, but the singular 'one ... item' framing makes the retrieval-vs-search distinction evident.

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?

'by id' implies the tool applies when an item id is already known, which is usable inference but not explicit guidance. It never states when not to use it or points to locate2u_search_items for id discovery, leaving the agent to infer the routing rule.

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?

readOnlyHint=true already covers the safety profile, so the description is free to add value — and it does, by enumerating the exact fields returned and naming the underlying endpoint. It stops short of stating behavior on missing/invalid credentials, but the read-only, no-side-effect nature is unambiguous.

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, front-loaded with the verb and resource, then the return fields, then the endpoint. Nothing is redundant and nothing could be cut without losing 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?

With no output schema, the description appropriately supplies the return field list, and with no parameters there is no input surface to cover. The only marginal gap is error/auth-failure behavior, which is minor for a trivial identity lookup.

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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly implies no input is needed, since the target user is derived from the connected app's auth context.

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 and resource: 'Get the user that owns the connected app', with the returned fields (name, email, role, time zone) and the backing endpoint GET /users/me. This is clearly distinguishable from data-fetching siblings like locate2u_get_team_member or locate2u_get_team, which target other entities.

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 rather than stated: an agent can infer this is the way to identify the authenticated account, but the description never says when to prefer it over locate2u_get_team_member or locate2u_list_team_members, nor does it mention prerequisites such as needing a valid connection.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description carries a lower burden. Beyond that it only restates the HTTP endpoint (GET /orders/{id}), saying nothing about not-found behavior, error shapes, or what an order record contains — minimal added value over the annotation.

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, front-loaded with the verb and resource; nothing is padded. The endpoint line is marginally redundant with the name but does anchor the call to a concrete API path.

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 should at least hint at what an order record returns or how failures surface. For a lookup-by-id tool the agent is left without any picture of the response or error case.

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?

Only one parameter exists and the schema documents it fully at 100% coverage (integer, positive, "The order id"). The description's "by id" merely echoes 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 ("Get one order by id") plus the underlying endpoint, so the operation itself is unambiguous. However, it does not differentiate itself from sibling readers such as locate2u_find_order, locate2u_search_orders, or locate2u_list_orders_created, leaving the agent to guess which order-retrieval tool applies.

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 no when-to-use guidance and no exclusions. With three sibling tools that also retrieve orders (find_order, search_orders, list_orders_created), the absence of any routing statement is a real gap rather than a minor omission.

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?

readOnlyHint=true already declares the safety profile, so the bar is lower. The description usefully discloses that the response includes nested pickup/drop stops and items, hinting at payload size, but says nothing about whether the optional flags expand the payload or about error behavior when an ID is not found.

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 with the response content front-loaded before the endpoint note. Nothing is padded, though the endpoint fragment is low-value filler for an agent that already knows the tool name.

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

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

For a read-only tool with no output schema, three parameters, and annotation coverage of the safety profile, the description is minimally adequate: it names the resource and the nested objects returned. It leaves the two optional flags unexplained and gives no sense of response size or failure modes, which is a real gap given 0% schema coverage.

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 0%, so the description carries the full burden and does not compensate at all. It never mentions include_tracking_link or include_cost_and_charge_lines, leaving the agent to infer from bare boolean names whether these add data, cost extra, or change response shape; shipment_id is the only self-evident parameter.

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 a shipment') and adds what comes back ('its pickup and drop stops and items'), which is more than a restatement of the title. It does not, however, distinguish this from sibling retrieval tools like locate2u_get_order, locate2u_get_stop, or locate2u_get_trip, so an agent must infer the resource 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?

There is no statement of when to use this tool versus locate2u_find_order, locate2u_list_unassigned_shipments, or the other get_* siblings. The only usage clue is the raw endpoint reference 'GET /shipments/{id}', which assumes API familiarity rather than guiding tool selection.

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?

readOnlyHint=true already declares the safety profile, so the description's job is lighter. It adds value by naming the returned facets (status, contact, address, time window), but says nothing about what the three include_* flags change in the response, which is the main behavioral unknown here.

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: resource-and-contents first, endpoint mapping second. No filler, no repetition of the title, and nothing 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?

With no output schema, the description does well to preview the returned fields. But for a four-parameter tool where three optional flags are undocumented anywhere, and with no detail on error behavior for a bad ID, an agent still has gaps to guess at.

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 only 25% – only stop_id has any description ('The stopId.'), which is itself tautological. The description does nothing to explain include_items, include_lines, or include_tracking_link, so three of four parameters are undocumented in both schema and description.

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 ('Get one stop') plus a clarifying gloss that a stop is a delivery or pickup, and an explicit endpoint mapping (GET /stops/{id}). It is distinguishable from list/scheduled-stop siblings, though it does not name search_stops or list_scheduled_stops as the 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 '/stops/{id}' form implies this is for a known stop ID rather than browsing, which is useful implicit routing. However, there is no explicit when-to-use, no exclusion of search_stops or list_scheduled_stops, and no prerequisite or permission guidance.

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 readOnlyHint annotation already establishes this is a safe read, so the description's burden is lower. It adds the underlying API route, which is mild context, but says nothing about what happens when a stop has no POD questions, whether results are paginated, or what the answer payload looks like.

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, front-loaded with the purpose and followed by the endpoint reference. Nothing is padded and the reader gets the gist from the first clause.

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

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

For a single-parameter read tool with only a readOnlyHint annotation and no output schema, the description should say something about the returned answers (question text, answer values, timestamps) and empty-result behavior. It covers the 'what' but leaves the return shape entirely unspecified.

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 one parameter at 0% schema description coverage, the description must carry the meaning. The phrase 'on a stop' plus the documented route GET /stops/{id}/podquestionanswers implies stop_id identifies the stop, but it never clarifies the expected type (integer ID vs external reference) or the failure mode for an invalid 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 verb and resource: retrieves a driver's proof-of-delivery question answers for a stop. The resource is unambiguous and does not overlap with any sibling tool, though it never explicitly contrasts itself with related stop tools like locate2u_get_stop or locate2u_list_stop_notes.

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: an agent can infer you call this when you need POD answers for a specific stop. There is no statement of when to prefer it over locate2u_get_stop (which likely embeds some POD data) or any prerequisite such as the stop having POD questions configured.

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, so the safety profile is covered. The description adds that the response includes settings and branding, which is useful return-value context given there is no output schema, but it says nothing about auth requirements, error cases (e.g., no connected team), or response shape beyond those two hints.

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 core purpose front-loaded and no redundant restatement of the title. The trailing "Locate2u API: GET /team" is mildly useful for debugging but adds little for an agent choosing a tool.

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

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

With no parameters and no output schema, the description's main burden is signalling what comes back; "settings and branding" does that adequately for a simple getter. Minor gaps remain around error behavior and whether branding includes URLs/assets.

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; the baseline for a no-param tool applies. The description correctly does not waste words on parameter syntax.

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 connected team") and adds scope detail ("with its settings and branding"), which distinguishes it from locate2u_get_team_member and locate2u_list_team_members. It does not explicitly name those siblings, so differentiation is implied by scope rather than stated.

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

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

Usage is only implied: the word "connected" suggests the currently authenticated team, and the singular noun suggests one record rather than a list. There is no explicit when-to-use or when-not-to-use guidance, and no mention of when to prefer locate2u_get_me or locate2u_list_team_members 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?

readOnlyHint=true already declares the safety profile, so the bar is lower. The description adds the HTTP verb/path (GET /team-members/{publicUserId}), which corroborates the read semantics, but says nothing about error behavior for a bad id, whether the response is a full object, or any access constraints.

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 zero waste; the identification rule is front-loaded and the endpoint is a useful trailing detail.

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 one required param and read-only annotations, the call mechanics are covered. But there is no output schema, and the description does not say what a team member record contains or how a missing/invalid id manifests, leaving the agent to guess the return shape.

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 with its exact source (locate2u_list_team_members). The description adds no format or validity detail beyond 'public user id', so it neither compensates for nor exceeds the schema — baseline 3.

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

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

States a specific verb and resource ('Get one team member') plus the keying parameter ('by public user id'), and the endpoint path reinforces it. It implicitly separates itself from locate2u_list_team_members via 'one', but never names the sibling, so differentiation is left partly to inference.

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

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

Usage is only implied: 'get one' suggests retrieval after a list call, and the schema description points at locate2u_list_team_members as the id source. There is no explicit statement of when to prefer this over the list tool or what happens if the id is unknown.

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, so the safety profile is covered. The description adds real value by naming the underlying endpoint GET /team/trips/{tripDate} and enumerating the returned summary fields, which is important because there is no output 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?

Two tightly packed sentences, front-loaded with what the tool returns and followed by the endpoint. No filler; every phrase carries 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 single-parameter read tool with annotations covering safety and no output schema, the field enumeration fills the return-value gap well. The remaining shortfall is the missing differentiation from sibling trip tools, which matters given how many trip-related siblings exist.

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?

One parameter at 0% schema description coverage. The description partially compensates: 'on a day' and the path template /team/trips/{tripDate} signal that trip_date is a calendar date, matching the yyyy-mm-dd pattern. However, it does not state the required format explicitly, so an agent must inspect the schema pattern to avoid an invalid call.

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 (summarize) and resource (team trips for a day), and enumerates the summary fields (driver, distance, time, stop counts, status), which is more than a restated title. It does not explicitly distinguish itself from the sibling locate2u_list_team_trips or locate2u_get_trip, leaving the agent to infer the difference.

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 title and the phrase 'every trip in the team on a day', suggesting an aggregate view, but there is no explicit when-to-use or when-not-to-use guidance. The presence of sibling list_team_trips and get_driver_trip makes a routing sentence valuable and it is absent.

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?

readOnlyHint=true already declares this is a safe read. The description adds real value by disclosing that the response embeds stops, which shapes how an agent uses the result. It says nothing about permissions, error behavior when the id is unknown, or the effect of include_lines, so the added context is modest.

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

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

Two short, front-loaded sentences with no filler; the payload note comes first and the endpoint detail second. The raw endpoint string is marginally redundant but cheap.

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 and no annotations beyond readOnly, the description gives only a hint of the return shape ('with its stops'). For a two-parameter tool it is serviceable, but the include_lines flag and expected response envelope remain undocumented.

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 0%, so the description carries the burden, but it only implicitly covers trip_id via the URL template. The include_lines boolean — likely the difference between a lightweight and a heavy response — is completely unexplained in both schema and description.

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 trip by id') and notes that stops are included in the result, which distinguishes it from list-style siblings like locate2u_list_team_trips. It does not explicitly contrast with the near-sibling locate2u_get_driver_trip, but the id-based single-resource scope 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?

Usage is only implied: fetch a single trip when you have its id. There is no explicit when-to-use/when-not guidance and no pointer to alternatives such as locate2u_get_driver_trip or locate2u_list_team_trips for retrieving trips without an id.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds the date-range scoping behavior and the REST endpoint, but says nothing about pagination, result ordering, or what a rating record contains. Moderate added value on top of 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?

Two short sentences, front-loaded with the resource, with zero filler. However, the brevity is under-specification rather than efficiency: the two most confusing filter parameters go completely unexplained.

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 tool with five parameters (two of them ambiguous boolean filters) and no output schema, the description should say what a rating record looks like and how the filters behave. Nothing about the return shape or the boolean filter semantics is provided, leaving real gaps.

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 only 20% – just team_id carries a description. The description does not explain the start_date/end_date format expectations or, more importantly, what the lower_ratings and higher_ratings booleans do (presumably filters, but direction and combinability are unstated).

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 resource (delivery ratings left by customers), the entity scope (team's stops), and the date-range constraint, so the agent knows exactly what is returned. It also cites the underlying endpoint GET /team/{teamId}/customer-ratings. No sibling covers ratings, so sibling differentiation is moot.

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 no when-to-use or when-not-to-use guidance and does not point at any alternative among the many list_* siblings. The date-range requirement is the only implied precondition, and that is only visible from the schema's required fields.

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=true, and the description is consistent with a read-only GET endpoint. It adds the team-scope context and API path, but does not mention pagination, response shape, 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 two short sentences with the main action front-loaded and no wasted text. The API endpoint is supplementary but compact.

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, the description covers the core purpose and scope. It could be more complete by noting whether the list is paginated or what it returns, but there is no output schema requiring that detail.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics for the description to compensate for.

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

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

The description states a clear verb and resource: 'List the team's customers.' The team scope helps distinguish it from get_customer, but it does not explicitly differentiate itself from search_customers or list_customer_ratings.

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 implies this is a bulk listing of all team customers, but it gives no explicit when-to-use guidance versus search_customers or get_customer. The alternative tools are left for the agent to infer from their names.

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?

readOnlyHint=true already establishes this is a safe read, so the description's added value is limited to the underlying API mapping (GET /orders/created) and the notion that results can be enriched. It says nothing about pagination, maximum range, response size, or what happens when the include flags are false.

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 filtering behavior front-loaded and no wasted prose. The trailing endpoint reference is mildly incidental but cheap and useful for API grounding.

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?

Six parameters with one-third coverage, no output schema, and no annotations beyond readOnlyHint. The description leaves the agent guessing about four boolean flags, pagination, and result shape, which is more than a minimal definition should omit 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 coverage is only 33% – from_date/to_date are documented, but the four include_* booleans are not. The phrase 'optionally with stops and items' gestures at them without mapping to specific flags or clarifying the difference between include_order_items and include_order_lines, so the description does not compensate for the gap.

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 orders') plus the scoping filter ('created between two dates') and the optional expansion via stops/items. It does not distinguish itself from close siblings like locate2u_search_orders, locate2u_find_order, or locate2u_get_order, so an agent 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?

No statement of when to prefer this over search_orders, find_order, get_order, or list_scheduled_stops, and no prerequisites or exclusions. The only hint is 'optionally with stops and items', which describes output shape rather than selection criteria.

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, so the safety profile is covered. The description adds only the backing endpoint (GET /runs/{tripDate}); it does not disclose result size, pagination, or how filters combine (AND vs OR).

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: scope first, then optional filters, then the underlying API call. Nothing extraneous.

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 4-parameter list tool with no output schema and no parameter descriptions, the definition is minimal — an agent still lacks any sense of returned run fields or result volume. Adequate to select and call, incomplete for interpreting 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 coverage is 0%, so the description carries the burden; it names all four dimensions (day, run number, customer, team member) and clarifies that the customer filter is a customer reference, not a name. It stops short of giving date format or identifier types, which the schema pattern only partly supplies.

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 (runs) scoped to a day, plus the optional filter dimensions. It implicitly distinguishes itself from trip-oriented siblings like list_team_trips, though it doesn't name an alternative 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 'scheduled for a day' framing implies when to use it, but there is no explicit when-not guidance or pointer to sibling tools such as get_trip or list_team_trips for other access patterns.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds genuinely useful behavior beyond that: the default is today in the team's timezone and results are paged. It stops short of stating page-size limits (schema caps take at 200) or anything about ordering and return shape.

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: behavior and default first, endpoint reference second. Nothing is padded and no sentence is wasted.

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 read-only list tool with no output schema, the description covers what an agent needs to call it correctly: default day, timezone interpretation, and pagination. The remaining undocumented optional filters are a small gap, not a blocking one.

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 only 20% — trip_date is the one documented parameter. The description gestures at 'for a day' and 'paging', which loosely maps to trip_date and skip/take, but team_region_id and include_shipments are left completely unexplained in both schema and description, and the take cap of 200 is never surfaced.

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 stops scheduled for a day') with the scope and default (today in the team's zone), plus the underlying endpoint. It implicitly separates itself from locate2u_list_unassigned_stops and locate2u_search_stops by the word 'scheduled', but never names those siblings to make the boundary explicit.

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 'scheduled for a day' implies the use case (a calendar/day view of scheduled stops), but there is no explicit when-to-use guidance, no mention of when to prefer locate2u_search_stops or locate2u_list_unassigned_stops, and no prerequisites or auth notes.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. It adds the underlying API mapping (GET /services) and that results are team-scoped, but says nothing about pagination, whether inactive services are included, or the shape of each entry.

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, front-loaded with the purpose, with the API endpoint as supporting detail. Nothing is wasted, though the endpoint reference is of marginal value to 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?

For a zero-param read tool this is close to sufficient, but with no output schema the description would ideally hint at what a service record includes (id, name, region availability) so the agent knows whether the result answers its question. That gap keeps it at the minimum-viable level.

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?

Zero parameters, so the schema carries no semantic load and the baseline is 4. There is nothing for the description to clarify or omit.

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 (services) plus a scope qualifier ('the team offers'), so the agent knows this returns the team's service catalog rather than any other resource. No sibling tool covers services, so no disambiguation is required, but the description doesn't say what a 'service' contains.

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: an agent would infer to call this when it needs the team's service catalog. There is no explicit when-to-use, no prerequisites, and no mention of how this relates to team/region/warehouse listings that appear as siblings.

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, so the safety profile is covered. The description adds the underlying endpoint (GET /shipments/{id}/notes), but says nothing about ordering, pagination, or what a note object contains — details that matter for a list operation with no output 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?

Two short sentences, zero filler, with the action front-loaded and the endpoint as supporting detail.

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 one-parameter read with no output schema, this is close to adequate, but the agent gets no sense of the return shape or result volume. A brief note on what a note record contains, or on pagination, would close the 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 0%, so the description carries the burden, and it only implies that the single parameter is a shipment identifier via 'on a shipment'. Format and validity constraints (positive integer) are left entirely to the schema.

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

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

States a specific verb and resource ('List all notes on a shipment') and adds the exact API endpoint, so the operation is unambiguous. It is distinguishable from add_shipment_note by the verb, but it never explicitly contrasts itself with the near-identical sibling list_stop_notes.

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?

No guidance on when to use this versus list_stop_notes or add_shipment_note, and no prerequisites or exclusions stated. The usage is only inferable from the tool name and the word 'shipment'.

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?

readOnlyHint=true already declares this a safe read, so the bar is lower. The description adds two genuinely useful facts beyond the annotations: the underlying endpoint (GET /stops/{id}/notes) and that attachments are returned with each note. It says nothing about pagination, ordering, or empty-result 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 compact sentences with zero filler; the functional purpose is front-loaded and the API endpoint follows as supporting detail. Nothing needs to be trimmed.

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 no output schema and an explicit readOnlyHint, this covers what an agent needs to invoke it correctly, and the attachments note usefully characterizes the payload. Only the sourcing of stop_id and result ordering are left implicit.

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 0%, so the single stop_id parameter is documented nowhere in structured form. The description partially compensates by embedding '/stops/{id}/notes', which implies stop_id identifies the stop, but it never states the type, format, or where an agent obtains a stop 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 verb and resource ('List all notes on a stop') plus a notable scope detail ('with attachments'). The resource word 'stop' cleanly separates it from sibling locate2u_list_shipment_notes, so an agent can pick the right one 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?

The description gives no when-to-use framing, no prerequisites, and no mention of alternatives such as locate2u_list_shipment_notes or locate2u_add_stop_note. Usage is only inferable from the verb+resource, which is the definition of no real guidance.

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

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

Annotations already declare readOnlyHint=true, and the description corroborates with the underlying 'GET /team-members' endpoint, which is useful confirmation of non-mutating behavior. It adds no further behavioral context such as pagination of results, result limits, or how 'last known location' behaves for members with no recent fix.

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 sentence front-loads the capability, followed by a short endpoint reference that is helpful for debugging though largely restated by the tool name and annotations. Nothing is bloated; the second clause could arguably be dropped without loss.

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

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

For a simple two-parameter, zero-required read tool this is close to sufficient, but with no output schema the agent gets no picture of what a team member record contains or whether the list is paginated or truncated. Those gaps are modest but real 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%, so both parameters are already documented in-schema, and the description's 'optionally with their current location' simply restates include_current_location. It contributes nothing about team_region_id or the region filter's effect, which is fine given the schema baseline but adds no extra 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 ('List the drivers and staff in the team') plus a scope qualifier ('optionally with their current location'), which makes the collection semantics clear against singular siblings like locate2u_get_team_member. It stops short of explicitly naming those siblings, so the differentiation is inferred rather than stated.

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

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

The word 'optionally' implies the agent can call this without any filters, and the schema cross-reference to locate2u_list_team_regions aids discovery indirectly. However, nothing says when to prefer this over locate2u_get_team_member or locate2u_get_team, and no exclusions or prerequisites are given.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds the REST endpoint, but does not disclose return shape, pagination, ordering, or other behavioral details beyond what annotations provide.

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 two short sentences with the action front-loaded and no wasted text. The endpoint reference is compact supplementary context.

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, no-parameter, read-only list tool with annotations covering safety, the definition is mostly complete. It could add minor context about what a region contains or whether results are paginated, but the core invocation requirements are clear.

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 are zero input parameters, so the baseline according to the rubric is 4. The description appropriately does not describe parameters because none exist.

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

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

The description states a clear verb and resource: list the team's regions. It distinguishes this from sibling list tools such as list_team_members or list_team_trips by naming regions specifically, though it does not explicitly contrast 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 purpose implies usage: call this when you need the team's regions. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternative tools for related team data.

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?

readOnlyHint=true already covers the safety profile, so the description only needs to add context. It usefully notes that both assigned and unassigned trips are returned and that driver and stops are embedded, but says nothing about result volume, pagination, or timezone behavior for 'a day'.

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, front-loaded with the scope and return content, with the endpoint as a compact footnote. 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 one-parameter read tool with no output schema, the description tells the agent what comes back (trips with driver and stops) and the endpoint. Minor gaps remain around day boundary/timezone semantics and result size, but nothing essential to a correct call 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 0%, but the single parameter is pattern-constrained (^\d{4}-\d{2}-\d{2}$), so the format is visible in the schema. The description adds only 'for a day' and the URL template, adding little semantically beyond what the regex communicates.

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: all trips (assigned and unassigned) for a day, with driver and stops, plus the underlying endpoint GET /trips/team/{tripDate}. This clearly separates it from get_trip or get_driver_trip, though it never explicitly contrasts with the closely named get_team_trips_summary.

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 day-based team scope implies when to use it (daily team roster of trips) but offers no explicit when-not or named alternative. An agent must infer that get_team_trips_summary and get_driver_trip are the alternatives rather than being told.

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 readOnlyHint=true annotation already establishes the safety profile, so the description only needs to add context. It adds the raw endpoint (GET /shipments/unassigned) but says nothing about pagination, default result limits, whether trip_date defaults to today, or how results are ordered — all of which matter for a list tool with three optional filters.

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 purpose front-loaded and no filler. The endpoint restatement adds little for an agent that never sees HTTP paths, but it costs only a clause.

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

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

With zero parameter documentation, no output schema, and no mention of result shape or pagination, an agent cannot tell how to filter or what it will receive. For a three-filter list endpoint this leaves the essential calling information 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 0% for all three parameters (trip_date, team_region_id, pickup_within_km_distance), and the description compensates for none of them — not their formats, defaults, or combined-filter behavior. The only filter it describes, "unassigned," is not even a parameter; it is implied by the endpoint.

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?

"List shipments that no team member has yet" gives a specific verb (list) and resource (shipments) plus a clear scope qualifier (unassigned). The resource noun alone separates it from the nearest sibling, locate2u_list_unassigned_stops, though the description 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?

There is no statement of when to call this versus locate2u_list_unassigned_stops, locate2u_list_shipment_notes, or a general shipment lookup. Usage is only inferable from the word "unassigned"; no prerequisites or exclusions are given.

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

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

readOnlyHint=true already covers the safety profile, so the bar is lower, but the description adds nothing beyond the raw API path. It says nothing about pagination, result ordering, whether an empty result is common, or how trip_date interacts with the unassigned status.

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, front-loaded with the purpose and with no filler. The API path sentence is marginally useful for cross-referencing docs but is the only near-redundant content.

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 this could be adequate, but with three entirely undescribed parameters and no output schema, the description leaves the agent unable to construct a correctly filtered call. It should at minimum explain the date and region filters and the optional shipment expansion.

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 0% across three parameters (trip_date, team_region_id, include_shipments), so the description carries the full burden and supplies nothing. An agent cannot tell whether trip_date filters by scheduled date, timezone, or format, nor what include_shipments embeds.

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

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

The description states a specific verb and resource ("List stops") with a clear qualifier ("that no driver has yet"), which tells an agent exactly what collection is returned. It does not, however, distinguish this from close siblings such as locate2u_list_unassigned_shipments, locate2u_list_scheduled_stops, or locate2u_search_stops.

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 by the word "unassigned"; there is no statement of when to call this versus search_stops or list_scheduled_stops, and no prerequisites or caveats. The endpoint reference adds no guidance about selection between siblings.

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, so the safety profile is covered without description help. The description adds that results are team-scoped and maps the call to GET /warehouses, but says nothing about pagination, result size, or return shape.

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 purpose front-loaded; nothing is padded. The trailing API endpoint clause is of marginal value to an agent but costs almost nothing.

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?

A simple one-parameter read tool with annotations and no output schema — the description is adequate to call it, but with no output schema the agent gets no sense of what a warehouse record contains or how many are 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?

Schema description coverage is 100% and the single optional parameter (team_region_id) is fully documented in the schema as a region filter. The description adds no syntax, default, or interaction detail beyond that, so the baseline of 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 team's warehouses') and scopes it to the team, which is unambiguous. It does not explicitly differentiate from sibling list tools, but no sibling lists warehouses, so the resource alone disambiguates.

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 by the tool name and purpose — there is no statement of when to reach for this versus a sibling, nor any prerequisite or exclusion. For a single-purpose reference lookup this is tolerable, but nothing is spelled out.

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 readOnlyHint=true annotation already establishes this as a safe read, lowering the disclosure burden. The description adds the underlying endpoint (GET /customers/search) but says nothing about match semantics (partial vs exact, case sensitivity), result ordering, or whether pagination defaults apply — useful context this tool would benefit from.

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 primary capability front-loaded; nothing is padded or buried. The endpoint reference is mildly redundant with the tool name but occupies little 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 three-parameter, single-required-field read tool with full schema coverage and no output schema, this is close to sufficient — the agent knows what to pass and what gets matched. The remaining gap is return shape and pagination behavior, which the annotations do not cover.

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 earns an extra point by enumerating the fields the search_text parameter actually matches against (name, company, email, phone), which the schema only describes circularly as 'Text to search for.'

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 ('Search customers') plus the searchable fields (name, company, email, phone), which tells an agent exactly what is being matched. It does not distinguish itself from the close sibling locate2u_list_customers or locate2u_get_customer, so the agent 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?

Usage is only implied: 'search by text' suggests using this when a query string is available rather than browsing, and the sibling list_customers is the natural alternative. There is no explicit when-to-use, when-not, or prerequisite statement, and no mention of paging through results when the match set is large.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's burden is low, but it adds essentially nothing beyond the endpoint path. It does not state pagination behavior, default page size, result caps (per_page max 200), or what happens when no filters are supplied.

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, filter axes front-loaded, no filler. The API-endpoint sentence is compact and mildly useful for cross-referencing; nothing is wasted, though nothing is expanded either.

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 six all-optional parameters, 33% schema coverage and no output schema, the description should clarify how filters combine (AND vs OR), which status field controls what, and roughly what a result contains. It covers none of this, leaving the agent to guess on a 6-parameter search 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 coverage is only 33% (page and per_page documented; keyword, item_status, warehouse_id, location_status are not). The description partially compensates by naming "keyword, warehouse or status," but it collapses item_status and location_status into a single ambiguous "status" and gives no accepted values despite zero enums being defined.

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 ("Search inventory items") with the three filter axes named, and the underlying endpoint GET /items/search is disclosed. An agent can distinguish it from locate2u_get_item (single record) and from the sibling search_customers/search_orders/search_stops tools by resource, though the description never explicitly names those 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?

No guidance on when to prefer this over locate2u_get_item, locate2u_list_warehouses, or the other search_* tools, and no statement of prerequisites such as needing a warehouse_id to scope results. The agent must infer usage entirely from the tool name.

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?

readOnlyHint=true already tells the agent this is a safe read, and the description adds the underlying endpoint (GET /orders/search), which is modest extra context. It does not disclose whether at least one filter is required, how results are sorted, or default/maximum page size behavior beyond what the schema states for per_page.

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 searchable facets front-loaded and the API endpoint appended as a compact reference. No filler or redundancy.

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 search tool with no output schema, the description covers what can be filtered but leaves the result shape, ordering, and pagination semantics unaddressed, and gives no signal on how many of the eight optional filters to combine. Adequate but with clear gaps.

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 63%, so most parameters are documented, and the description enumerates the searchable facets, which helps prioritize filters. However, 'customer' is ambiguous against the integer customer_id, status values are left unspecified with no enums anywhere, and pagination parameters are not mentioned in the description.

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 (search) and resource (orders) plus the facets it queries, so the operation is unambiguous. It stops short of distinguishing itself from close siblings such as locate2u_find_order, locate2u_get_order, and locate2u_list_orders_created, which an agent could easily confuse with a filtered 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 listing of queryable facets implies that this is the multi-filter lookup tool, but there is no explicit when-to-use guidance and no mention of the alternatives (find_order for a single lookup, list_orders_created for recent orders). The agent must infer the routing decision from sibling names alone.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description usefully clarifies that source_reference is an integration-assigned value and names the underlying endpoint, but says nothing about whether the search returns one or many stops, what happens on a miss, or what the include_* flags change.

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 with the lookup predicate front-loaded and no filler. Nothing is wasted and the key differentiator appears first.

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 4-parameter tool with no output schema and 0% schema coverage, the definition is too thin: result cardinality, miss behavior and the three include_* toggles are all unaddressed, so an agent cannot confidently predict the call's outcome.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate and largely does not. It gives helpful meaning for source_reference, but include_items, include_lines and include_tracking_link are undocumented in both schema and description, leaving an agent to guess at their cost/effect.

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 (find) and resource (stops) plus the discriminating lookup key — the source reference stored by the integration — and adds the backing endpoint GET /stops/search. That clearly separates it from locate2u_get_stop (id lookup) and the list_* stop tools, though no sibling is named 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?

Usage is only implied: an agent can infer it should call this when it holds a source reference rather than a stop id. There is no explicit when-to-use/when-not guidance and no pointer to locate2u_get_stop or locate2u_list_scheduled_stops as 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?

readOnlyHint=true already establishes the safe-read profile, so the description does not need to restate it. It adds useful aggregation context (distance and time driven by members and asset groups) plus the underlying endpoint, but says nothing about aggregation granularity, defaults when dates are omitted, or result volume.

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 with the substantive content front-loaded and no filler. The endpoint reference is marginal value-add but short enough not to be 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?

There is no output schema, so the description would ideally indicate what the statistics look like, and with 0% parameter coverage it should explain team_region_id and date handling. It conveys the domain adequately for a read-only report but leaves real gaps an agent would hit while calling it.

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 0% across all three parameters, so the description carries the full burden and fails to meet it. It implies a date range for from_date/to_date but never states the format or whether bounds are inclusive, and team_region_id is completely unmentioned.

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 names the specific resource (travel statistics: distance and time driven) and the scope (team members and asset groups over a date range), which is a clear read-reporting purpose. It does not distinguish itself from nearby siblings like get_team_trips_summary or list_team_trips, so an agent must still guess which reporting tool is correct.

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 when-to-use guidance, no mention of alternatives such as get_team_trips_summary, and no prerequisites or exclusions. The only implied context is the date range, which is a parameter, not usage guidance.

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