Unwrap MCP Server: Security Overview & FAQ

Last updated: September 8, 2026

A reference for security, privacy, and compliance teams evaluating the Unwrap MCP server before enabling it in their environment.

Who this is for: Security & Compliance Reviewers, IT Administrators, Unwrap Admins

Overview

The Unwrap MCP (Model Context Protocol) server lets your team query Unwrap insights from an MCP-compatible AI client instead of the Unwrap web app. It exposes the same analysis capabilities that power the Unwrap Assistant — searching Groups, sampling and classifying feedback, plotting charts, and pulling metrics — through a standard protocol your existing AI tooling can call. 

It is hosted by Unwrap, authenticated with OAuth 2.1, governed by the same role-based access controls as Unwrap’s web app, and backed by the same LLM providers already approved for use of your Unwrap instance. If a user cannot see a View in the Unwrap UI, they cannot query it over MCP.

What Changes Compared to the Web Platform

Use this table to scope your review. If your team has already approved the Unwrap platform, most of your prior assessment carries over.

Area

Unwrap web platform

Unwrap MCP server

Data accessed

Groups, Entries, metrics, metadata

Same, scoped by the same permissions

Underlying LLM tools

Assistant tools

Same tools, plus a small number of MCP-only tools that bring Assistant capabilities to MCP client. These new tools don’t change the data access restrictions.

LLM providers

Providers named in your contract

Same providers, same sub-processor agreement

Access control

RBAC

Same RBAC, enforced against the OAuth token created per user

Authentication

Platform login / SSO

OAuth 2.1 + PKCE

Write access

Available in-product

Read-only for now (see Blast Radius)

Hosting

Unwrap’s VPC in US AWS availability zones

Same infrastructure

The net new surface for your review is the authentication model, the client that connects to it, and the agentic risk that comes with putting feedback content into an AI agent's context.

Architecture and Data Flow

The MCP server is hosted and operated by Unwrap on the same infrastructure as the rest of the platform. There is no self-hosted or on-premise option.

The flow is:

  1. Your MCP client authenticates to Unwrap over OAuth 2.1 + PKCE and receives an access token.

  2. The client calls a tool, passing a view_id and any filters.

  3. Unwrap validates the token, resolves the caller's RBAC permissions, and confirms the caller has access to the requested View.

  4. The tool executes against your Unwrap data. Tools that perform semantic analysis — for example, classifying or summarizing sampled Entries — invoke an LLM server-side.

  5. Results return to your client over TLS.

On LLM processing: because the MCP server vends the same tools that power the Assistant, LLM usage falls under the configurations as use of Unwrap’s web app. Any model an MCP tool invokes is an already-approved sub-processor. Enabling MCP does not introduce a new sub-processor, and it does not change where your data is processed or stored relative to the platform.

Endpoint: https://nlp.api.production.unwrap.ai/mcp — this is the domain to allowlist for egress. No inbound firewall changes are required. 

Authentication and Authorization

Supported flows

The server implements OAuth 2.1 with PKCE and supports three patterns:

Pattern

Grant type

Token identity

Typical use

Org-level static token

authorization_code,refresh_token, client_credentials

Organization

Can only be created by Org Admins. Shared or service-style integrations. Created in the Unwrap admin page. Machine-to-machine access is supported via client_credentials. No interactive user authorization with these tokens.

Dynamic Client Registration (DCR)

authorization_code, refresh_token

Individual user

Individual users connecting their own MCP client using their permissioning with DCR.

Privilege parity

Tokens issued through the DCR flow are bound to the individual user and backed by the same RBAC permissions the platform uses everywhere else. A user querying over MCP retrieves exactly what they could retrieve in the UI — no more. There is no elevated service path and no way to reach a View, Group, or Entry that RBAC does not already grant.

Org-level static tokens carry organization-scoped access rather than an individual user's scope. If your security posture requires per-user attribution and least-privilege scoping, use the DCR flow.

Token scope

All OAuth tokens are currently read-only and enforced server-side.

Revocation and lifecycle

Access token lifecycle: 1hr

Refresh token lifecycle: 30 days

Tenant Isolation

Every tool requires a view_id parameter, which is supplied by the caller. That parameter is validated server-side against the permissions attached to the OAuth token. If the token does not grant access to the requested View, the tool returns an error and no data is returned.

This is the control that prevents insecure direct object reference (IDOR) — a caller cannot enumerate or guess their way into another tenant's or another team's View by manipulating the view_id they send.

Data Handling and Retention

What can be retrieved

Through MCP tools, an authorized user can retrieve:

  • Feedback Groups and taxonomy structure, including group titles and semantic search results

  • Feedback summaries — condensed representations of Entries rather than raw source text

  • Metadata and segments attached to feedback, such as account name, ARR, sentiment, and other Custom Fields

  • Metrics — feedback volume, favorability, relative share, resolution rate, and numeric segment aggregates such as NPS and CSAT

  • Charts and tables built from the above

A full tool-by-tool inventory lives in the MCP tool reference. 

Deleted data

Data deleted in Unwrap is not served over MCP. Deletion propagates to every surface, including this one.

Model training

No customer data via the MCP is used to train Unwrap's models. Sub-processor LLMs operate under the same ZDR agreement that governs the Assistant.

Query logging

Every MCP tool requires an explanation parameter — a short sentence describing why the call is being made. Unwrap uses this to understand how the MCP is being used in practice. This data is currently not stored anywhere other than logs, to help debug what may have happened on the clients side when they experience errors.

Admin Controls and Monitoring

  • Usage visibility. The admins of your Unwrap org can see MCP usage through the Usage feature in the Unwrap web app.

  • Client-side visibility. Unwrap does not provide any monitoring on clients used with the MCP.

  • Tool-level controls. Admins cannot currently disable individual tools. Access is governed at the token and RBAC level.

  • MCP Access Control: Admins cannot control which users have MCP access currently. All Unwrap users can use the MCP automatically because it just inherits their existing RBAC-governed access.

Related Articles