Analytics and observability
One analytics subscription buys you two things: the dashboard your end users see inside your product, and your own business intelligence about how that product is being used.
| Audience | Platform teams and product managers who have embedded MCP Studio |
|---|---|
| Prerequisites | SDK credentials, a saved configuration, and at least one deployed end-user server for data to appear |
The two sides
End-user analytics is what you resell. Your customers get a dashboard on the MCP servers they created through your embed, without buying an MCP Studio subscription themselves. You choose which cards appear and how it looks.
Portal business intelligence is what you keep. Aggregate insight into how the feature you embedded is actually being adopted and used across your whole customer base. This is the reason SDK analytics costs more than MCP Studio standalone: you are buying reporting scoped to a business, not to one server.
Pricing
| Tier | Price | End users get | You get in the portal |
|---|---|---|---|
| Core | $350/mo | Usage, latency, tool and source breakdown, request log | Adoption, activation, AI client mix, source reach |
| Core + Action | $450/mo | Exact passages, code provenance, content gaps, impact model | Top questions across all users, aggregate gaps, ranked fixes |
| Core + Action + Predictive | $550/mo | Requests to answer, source grades, forecasts | Efficiency trends, aggregate grades, forecasts, at-risk integrations |
Tiers stack, and every tier includes the one before it. New developers get a 30-day trial with all three unlocked on both sides.
What the portal shows
Portal → Embed Usage. Always available, at every plan level including no plan at all: servers deployed, MCP requests, success rate, average response, requests over time, most used tools, and busiest servers.
Each tier then adds a section:
Core — adoption and reach
Who is using the feature you shipped and whether it is spreading.
- Activation rate — new servers that went on to be queried. Deploying a server and never using it is the most common way an integration quietly fails, so it gets its own number.
- Dormant servers — deployed but never queried.
- AI clients — Cursor, Claude Desktop, Windsurf, and so on.
- Most referenced sources — which content your users' agents actually reach.
Action — what your users are asking
- Top questions across every end user, collapsed so the same question phrased two ways counts once. This is the clearest signal of what people came to your product to find out.
- Content gaps — questions that returned nothing useful.
- Grounded answer rate and low-confidence request counts.
- Ranked fixes with the number of requests each would affect.
Predictive — efficiency and forecast
- Requests to answer — how many MCP requests it takes a user to get somewhere, with a healthy threshold to compare against.
- Source grades (A–D) aggregated across your integration.
- At-risk integrations — servers whose usage dropped by half or more in the window. A server that was busy and went quiet is a churn signal you can still act on; one that was never used is an onboarding problem instead.
Why this matters for internal tools
If you have embedded MCP Studio in an internal application, the portal is where you see how employees are using it: which questions they ask, which internal sources answer them, and which teams have adopted it. That is business intelligence about your own organisation's knowledge, not just uptime monitoring.
Customizing the end-user dashboard
In the configurator, under Analytics:
Which cards appear. Metrics are grouped by the tier that includes them. Cards above your selected tier are shown but cannot be enabled, so it is always clear what upgrading would add.
How it looks. By default the dashboard inherits your wizard's colors and font, so both surfaces match your product. Turn that off to set the dashboard's background, surface, text, and accent colors and its font independently.
Only plain hex colors and plain font names are accepted, and the selection is re-validated before it is rendered.
Granting analytics to your end users
Two things have to be true before an end user sees paid analytics:
- You pay for the tier.
- You expose it — turn on Include analytics step in wizard and pick the tier.
The grant is the lower of the two. Paying for Predictive while exposing Core grants Core. Exposing Predictive without paying grants nothing, so the toggle alone never unlocks paid analytics. During your trial the paid ceiling lifts, so whatever you select is what your end users get.
Additive, never subtractive
An end user who already pays MCP Studio for analytics keeps everything they pay for. Your grant can only raise their tier on servers created through your embed. If you downgrade or your trial ends, nobody loses access they bought themselves.
Per server, not per account
Attribution attaches to the individual server. An end user with three servers, one from your integration, sees your granted tier on that one and their own tier on the other two.
How subscribing works
Subscribe from the SDK pricing page while signed in. The checkout link carries your developer ID so the purchase can be attributed back to your account; subscribing from a signed-out session cannot be matched to you, which is why the button asks you to sign in first.
Your tier activates automatically once Stripe confirms the payment, and the pricing page then shows it as your current plan. Upgrades stack and never regress — buying Core while holding Predictive will not downgrade you.
To cancel or change payment details, use the Stripe billing portal linked from your receipt. Checkout links cannot cancel a subscription.
How attribution works
Your client ID travels with the deployment. When an end user finishes the embedded wizard, the handoff to MCP Studio carries the client ID from your snippet, and the resulting server is tagged with it.
MCP Studio validates the client ID before honouring it. An unrecognised value attributes nothing and grants nothing, so a client ID copied out of someone else's page cannot be used to claim analytics or pollute their numbers.
Servers deployed before you subscribed are still attributed and still appear in Embed Usage. Telemetry behind every tier is recorded on every request regardless of what is unlocked, so subscribing backfills history rather than starting a new clock.
What you cannot see
Embed Usage is aggregate by design. You see server names and usage totals for servers carrying your client ID. You do not see your end users' identities, their raw tool inputs, or anything about servers they created directly in MCP Studio outside your integration. Per-request detail stays in the end user's own dashboard, which is what your subscription grants them.
When numbers are empty
Embed Usage reports zeroes until an end user deploys a server from your embed and an AI agent queries it. Testing the wizard without completing a deployment produces no data, because there is no server yet.
Related
- Configure your widget — where the analytics settings live
- SDK plan limits — tier pricing and caps
- Action and Predictive analytics — what each tier shows your end users