Set the tip amount on a Grubhub cart by providing the cart ID and tip amount in dollars, so checkout reflects the intended gratuity.
Set the tip amount on the cart.
Args: cart_id: The cart ID tip_amount: Tip amount in dollars
| Name | Required | Description | Default |
|---|---|---|---|
| cart_id | Yes | ||
| tip_amount | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.1.7Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It does not say whether this requires an authenticated session, whether it overwrites or adds to an existing tip, whether zero is allowed, or what happens on an already-placed order.
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 purpose sentence is front-loaded and the Args block is compact with no redundant prose. Nothing extraneous, though the argument list largely restates the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. But for a mutation tool with no annotations, the description omits auth/permission expectations, replacement semantics, and routing versus post_delivery_tip, leaving real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents both parameters, and 'Tip amount in dollars' usefully resolves the unit ambiguity of a bare number. But 'The cart ID' adds nothing beyond the schema title 'Cart Id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Set the tip amount on the cart.' An agent can tell what changes. However, it does not differentiate itself from the similarly-named sibling post_delivery_tip, which is the most likely confusion point.
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 when-to-use guidance, no conditions, and no mention of the alternative (post_delivery_tip for after an order, update_cart_item for other cart fields). The agent must infer that this applies to a pre-checkout cart only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.