rappi_web_cartInspect your Rappi cart via web gateway, with street, phone, email, and last-four redacted. Read-only access returns cart data as summary, structured, or raw output.
Alternate cart inspect via web-gateway. Street/phone/email/last-four redacted. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| privacy_mode | No | ||
| response_format | No | markdown |
Changes observed during successful MCP inspections.
v0.1.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the concrete behavioral detail that street, phone, email, and last-four are redacted, which is not present in annotations. It also confirms 'Read-only,' consistent with annotations, and no contradiction exists.
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 extremely concise: three short sentences with zero fluff. The purpose is front-loaded ('Alternate cart inspect'), followed by the redaction note and read-only confirmation. Every sentence earns its place and the structure is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a simple read-only tool with two optional parameters and no output schema, the description covers the core intent and redaction behavior. However, it lacks parameter semantics and does not clarify when to use this tool over the primary rappi_get_cart. The 'alternate' hint is present but not elaborated, so an agent might not fully understand the trade-offs of using the web-gateway version.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. The parameters privacy_mode (summary/structured/raw) and response_format (markdown/json) are not explained anywhere in the description. The enums give some hint of variability, but the agent cannot determine what each mode returns or how they differ, leaving a significant 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?
The description clearly states the tool's purpose: 'Alternate cart inspect via web-gateway' – a specific verb (inspect), a specific resource (cart), and a distinguishing method (web-gateway) that separates it from the sibling rappi_get_cart. It also notes redaction of sensitive fields, which further clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Alternate' implies it's an alternative to a primary cart inspection tool, but it does not explicitly state when to prefer this over rappi_get_cart or any other sibling. It mentions redaction, which hints at use cases that require privacy, but not in a directive way. There is no explicit when-to-use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.