Lalamove MCP by usefulapi

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

Annotations already flag destructive/non-idempotent, but the description adds the material facts an agent cannot infer: real money leaves the wallet, only the delta over the previous fee is charged, and the amount replaces rather than supplements the earlier fee. The pre-acceptance time window is also a behavioral constraint not encoded anywhere in the schema.

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

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

The cost warning is front-loaded in the first two words, followed by purpose, timing constraint, financial mechanics, and currency. Every sentence carries non-redundant information and the endpoint is appended last.

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 3-parameter money-spending mutation, the description covers purpose, timing window, charge mechanics, currency unit, and the API route. With no output schema, the absence of return-value detail is acceptable given how thoroughly the action's consequences are described.

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 applies. The description does add one real semantic layer by specifying the amount is in the market's currency and pointing to priceBreakdown.currency, but it does not clarify order_id or confirm beyond the schema's own text.

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 ('add a priority fee (tip) to an order') plus the intent ('to attract a driver'), which no sibling tool shares. The leading 'WRITE, SPENDS MONEY' tag immediately separates it from read tools like lalamove_get_order and lalamove_track_order.

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

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

Gives a clear precondition window ('Only possible before a driver accepts the order') and a constraint on the value ('must be higher than' the earlier fee). It does not name a sibling alternative (e.g. cancel vs. re-place) for the case where the window has closed, so it stops short of full routing 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 destructiveHint=true and idempotentHint=true, so the bar is lower, yet the description still adds the business rule (time/state window), the exact error code returned on refusal, and the irreversibility fact ('cannot be revived, only re-placed from a new quotation'). This is real behavioral context an agent cannot infer from structured fields.

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

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

Two dense sentences plus the endpoint. The WRITE/DESTRUCTIVE label and the cancellation window are both front-loaded, and every clause carries a distinct fact (constraint, error code, irreversibility, route) with no repetition of the title.

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

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

No output schema exists, and the description covers what matters for a destructive two-parameter operation: preconditions, failure signal, and post-state irreversibility. Combined with the schema's confirm gate, an agent has everything needed to decide whether to call and to interpret a refusal.

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 order_id and the confirm:true gate are already fully documented, including the explicit-confirmation requirement. The description only echoes the orderId path parameter and adds nothing about the confirm flag, which is baseline-adequate rather than additive.

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 ('cancel a delivery order') and immediately qualifies it with the allowed order states. Names the underlying endpoint DELETE /v3/orders/{orderId}, which pins the operation unambiguously against siblings like lalamove_get_order or lalamove_change_driver.

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

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

Gives an explicit when-it-works condition (ASSIGNING_DRIVER, or <5 minutes after driver acceptance) and the failure mode otherwise (ERR_CANCELLATION_FORBIDDEN), plus the recovery path (re-place from a new quotation). It does not name which sibling to use when the cancellation window has closed, so routing to alternatives is implied rather than stated.

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

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

Annotations already flag destructiveHint=true and non-idempotent, but the description adds real context: no extra fee, a hard 15-minute time limit, the state transition to ASSIGNING_DRIVER with a new driver search, and the underlying DELETE endpoint. This goes materially beyond what the annotations convey.

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

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

Three tight sentences, front-loaded with the WRITE marker, then constraint, then prerequisite. Every clause carries operational information; nothing is 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 destructive mutation with no output schema, the description supplies the timing constraint, prerequisite lookup, state outcome, and cost impact. The confirm gate and reason enum live in the schema, so nothing an agent needs is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds provenance for driver_id by pointing to lalamove_get_order for the current driver id. It does not explain reason or the confirm gate, which the schema already handles in detail.

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

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

Opens with an explicit verb and resource ("ask Lalamove to replace the driver of an order") and tags it as a WRITE operation. That is clearly distinct from siblings such as lalamove_get_driver, lalamove_cancel_order, and lalamove_track_order, so no schema comparison is needed to identify 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?

Spells out the exact eligibility window (15 minutes after driver match, before pickup) and the prerequisite data source ("Needs the current driver id from lalamove_get_order"). It also names the outcome (back to ASSIGNING_DRIVER), which tells the agent when this is the right tool rather than cancel or track.

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?

Adds genuinely non-obvious behavior beyond annotations: the ~5 minute expiresAt, that nothing is ordered or charged (clarifying the readOnlyHint=false), and the POST /v3/quotations endpoint. It does not discuss rate limits or failure modes, keeping it just short of a 5.

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

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

Four tight sentences front-loading the core action, then return values, then the safety disclaimer, then prerequisites. No filler; every sentence carries distinct 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 compensates by naming the returned fields (quotationId, stopId, price breakdown, currency, distance, expiresAt). Nested-object complexity and the 8-parameter surface are adequately covered by the schema plus this text.

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 baseline is 3; the description still adds value by clarifying that the first stop is the pickup and the remainder are drop-offs, and by pointing to lalamove_list_cities as the source of service_type values. Most other parameter detail is repeated from 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 ('Price a delivery') plus scope (2-16 stops, vehicle type, optional extras), and explicitly disambiguates from lalamove_place_order by saying it creates a quotation and nothing is ordered. An agent can immediately tell it apart from get_quotation and place_order.

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?

Names the prerequisite sibling ('Get the vehicle keys from lalamove_list_cities') and prescribes the workflow step ('Show the price to the user before placing an order'). Both the when and the sequencing relative to alternatives are explicit.

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 read-only annotation, the description discloses the access window, the 403 behavior outside it, and the approximately 10-second coordinate refresh cadence. These are meaningful behavioral constraints an agent needs before calling the tool.

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

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

The description is front-loaded with the returned data, then adds the access window and endpoint in compact form. Every sentence contributes useful selection or invocation 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?

There is no output schema, but the description enumerates the returned driver fields and explains the main availability constraint and failure mode. An agent has enough information to decide whether to call it and how to interpret a 403.

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 order_id and driver_id are already well documented in the schema. The description only refers to them via the endpoint path and does not add format or edge-case semantics beyond what the schema provides.

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/resource combination: fetching the driver of an order, with the returned fields named explicitly (name, phone, masked plate, photo, coordinates). This distinguishes it from sibling tools such as get_order and track_order without requiring the agent to open schemas.

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

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

It gives clear operating context: the driver data is only shared from one hour before pickup or arrival until completion, and outside that window the API returns 403. It does not explicitly say when to prefer track_order or get_order instead, so it is strong context but not full alternative routing.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the description's added value is the 60-day lookback limit and the shape of what is returned (statuses, proof of delivery, metadata). It does not mention failure modes such as an unknown or expired order id, which would be the remaining gap.

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

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

Three dense sentences: payload contents first, then the retention constraint, then the endpoint. No filler, and the most decision-relevant constraint is not 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, listing the returned fields and the 60-day cap gives an agent enough to call and interpret the result. Only error/not-found behavior is left unstated.

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

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

Schema coverage is 100% and the single order_id parameter is fully documented with a pattern and example, so the schema does the heavy lifting. The description adds nothing about the id format beyond what the schema already says, which is the baseline-3 case.

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

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

"One delivery order" plus the endpoint GET /v3/orders/{orderId} states the resource and operation unambiguously. The enumerated payload (status values, price breakdown, driver id, stops) makes it clearly distinct from siblings like lalamove_track_order or lalamove_get_driver.

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 60-day retention constraint is real usage guidance the agent cannot infer elsewhere. However, there is no explicit statement of when to pick this over lalamove_track_order or lalamove_list_cities, nor what to do when an order falls outside the window.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered; the description adds genuinely new behavioral context by disclosing the 5-minute ordering window tied to expiresAt. It still doesn't say what happens when the quotation has expired (error vs. stale data), which is the main behavioral unknown for a read-only fetch.

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

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

One compact sentence with the resource front-loaded and no filler; the enumeration of return fields earns its place because no output schema exists. The telegraphic fragment style ('A quotation by id: ...') costs it a point on readability.

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

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

With no output schema, the description usefully enumerates the return payload and the expiry constraint, which is what an agent needs to decide whether to use or re-create a quotation. The remaining gap is error/expiry behavior, minor for a single-parameter read tool whose annotations cover safety.

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 already documents the id format and where it comes from (quotationId from lalamove_create_quotation), so the description adds nothing about the parameter. Baseline 3 is appropriate when the schema carries the full burden.

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 identifies the specific resource (a quotation by id) and the endpoint GET /v3/quotations/{quotationId}, and enumerates what the response contains (stops with stopId, vehicle, price breakdown, currency, distance, expiresAt), which clearly separates it from the mutating siblings like lalamove_create_quotation or lalamove_place_order. It lacks an explicit verb ('Retrieve'/'Fetch') so the phrasing is a fragment rather than a full statement of action.

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 note that 'a quotation can be ordered for 5 minutes' hints that this should be called shortly before ordering, and the sibling list makes the create-vs-get split inferable. There is no explicit when-to-use/when-not statement, no mention of calling this after lalamove_create_quotation or before lalamove_place_order, and no guidance for expired quotations.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the underlying endpoint (GET /v3/cities), which is useful context, but says nothing about auth requirements, rate limits, or market scoping behavior — only that results are limited to the connected market.

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 resource and its contents come first, the downstream usage second, and the endpoint last. Every sentence earns its place.

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

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

With no output schema, the description carries the burden of describing return content, and it does so reasonably well: cities, vehicle types and their keys, size and load, and accepted special requests. It stops short of describing the response shape or ordering, but an agent has enough to call and parse 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?

The tool takes zero parameters, so there is no parameter semantics to explain; baseline is 4. The description does usefully pre-announce the serviceType keys that appear in the response and will be reused as inputs elsewhere.

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 a rich resource: it lists the cities of the connected market together with vehicle types, their size and load, and the special requests each accepts. This is clearly distinguishable from sibling operations like quotation creation or order tracking, and it names the concrete key field (serviceType) the agent will encounter.

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 a concrete downstream usage instruction — use these exact keys in lalamove_create_quotation — which tells the agent why and when to call this tool before quoting. It does not state explicit exclusions or when not to call it, so it falls short of a full 5.

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

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

Annotations already flag destructive/openWorld/non-idempotent, and the description goes well beyond them: money is charged to a prepaid wallet, a driver is dispatched, free cancellation only within Lalamove policy, expired quotations are refused, and the confirm_total is server-checked against the quotation. The 'placed once, do not retry blindly' note directly reinforces idempotentHint=false with an actionable recovery 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?

Front-loaded with the two facts that matter most (write, spends money), then preconditions, then failure handling. Six short clauses, no filler; even the endpoint reference is compact and does not displace the decision-critical 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?

No output schema exists, and the description never says what a successful call yields (e.g. an order id usable with lalamove_get_order / lalamove_track_order) — the one thing an agent needs immediately after placement. Everything else a caller must know for a 7-parameter, nested-object, money-spending tool is covered.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real cross-field semantics the schema cannot express — confirm_total must equal the quotation's total and is validated server-side, and recipients are matched positionally to the quotation's drop-off stops in stop order. The confirm boolean gate is also restated with its user-consent condition.

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 ('order a delivery from a quotation') and anchors it to the sibling that must precede it (lalamove_create_quotation), plus the underlying POST /v3/orders. The leading 'WRITE, SPENDS MONEY' capsule distinguishes it instantly from read-only siblings like lalamove_get_quotation.

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

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

Gives an explicit precondition ('Only call it after the user has seen the quotation price and said yes'), an explicit failure-recovery route ('do not retry after an error without checking lalamove_get_order'), and warns about expiry. It also names what a cancellation costs, which is the alternative the agent would otherwise improvise.

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

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

Annotations already cover read-only, non-destructive, open-world, so the bar is lower; the description still adds real value by disclosing that this performs two underlying GET calls and under what state conditions the second fires. It stops short of noting what happens when no driver is assigned beyond the implicit 'no driver data'.

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

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

Front-loaded with the user-facing question and what comes back, then the call mechanics. Two sentences, no filler; the endpoint paths are slightly technical but justify themselves by explaining the conditional second read.

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

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

With no output schema, the description carries the return-value burden and does name the key fields (status, POD, share link, driver name, live coordinates). For a single-parameter read tool this is nearly sufficient, though the absence of any contrast with lalamove_get_order leaves a selection ambiguity.

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 with 100% schema description coverage, so the schema fully documents order_id including its pattern. The description adds no extra semantics about the id format or accepted values, 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?

Opens with a concrete question-form purpose and enumerates exactly what is returned: order status, stop-level proof of delivery, share link, and conditional driver name/coordinates. The verb 'track' plus resource is clear, but it never distinguishes itself from the sibling lalamove_get_order, which likely overlaps heavily.

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

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

Gives an explicit condition for the extra driver read ('if a driver is assigned and the order is ON_GOING or PICKED_UP'), which tells the agent what to expect rather than how to choose the tool. No guidance on when to pick this over lalamove_get_order or how it relates to cancel/change_driver.

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