MCP

SnipForm runs one MCP server per property. Connect Claude, Cursor or any MCP client to it and you can ask questions in plain language - “how did traffic compare to last week”, “where do people drop out of the signup funnel” - and the assistant answers from your real data instead of guessing.

https://api.snipform.io/mcp/{propertyId}

One command in most clients:

claude mcp add --transport http snipform-example-com https://api.snipform.io/mcp/PROPERTY_ID

A browser window opens, you approve the connection once, and the assistant can start asking. The exact command, with your property id and a server name already filled in, is on the property’s API page at https://app.snipform.io/property/{property}/api.

• Connect a client - sign-in (OAuth) and token flows for Claude Code, Claude Desktop, Cursor and anything with a config file.
• Tool reference - the 12 tools the server exposes, every parameter, the window vocabulary and the limits.

What it can answer

The tools cover the analytics surface of a property:

• Session counts, page views, views per session, time on site, scroll depth and bounce rate over any window
• Breakdowns by country, device, browser, landing page, exit page, referrer, UTM, channel or screen size
• Trends bucketed by hour, day, week or month, and one window compared with the window before it
• Every conversion on the property, with entries, conversion rate, value and step-by-step funnel drop-off
• The last 12 weekly reports, including which checks were triggered
• Ad spend and performance per platform (Google Ads, Meta), with CPA and ROAS where a conversion is linked, plus a connection diagnosis tool

Every tool accepts the same optional filters (country, device, UTM, channel, and so on), numeric ranges (time on site, views, scroll, viewport), a bounce filter and an event filter, so “bounce rate on mobile for visitors who came from paid search” is one tool call.

What it cannot do

Nothing reachable over MCP can change your data. That is enforced in code, not left to the assistant’s good behaviour: every tool is wrapped by a bridge that declares itself read-only and idempotent, and a test scans the whole reachable surface for writes and fails the build if any appear.

• No writes. There is no tool that creates, edits or deletes anything.
• No other property. A connection is pinned to exactly one property. The property id is stripped from every tool’s advertised schema and injected server-side from the token, so a client cannot name a property at all - not even a sibling on the same account. A tool that takes a conversion_id resolves that conversion’s property and refuses it if it is not the pinned one.
• No individual visitors. There are no tools for contacts, emails, IP addresses or single sessions. Only counts, aggregates and groupings.
• No code execution. Tools run fixed, parameterised Elasticsearch aggregations.

Note

Your prompts never reach SnipForm. The assistant decides which tool to call; only that call and its JSON answer cross the wire. Every call is logged (tool name, arguments, duration, outcome) against the user who authorised the connection.

Two ways in

	Sign in (OAuth)	Token
Needs a token	No	Yes - an MCP token from the property’s API page
How it works	The client is refused, follows the discovery metadata to SnipForm’s authorization server, registers itself, and sends you to the normal consent screen	You paste a bearer token into the client’s config
Best for	Claude Code, Claude Desktop, Cursor, VS Code	Clients that cannot run an OAuth flow, and curl
Scope	The signed-in account’s access to the property named in the URL	Exactly one property, fixed when the token is created

OAuth is listed first on the API page because it needs nothing pasted anywhere. The token flow is the fallback. Both arrive at the same server with the same tools. See Connect.

Rate limit and errors

The MCP route is throttled at 60 requests per minute per token - harder than the REST API, because the caller is software and every tool call is an aggregation. An assistant that loops will hit this; the server’s instructions tell it to report an error rather than retry the same question differently.

Every tool returns one of two JSON shapes as its text content:

{ "ok": true, "data": { ... } }

{ "ok": false, "error": { "code": "tool_error", "message": "Unsupported window: last_3. Supported: live, today, ..." } }

HTTP-level failures, before any tool runs:

Status	Meaning
401	No bearer token, or an expired/revoked one
403	The token lacks the mcp:use scope (an API token was used), is bound to a different property than the URL names, or the property belongs to another account
404	No property with that id
429	Over 60 requests in a minute

What the assistant is told

The server sends these instructions to every connected client, with the property name and domain filled in:

Analytics for the SnipForm property “example.com” (example.com).

Every tool is scoped to this one property by the token, so there is no property argument to pass and no way to reach another property.

Rules:

• Prefer a named window over raw dates. Supported: live, today, yesterday, last_24h, prev_24h, last_7, last_28, month_to_date, year_to_date, last_12_months, last_week, prev_week
• Cite the numbers the tools return. Never estimate or fill gaps.
• Sessions default to real users. Ask for the bot or any audience only when the question is actually about crawler traffic.
• Every tool returns {ok: true, data: ...} or {ok: false, error: ...}. Report an error rather than retrying it as a different question.

Server name: SnipForm Signals, version 1.0.0.

MCP or the REST API?

Use MCP when a person is asking questions through an assistant. Use the REST API or the PHP SDK when your own code needs the data: the API has write endpoints, pagination, the full query language and the complete field catalog, none of which are exposed over MCP. The two also use slightly different vocabularies for windows and metrics - see the note on the Tools page.