Automating with AI agents

Evident runs a remote MCP server, which means an assistant can work with your reviews, catalogue, orders and loyalty programme directly.

https://mcp.evidentugc.com/mcp

Authenticate with an Evident API key as a bearer token. The key carries its organization, role and scopes, so the agent can do exactly what that key can do and nothing more. That is the entire security model, and it is the thing to design around.

Start read-only

Create a key scoped read and connect that first.

Almost everything valuable an assistant does here is reading. Give it write access when you have a specific write you want it to perform, not in advance.

See API keys & scopes for the scope strings, and Agent access for the full tool list.

What works well

Analysis across things you would otherwise open five screens for

“Which products dropped below 4 stars this quarter, and what are the negative reviews actually complaining about?”

The agent pulls review analytics, top products, and the review text, and answers in one pass. The analytics tools return real aggregates rather than a sample, so the numbers are numbers.

Drafting replies at volume

“Find unanswered reviews below 3 stars from the last month and draft a reply to each.”

Have it draft, not post. Read the drafts, adjust, post the good ones. A human reading twenty drafts is much faster than a human writing twenty replies, and the failure mode of a bad draft is a wasted minute rather than a public one.

Moderation triage

“Summarise the pending queue. Flag anything that mentions a safety issue, contains personal data, or looks like it belongs to a different product.”

This is genuinely good use of a model: it is a classification job over text, with a human making the decisions.

Content

“Read the FAQs and the last 200 reviews for this product, and tell me which questions customers keep asking that we haven’t answered.”

Then write those FAQs. The gap between what your FAQ page says and what your reviews keep explaining is usually large and usually cheap to close.

Support context

“What has customer [email protected] bought, reviewed, and what’s their loyalty balance?”

One question instead of three screens.

Where to keep a human

adjust_loyalty_points mints value. Points redeem into store credit and discount codes. It is a legitimately useful tool — “the customer in ticket 4471 had a damaged order, credit them 500 points” is a good use of an assistant — and it is the one tool in the set whose mistakes cost real money.

If you are not certain, omit loyalty:write from the key. You can widen it later; you cannot un-issue points that were already redeemed.

Moderation decisions. Auto-approving by model judgement is a defensible thing to want and a bad thing to run unattended, because the failure is public and the model has no idea which of your products has a pending safety recall.

Anything customer-facing. Replies, in particular. Draft, review, post.

The prompt-injection problem, concretely

Review content is untrusted text written by the public.

An agent reading reviews is reading text a stranger wrote. If it has write access and you have wired it to act without review, a review body containing instructions is an attack surface — and unlike most injection scenarios, the attacker does not need to compromise anything to get their text in front of your model. They just leave a review.

So:

• Do not build unattended automation that acts on review text.
• Treat everything read from reviews, FAQ submissions and gallery captions as data, never as instructions.
• If you must automate a write triggered by review content, gate it on structured fields — rating, verified status, product — not on the body.

No-code platforms

n8n, Zapier and Make can all connect to the MCP server directly, or call the REST API over HTTP. Nothing to install, nothing to review, works today.

Useful shapes:

• Outbound webhook → Slack. A new review below three stars posts to a channel. This is the single highest-value automation most stores build, and it needs no AI at all.
• Outbound webhook → helpdesk. A one-star review opens a ticket.
• Scheduled digest. Weekly summary of new reviews, rating movement and moderation backlog.
• Redemption → fulfilment. A redemption.created event with fulfillment_status: unsupported means the platform could not issue the discount and you must — route it somewhere a person sees.

See n8n, Zapier and Make.

Webhooks, not polling

If you want an agent or automation to react to changes, subscribe to outbound webhooks rather than polling on a schedule. Thirteen events cover reviews, orders, gallery submissions and redemptions.

One thing to build for: delivery is fire-and-forget with a 15-second timeout, and there is no automatic retry. Acknowledge fast, and reconcile against the event log on a schedule to catch anything that did not land.

Practical hygiene

• One key per assistant or automation. The activity log records the key, not the person who asked. One key per integration means the log tells you which system did what, and lets you revoke one without breaking the others.
• Name the store. Tools take a store environment ID. If you run several, expect to say which — the agent will not guess, and should not.
• Scope narrowly. A key with no scopes is unrestricted; that default exists for backwards compatibility with keys minted before scopes were enforced, not as a recommendation.
• Watch first use. Key creation and first use are in the security audit log. A key created months ago and used for the first time today is worth a question.