SiteCheck Shop & Social

Rappi restaurant menu and prices: for a Rappi store ID

ecommerce_rappi

Read-only

Rappi restaurant menu and prices (Mexico, Brazil, Colombia, Argentina, Chile, Peru, Uruguay, Ecuador, Costa Rica): for a Rappi store ID returns store name, brand, address, open status, ETA, delivery fee, rating and reviews, cuisine tags, weekly schedule, active offers, and the menu by section with each product's price, original price, discount %, availability and description. From the public restaurant page; no store search. Related tools on this server, for a different need: ecommerce_costplusdrugs when you need Cost Plus Drugs mail-order cash prices from its official; ecommerce_singlecare when you need SingleCare prescription coupon prices for a drug: price. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "storeId": "<storeId>"
    },
    "name": "ecommerce_rappi"
  }
}

Input Schema

Name	Required	Description
`country`	No	mx (default), br, co, ar, cl, pe, uy, ec, cr; taken from the URL if a URL is given
`storeId`	Yes	Rappi store ID (the number in rappi.<country>/restaurantes/<id>-name) or a restaurant URL (required)
`maxProducts`	No	Max menu products to return, 1 to 500 (default 200)

Output Schema

Name	Required	Description	Default
`menu`	No
`store`	No
`source`	No
`country`	No
`currency`	No
`returned`	No
`checkedAt`	No
`productCount`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 24, 2026
- addedOutput schema / properties / checkedAt
```
Added value: +{}
```
- addedOutput schema / properties / country
```
Added value: +{}
```
- addedOutput schema / properties / currency
```
Added value: +{}
```
- addedOutput schema / properties / menu
```
Added value: +{}
```
- addedOutput schema / properties / productCount
```
Added value: +{}
```
- addedOutput schema / properties / returned
```
Added value: +{}
```
- addedOutput schema / properties / source
```
Added value: +{}
```
- addedOutput schema / properties / store
```
Added value: +{}
```
First observedOct 23, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the data source (the public restaurant page), the hard limitation of no store lookup, and — most valuably — the charging model: $0.002 USDC per successful call via x402 on Base/Solana/Arc, with failed calls not charged. That cost and payment-rail disclosure is exactly the kind of behavior an agent cannot infer from structured fields.

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

Conciseness3/5

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

The purpose and payment terms are front-loaded, but the middle of the description is a single running sentence that re-enumerates the return fields already captured by the output schema, which is redundant payload. The sibling-tool routing sentence is also only loosely relevant given how distant those tools are from this one.

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

Completeness4/5

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

With an output schema available and full parameter coverage, the description need not explain return values, and indeed its remaining obligations are met: source of data, the no-search limitation, and cost/payment mechanics are all stated. Only a note on rate limits or failure modes beyond billing would add more.

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

Parameters3/5

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

Schema coverage is 100%, so country, storeId and maxProducts are already fully documented with defaults and accepted forms. The description only echoes the store-ID input and the country list without adding format, fallback or interaction semantics, so it does not meaningfully exceed what the schema already provides.

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

Purpose5/5

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

The description opens with a specific verb+resource pair (return Rappi restaurant menu and prices for a store ID) and enumerates the exact payload: store name, brand, address, open status, ETA, delivery fee, rating, schedule, offers, and menu items with prices and discounts. An agent knows precisely what it gets and which geographies are covered, and the sibling tools it names are clearly marked as serving a different need.

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

Usage Guidelines4/5

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

It gives a clear precondition ("for a Rappi store ID") and an explicit exclusion ("no store search" — you must already have the ID or URL), which is the key usage constraint. It also routes to ecommerce_costplusdrugs and ecommerce_singlecare for different needs, though those are not close neighbors and it offers no guidance versus menu-adjacent siblings like ecommerce_grubhub or ecommerce_falabella_latam.

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

All SiteCheck Shop & Social tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?