GrowSurf

Get Participant Analytics

growsurf_get_participant_analytics

Read-onlyIdempotent

Fetch analytics for one participant by GrowSurf participant ID or email. The base response includes all-time engagement, rank, share, and applicable affiliate revenue, commission, and payout metrics. Add activation to include for the program-specific eligibility anchor and covered first milestones, including firstPortalViewedAt and firstShareChannel. A null milestone with a partial or unavailable state is unknown, not proof that the action never happened. Request both activation and series for covered portalViews and shareActions buckets. Filter optional series and email data with days (up to 1825) or both startDate and endDate as positive Unix timestamps in milliseconds. endDate must be at or after startDate, and the range can span at most 1825 days. These date parameters do not filter the base response or activation milestones. Targets campaignId if passed, otherwise GROWSURF_CAMPAIGN_ID.

Input Schema

Name	Required	Description
`days`	No	Number of days for optional `series` and `email` analytics. Does not filter the all-time base response.
`endDate`	No	End of the optional-data timeframe, positive Unix timestamp in milliseconds. Supply `startDate` too; `endDate` must be >= `startDate` and at most 1825 days later.
`include`	No	Comma-separated optional data. Current values are `series`, `email`, and `activation`; the API returns `400` for unknown values.
`interval`	No	Bucket size for `series` and email series. Defaults to `day`.
`startDate`	No	Start of the optional-data timeframe, positive Unix timestamp in milliseconds. Supply `endDate` too; the window must span at most 1825 days.
`campaignId`	Yes	Target program (campaign) id for this call. Defaults to GROWSURF_CAMPAIGN_ID when omitted. Program IDs also identify newly created programs without restarting the server.
`participantId`	No
`participantEmail`	No

Output Schema

Name	Required	Description
`email`	No	Sent, delivered, opened, clicked, bounced, and spam complaint metrics for program emails in the requested window.
`ranks`	No	Leaderboard ranks for this participant.
`series`	No	This participant's per-period activity. Present when `include` contains `series`.
`endDate`	No	Window end (Unix ms). Present with `series` or `email`.
`analytics`	No	All-time participant analytics totals. Date-window parameters do not filter these fields.
`startDate`	No	Window start (Unix ms). Present with `series` or `email`.
`activation`	No	Opt-in covered eligibility and first-milestone analytics for one participant.
`shareCount`	No	Per-channel share counts (e.g. `email`, `facebook`, `twitter`).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 8, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a safe read (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavior: what the base response contains, what `activation` unlocks, the 1825-day cap, and the crucial null-milestone interpretation rule. It also warns that date params do not filter the base response or milestones.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and then layers optional behavior; nearly every sentence carries non-obvious rules. It is dense and slightly long, but no sentence is pure filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 8 parameters and conditional (anyOf/allOf) schema constraints, the description covers the base vs optional response split, include semantics, date-window rules, and the null-milestone caveat. With an output schema present, no return-format explanation is needed, so nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so the schema already documents most parameters. The description still adds integration-level meaning: that date params do not filter the base response, that `endDate` must be >= `startDate` within 1825 days, and the campaignId targeting fallback to GROWSURF_CAMPAIGN_ID.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Fetch) and resource (analytics for one participant) plus the two identification keys (participant ID or email). The 'one participant' scoping cleanly distinguishes it from the campaign-level siblings like get_campaign_analytics and get_campaign_activation_analytics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit conditional guidance: add `activation` for eligibility/milestones, request both `activation` and `series` for covered buckets, and how to bound ranges with `days` or `startDate`/`endDate`. It lacks explicit routing against adjacent siblings (get_participant, get_participant_activity_logs), so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All GrowSurf tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.