Agent access (MCP)
Connecting an AI assistant to your Evident data over the Model Context Protocol.
5 min read
On this page
Evident runs a remote MCP server, so an AI assistant can read your reviews, catalogue, orders and loyalty programme — and, where you allow it, act on them — without anyone writing an API client.
https://mcp.evidentugc.com/mcp
It speaks streamable HTTP, which is what Claude, ChatGPT, n8n, Zapier and Make all expect from a remote MCP server.
Connecting
There are two ways to authenticate, and which one you use depends on the client.
Sign in with your Evident account. Claude’s connector settings have no field for a key: add the URL, click Connect, sign in to Evident and choose an organization. The agent then acts as you, with your role in that organization, and Evident re-checks your membership on every call.
Use an API key as a bearer token. n8n, Zapier, Make, ChatGPT and Claude Code all take a bearer credential. Create one under Settings → API Keys — see API keys & scopes — and give it to the tool as the server’s bearer credential. The key carries its organization, its role and its scopes with it. An agent can do exactly what that key can do, and nothing more. If you want an assistant that can read but never change anything, give it a key scoped read.
Setup differs per tool; see Claude, ChatGPT, n8n, Zapier and Make.
What the agent can do
Twenty-two tools, split by whether they change anything.
Read
list_stores · search_products · get_product · list_orders · get_customer_activity · search_reviews · get_review · get_product_review_stats · get_review_analytics · get_top_products_by_reviews · get_evidence_analytics · list_faqs · get_loyalty_account · get_loyalty_stats · list_loyalty_rewards
Write
moderate_review · reply_to_review · send_review_request · create_faq · update_faq · adjust_loyalty_points · create_loyalty_reward
Read tools are annotated as read-only, so a well-behaved client can show you which of these actually touch anything.
Which store
Most tools take a store environment ID. list_stores is how the agent finds it — and it is deliberately exempt from scope restrictions, so even a narrowly scoped key can discover the store it is scoped for.
If you have several stores, expect to name the one you mean. The agent will not guess, and nor should it.
Think about adjust_loyalty_points before you enable writes
That tool mints value. An assistant with a write-scoped key can credit points to a customer, and points redeem into store credit or discount codes.
That is genuinely useful — “the customer in ticket 4471 had a damaged order, give them 500 points” is a good use of an assistant. It is also the one tool in the set whose mistakes cost money.
If you are not sure, hand the agent a key scoped read, or one that omits loyalty:write. You can widen it later; you cannot un-issue points that were already redeemed.
What agents are good at here
- Reading across things you would otherwise open five screens for. “Which products have dropped below four stars this quarter, and what do the negative reviews say?”
- Drafting replies.
search_reviewsfor unanswered negatives, draft a reply for each, and let you approve them — rather than letting it post directly. - Triage. Summarising the moderation queue, flagging what needs a human.
- Answering questions with numbers. The analytics tools return real aggregates, so it does not have to estimate from a sample.
What to be careful about
- Review content is untrusted text. It is written by the public. An assistant reading reviews is reading text a stranger wrote, and treating it as instructions rather than data is the whole prompt-injection problem. Do not build unattended automation that acts on review text without a human in the loop.
- A key is not a person. Everything the agent does appears in the activity log under that key, not under whoever asked. Use one key per assistant so the log is legible.
- Scope narrowly and widen later. The unrestricted default exists for backwards compatibility with keys minted before scopes were enforced. It is not a recommendation.
Which to choose
A signed-in connection is the right shape for a person using an assistant: it is scoped to one organization, carries your own role, and stops working the moment you leave that organization. An API key is the right shape for unattended automation: it can be scoped narrower than any person’s role, revoked on its own, and shows up in the activity log as itself rather than as you.
Something missing or out of date? Email [email protected] — docs corrections go straight to the team that builds the feature.