Rappi MCP (unofficial)
Server Quality Checklist
Latest release: v0.1.7
- Disambiguation1/5
Many tools have overlapping purposes: browse_catalog, search_stores, browse_stores, and home_feed all provide store/catalog browsing; get_order, track_order, get_order_eta, get_order_status, and get_order_receipt/invoice all serve order tracking/inspection. Additionally, web_cart and get_cart both retrieve cart contents. This high overlap makes it difficult for an agent to distinguish which tool to use.
Naming Consistency4/5All tools follow a consistent 'rappi_' prefix with snake_case, and most use a verb_noun pattern (e.g., get_order, create_address, place_order). Minor deviations exist like 'rappi_recent_searches' and 'rappi_connection_status' which are noun phrases, but overall the naming is predictable and uniform.
Tool Count2/5With 40 tools, the surface is excessively large for a single domain, even one as complex as Rappi. Many tools are highly redundant (e.g., multiple order status tools, multiple cart inspection tools). This volume overwhelms agents and increases selection errors, making it poorly scoped.
Completeness4/5The tool set covers the core domain comprehensively: catalog browsing, product search, cart management, order placement and tracking, addresses, payment methods, coupons, and even privacy/state inspection. Only minor gaps exist, such as lack of explicit order cancellation confirmation flows, but the coverage is robust.
Average 2.9/5 across 40 of 40 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the write nature is covered. The description adds the specific gating mechanism (RAPPI_ALLOW_MUTATIONS and explicit_user_intent), which is not in annotations, providing some behavioral context. However, it does not describe side effects, error handling, or what happens on invocation beyond the gate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one short line), which is efficient but under-specified. It prioritizes the gating constraint but omits essential details about the tool's purpose and parameters, so it is not properly structured for an agent to act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no output schema, and low parameter coverage, the description is severely incomplete. It fails to explain the operation, parameter purposes, return values, or error behavior. Without this, an agent cannot reliably invoke it correctly, especially given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only explicit_user_intent has a description). The tool description provides no parameter semantics whatsoever. With such low coverage, the description should compensate by explaining key parameters like product_id, quantity, or store_id, but it remains silent, leaving agents to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Gated write' with gating requirements, but never explicitly says it updates a cart item. The title and name imply the action, but the description itself is vague about the resource and verb. It distinguishes from siblings only by noting it's a write, which is insufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 like rappi_add_to_cart or rappi_get_cart. It does not mention scenarios, preconditions beyond gating, or exclusions. The gating requirement is a condition, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, which cover the safety profile. The description adds 'token present' (likely a check for authentication) and 'mutations off by default,' but these are partially redundant with the annotations and still vague. It does not disclose what the tool returns, how it behaves on success/failure, or any side effects. The description adds marginal value beyond 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it is not concise in a helpful way. It consists of three cryptic fragments that convey little clear meaning. It lacks a front-loaded, clear statement of purpose. The brevity is under-specification rather than efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description still leaves major gaps: it does not explain what kind of status information is returned, what 'local doctor' means, or how it relates to the many sibling tools. An agent would be uncertain about the tool's exact capabilities and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the only parameter (response_format) is optional with an enum and default, so the schema alone fully documents it. The description does not mention the parameter at all and adds no semantic context. Given the low coverage, the description should compensate, but it does not, so a score of 2 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is highly cryptic: 'Local doctor: token present, mutations off by default, unofficial consumer surface.' It never explicitly states that this tool checks the connection status or health of the Rappi integration. The title hints at 'connection status' but the description itself does not provide a clear verb+resource. The mention of 'token present' suggests a diagnostic check, but it's vague and not actionable for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings like rappi_capabilities or rappi_privacy_audit. The description does not mention any scenario, prerequisite, or alternative. It only gives obscure facts ('mutations off by default') without explaining how they relate to selection criteria. An agent has little basis to decide to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that explicit_user_intent is required and that the tool does not charge. These are useful behavioral notes beyond what annotations provide. Annotations already indicate destructiveHint and non-readOnly, so the description supplements with cost clarification. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and to the point, but it lacks substance. It is not structured to front-load the purpose; it merely presents two unrelated statements without a coherent flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters and no output schema, this description is grossly incomplete. It provides no information about return values, error handling, or required preconditions beyond explicit_user_intent. An agent cannot correctly invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only explicit_user_intent has a description). The tool description does not explain score, comment, order_id, or response_format. With low coverage, the description fails to compensate, leaving agents without parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Requires explicit_user_intent. Does not charge.' does not state what the tool does. It only mentions prerequisites and cost, not the action of rating an order. The purpose is implied by the name and title but not clearly articulated, making it vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives like rappi_tip_order or rappi_cancel_order. No context about typical scenarios, exclusions, or differentiation from siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and destructiveness (destructiveHint=true). The description adds the requirement for explicit user intent, which is already stated in the parameter schema, and clarifies that it does not place an order. However, it does not disclose the actual effect (changing the active address) or its reversibility, leaving a significant gap in behavioral understanding. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with each sentence serving a purpose. 'Requires explicit_user_intent' and 'Does not place an order' are both relevant, but they are insufficient for a complete definition. The brevity is acceptable but not balanced with necessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and many siblings, the description is severely incomplete. It lacks a clear statement of the tool's purpose, effect, when to use it, and parameter details. An agent would have to infer almost everything from the name and title, which is unrealistic in a complex environment with similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, with only explicit_user_intent having a description. The description mentions this requirement but adds nothing about address_id or response_format. It fails to compensate for the low schema coverage, leaving the meaning and format of key parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description never states the tool's actual function of setting the active address. It only mentions a usage requirement ('Requires explicit_user_intent') and a negation ('Does not place an order'). The name and title imply the purpose, but the description itself fails to clearly convey what the tool does, making it ambiguous for an agent without additional inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling address tools (create, update, delete, list). 'Requires explicit_user_intent' is a precondition, not a usage scenario. 'Does not place an order' distinguishes from order placement but not from other address-related actions. There is no mention of alternatives or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the gating requirements (RAPPI_ALLOW_MUTATIONS and explicit_user_intent) beyond the annotations, which is valuable context for a destructive operation. However, it does not describe the effect of clearing (e.g., emptying the cart) or other behavioral traits. Given the annotations already mark it destructive, this adds some but limited transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the key gating condition in a single sentence with no wasted words. The structure is effective and efficient, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits the core purpose of the tool. While the title hints at clearing the cart, the description should explicitly state that to ensure correct usage. It also does not mention outcomes or side effects, and with no output schema, the agent lacks a complete picture of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on any parameters. It references explicit_user_intent but adds no meaning beyond the schema's own description. The response_format parameter remains undocumented in both schema and description (schema coverage is only 50%), and the description fails to compensate, so agents get no additional parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only labels the tool as a 'Gated write' and does not explicitly state that it clears the cart. The action is inferred from the tool name and title, but the description itself lacks a clear verb+resource statement, making it ambiguous for an agent that relies on the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like rappi_update_cart_item or rappi_get_cart. The description only mentions a gating prerequisite, not usage context, scenarios, or exclusions, leaving the agent without direction on selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description merely repeats that with 'Read-only' and 'Does not add to cart.' No additional behavioral context is provided—nothing about response format, limits, privacy_mode behavior, or potential side effects. Since annotations already cover the safety profile, the description adds little beyond what is already structured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three short sentences), which is concise, but it is under-specified rather than efficiently informative. It fails to earn its sentences by adding only redundant read-only information. While not verbose, the brevity is at the cost of essential operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six optional parameters, no schema descriptions, no output schema, and no examples, the description is severely incomplete. It does not explain what the tool returns, how parameters influence the search, how privacy_mode or response_format behave, or any usage nuances. An agent has almost no information to call this tool correctly beyond the schema's bare field types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. However, the description mentions none of the six parameters (query, limit, latitude, longitude, privacy_mode, response_format). It gives no meaning to any of them, leaving the agent completely dependent on the schema, which also lacks descriptions. This is a major gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Search products near a point') and distinguishes itself from cart-modifying tools by stating 'Does not add to cart.' It is not a tautology and gives a clear, specific purpose, though it does not explicitly name alternative search tools like browse_catalog or search_stores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool versus alternatives. It notes the tool is read-only and does not add to cart, which implies safe usage, but it does not explicitly state conditions for choosing this tool over siblings like rappi_browse_catalog or rappi_search_stores. No when-not-to-use or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false, so the write nature is known. The description adds the gating requirement (RAPPI_ALLOW_MUTATIONS and explicit_user_intent) and states it does not checkout, which provides additional context. However, it doesn't reveal other side effects (e.g., whether it replaces existing cart items) or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences and contains no fluff. It avoids wordiness and is short, but the content is too sparse to fully inform. For conciseness alone, it earns a high mark, though the structure could be improved by front-loading the actual action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with 5 parameters and no output schema, the description omits crucial context: what the operation does, when it should be used, and what responses to expect. It doesn't even state it adds to cart, nor does it explain how it relates to other cart operations, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only explicit_user_intent has a description). The description itself provides no parameter details, leaving product_id, quantity, store_id, and response_format unexplained. With low schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Gated write' but never states that the tool adds a product to the cart. The title 'Add to Rappi cart' suggests the action, but the description itself is vague and does not clearly specify the operation (e.g., 'Adds a product to the cart'). It only mentions it does not checkout, which is a distinction but not a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states preconditions (RAPPI_ALLOW_MUTATIONS=true, explicit_user_intent=true) and clarifies it does not checkout, but it does not guide when to use this tool over siblings like rappi_update_cart_item, rappi_reorder, or rappi_place_order. No explicit reasoning for choosing this tool is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats 'Read-only', which is already declared by readOnlyHint=true, and adds nothing else about behavior. It does not disclose output format, pagination, or any side effects beyond what annotations already cover. The 'Optional lat/lng' is parameter-related, not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with no redundant sentences. However, the cryptic phrase 'restaurant-bus' is confusing and detracts from clarity, though it does not make the text verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no parameter descriptions in the schema, no output schema, and many sibling tools, the description is severely incomplete. It gives only a basic idea of the tool's function and fails to explain how parameters affect results, how to control privacy_mode, or what the output looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 only explains the optional lat/lng parameters, while limit, query, privacy_mode, and response_format are left undocumented. This partial coverage does not sufficiently aid an agent in using the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Browse') and a resource ('store catalog'), but 'Nearby' and 'restaurant-bus' are vague and do not clearly differentiate from sibling tools like rappi_browse_stores. The purpose is understandable but not specific enough to distinguish it from similar browsing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Nearby' and 'Optional lat/lng', implying it is for location-based browsing, but it provides no explicit guidance on when to use this tool over alternatives such as search_stores or browse_stores. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description merely repeats 'Read-only' without adding new context. No additional behavioral traits (e.g., rate limits, response behavior, authentication needs) are disclosed. The description is consistent with annotations but adds no value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the main action, which is efficient. However, it is under-specified for the tool's complexity; a 3-parameter tool with two enum-based options warrants more detail than just 'Track one order'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (one required, two with enums) and no output schema, the description is too bare. It fails to explain the privacy_mode and response_format options, and it doesn't clarify how this tool differs from closely named siblings. An agent would struggle to invoke it correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 the lack of parameter documentation. However, it does not explain any of the three parameters except implicitly referencing order_id via 'by id'. privacy_mode and response_format are completely undocumented in both schema and description, making it impossible to know how to use them as intended.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Track') and resource ('one order by id'), which is specific. However, it does not differentiate from siblings like rappi_track_order or rappi_get_order_status, so it misses the top score for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or contrast with sibling tools, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the 'logged-in consumer' context, which implies authentication requirements, and repeats 'read-only' which is already covered by readOnlyHint. However, it does not disclose return format, pagination, or any data structure. Since annotations already provide strong safety hints (readOnly, idempotent, openWorld), the description adds minimal but non-contradictory value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It front-loads the core idea ('web home') and safety property ('read-only'). It is appropriately sized for the information conveyed, though it is short to the point of being minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is severely incomplete for a tool with two parameters and no output schema. It does not explain what the home page contains, how parameters affect the results, or what the agent should expect in return. Without additional context, the agent cannot reliably use this tool or interpret its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description completely omits any explanation of the two parameters, privacy_mode and response_format. The enum values give some inherent guidance, but the lack of descriptions or examples leaves the agent to guess their exact impact. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as the web home for a logged-in consumer and explicitly states it is read-only. This conveys a general resource but lacks a specific verb or detailed functionality. It does not differentiate from sibling tools like rappi_home_feed or rappi_browse_stores, so the purpose is clear only at a high level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of typical use cases, exclusions, or preferred scenarios. The agent is left without any direction to select this tool over rappi_home_feed or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's 'Read-only' is redundant. The 'in-flight / active' context adds a minimal behavioral nuance, but the 'unofficial user-order-home' phrase is unexplained and provides little additional transparency beyond 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), so it is concise, but it is not front-loaded with the most critical information. The cryptic 'unofficial user-order-home' consumes space without adding clarity, making it less effective than a clearer structured sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% parameter descriptions, the description should explain what the returned list contains, the meaning of the parameters, and any relevant behavior. It only vaguely says 'in-flight / active orders,' leaving the agent to guess the structure, format options, and exact semantics. Incomplete for a tool with optional enum parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the two parameters (privacy_mode, response_format) at all. With no descriptions in the schema or text, the agent receives no explanation of how these enums affect the call, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly indicate a 'list' operation for 'active orders', but the added phrase 'in-progress (unofficial user-order-home)' is cryptic and does not clarify the exact scope or how it differs from rappi_list_orders or rappi_get_order. The verb and resource are identifiable, but the description adds confusion rather than precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like rappi_list_orders, rappi_get_order, or rappi_track_order. There is no mention of context or exclusions, leaving the agent to infer when this specific list is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint false, and the description repeats 'Read-only' and adds 'Does not apply a coupon,' which is redundant. It adds only the vague context of 'unofficial user-order-home' without disclosing additional traits like authentication, rate limits, or failure behaviors. The description adds minimal behavioral value beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the purpose, which is efficient. However, it repeats 'Read-only' which is already in the annotations, so some redundancy exists. It is not poorly structured but is more minimal than fully structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with two optional parameters and no output schema, the description lacks any explanation of the parameters, expected return format, or how the 'unofficial user-order-home' source affects results. It is under-specified for an agent to know how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the properties privacy_mode and response_format have no descriptions in the schema, and the tool description does not mention them at all. An agent has no guidance on what these parameters control or how to set them, making this a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (wallet coupons) and clearly states it is a read-only operation that does not apply a coupon, which distinguishes it from coupon-related actions. Though the verb 'list' is not explicitly stated, the tool name and the context make the purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for viewing coupons without applying them, but it provides no explicit guidance on when to use this versus alternatives. No exclusions, prerequisites, or alternative tools are mentioned, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the 'Requires explicit_user_intent' constraint, which is a behavioral requirement beyond what annotations already declare (destructiveHint=true). However, it does not elaborate on what the update entails, side effects, or any other behavioral traits, so the added transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence), but this brevity constitutes under-specification rather than effective conciseness. It omits essential usage and parameter information, making it a placeholder rather than a well-structured definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, a destructive action, and no output schema, the description is severely incomplete. An agent cannot infer what fields to populate, valid values, or the expected response. The only required field (address_id) is in the schema, but the rest is undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8% (only explicit_user_intent has a description), and the tool description provides no parameter-level detail for the 12 parameters. Fields like street, city, latitude, active, etc., remain entirely undocumented, so the description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Update') and the resource ('a saved address') clearly. However, it does not differentiate this tool from siblings like rappi_create_address or rappi_set_active_address, so while the purpose is unambiguous, it lacks distinguishing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The only directive, 'Requires explicit_user_intent,' is a prerequisite rather than a usage guideline, and no information about when not to use the tool or which sibling to prefer is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's 'Read-only' adds no new information. It adds 'Web-gateway' as a mild behavioral hint about access method, but doesn't disclose return format, pagination, or other traits. Given annotations cover safety, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is terse and easy to read, but it's under-specified rather than efficiently concise. It lacks any structured breakdown of what the tool returns or how to use it, so it doesn't earn high marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and undocumented parameters, the description should explain what the agent will get back and how to control output. It does neither, leaving significant gaps for a browse operation that should clarify its data format and privacy options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of privacy_mode or response_format parameters. The agent must infer meaning solely from enum values (summary/structured/raw, markdown/json), which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('browse stores') and resource, and explicitly differentiates itself from rappi_search_stores by calling itself a complement. However, 'web-gateway' is vague and doesn't clarify what kind of store list this returns or how it differs from other browsing tools like browse_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It only says 'Complements rappi_search_stores,' which gives a hint of relationship but no explicit when-to-use or when-not guidance. There is no mention of alternatives like browse_catalog or conditions that would favor this tool over search_stores.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds the explicit 'Read-only' label, which is consistent but redundant. It doesn't describe the actual response shape, data freshness, or any caveats about the status surface. Since annotations cover the safety profile well, the description provides minimal additional behavioral context, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short ('Courier/order-status surface for one order. Read-only.'), which makes it easy to parse. However, it is too terse to be truly informative. 'Surface' is an awkward term that may confuse. It's concise but sacrifices necessary detail. A balanced description would be slightly longer but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and zero schema description coverage. The description provides only the most basic idea—that it returns order status for one order. It does not explain what data is returned, how to set privacy_mode or response_format, or any constraints like authentication. An agent would not know how to correctly invoke it beyond passing an order_id. This is inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (order_id, privacy_mode, response_format) are explained in the schema. The description does not mention any parameter names or their meaning. It gives no hint about what 'privacy_mode' options (summary, structured, raw) do or how response_format affects output. With zero schema coverage, the description must compensate, and it fails to do so entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: it's a courier/order-status surface for one order. The verb 'get' is implied from the tool name, and 'status' is specific enough. It distinguishes from list-type tools like rappi_list_orders by saying 'for one order', though it does not explicitly differentiate from other order-specific tools like rappi_get_order or rappi_track_order. Still, the resource and scope are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It says 'for one order' but doesn't explain how this differs from rappi_get_order, rappi_track_order, or rappi_get_order_eta. There is no mention of when not to use it or what conditions would favor a sibling tool. The agent is left to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats that the operation is read-only, which is already covered by annotations (readOnlyHint=true, destructiveHint=false). It adds no additional context about response formats, error behavior, or the implications of 'unofficial' backend. Given annotations already disclose the safety profile, the description adds minimal value but does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, comprising two short clauses with no fluff. The core purpose is front-loaded. However, it is so brief that it omits crucial details about parameters and usage, making it under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, 0% schema coverage, and no output schema, the description is insufficient. It does not clarify parameter meanings, expected return values, or how it fits among store-related siblings. An agent cannot reliably invoke this tool without external knowledge or guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters. While store_id is intuitive, privacy_mode and response_format are enums that would benefit from explanation, and none is provided. The description fails to compensate for the lack of schema descriptions, leaving parameter semantics entirely to the schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose as retrieving a store's catalog/detail, with a specific endpoint reference. It distinguishes from sibling tools like browse_stores or search_stores by focusing on a single store ID, though it does not explicitly name differences. The verb 'get' and resource 'store' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browse_stores, search_stores, or browse_catalog. It does not state that this is for fetching a specific store by ID or mention any prerequisites. The agent must infer context from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the 'Read-only' text is redundant. The description adds minimal context (tracking summaries) but doesn't disclose output format, pagination, rate limits, or privacy implications. Since annotations cover safety, the bar is lower, but the description adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that gets to the point immediately. It is concise and free of fluff. However, its brevity comes at the cost of missing essential details, which is a structural tradeoff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and two undocumented parameters, the description is incomplete. It doesn't specify what the list contains beyond 'tracking summaries', nor how privacy_mode affects output. It also lacks guidance on selecting this among many order-related siblings. Overall, it leaves too much open for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for explaining parameters. It fails to explain privacy_mode (summary/structured/raw) or response_format (markdown/json), leaving agents to guess their meaning. The description doesn't even mention that parameters exist, so it provides zero semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List recent personal orders / tracking summaries' clearly states the verb (list), resource (personal orders), and scope (recent). It also hints at output content (tracking summaries), distinguishing it from sibling tools like rappi_list_active_orders. However, it does not explicitly differentiate from other order-related tools, so it's clear but not fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. While 'recent personal orders' implies a historical scope, it doesn't explain when to prefer this over rappi_list_active_orders, rappi_get_order, or rappi_track_order. There is no mention of exclusions or contextual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description repeats 'read-only' but adds no additional behavioral context. It does not disclose variabilities like location-dependent results, privacy_mode effects, or response format nuances. Given the annotations cover the core safety profile, the description contributes almost nothing beyond what is already structured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is incredibly concise: 'Recent/top searches near a point. Read-only.' It is two short sentences with no fluff, and the main purpose is front-loaded. While it may be under-specifying, that is a completeness issue, not a conciseness one. For what it says, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters and no output schema, this description is far too sparse. It does not explain what privacy_mode does, what each enum value means, how location impacts results, or what the response contains. Correct invocation is uncertain, especially the 'summary', 'structured', and 'raw' modes. The description fails to provide the necessary context for an agent to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for any parameters, and the description does not compensate at all. It never mentions latitude, longitude, privacy_mode, or response_format. The enum values for privacy_mode (summary, structured, raw) are completely unexplained, leaving the agent without any clue as to what each mode returns. This is a severe gap given the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Recent/top searches near a point. Read-only.' This clearly identifies the resource (recent/top searches) and the location context (near a point). It is distinct from sibling search tools like rappi_search_stores and rappi_search_products because it retrieves past searches rather than performing active searches. However, it lacks specificity about whose searches or what 'top' means, which holds it back from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, exclusions, or scenarios where another tool (e.g., rappi_search_stores) would be more appropriate. The agent is left to infer usage purely from the general purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description only repeats 'Read-only,' adding no new behavioral context such as what happens for invalid order IDs, rate limits, or response handling. It adds negligible value beyond 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences with no filler. It front-loads the core purpose ('ETA for one order') and the safety qualifier ('Read-only'). While it is appropriately brief, it sacrifices detail for brevity, which is still acceptable for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and the schema has zero property descriptions, the description should explain more. It only covers the basic purpose and read-only nature, but fails to describe parameter usage, expected inputs, or what the ETA represents. An agent would likely need to infer parameter values from the enum names alone, which is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description says nothing about the three parameters (order_id, privacy_mode, response_format). It does not explain what values are acceptable for privacy_mode or response_format, nor does it clarify that order_id is required. The description does not compensate for the schema's lack of descriptions, leaving the agent to guess parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'ETA for one order,' which clearly identifies the resource (order ETA) and the action (get). It is unambiguous and the tool name reinforces it. However, it does not explicitly distinguish it from siblings like rappi_track_order or rappi_get_order_status, so it falls 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Read-only' signals that this is a safe query operation and implies it is used when the agent needs an ETA. But it provides no explicit guidance on when to prefer this over alternative order-related tools (e.g., rappi_get_order, rappi_track_order), nor any exclusions or context about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it explains which writes stay gated, providing context about the tool's purpose. It does not contradict annotations, and it adds a small amount of behavioral context beyond 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. It front-loads the core purpose without unnecessary detail. However, it is so terse that it might under-specify, but it earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description should clarify what the tool returns or how to interpret its output. It only states the general topic (read/write capabilities) but does not describe the format, list of capabilities, or any response details. This is incomplete for an agent needing to act on the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 guidance. The sole parameter `response_format` is documented only via its enum values and default in the schema, and the description does not mention it at all. No meaning is added beyond what the schema already provides, and the low coverage is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose: it reports what the MCP can read and which writes are gated. This clearly distinguishes it from the sibling tools, which are all specific operations like browsing catalogs or placing orders. It could be more explicit about the output (e.g., returning a list of capabilities), but the intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for understanding the MCP's read/write capabilities, which is useful for an agent deciding whether to perform operations. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the agent knows it's safe. The description adds 'Does not charge' and 'Read-only', which reinforces the annotations but adds little beyond them. It doesn't describe whether the preview reflects the current cart state, or whether it requires an active cart. Given the strong annotations, the description adds marginal value, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is good for token efficiency, but it is under-specification rather than conciseness. Each word earns its place ('Totals preview. Does not charge. Read-only.'), and the key safety property is front-loaded. However, a few more words on parameters would not hurt.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 0% schema coverage, and no output schema, the description is incomplete. The agent does not know what the output will look like, whether the preview is for the current cart or a specific checkout, or how the privacy_mode and response_format affect results. The annotations cover safety, but not operational details. This is a moderately complex tool that needs more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for explaining parameters. It fails entirely. The tool takes address_id, payment_method_id, privacy_mode, and response_format, but the description mentions none of them. The agent must guess what address_id and payment_method_id mean, and which arguments are optional. There is no default behavior explained. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Preview') and resource ('Rappi checkout'), which is clear enough to distinguish it from order-related tools like get_order or track_order. It could be more explicit that it previews the checkout totals for the current cart, but the title and description align well. It doesn't name a sibling, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It doesn't mention that it should be called before placing an order, or that it's useful for confirming prices. There is no mention of when not to use it (e.g., not for actual purchase). Sibling tools like place_order or get_cart are not referenced. The agent is left to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds value by highlighting the explicit_user_intent consent gate, signaling this harmful action must not be invoked without direct user request. It does not contradict the annotations — 'Delete' aligns with destructiveHint=true. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences with no filler — each carries meaning: one states the purpose, one states the consent requirement. Appropriately sized for a simple destructive tool. The consent requirement is positioned second rather than first, which for a destructive action is a minor front-loading nit, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 and low param coverage, the description is thin. It omits what happens on success, whether deleting the active address has side effects, and any constraints (e.g., cannot delete a default address). An agent only learns the core action and consent gate but not the consequences of the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (below the 50% threshold), so the description should compensate for the undocumented parameters. It does not explain address_id or response_format at all; it only re-emphasizes explicit_user_intent, which the schema already documents. address_id is self-explanatory by name, but response_format's behavior (markdown vs json output) is left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('a saved address'). It clearly separates this from its siblings create_address, update_address, and set_active_address by the delete verb alone. The title 'Delete Rappi address' is nearly identical, but the description adds the word 'saved', implying it acts on stored addresses rather than transient ones, giving slight extra meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 in the sibling set (update_address, set_active_address). It doesn't state prerequisites such as whether the address must not be the active one, or when deletion is appropriate versus editing. The only usage signal is the consent requirement, which speaks to authorization, not selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does 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 'Identity redacted by default,' a behavioral trait not captured in annotations, and reaffirms 'Read-only' consistently. This provides useful context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using two short sentences. It front-loads the core purpose and includes the redaction note efficiently. While it could be longer to convey more detail, it avoids unnecessary verbosity for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with no schema descriptions and no output schema, the description is too sparse. It does not explain what the receipt contains, how privacy_mode affects output, or what response_format options do. An agent calling this tool would lack critical information about expected behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does not mention order_id, privacy_mode, or response_format. The only hint is 'Identity redacted by default,' which implicitly relates to privacy_mode but is insufficient. An agent cannot determine how to use these parameters correctly from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: 'Receipt for one order.' This clearly identifies the tool as retrieving a receipt for a given order. It is not a tautology and adds the useful detail of identity redaction. However, it does not explicitly differentiate from siblings like rappi_get_order_invoice, so it misses the full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as rappi_get_order_invoice or rappi_get_order_status. The description does not mention selection criteria or contrast with other receipt/order tools. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints, so the description's 'Read-only.' is redundant. The addition of 'dynamic' suggests content can change between calls, which is a useful behavioral trait, but it is too vague to inform expectations (e.g., caching, rate limits, or response variability). With the safety profile covered by annotations, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only a few words plus a standalone 'Read-only.' It is front-loaded with the resource name and no filler. However, extreme brevity may under-specify for a tool with two parameters, though that is penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, two optional parameters, and many sibling tools, the description is far too thin. It fails to clarify what the home feed contains, how it relates to other navigational tools, or what the return format looks like. The agent would struggle to use this tool appropriately beyond a basic fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 provides none. 'privacy_mode' has enum values (summary, structured, raw) that are not explained, and 'response_format' is partially self-explanatory (markdown/json). The agent cannot infer semantics of privacy modes or how they affect the output from the description or schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('home feed') and signals it is dynamic and read-only, which is clear. However, it does not differentiate from sibling tools like rappi_home or rappi_browse_stores, and the 'web-gateway' qualifier adds little clarity. Not a tautology, but lacks uniqueness among many similar browsing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The read-only hint implies a retrieval use case, but no explicit exclusions or comparisons to other feed/browsing tools. Agents are left to infer, which falls short of the many siblings present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it states that the tool charges money, is fail-closed, requires a non-guest token, and never runs in default read-only mode. These are specific safety and operational traits not fully captured by the annotations (readOnlyHint:false, destructiveHint:true). It exceeds the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the most critical safety information (fail-closed, charges money). It avoids fluff, but the lack of a purpose statement makes it efficient yet incomplete in coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no output schema, and low parameter documentation, the description is incomplete. It does not explain the order placement flow, required parameters, possible return states, or error conditions. The safety prerequisites are covered, but operational completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, and the description does not compensate. It only indirectly references explicit_user_intent (via the requirement) but offers no explanation of address_id, payment_method_id, store_id, notes, or response_format. The description fails to clarify what these parameters mean or how they relate to placing an order.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description focuses on constraints (fail-closed, charges money) rather than stating the action explicitly. It implies 'place an order' through the tool name but does not state a clear verb+resource in the description itself. It is not a tautology, but a direct statement of purpose is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No mention of when to use this tool versus siblings like checkout_preview or add_to_cart. The description explains prerequisites (mutation flag, user intent, personal token) but not the contextual triggers. This leaves the agent without guidance on selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the trailing 'Read-only' just restates structured data. The description does add slight value beyond annotations: the 'unofficial' qualifier signals reliability caveats and 'live' implies a real-time-returning behavior rather than a static fetch. It does not explain what the live tracking returns or how it degrades.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with information front-loaded and zero filler words. It is concise, though the brevity stems partly from under-specification rather than efficient completeness, since it omits sibling differentiation that would earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 38 siblings including overlapping ETA/status tools and no output schema, the description should clarify its unique niche and its return behavior. It does not explain how 'live tracking' differs from the one-shot rappi_get_order_eta, nor what the returned data looks like, leaving an agent guessing about when this tool applies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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; it does not mention any parameter. The enums self-document two of three params (summary/structured/raw and markdown/json values are self-explanatory), and order_id is self-evident from context, but the description adds nothing about what privacy_mode changes or what each response_format produces.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource ('Live tracking / ETA for one order') and adds a useful scoping qualifier ('unofficial user-order-home tracking'). However, it does not distinguish itself from the near-twin sibling rappi_get_order_eta, whose name and purpose overlap heavily, so an agent cannot confidently choose between the two without opening both schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. Given 38 siblings including several ETA/status tools (rappi_get_order_eta, rappi_get_order_status, rappi_get_order), the description offers no conditions for preferring this tool, no exclusions, and names no alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description's 'Read-only' adds nothing new. It does add the 'unofficial' caveat and 'nearby' scope, which are useful, but it omits other behaviors like rate limits, pagination, or error handling. The description is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no filler. It front-loads the core purpose and immediately covers the crucial location parameters, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with six optional parameters and no output schema. It lacks explanation of privacy_mode, response_format, query behavior, and limits, and it does not differentiate from closely related tools. An agent would have to guess or inspect schemas to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only explains the optional lat/lng and the RAPPI_LAT/RAPPI_LNG fallback. It leaves limit, query, privacy_mode, and response_format completely unexplained. For a tool with six parameters, this is inadequate compensation for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses nearby stores on the unofficial Rappi consumer surface, with optional location parameters. However, it does not explicitly differentiate from the sibling rappi_browse_stores, and the title says 'Search' while the description says 'Browse', which is mildly inconsistent. Overall, the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives like rappi_browse_stores or rappi_search_products. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description correctly implies a write operation. It adds the behavioral requirement for explicit_user_intent, which is not fully captured by the annotations alone (though the parameter exists). It does not mention idempotency (annotations say false) or what happens on success/failure, but the description is consistent and adds some useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the primary action and then add critical caveats. There is no redundant phrasing or fluff. Every word contributes to clarity, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with 10 parameters and no output schema, the description is incomplete. It does not explain the required inputs (latitude, longitude, address) or how the saved address will be used (e.g., as a delivery location for future orders). It also lacks information about return values or side effects beyond saving. While it correctly notes that it does not place an order, an agent still lacks enough context to confidently invoke the tool with valid parameter values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 10%, with just explicit_user_intent explained. The description does not clarify the meaning of latitude, longitude, address, or any optional fields like tag, city, number, etc. It simply says 'delivery address', which is vague. With 10 parameters and minimal schema help, the description fails to compensate, leaving agents uncertain about what each parameter represents and how they combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'save' and the resource 'delivery address', which is specific and aligns with the tool's name. It also adds 'Does not place an order' to distinguish it from order-related tools, but it does not explicitly differentiate from address update or delete operations, which are siblings. The purpose is clear enough for an agent to understand the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage condition: 'Requires explicit_user_intent', indicating it should only be used when the user explicitly requests an address save. It also clarifies a non-goal: 'Does not place an order', preventing misuse. However, it does not mention when to use this over rappi_update_address or rappi_delete_address, leaving the agent to infer from the name. This is partial but not comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which the description redundantly restates with 'Read-only'. However, it adds the important behavioral detail that identity is redacted by default, which is not captured in structured data. This gives agents a key privacy-related expectation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero fluff. The core purpose and the default privacy behavior are presented first, and every word serves a purpose. It is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters (two enums), no output schema, and no parameter descriptions, the description is far too sparse. It does not explain what privacy_mode values do, what response_format affects, or what the returned invoice contains. Agents will struggle to call this correctly with only the given text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the three parameters (order_id, privacy_mode, response_format). It does not mention any of them, leaving agents to infer from the schema enum names alone. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Invoice for one order' clearly indicates the tool retrieves an invoice for a single order, which distinguishes it from siblings like get_order_receipt and get_order_status. However, it lacks an explicit verb like 'retrieve' or 'get', though the name itself implies the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_order_receipt or get_order. There is no mention of prerequisites, exclusions, or context preferring this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the charge behavior is partly carried. The description adds real value beyond annotations: the FAIL-CLOSED semantics (defaults to refusing unless explicit conditions met), the personal-token auth requirement, and reinforcement that explicit_user_intent must be true. This is context the structured fields cannot express. No contradiction with annotations — destructiveHint=true aligns with "Charges a tip."
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight fragments — "FAIL-CLOSED. Charges a tip. Requires mutations, explicit_user_intent, and a personal token." — with the most critical behavioral warning (fail-closed) front-loaded. Every element earns its place; there is no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, money-moving mutation with no output schema, the description under-delivers. It does not state what happens on success or failure, whether the tip is the final charge, or how errors surface. With two of four params undocumented in both schema and description, an agent lacks enough to safely invoke a financial write end-to-end.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (one of four params documented), so the description must compensate but does not. It never explains the meaning of tip (currency? inclusive?), order_id, or response_format. The only parameter value added is "Requires explicit_user_intent," reinforcing the schema's own documentation of that field. With a low-coverage schema and a monetary amount parameter, this is a genuine gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb plus resource — "Charges a tip" — which unambiguously names the action and target. It is clearly distinct from siblings like rappi_rate_order, rappi_cancel_order, and rappi_place_order, though it never names them explicitly. The leading "FAIL-CLOSED" is a behavioral note rather than a purpose statement, so the purpose itself is clear but not differentiated by reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives prerequisite conditions (requires mutations, explicit_user_intent, personal token) which inform when the tool can be invoked, but it provides no guidance on when to prefer this tool over alternatives and no exclusions. Nothing tells the agent to use rappi_rate_order or rappi_get_order instead in any scenario. Prerequisites are useful, but active tool-selection guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true. The description adds valuable behavioral context beyond annotations: 'May refund' (consequence) and 'Guest tokens rejected' (auth requirement). These are not present in the annotations, so the description contributes meaningfully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short fragments, each carrying distinct info: gating, refund, mutations/intent, guest token rejection. It's front-loaded with the 'Gated' caveat and has no fluff. Efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple cancellation tool, the description covers gating, refund, and auth, but omits operational details such as when an order is cancellable (e.g., status limits), what the response/result format looks like (no output schema), and potential error cases. The destructive nature is covered by annotation, but the description lacks enough to handle real-world invocation nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% – only explicit_user_intent has a description. The description reinforces that parameter ('Requires ... explicit_user_intent') but adds nothing about order_id or response_format. With low schema coverage, the description fails to compensate for the undocumented parameters, leaving the agent to infer order_id and response_format meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The name 'rappi_cancel_order' and title 'Cancel Rappi order' clearly indicate verb+resource. The description adds 'May refund' which gives a hint of the effect, but doesn't explicitly state 'Cancels an order' — it's implied. It distinguishes from read-only order tools like get_order and track_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives preconditions ('Requires mutations and explicit_user_intent', 'Guest tokens rejected') but does not explicitly say when to use this tool vs alternatives. Since cancellation is unique among siblings, the context is clear from the name, but the description lacks explicit 'use when' guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false. The description adds valuable context beyond these: the operation is gated by a global flag and user intent, guest tokens are rejected (an authentication restriction), and it explicitly states 'Does not charge' to clarify the side effect. This gives an agent important preconditions and avoids misinterpretation about charging.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, with only four short statements: 'Gated payment write', the gating conditions, guest rejection, and 'Does not charge'. Each sentence carries distinct information, there is no fluff, and the most important classification is front-loaded. It is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters (one required ID) and no output schema, the description leaves significant gaps: it never explains what payment_method_id refers to (e.g., that it should come from rappi_list_payment_methods), what a successful call returns, or whether it affects the current order/cart. The safety and gating info is helpful, but missing operational context makes it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% – only explicit_user_intent has a description. The description reinforces explicit_user_intent by naming it in the gating condition, but it adds no explanation for payment_method_id (what it should be or where to obtain it) or response_format (how it affects output). With low schema coverage, the description should compensate, but it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description labels the operation as a 'Gated payment write' and clarifies 'Does not charge', which combined with the title 'Select Rappi payment method' makes it clear the tool sets a payment method without charging. It implicitly distinguishes from read-only siblings like rappi_list_payment_methods by emphasizing it is a write operation, but it doesn't use an explicit verb like 'select' or 'set' in the description itself, relying on the title for that specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage constraints: requires RAPPI_ALLOW_MUTATIONS flag and explicit_user_intent=true, and rejects guest tokens. This tells an agent when it can be called, but it doesn't mention alternative tools or when not to use it (e.g., to view payment methods, use rappi_list_payment_methods; to finalize order, use rappi_place_order). The guidance is conditional but not comparative, leaving out any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, establishing the safe read-only nature. The description adds unique behavioral information about redaction of street, phone, and email in the default privacy mode, which is not captured elsewhere and useful for output expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the primary function is front-loaded, and the redaction note adds critical detail in the second sentence. It is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, a complete description should clarify the structure of returned addresses (e.g., IDs, labels) and how privacy_mode affects the response. The description only covers redaction, leaving other output aspects unspecified, so it is adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'default privacy mode' but does not explain the enum values (summary, structured, raw) for privacy_mode or the response_format choices. This gives only a partial hint, leaving meaning mostly to the agent's inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List saved delivery addresses', a specific verb and resource that distinguishes it from sibling tools focused on creating, updating, deleting, or setting addresses. The redaction note also clarifies the output scope without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context on when to use this tool versus alternatives like rappi_create_address or rappi_set_active_address. It only states what it does, leaving the agent to infer use cases, which is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description is consistent. It adds the specific behaviors ('checkout is off unless both gates are set') which is useful context beyond the annotations, but it does not disclose further side effects or edge cases. Given the strong annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that front-loads the purpose. No filler, no repetition of schema or annotations. Every word contributes to conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the essential behavioral outcome. It could elaborate on what 'both gates' refers to, but the overall context is sufficient for an agent to invoke it correctly. The lack of output schema makes the description's indication of what it shows more important, and it does that well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (the parameter `response_format` has no description in the schema). The description does not mention the parameter at all, so it fails to compensate for the low schema coverage. However, the parameter is trivial with an enum and default, so the lack of explanation is a minor gap; still, the description adds zero value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Shows') and names concrete resources (redaction defaults, token path, checkout gating) — clearly distinct from all sibling tools, which are primarily transactional (cart, orders, search). It's not a tautology and an agent can immediately understand the tool's output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (if you need to inspect privacy/audit state, call this) but does not explicitly state when to use it over alternatives or exclude other tools. There are no competing audit-like siblings, so it's acceptable, but it offers no explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, lowering the bar. The description adds genuinely useful behavioral context beyond the annotations: that street/phone/email/last-four are redacted by default. This informs the agent about output-shaped behavior and does not contradict the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. Purpose is front-loaded, followed by one behavioral note. Every word earns its place, and nothing is redundant with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only inspection tool with a full annotation safety profile and self-descriptive enum parameters, the description is nearly complete. It discloses the default redaction behavior, which is the main thing an agent needs to anticipate output shape. No output schema exists, but the tool is simple enough that this isn't a material gap; a note on what fields the cart contains would push it higher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries burden for explaining parameters. However, both parameters (privacy_mode, response_format) are self-documenting enums that convey their meaning via names and values. The redaction sentence hints at privacy_mode's purpose but doesn't explicitly map it to the summary/structured/raw values. The description adds value but doesn't fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and a specific resource ('the current personal cart'), making the read-only intent clear. The word 'personal' helps distinguish it from the sibling rappi_web_cart, though the sibling is not named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current personal cart' implies this is for inspecting the active session's cart rather than the web cart or cart mutations, but no explicit when-to-use or when-not-to-use guidance is given. It does not name alternatives or exclusion criteria, so the agent must infer when to pick this over rappi_web_cart or cart items tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does 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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters2/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc., but the description adds 'unofficial' (implying potential instability) and 'Street redacted by default' (privacy behavior). These go beyond annotations and give the agent useful expectations about the data source and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The purpose is front-loaded, and the read-only and redaction details are placed concisely. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description is too sparse. It doesn't explain the privacy modes, the response structure, or how response_format affects output. The agent is left without enough information to call the tool correctly beyond basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain any of the parameters (latitude, longitude, privacy_mode, response_format). It mentions redaction but not what privacy_mode or response_format do, so the description fails to compensate for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Resolve') and resource ('unofficial users-address/address'), clearly distinguishing it from sibling tools like list_addresses or create_address. It also notes read-only and redaction behavior, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (resolve lat/lng to address) and mentions read-only and redaction, which provide context. However, it does not explicitly name alternatives or when not to use it, but given it is the only geocoding tool, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's job is lighter. It adds two concrete behavioral facts beyond annotations: 'Last-four and identity redacted by default' and 'Does not charge.' These are useful and not redundant with 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose. Every word adds value; no fluff. The redaction and 'no charge' notes are the next most important facts and are placed immediately after.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with no required parameters and no output schema, the description covers the core behavior (read, redact, no charge) but omits how the parameters alter the output (e.g., what 'summary' vs 'raw' privacy_mode produces, or how markdown vs json formats differ). Since the parameters are the only way to customize the tool, this missing context is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters' purpose, but it doesn't mention privacy_mode or response_format at all. The schema only provides enum values, leaving the agent to guess their impact on output. This is a significant gap for a tool with two optional parameters that clearly affect the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Read') on a specific resource ('saved payment methods') and adds two distinguishing details: redaction defaults and 'Does not charge.' This clearly separates it from sibling tools like rappi_list_orders or rappi_list_addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose obvious: it lists payment methods. While it doesn't explicitly mention when to avoid it (e.g., for setting a payment method, use rappi_set_payment_method), the clarity of the resource and the context of sibling names make the usage scenario straightforward. There are no explicit exclusions but also no misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false; the description confirms the destructive scope by naming the local token file as the target. It adds genuine value beyond annotations by disclosing that the tool bypasses RAPPI_ALLOW_MUTATIONS, which signals the agent that explicit_user_intent is the only safeguard. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler; the core action is front-loaded and the gating caveat is disclosed last. Every sentence earns its place, though the same intent caveat appears both in the description and the schema, a slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logout tool, the description covers the action, the safety precondition, and the gating exception. The schema documents both parameters (response_format via enum, explicit_user_intent via description), and annotations carry the destructive/idempotent profile. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, and the description compensates partly by connecting 'Requires explicit_user_intent' to the boolean flag. However, response_format receives no description-level treatment beyond its enum in the schema, and the intent requirement largely echoes the schema's own parameter description. Marginal added meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Clears'), a specific resource ('the local token file'), and the scope of the effect. Since no sibling tool performs logout, it is trivially distinguishable from all 40+ siblings without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the key precondition ('Requires explicit_user_intent') and the unusual operational context ('Not gated by RAPPI_ALLOW_MUTATIONS'), telling the agent when it may run and that the normal mutation gate does not protect the user. It does not state explicit when-not-to-use cases, but no alternative logout sibling exists, so exclusion guidance is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the write/destructive nature is known. The description adds the 'gated cart write' nuance and explicitly states that checkout is not performed, adding behavioral context beyond the structured fields. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with zero fluff. The core purpose is front-loaded, and the gating and checkout exclusions are stated economically. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key operational facts: what it does, that it is a write, and that it does not checkout. Annotations carry the destructiveness. Parameters are mostly in the schema, and with no output schema, return values are not required. It lacks an explicit note that the current cart is replaced, but destructiveHint covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only explicit_user_intent has a description). The description implies that order_id is the past order ID but adds nothing about response_format or the gating condition in more detail. With low coverage, the description fails to compensate for ambiguous parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('rebuilds') and resource ('cart from a past order'), clearly distinguishing it from checkout and cart-modification siblings. 'Does not checkout' further separates it from place_order and checkout_preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: the tool rebuilds a cart from a past order and is a gated write. It does not name specific alternatives or exclusions explicitly, but the checkout exclusion and the cart-write nature give the agent enough to select it appropriately among the many cart/order siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidmosiah/rappi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server