Connect an AI agent to India price data: API, CLI or MCP?

Choose an interface: 3 choices

The three interfaces are thin layers over one API. Pick by who sends the request and who reads the answer. You can start with one and move to another later without changing your account, your key or what a read costs.

If you are unsure, start with the REST API. It is the interface the other two are built on, so a request that works there tells you the data, the key and the permissions are right before an agent is involved.

One contract, so the rules do not change

Whichever interface you pick, the same things hold. The data is the same: a field means the same thing in an API response, a terminal and an agent's tool answer. The key is the same, and so are its scopes: reading data and approving a quote are different permissions on every interface. An agent connection does not bypass a scope or a credit review.

Cost is the same too. Tools are free; delivered data spends credits at its published rate, and a run that delivers nothing costs nothing. A run with no published rate shows the API's quote and starts only after you approve it. See how data credits work and the credit reference.

Coverage does not change with the interface either. A connection cannot make a missing pin code or app appear. The data catalogue shows each dataset's current status and freshness. Read it before you ask an agent a question the data may not answer.

Match the interface to the job

Most teams do not need all three. Four common jobs show where each one fits, and why the answer is often the plain API even when an AI agent is involved.

A report that runs every night

A job that reads the same products at the same pin codes every night and writes them to a sheet or a database belongs on the REST API. Your code decides the inputs, keeps every response with its reading time and can be reviewed line by line. Nothing in the loop needs a conversation, so an agent adds cost and uncertainty without adding anything the job needs. If the report should run on a schedule with a spending limit, look at Monitors before you build a scheduler of your own.

A one-off question from an analyst

An analyst who wants to check one product at one pin code today needs a small read and a clear answer, not a program. The CLI suits this once its install steps are published: the request and the response sit side by side in the terminal, so it is easy to see which field answered the question. Until then, the same read works as a single API request from the first request guide.

An agent that answers questions in a chat

When a person asks an AI assistant something like "what does this pack cost at my pin code this week?" and expects the assistant to look it up, MCP is the natural fit. The client discovers the tools, picks one, sends the inputs and reads the answer back. That convenience is also the risk: the agent chooses the tool and the inputs, so review its plan before a wider or chargeable read, and ask it to keep the reading time and pin code next to every figure it reports.

An agent built in your own code

If you are building the agent yourself, with your own framework and your own tool definitions, you can call the REST API from those tools directly. You keep control of retries, logging and which fields reach the model. MCP helps most when the client is someone else's and you cannot add tools to it any other way.

Connect in 3 checks

The same three checks apply to the API, the CLI and the MCP server. Treat each one as separate: passing one does not prove the next.

1. Reach the service: confirm your client or code can reach the documented address, https://api.rewalto.com for the API and https://mcp.rewalto.com/mcp for MCP (preview).
2. Check identity and permissions: run a free identity or catalogue read and confirm the organisation and permissions it reports are the ones you meant to use.
3. Inspect a small result: read one bounded answer and check its location, date and source before you widen the request or schedule it.

Keep the key out of prompts, screenshots and shared conversations. Store it in the client's supported secret setting or your server's secret store, and give it only the scopes the work needs.

Write down what each check showed, with the date. If the first check fails, the problem is the address or the network, not your key. If the second fails, look at the key, its scopes and the organisation before you touch anything else. If the third returns fewer rows than you expected, the connection is working and the question is coverage: check the catalogue for that app and pin code before you assume something broke.

Ground rules to give an agent

An agent will do what it is asked as well as it can, which includes guessing when it is not told to stop. A few plain instructions, given at the start of the task, prevent most of the answers you would later have to unpick.

• Say which product, pin code and period you mean, and ask it to confirm them back before it reads.
• Ask it to mark a missing reading as unknown, never as zero and never as out of stock.
• Ask it to keep the reading time and pin code beside every price it reports.
• Tell it to stop and ask before any read that spends credits or needs a quote.
• Ask it to say which tool or request produced each figure, so you can repeat it.

These rules are the same whether the agent calls MCP tools or your own API wrappers. They are not a substitute for permissions: a key that cannot approve a quote is a firmer limit than a sentence in a prompt. Use both. When the agent hands back a table, read a few rows against the source before you share it, and keep the request reference with the result so the figures can be traced later.

Switching interfaces later

Because the three share one contract, moving between them is mostly a change of who sends the request. A read you tried by hand can become a line in a script, and a script can become a tool an agent calls, without new terms or a new price. What changes is who decides the inputs. In your own code you choose them; through MCP the agent does, so keep the bounds tighter at first and widen them once the answers check out.

Keep one key per workflow rather than one key for everything. If a nightly job and an agent share a key, a problem in one forces you to rotate the key for both. Separate keys also make the credit usage for each workflow easy to read on its own.

What is not published yet

Client-specific installation, OAuth sign-in, saved agent connections and connection testing are not published yet in the API, CLI and MCP reference, and neither are the CLI's install steps. This page gives no setup steps for any one client, because none are published to point to.

Until they are, the REST API returns the same data: start with the first request guide. When a client offers a connector screen or reads a configuration file, follow that client's own current instructions and check the transport and sign-in method it supports.

Common questions