Quick commerce MCP server for India data: what it returns and how to connect

What the server exposes today

An MCP server lets a compatible AI client discover and call documented tools. These are the quick commerce data reads. The server also has catalogue, account and quote tools, and data tools for other sources.

A connection does not make missing coverage available, verify every interpretation the agent produces, or remove the need to review the cost of delivered data. A returned table still needs its location, collection date and source context before it supports a conclusion.

Treat connection, permissions and task completion as separate checks. A client recognising the server does not prove that it has signed in. A successful account check does not prove that a particular data tool can answer your question.

Think of the tool response as evidence for the agent to examine. Ask it to retain the distinction between returned fields, calculations it performs and conclusions it proposes. When the result leaves the conversation as a report, keep that distinction visible. A polished paragraph is not a replacement for the underlying records, and fluent wording does not establish that a location or period was covered.

A data MCP, not an ordering MCP

Some shopping apps publish MCP servers that place orders on a shopper's own account. Rewalto's server is for reading dated market data across apps and pin codes; it cannot order, and it is not any app's own feed.

Connect in 3 checks

Rewalto's dedicated MCP address (preview) is https://mcp.rewalto.com/mcp. Its REST API uses https://api.rewalto.com; the India ecommerce data API guide lists what it returns today. These are different interfaces, so do not build an MCP address by adding a path to a remembered API hostname. Treat each check below as separate.

1. Reach the service: confirm your client can reach the documented address.
2. Verify identity and permitted capabilities: run a free identity or catalogue check and confirm the organisation and permissions it reports.
3. Inspect a small result and its source context: read one bounded answer and check its location, date and source.

Client-specific installation, OAuth, saved agent connections and connection testing are not published yet in the API, CLI and MCP reference. Until they are, the REST API returns the same data: start with the first request guide.

Different agent clients expose remote connections in different places. Some provide a connector screen; others read a configuration file. Use your client's current official instructions, check the transport and authentication method it supports, and review the requested account and organisation permissions before continuing. Do not assume a configuration for one client works in another. If a client only reports a generic connection error, collect safe diagnostic context before changing permissions. Seeing the expected organisation confirms identity. Seeing a catalogue entry confirms discovery. Neither establishes that a historical data request, export or recurring delivery works, so record the actual outcome and the next unverified step.

Keep a connection record for your own team: the intended environment, client name, setup documentation used and date of the last successful check. Do not include the credential itself. This helps distinguish an outdated setup instruction from a changed service capability. If an address changes, update the supported configuration deliberately instead of trying alternate hosts until one happens to answer.

3 example prompts

These are example prompts, not results. Each one is bounded and read-only. Replace the words in square brackets, and keep the first request small enough to inspect before expanding it. Start with discovery: which available record types, fields and locations could answer your question. Then specify the product or entity, location, period and output you need.

• List the fields list_observations returns and the pin codes covered for [brand], then wait.
• For [product] at pin code [pin], show the last 7 days of price, MRP and stock readings with the time of each reading. Mark missing days unknown.
• Which dark stores serve pin code [pin], by app, and when was each last seen?

Ask for a plan before a wider data task: which tool the agent intends to use, which inputs it needs and what output would answer the question. Review that plan for assumptions about geography, product matching and time. It should not assume every location is covered, read missing prices as zero or infer sales from listing changes. If it cannot name the source of a field, it should mark that field unknown instead of generating a plausible value.

See commerce data and dark stores in India for what each dataset covers.

Keep credentials private and permissions narrow

A private API key belongs in the client's supported secret configuration, not in the question you send to an agent. Never paste a key into a public prompt, a screenshot, a shared conversation or an issue report. A copied setup prompt should describe the task and point to documentation without including the secret.

Where an API-key connection is supported, select only the scopes required for the work. Reading data and approving a quote are different permissions. Check the key's expiry and status, use the dashboard to manage access, and do not grant a wider scope to work around an unexplained error. Where a sign-in connection is available, review its consent screen and chosen organisation.

Access also needs an owner. Agree who can rotate or revoke a key and how a departing team member loses access to the agent configuration. If a secret appears in a shared place, remove it from that place and follow the supported revocation process; hiding the text afterwards does not make the exposed credential private again. Avoid retaining secrets in copied examples or exported connection notes.

An agent connection does not remove cost review

MCP and REST use the same underlying data and charging principles. Tools are free; delivered data can spend credits. Review a published rate before a chargeable read. When the work needs a quote, review the API's quote before approving it. Connecting an agent is not blanket permission for future purchases or recurring work.

Tell the agent when approval is required, but also use the available account permissions. A sentence in a prompt is not a substitute for access controls. Keep receipts and request references with delivered results. See how data credits work and the credit reference before widening the task.

Consider what happens after an error as part of that approval boundary. An agent may naturally try another tool or repeat a request to finish the task. Tell it to stop when the next step needs a new approval, and rely on scoped permissions where available. A previous successful request is not consent to a larger request, a different dataset or an ongoing schedule.

Diagnose connection and data problems separately

Most early problems belong to one layer, and fixing the wrong layer can create a second problem. Work through them in order and record what each check proved before moving on.

First check the address and client configuration, then authentication, organisation access and required permissions. Only after those checks should you investigate the selected data tool and its inputs. A missing field or uncovered location is not necessarily a connection failure.

When reporting an error, include the client, environment, attempted operation and safe request reference. Remove credentials and private response content. Do not repeatedly approve or retry uncertain writes. If setup remains unavailable, use the documented REST path; do not invent a local workaround that bypasses the same account and credit rules.

Questions people ask