What it is
The Evidence MCP server is a read-only retrieval interface into evidence your account has already published. It is not a model and not an agent. It accepts a query over HTTPS, resolves one identity, runs the query inside that identity's account scope, and returns ranked results.
No customer data is copied out of UserEvidence, and no UserEvidence component runs inside your infrastructure.
Data flow
A user asks a question in your AI client.
Your client issues an MCP call to
https://app.userevidence.com/mcp/v1over HTTPS with a bearer token.UserEvidence resolves the caller's identity, account, visibility and allowed tools.
The query runs against your account-scoped search index.
Every candidate result is re-checked against the live database record.
Ranked results return to your model, which composes the answer.
The direction of the final step is the part worth noting: your AI client sends the query and receives the results. UserEvidence does not send your data to an LLM in order to serve an MCP call. What your model then does with the returned content is governed by your own agreement with that model provider.
Subprocessors in the retrieval path
Component | In the | Notes |
Semantic search index | Yes | Serves the ranked candidate set; indexes published evidence content |
Live application database | Yes | Every result is re-checked against the live record before return |
Anthropic / OpenAI / Google via UserEvidence | No | Used for authoring, summarisation and analytics elsewhere in the product. Not invoked to serve an MCP retrieval call |
Your own model provider | Yes, on your side | Under your agreement with that provider |
MCP retrieval is a distinct processing activity from UserEvidence's own AI features, and introduces no subprocessor beyond the semantic search index already listed in our DPA. For DPA or addendum questions, contact your UserEvidence representative.
Hosting and transport
Hosted SaaS on AWS (US). All transport is HTTPS/TLS; TLS 1.2 and 1.3 are negotiated. The service is multi-tenant, with account-level isolation enforced at the authorization boundary described below. Single-tenant deployment and customer-managed keys are not offered.
Authentication and authorization
Authorization resolves once per request, before any tool runs. A request that fails this boundary never reaches a tool. There is no second, in-tool permission check.
Connection kinds
Kind | Grant | Who the call is |
Interactive | Authorization code + PKCE | The named user who authorised it |
Service | Client credentials | One org-wide credential, no individual user |
Embedded | Client credentials + asserted user | The end user your client names per call. Provisioned by UserEvidence on request, not self-service |
The checks, in order
Token present, unexpired, unrevoked — otherwise
401.Audience — the RFC 8707 resource indicator must name this server. A token stamped for another resource is refused, so a token cannot be replayed across servers.
Connection — the token's OAuth application is the connection. A token issued to any other application resolves to no connection and is refused before it can name an account. This lookup includes the connection's enabled state, which is why disabling a connection takes effect immediately.
Scope — the token must carry
mcp:evidence:read, or the request is refused with403.User — for an interactive connection, the token's resource owner must belong to the connection's account, or the request is refused rather than silently downgraded.
Policy is read from the database on every request, never baked into the token. An administrator's change takes effect on the very next call — no re-authorization, no waiting for a client in the field to reconnect.
What the connector can and cannot reach
By default, a connection reaches published, buyer-facing evidence for exactly one account and nothing else.
Account scope
Every result is scoped to the single account the connection is bound to. The scope resolves at the authorization boundary, before any tool runs, so it is not a filter a tool could omit. A connection with no bound account is refused outright.
Public and private
Setting | What the connection sees |
| Published, buyer-facing evidence only |
| The above, plus private evidence — marked internal-only, unlinked, attribution anonymised |
Private evidence requires a deliberate per-connection grant by your administrator. The default is public_only, and an unset visibility means the restrictive value — a connection registered tomorrow does not start out reading the private library.
When private access is granted, three protections apply to every private result:
The internal-only marker is inside the text itself, so a model that reproduces the text carries the marker with it.
No URL is returned. A private asset has no page anyone can open.
Attribution is always anonymised to an industry-and-size stand-in such as "Large Enterprise Health Care Company." Consent to be named is reviewed when evidence is published; a private asset has not been through that review, so the company behind it is withheld rather than guessed at.
The caller cannot choose. Visibility is fixed per connection, and no tool argument widens or narrows it.
Never returned, on any setting
Raw individual survey responses
Survey summaries
Draft case studies
Unpublished customer spotlights
Internal asset lists
Salesforce records, advocate PII and reference request text — these belong to the separate Advocacy / References MCP, approved separately
Any financial, health or credential data — UserEvidence does not process these
Consent
Consent state is re-checked against the live record on every call, not read from the search index. An asset whose visibility changed after indexing is judged on the live record. Customer names are gated on the asset's own attribution decision rather than on a convenience field in the index.
Write access
There is none. Five read-only tools, no write path on this server — not a disabled one, not a flag-gated one. Nothing is written to your Salesforce, Slack or any other system.
Administrative controls
Account administrators govern their own MCP access in Settings → MCP, with no UserEvidence involvement:
Connection list — name, kind, enabled state, last used
Account tool baseline — the ceiling for every connection on the account
Per-connection tool selection — narrows further under the baseline; it can never widen
Visibility grant —
public_onlyorprivate_allowed, per connectionKill switch — disables a connection, enforced at the authorization boundary on its next call
A disallowed tool does not appear in the client's tool list and is not callable — one structural gate, not two separate checks.
Credential handling
Service credentials are shown once, on a reveal-once screen, and are not recoverable. There is no stored retrievable secret. An administrator who closes that screen without copying must create a new connection.
Offboarding
Each interactive connection records the user who most recently authorised it, so an administrator can identify the right row and disable it. The next call from that connection is refused immediately, because the enabled state is checked at the authorization boundary on every request.
Logging and audit
Recorded | Notes |
Which connection called, and when | Written as an access log |
Which tool was called, and what it returned | Feeds administrator usage visibility |
Calling client | Derived from the User-Agent — analytics only. The caller writes its own User-Agent, so no access decision depends on it |
Application and infrastructure logs | Credential and secret redaction applied |
Access and audit logs can be exported and shared with your security team on request.
Assurance
SOC 2 Type 2 — UserEvidence, Inc. holds a SOC 2 Type 2 covering UE Evidence. UE References holds a separate report; the next audit period covers both in one.
Penetration testing — The UserEvidence web application and APIs were penetration tested by BSK Security LLC in October 2025, with a December 2025 retest confirming all High and Medium findings remediated. The /mcp/v1 server post-dates that test; a new engagement covering it is being scheduled. The 2025 report and remediation evidence are available on request.
Review tier — Customers running MCP governance tiers have placed this connector at Tier 1: read-only, no write access, no PII beyond what the customer has approved for publication.
Current limitations
Stated plainly so they don't surface as surprises later:
Limitation | Where it stands |
v1 is not yet covered by a penetration test | New engagement being scheduled; 2025 report available |
No secret rotation | Replacing a secret means creating a new connection and re-pointing the integration |
No self-service per-token revocation | The per-connection kill switch is the immediate control; individual token revocation goes through UserEvidence |
No role-based access from customer SSO | Not available today. Policy is per connection, not per role |
Administrator usage visibility | In development, not yet generally available |
Questions
Contact your UserEvidence representative, or email [email protected]. Security questionnaires, DPA questions and audit artifacts can be routed through the same channel.