Point your own AI agent at your cart — under the permissions you already have

The most useful AI for a busy shopkeeper may not live inside Kadaikodi at all. It may be the assistant they already use every day. So Kadaikodi publishes a Model Context Protocol server: a typed tool surface over the marketplace that an external agent can call directly.

The domain coverage is real and enumerated rather than vague. Twenty-five Kadaikodi tools span eight entity families — merchants, offerings, orders, workers, tasks, reviews, investments and analytics — grouped so an agent can list and read across the marketplace and write where a human could: create and update a merchant, create and update offerings, place an order, move an order’s status, write and respond to reviews. Alongside them the same server mounts the shared platform modules a merchant actually needs — authentication, files, conversations, notifications, scheduling, export, tags, groups, organisations, permissions, billing, support and the store — so a single agent session can move between marketplace work and workspace work without changing tools.

Crucially, it is not a privileged channel. The server signs in through the platform’s own identity flow and calls the same gateway the app calls, which means every tool call is evaluated against the calling person’s permissions. An agent cannot read an order the operator cannot read, and cannot mutate a merchant they do not administer. Guided prompts and live schema resources are registered alongside the tools so the agent grounds its calls against the real API instead of improvising field names.

The honest caveats are specific, because this is where a marketing page usually stops. First, the tool surface currently issues several operations under the pre-namespace field names rather than the marketplace’s namespaced ones, so a portion of the toolset needs a mechanical correction pass against the live schema before it can be called reliable. Second, destructive-action confirmation is opt-in in the shared MCP core and Kadaikodi has not turned it on — and the naming heuristic that flags destructive tools would not catch order placement or an investment commitment anyway. Placing an order or committing money should require an explicit confirmation step, and today it does not. Third, there is no per-agent provenance ledger yet correlating a prompt to the operations it produced.

One genuine safety net does already hold: the investment surface is fail-closed on the server pending securities sign-off, so even a mis-instructed agent cannot commit money through Kadaikodi today — the API refuses it regardless of who is asking.

Status: in progress, not shipped-and-done. The server, the tools, the prompts and the identity path exist in code and are named above; the correction pass, the confirmation gate and the provenance ledger are open work.