LimoExpress MCP by usefulapi

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

The readOnlyHint=true annotation already establishes this is a safe read, so the description is not carrying the full burden. It contributes the endpoint path but says nothing about what the fee structure contains, whether fees can be conditional, or what happens if a currency/vehicle-class combination has no fees configured.

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 prose. The raw REST path adds little for an agent already given a structured tool definition, which keeps it just short of a 5.

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

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

For a two-required-parameter read tool with a clean schema and a readOnly annotation, the essentials are covered. However, with no output schema, the description should have indicated what the returned extra-fee pricing looks like, and it offers nothing on that front.

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

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

Schema coverage is 100%, so both parameters are already documented as UUIDs sourced from list tools. The description only restates that the two inputs are a currency and a vehicle class, adding no format or edge-case detail beyond the schema — the baseline 3 applies.

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

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

States a specific verb and resource with precise scope: 'Get the extra fees for one vehicle class and currency.' This is clearly a narrower pricing lookup than the sibling limoexpress_get_pricing, though the description never names that sibling to make the distinction 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?

There is no when-to-use guidance, no mention of when this is preferable to limoexpress_get_pricing, and no stated prerequisites. The only implicit hint is that it operates on a single currency/vehicle-class pair, which the agent has to infer from the wording.

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 lookup, so the description only needs to add context. It adds the endpoint and the conditional input rule, but says nothing about what the price depends on (time, date, surcharges), what currency is returned by default, or how missing vehicle class is handled.

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

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

Three short sentences, front-loaded with the purpose before the input rules. The trailing "GET /api/integration/pricing" adds little for an agent choosing a tool, but it takes no meaningful space.

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

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

With seven parameters, no output schema, and only a readOnly annotation, the agent still lacks the shape of the answer (currency of the quote, whether it is a single price or a breakdown) and any precondition for a valid result. Adequate to attempt a call, not sufficient to interpret 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 coverage is 100%, so every parameter is already documented including the source tools for currency_id and vehicle_class_id. The description restates the optionality of vehicle class and currency and adds the to-coordinates-or-distance choice, but that conditional is only weakly expressed and mostly mirrors the schema's own wording.

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 price for a trip") plus the scoping inputs (coordinates, vehicle class, currency), so the agent knows exactly what the call produces. It never names limoexpress_get_extra_fees_pricing, so sibling differentiation is left to the agent despite that tool sounding very close.

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

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

"Give the destination coordinates, or a distance when there is no destination" is genuinely useful guidance on which input mode to pick. However, there is no statement of when to use this versus limoexpress_get_extra_fees_pricing, nor any prerequisite about validating vehicle_class_id or currency_id first.

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 'GET /api/integration/all-currencies' endpoint and the 'every currency the platform supports' scope, which is useful context, but it does not describe pagination behavior, return shape, or authentication requirements.

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 zero waste. The primary scope statement is front-loaded, followed by the endpoint reference, making it easy to scan.

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 listing tool with full schema coverage and a readOnlyHint annotation, the description is largely complete. Its main gap is not explicitly naming or differentiating from limoexpress_list_organisation_currencies, but the 'every currency the platform supports' wording does enough to imply global scope.

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

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

Schema description coverage is 100%, so the three parameters (page, per_page, search_string) are already fully documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, which is the baseline expectation when schema coverage is high.

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 every currency the platform supports.' This is clear, but it does not explicitly distinguish this global currency list from the sibling tool limoexpress_list_organisation_currencies, so an agent must infer the difference from the 'platform supports' wording.

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 explicit guidance on when to use this tool versus alternatives, particularly limoexpress_list_organisation_currencies. The description gives no exclusions or prerequisites, leaving the agent to infer usage from the name and scope phrase.

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, but the description adds no behavioral context beyond the raw endpoint path — no pagination behavior, no default page size, no statement about whether results are ordered or complete. The one genuinely useful clarification (offers = quotes sent to clients) is definitional rather than behavioral.

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 fragments with the purpose and the disambiguating gloss front-loaded, followed by the endpoint. No filler. It is arguably a touch too terse, but 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?

For a simple read-only list tool with fully documented parameters and an explicit readOnlyHint, the description covers the essentials. However, with no output schema, it gives no hint about what fields an offer record contains, which an agent needs to decide whether this is the right source for quote data.

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%: page, per_page, and search_string are all documented in the schema, including the default and the 200 cap. The description adds nothing about parameter semantics, so the baseline 3 applies.

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

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

States a specific verb and resource ("List booking offers") and adds a clarifying gloss — "quotes sent to clients" — that disambiguates it from the sibling limoexpress_list_bookings. The REST endpoint is included as supplementary evidence. It stops short of naming a sibling to contrast with explicitly, but an agent can tell what this returns.

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 parenthetical definition of an offer as a quote; there is no explicit when-to-use or when-not-to-use guidance versus limoexpress_list_bookings or limoexpress_list_booking_statuses. No prerequisites, no note on whether offers are filterable by client or status. Adequate but clearly incomplete for an agent choosing among 21 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 safe-read contract is covered. The description adds only the filterable dimensions and the endpoint path; it says nothing about pagination behavior, default result ordering, or result volume, which would be useful additional context for a list endpoint with 12 params.

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

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

Two compact sentences, front-loaded with the resource and then the filter facets; nothing is padded. The endpoint path at the end is arguably waste for an agent but it is a single trailing token.

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

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

For a read-only list tool with full schema coverage and no output schema, the description covers what the tool returns at a level an agent needs to select and call it. Pagination and default sorting are handled by the schema, so their absence from the description is acceptable, though a note on result size or default ordering would complete 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 100%, so every parameter is already documented in the schema, including the date format and enum values. The description restates a subset of the filter parameters (time range, status, type, payment method, vehicle, client) but omits page, per_page, order, order_by, and search_string, adding no new meaning beyond the schema.

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

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

The description opens with a specific verb and resource ('List bookings of the organisation') and enumerates the filterable dimensions, so an agent can tell it apart from siblings like limoexpress_list_clients or limoexpress_list_booking_offers. It is clear but does not explicitly contrast itself with any sibling 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?

Usage is implied ('List bookings... Filter by pickup time range...') and the filters give a hint of when this tool applies, but there is no statement of when to prefer it over alternatives or any prerequisite context. The trailing endpoint reference adds nothing operational.

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 with no side effects, so the description's main addition is the raw endpoint path (GET /api/integration/booking-statuses). It adds nothing about whether statuses are global vs. account-specific or how many are typically returned.

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 fragments, purpose first, endpoint second; nothing extraneous. The key information (what it lists and what the IDs are for) is front-loaded.

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

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

For a zero-parameter lookup with no output schema, the description covers what the agent needs: the resource and the intended downstream use. It could say slightly more about the shape of results (id + label vs. bare ids), which matters because there is no output schema to fall back on.

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 no parameter semantics to document; the baseline of 4 applies. The description correctly signals that no input is needed.

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 booking statuses') and adds why it exists ('ids for the status filter'), which separates it from sibling list_* tools that return full objects. It does not explicitly contrast with the closest sibling (limoexpress_list_booking_types), so it stops short of a 5.

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

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

The parenthetical 'ids for the status filter' implies the workflow (fetch these before filtering bookings by status), but there is no explicit when-to-use statement, no prerequisites, and no named alternative. Usage must be inferred.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description adds little beyond restating that with 'List'. The only extra information is the HTTP endpoint path, which is useful for tracing but says nothing about response shape, ordering, pagination, or whether the list is filtered by account scope.

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, purpose front-loaded, no filler. The endpoint path is partly redundant with the tool name but is cheap and occasionally useful, so it does not hurt much.

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 trivial zero-param list tool the description is close to sufficient, but with no output schema it should at least indicate what a booking type record contains (id, name, maybe code) so the agent can decide whether the result answers its question. That gap keeps it at minimum-viable 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; per the zero-parameter baseline this scores high by default. Schema coverage is also 100%.

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

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

A specific verb (List) plus resource (booking types) makes the operation unmistakable. It does not, however, distinguish itself from near-neighbour siblings such as limoexpress_list_booking_statuses or limoexpress_list_booking_offers, so the agent must infer the difference from the names alone.

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

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

There is no guidance on when to call this versus the other list_* metadata endpoints, and no stated prerequisites or context (e.g., use when populating a booking-type dropdown before creating a booking). The agent gets only the bare purpose.

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 'GET /api/integration/clients' line reinforces that this is a non-mutating read. The description adds little beyond that: no pagination behavior, no result-size limits, no note on default ordering. Adequate but thin for a tool with annotation coverage.

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 padding, and the resource description ('customers and organisations') is front-loaded. The raw endpoint path is marginally useful but borders on 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 read-only list tool with fully documented optional params and no output schema, the description is minimally sufficient. However, an agent gets no picture of the response shape beyond 'contact details', nor of pagination defaults, which matters 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?

All three parameters (page, per_page, search_string) are fully documented in the schema at 100% coverage, so the schema carries the burden. The description adds no extra semantics such as what fields search_string matches against beyond 'contact details' being returned. Baseline 3 applies.

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

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

States a specific verb and resource ('List clients') and even disambiguates the resource as 'customers and organisations', which helps against siblings like list_passengers and list_users. It does not explicitly name a sibling it is not, so it stops short of a 5.

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

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

No statement of when to use this versus list_passengers, list_users, or list_subcontractors, and no guidance on when to paginate or when to supply search_string. The use case is only inferable from the 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description adds the concrete endpoint (GET /api/integration/countries), confirming a read, but says nothing about pagination defaults, result volume, or whether the list is tenant-scoped versus global.

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 zero filler, and the purpose is front-loaded ahead of the endpoint detail. Slightly more terse than ideal for a tool with a filter parameter, but 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?

For a simple read-only list tool with full schema coverage and a safety annotation, the definition is close to sufficient. The remaining gap is that no output schema exists and the description never indicates what a country record contains (code, name, active flag), leaving the return shape to discovery.

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%: page, per_page, and search_string are all documented in the schema. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ("List countries known to the platform"), which is unambiguous against siblings like list_all_currencies or list_organisation_currencies. It does not explicitly name a sibling to distinguish from, but the resource noun is distinct enough that no routing ambiguity exists.

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 guidance on when to use this tool versus the currency/pricing siblings, nor any prerequisites or exclusions. The only usage signal is the implicit one that it is a list endpoint, which the agent must infer entirely from the 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 declares the safety profile, so the bar is lower, but the description adds only the raw endpoint path — no information on result ordering, pagination behaviour, or what a voucher record contains. It neither contradicts nor meaningfully enriches the annotations.

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

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

A single compact sentence that front-loads the action and scope. The trailing endpoint path is low-value filler but the description stays short and readable.

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 read-only list tool with fully documented params and safety annotations, so most needs are met. However, with no output schema, the agent still has no idea what fields a voucher returns or how results are paged — a brief note 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 coverage is 100% and each parameter (page, per_page, currency_id) is documented in the schema. The description adds only a restatement of the currency filter, 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?

Specific verb+resource ('List discount vouchers') with an optional currency scope, and the endpoint path confirms the resource. It is clearly distinct from the many other list_* siblings such as list_bookings or list_all_currencies, though it doesn't say so 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?

'optionally for one currency' hints at a filter but gives no guidance on when to use this versus other pricing/offer list tools (e.g. list_booking_offers), no mention of pagination defaults, and no exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered structurally. The description adds nothing beyond the raw endpoint path — no mention of pagination behavior, default page size, ordering, or what 'events' contain. For a paginated list endpoint, that leaves meaningful behavioral gaps.

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 padding. The endpoint string is mildly redundant but arguably useful for cross-referencing API docs. 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?

For a simple read-only list tool with full schema coverage and a readOnlyHint annotation, the definition is minimally sufficient to call it. However, there is no output schema, and the description says nothing about the shape of returned events or pagination semantics, so an agent cannot anticipate the response.

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

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

Schema description coverage is 100%, with page, per_page, and search_string each documented in-schema, so the baseline of 3 applies. The description contributes nothing extra about parameter interplay (e.g., search_string scoping or per_page maximum behavior).

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 events defined in the organisation') and names the API endpoint. The scope ('in the organisation') is clear. It does not explicitly differentiate from the many sibling list_* tools, but 'events' is a distinct resource so the risk of confusion is low.

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 tool versus alternatives, no stated prerequisites, and no mention of when not to use it. The only implicit signal is that it lists rather than filters or mutates.

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?

With readOnlyHint=true already declaring the safety profile, the description adds only the scope word 'in the organisation' and the raw endpoint path. It says nothing about pagination behavior, default page size, ordering of results, or what an empty result means.

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 clauses with zero padding and the purpose front-loaded. The endpoint path is arguably redundant with the tool name but is compact enough not to hurt.

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 filtered-list tool with fully documented params and readOnly annotations, the essentials are covered. However, with no output schema, the description should hint at the result shape or pagination envelope, and it does not.

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% (page, per_page, search_string all documented), so the schema carries the parameter semantics and the description adds nothing. Baseline 3 applies per the high-coverage rule.

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 expenses recorded in the organisation') and even names the backing endpoint, so the agent knows exactly what it retrieves. The differentiation from near-siblings like limoexpress_list_invoices is only implicit in the noun 'expenses'.

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 or when-not-to-use guidance, no mention of the alternative list tools (invoices, bookings), and no prerequisites. The only guidance is the self-evident implication of 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; the description reinforces it by naming the GET endpoint. It adds the useful detail that paid status is returned, but says nothing about pagination behavior, result volume, or total counts, so it adds only modest value beyond 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 purpose. The trailing endpoint path is of marginal use to an agent but costs almost nothing, so overall it is tight and waste-free.

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

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

For a simple read-only list tool with full schema coverage, this is minimally adequate. With no output schema, the description should say more about what an invoice record contains or how results are ordered, which it does not.

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 page, per_page, and search_string are already documented in the schema. The description contributes nothing additional about parameter behavior (e.g., which fields search_string covers beyond 'record fields'), so the baseline 3 applies.

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

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

States a specific verb and resource ('List invoices') plus the notable payload attribute ('with their paid status'), which distinguishes it from the mutation sibling limoexpress_mark_invoice_as_paid. It does not explicitly distinguish itself from other list_* siblings, but the resource is unambiguous.

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

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

There is no guidance on when to call this versus alternatives, no mention of preconditions (e.g., paging through results, or using it to find an invoice before calling limoexpress_mark_invoice_as_paid). Usage is only inferable 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying endpoint path (GET /api/integration/currencies), which is minor context, but says nothing about pagination, ordering, or empty-result behavior for a tool with zero annotations beyond readOnly.

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. The second sentence is just an API endpoint path, which earns little place but does no harm.

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 parameters, the description is the only place to learn what a returned currency record contains (code, symbol, id, default flag). It doesn't say, leaving the agent to guess the response shape for a simple but underspecified list tool.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate. Baseline 4 applies since the empty schema leaves no semantic 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?

Specific verb+resource ("List the currencies enabled for the organisation") that clearly scopes the result to org-enabled currencies rather than all currencies. It implicitly distinguishes itself from the sibling limoexpress_list_all_currencies, though it doesn't name that sibling explicitly.

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

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

Usage is only implied: an agent can infer it should call this when it needs the currencies actually available to the organisation. There is no explicit statement of when to prefer it over limoexpress_list_all_currencies, nor any prerequisites or exclusions.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful context by disclosing that records contain personal data and giving the underlying GET endpoint, but it does not describe response shape, pagination behavior, or any privacy-related handling 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?

The description is three short sentences and front-loads the core operation. The PII warning and endpoint are compact, and there is 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 simple read-only list endpoint with fully documented optional parameters and no output schema, the description covers the essential identity, privacy note, and endpoint. It could be stronger with a brief note on result pagination or typical use, but it is largely 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%, so the page, per_page, and search_string parameters are already fully documented in the schema. The description adds no additional parameter semantics, which is acceptable given the schema coverage baseline.

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 passengers.' It is specific enough to distinguish this from pricing, booking, invoice, and user tools, but it does not clarify scope or how it differs from other list endpoints beyond the resource name.

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 guidance on when to use this tool versus alternatives, nor does it mention how pagination or search should be applied. It simply states the operation without usage context.

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 HTTP endpoint and the fact that returned IDs feed booking filters, but says nothing about pagination behavior, auth requirements, or the shape of returned records.

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

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

Three short sentences with no filler, and the core purpose is front-loaded. Slightly terse rather than bloated — the endpoint path earns its place as implementation 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 read-only list tool with full schema coverage and a safety annotation, the essentials are present. With no output schema, though, the description gives no hint of what a payment method record contains (id, name), leaving the agent to discover the return shape by 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 100%, so page, per_page, and search_string are already fully documented in the schema. The description adds no syntax, defaults, or semantics beyond what the schema provides; baseline 3 is appropriate.

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

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

The description states a specific verb and resource ("List payment methods") and pins the underlying endpoint (GET /api/integration/payment-methods), so an agent knows exactly what it retrieves. It doesn't differentiate itself from the many sibling list_* tools, but the resource is unambiguous enough that confusion is unlikely.

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?

"Ids are used to filter bookings" hints at the downstream use case (fetching payment-method IDs to filter booking queries), which is real implied guidance. However, it never states when to call this versus the other list endpoints, nor any prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the org scoping ("of the organisation") and the underlying endpoint, but says nothing about pagination defaults, total counts, or result shape — modest value beyond 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 compact sentences, front-loaded with the purpose and followed by the endpoint reference. Nothing is wasted or 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?

It is a simple read-only list with fully documented parameters, but there is no output schema and the description never indicates what a subcontractor record contains. For a list tool whose return shape is otherwise undisclosed, one clause on returned fields 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 coverage is 100% with all three parameters (page, per_page, search_string) documented in the schema. The description adds no meaning about search semantics, page-size limits, or sorting, so it lands at the baseline.

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 subcontractors") and disambiguates the domain term by equating it with "partner operators of the organisation." The resource is distinct from every sibling list_* tool, so no explicit contrast sentence is required, though none is given.

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

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

There is no statement of when to use this versus alternatives, no prerequisites, and no note on when the result set would be empty or how it relates to other organisation-scoped listings. Usage is only inferable from the resource 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful context by naming the endpoint as GET and clarifying that results include staff and drivers, but it does not disclose pagination behavior, authentication needs, 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 resource and scope front-loaded, followed by the endpoint. There is no redundant or wasted text.

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

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

For a simple list tool with fully documented parameters and a readOnlyHint annotation, the description is minimally adequate. It does not explain return values or pagination behavior, but the schema covers the input side and the tool's purpose is clear enough to invoke.

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

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

Schema description coverage is 100%, with page, per_page, and search_string fully documented in the schema. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description gives a specific verb and resource: list users (staff and drivers) of the organisation, and even includes the backing endpoint. It is clear which resource it returns, though it does not explicitly contrast itself with similar list tools such as list_clients or list_passengers.

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 implies a simple listing operation but offers no guidance on when to use this versus sibling listing tools, nor any prerequisites or exclusion conditions. The parenthetical clarifies scope but not usage decisions.

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 that the endpoint is a paginated GET listing and that returned class ids feed pricing, which is genuinely useful downstream context, but it says nothing about pagination limits, total counts, or how many results come back by default.

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

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

Three short sentences, front-loaded with purpose and examples before the incidental endpoint path. Tight and readable, though the raw GET path is arguably redundant for an agent that never constructs URLs itself.

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

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

For a simple read-only lookup with a fully documented three-parameter schema and no output schema, the description covers what it is, what it returns (class ids), and why they matter. Only the relation to limoexpress_list_vehicles and pagination behavior remain unaddressed, both minor here.

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% — page, per_page, and search_string are all documented in the schema with bounds. The description contributes no additional parameter meaning (e.g. that search_string matches class names specifically), so the schema does all the work and baseline 3 applies.

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

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

States a specific verb and resource ('List vehicle classes') and grounds it with concrete examples (sedan, van), plus explains that class ids are the key consumed by pricing. It does not explicitly distinguish itself from the nearby limoexpress_list_vehicles sibling, which an agent could plausibly confuse with it.

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 line 'Class ids are used for pricing' implies the tool should be called before the pricing siblings (limoexpress_get_pricing, limoexpress_get_extra_fees_pricing), but this connection is left for the agent to infer. No explicit when-to-use, when-not-to-use, or named alternative is given.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds the organisational scope and the underlying GET endpoint, but it does not mention pagination behavior, authentication, rate limits, or return characteristics.

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

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

The description is very short and front-loads the core purpose. The endpoint path is not strictly necessary for tool selection, but the overall wording is efficient and not padded.

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

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

For a simple read-only list tool with complete input schema coverage, the description is minimally adequate. However, it does not clarify return values or how the vehicle list differs from related vehicle-class or subcontractor listings.

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 page, per_page, and search_string are already documented in the schema. The description does not add further meaning about pagination or search semantics, which is acceptable given the complete schema.

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

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

The description states a specific verb and resource: list fleet vehicles of the organisation. It is clearer than a generic list tool, but it does not explicitly differentiate itself from close siblings such as limoexpress_list_vehicle_classes.

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 the tool is for listing fleet vehicles, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. An agent must infer whether to use this versus list_vehicle_classes or other fleet-related list tools.

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 'WRITE:' prefix and endpoint align with the destructiveHint=true annotation, so there is no contradiction. It does add that this affects exactly one booking and is a state mutation. But with no annotation covering side effects, it does not disclose whether the prior status is overwritten, whether the change is reversible, or whether notifications are triggered.

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

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

Three short sentences, front-loaded with the WRITE marker and the core action. Every sentence carries information: operation type, targeted resource, and how to source the id.

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 mutation with destructiveHint=true and no output schema, the definition covers the mechanics but omits consequences: what the response looks like, what happens on invalid or already-confirmed bookings, and any downstream effects. 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 description coverage is 100%, and the parameter already documents 'Record id (UUID) from the matching list tool.' The description's pointer to limoexpress_list_bookings largely restates the schema rather than adding new meaning, 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 with scope: 'set one booking to the confirmed status', plus the underlying endpoint POST /api/integration/mark-booking-as-confirmed. An agent can distinguish it from limoexpress_list_bookings and from the analogous limoexpress_mark_invoice_as_paid without opening the schema, though no explicit contrast is drawn.

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?

Provides a prerequisite workflow ('Use limoexpress_list_bookings to find the id'), which is useful context for obtaining the required argument. However, it gives no guidance on when this action is appropriate versus when it should be avoided, nor what preconditions (e.g. current status) must hold before confirming.

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 destructiveHint annotation already flags the operation as a mutation; the description adds the useful context that it changes accounting state and labels it WRITE. It does not say whether the change is reversible, whether already-paid invoices error out, or what permissions are needed.

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

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

Three short sentences, front-loaded with the WRITE marker and the state-change warning, with zero filler. Every clause carries actionable 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 mutation with annotations present and no output schema, the definition covers what the tool does, the side effect, and how to get the id. Missing only edge-case behavior (idempotency, error conditions) for full completeness.

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

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

Schema coverage is 100% and the schema already documents invoice_id as a UUID from the matching list tool, so the description's instruction to use list_invoices largely restates it. Baseline 3 applies since the schema does the heavy lifting.

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 ('record one invoice as paid') plus the exact endpoint, which pins down the operation unambiguously. It is clearly distinguishable from the sibling list_* tools and from mark_booking_as_confirmed.

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

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

Explicitly routes the agent to limoexpress_list_invoices to obtain the id before calling, which is the key prerequisite. It offers no exclusions or when-not-to-use guidance (e.g. invoices already paid, or when a payment record should be created instead), so it stops short of a full routing statement.

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