Feature: Model Context Protocol (MCP) server exposing Measure Studio analytics to third-party AI clients (Claude, ChatGPT, etc.)
AI Provider: None — Measure Studio is the data source; the AI model is operated by the customer's chosen client
Last updated: May 2026
1. Feature overview
The MCP server lets a customer connect their Measure Studio workspace to any MCP-compliant AI client. Once connected, the client can call a curated set of read-and-light-write tools (search posts, fetch analytics, build report slides, tag posts, etc.) on behalf of the authenticated user. The AI runs on the customer's side — Measure Studio is the data source, not the model provider.
The feature is opt-in per company via a feature flag. No data leaves Measure Studio to any third-party AI provider through this surface unless a customer explicitly connects a client and that client issues a tool call.
2. Data sent to the MCP client
The MCP server only returns data scoped to the authenticated user's workspace and permission level (see §5). What flows out depends on which tool the client invokes.
What can be sent
Data type | Details | Purpose |
Account metadata | Display name, platform, follower count, public/owned status, scope tag | Letting the AI describe the workspace |
Post metadata | Title, description, caption, post type, published date, tags (hashtags, user tags, AI tags), thumbnail URL | Search and content analysis |
Post analytics | Engagement, reach, impressions, video views, demographics on owned accounts | Performance Q&A and reporting |
Group / dashboard info | Names and IDs of groups, dashboards, reports the user can access | Navigation between resources |
Report slide payloads | Slide content produced by visual tools | Building a report from a chat session |
Static documentation | Three reference docs (data model, query reference, visual tools guide) | Helps the client form valid tool calls |
What is NOT sent
User credentials, OAuth tokens, refresh tokens, or session cookies
Other workspaces' or other companies' data (multi-tenant isolation is enforced per request — see §5)
Internal system fields (audit log entries, billing data, internal IDs of unrelated records) System prompts or internal AI configuration used by the in-product chatbot
Historical performance data or analytics data from accounts without the feature enabled
3. Available tools
The MCP server exposes the following tools. All tools operate within the authenticated user's workspace and permissions.
Data tools (read-only)
Tool | Description |
list_accounts | Lists all social media accounts in the workspace with platform, type, and status |
list_account_groups | Lists account groups (collections of accounts) in the workspace |
list_dashboards | Lists all custom dashboards the user has access to |
list_reports | Lists available reports in the workspace |
list_post_groups | Lists all post groups in the workspace |
list_user_tags | Lists all user-created tags in the workspace |
list_post_collaborators | Lists all post collaborators (e.g. Instagram Collabs) in the workspace |
list_post_partners | Lists all branded content / paid partnership partners in the workspace |
list_available_metrics | Lists available metrics with keys, labels, scope, and post type support |
search_posts | Searches posts with filters (keywords, dates, types, accounts, groups, performance) |
get_post_details | Gets detailed metadata for a specific post |
get_post_analytics | Gets analytics (engagement, reach, views, etc.) for a single post |
get_post_audience | Gets audience demographic and geographic data for a specific post |
get_post_content | Gets computer vision data, transcript, and AI-generated categories for a post |
Tool | Description |
get_account_stats | Gets account analytics for a time period |
get_account_demographics | Gets audience demographics (age/gender) for an account |
get_account_geography | Gets audience geography (country/city breakdown) for an account |
get_account_group_stats | Gets analytics for a platform within an account group |
get_group_stats | Gets analytics for a post group at platform or account level |
get_platform_stats | Gets aggregated stats across all accounts for a platform |
get_dashboard_widgets | Lists all widgets on a custom dashboard with their configurations |
get_dashboard_widget_data | Fetches analytics data for a specific dashboard widget |
get_dashboard_targets | Fetches targets configured on custom dashboards |
get_target_progress | Fetches current progress for a specific dashboard target |
Write tools (limited actions)
Tool | Description |
add_tags_to_posts | Adds one or more user tags to one or more posts |
remove_tags_from_posts | Removes one or more user tags from one or more posts |
create_post_group | Creates a new post group with filters |
create_report | Creates a new empty report |
create_report_from_template | Creates a new report based on an existing template |
add_slide_to_report | Adds a previously created slide to an existing report |
update_slide | Updates the title, subtitle, or footer of an existing slide |
set_targets_dashboard | Sets the targets dashboard for the session |
Visual tools (create report slides)
Tool | Description |
visual_compare_accounts | Creates a slide comparing 2–9 accounts side by side |
Tool | Description |
visual_compare_posts | Creates a slide comparing 2–4 posts side by side with metrics |
visual_create_text_slide | Creates a text-only slide with title and body |
visual_get_account_demographics | Creates a slide showing audience demographics for an account |
visual_get_account_geography | Creates a slide showing audience geography for an account |
visual_get_account_group_metric | Creates a slide with a single metric chart for an account group |
visual_get_account_group_stats | Creates a slide with multiple metrics for an account group |
visual_get_account_metric | Creates a slide with a single metric chart for an account |
visual_get_account_stats | Creates a slide with multiple metrics for an account |
visual_get_group_metric | Creates a slide with a single metric chart for a post group |
visual_get_group_stats | Creates a slide with multiple metrics for a post group |
visual_get_platform_metric | Creates a slide with a single metric chart for a platform |
visual_get_platform_stats | Creates a slide with multiple metrics for a platform |
visual_get_post_analytics | Creates a slide with multiple metrics for a post |
visual_get_post_details | Creates a slide showing a single post with thumbnail and key metrics |
visual_get_post_metric | Creates a slide with a single metric chart for a post |
visual_search_posts | Creates a slide displaying multiple posts (max 8) |
4. Third-party AI handling
Measure Studio is not the AI provider here. The model running on the client side (Claude, GPT, Gemini, etc.) is operated by whichever vendor the customer chose. Their data handling, training opt outs, and retention policies apply to anything the customer's client sends to that model — including the tool responses Measure Studio returns.
Customers are responsible for configuring their MCP client against a model tier that meets their own data residency and training requirements. Measure Studio does not send data to any AI provider through this surface; it only responds to authenticated tool calls from the client.
Recommended client configurations:
Claude / ChatGPT: use enterprise or team plans where the provider does not train on customer data
Gemini CLI: use the paid API tier where Google explicitly does not use input/output data for model training
5. Data storage and retention
The MCP server is stateless beyond standard request logging. Tool calls are not persisted as conversations
Request/response bodies are not stored — only access logs (path, status, duration, OAuth client ID) are kept under the same retention policy as the rest of the application
A short-lived session header is minted at connection time for client-server correlation; it lives only in the client's memory and server logs
OAuth access tokens, refresh tokens, and user bindings are stored encrypted at rest in the database, following the same practices as the rest of the platform
Errors are reported to the application's exception monitoring service with tool name tagged but without raw arguments or response data
6. Access controls
Control | Details |
Feature gating | Disabled by default. Each company must have the MCP feature flag enabled. Without it, all MCP requests are rejected regardless of token validity. |
Workspace status | The workspace must be active. Inactive or suspended workspaces are rejected even with a valid token. |
OAuth scope | All requests must present a bearer token issued with the dedicated MCP scope. Tokens without this scope are rejected. |
Per-user binding | Each MCP access token is bound to the specific user who authorized it, captured server-side during the OAuth flow — never trusted from the client request. |
Per-user permissions | Every tool resolves data through the same permission policies used by the web application. The MCP user only sees what they would see logged in. |
Tool-level permissions | Individual tools can require specific permissions; these are checked before execution. |
Authentication | OAuth 2.1 with PKCE (S256). Supports Dynamic Client Registration (RFC 7591) and Client ID Metadata Documents so third-party clients can self-register. |
Redirect URIs | Client registration only accepts HTTPS, URN, or loopback HTTP redirect URIs. Non loopback HTTP is rejected. |
Control | Details |
Rate limiting | Per-company per-minute request limit (configurable, default 60). Client registration is additionally limited to 5 requests per IP per hour to prevent spam. |
Network | All communication is encrypted via HTTPS (TLS 1.2+). The MCP endpoint runs behind the same TLS termination as the rest of the application. |
Transport | Single POST endpoint — other HTTP methods are rejected. Every request after the initial handshake must include a valid session header. |
Tenant isolation | Each tool fetches data exclusively within the authenticated user's workspace. Tokens cannot be replayed against a different workspace because the access token is tied to a single workspace at issuance. |
7. Output data
Tool output passes through the same code paths as the in-product AI assistant — no free-form generation happens on the Measure Studio side. The "AI" that synthesizes prose is the customer's client, using only what Measure Studio returned.
Output includes:
Structured tool results — JSON or markdown payloads (search results, metric values, slide definitions)
Resource documents — markdown reference text (data model, query reference, visual tools guide) Error messages — sanitized error strings; internal exceptions are caught and returned as a generic error. No raw SQL, stack traces, or internal identifiers are exposed.
All output conforms to the JSON-RPC 2.0 envelope defined by the MCP specification.
8. Incident handling
The MCP endpoint is covered by the same operational monitoring (request volume, error rate, latency) as the rest of the application
Tool exceptions are routed to the existing exception monitoring pipeline
Rate-limit violations return standard HTTP 429 responses
The MCP server is fully independent of core data sync — an outage does not affect post ingestion, scheduled reports, exports, or any other product surface
Customers can revoke an MCP connection at any time, which immediately invalidates all access and refresh tokens issued for that connection
9. Compliance
Requirement | Status |
GDPR | No new categories of personal data are introduced. Data flowing through MCP is the same workspace-scoped data already covered by the existing Measure Studio DPA. The customer's chosen AI client is a separate processor under the customer's control. |
Data residency | All MCP traffic terminates at the same Measure Studio infrastructure region as the rest of the application. What the client does with returned data is governed by the client's provider. |
Right to deletion | Removing a user or workspace cascades to all OAuth grants and tokens; future MCP calls fail authorization. |
Sub processor | Measure Studio does not introduce a new sub-processor for MCP. The client and its model provider are configured by the customer, not by us. |
|
|
10. Frequently asked questions
Q: Does Measure Studio see what the AI does with our data? No. We only see the inbound tool calls (which tool, which arguments) and the response we returned. We do not see the model's reasoning, the conversation context on the client side, or how the user phrased their question.
Q: Is data sent to an AI provider for training? Not by us. Measure Studio sends nothing to any AI vendor through this surface. The customer's MCP client may send our tool responses to its model — whether that traffic is used for training depends on the client and its tier (enterprise/team tiers from major providers exclude training).
Q: How is the feature enabled? A Measure Studio admin enables the MCP feature flag on the company. The end user then connects their MCP client via the standard OAuth authorization flow. Both steps are required.
Q: Can an MCP client take destructive actions? Tools are limited to what the in-product AI assistant can do — primarily reads and lightweight writes (creating slides, applying tags, creating post groups). Account-level destructive operations (disconnecting accounts, deleting workspaces, billing changes) are not exposed.
Q: What happens if a token is stolen? The token grants access only to the workspace and user it was issued for, scoped to the MCP OAuth scope. Revoking the connection immediately invalidates all tokens. Bearer tokens are short-lived and refreshable via the standard OAuth refresh flow.
Q: What happens if the MCP endpoint goes down? Nothing else is affected. The endpoint is isolated from data ingest, scheduled jobs, and the rest of the API. Clients receive standard error responses and can retry. Failed tool calls do not corrupt state.
Q: Are conversations logged? No conversation transcripts are stored. Access logs capture metadata (timestamp, OAuth client, status, latency) but not request or response bodies.
Q: How is multi-tenancy enforced? Every tool resolves data through the authenticated user's workspace scope and permission policies. The access token is bound to a single workspace and a single user. There is no path that lets a token access data from another workspace.