Skip to main content
Glama
Sign In

Privatrak

by com.privatrak
OverviewDiscussionsAdmin

Review data

get_review_data
Read-onlyIdempotent

The numbers an AI review of one scope is built on, built by Privatrak: the whole site, one page or one funnel's flow, optionally against a key action (a feature or a funnel). Fixed sections for the scope, each with a plain summary; checks (candidates for what stands out, sorted by the views they affect); and data notes (automated share, origins that began reporting mid-period, a previous period that cannot be compared, bursts). save_review builds the same data again and stores it with the review. Views by people leave out automated visits; flow numbers include them. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. At most 92 days.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_review_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLast day, YYYY-MM-DD in the project's timezone, inclusive. Default: yesterday, the last complete day.
fromNoFirst day, YYYY-MM-DD in the project's timezone, inclusive. Default: 27 days before 'to'. At most 92 days.
scopeNosite (the whole project), page (one page: page_origin and page_path) or flow (one funnel's flow: funnel_id). Left out: page when page_origin or page_path is given, flow with funnel_id, otherwise site.
projectNoProject ID, from list_projects. Required when this connection covers more than one project; may be left out when it covers one (and with an API key, which belongs to one project).
funnel_idNoScope flow: the funnel's id, from list_funnels.
page_pathNoScope page: the page's path, exactly as list_pages gives it (e.g. /pricing, or /products/:id rather than one product's URL). It needs page views in the period.
page_originNoScope page: the page's origin, exactly as list_pages gives it (e.g. https://shop.example.com).
goal_featureNoOptional key action to judge against: a feature name, exactly and case-sensitively as list_features or list_feature_rules gives it. Adds key action clicks per page and the goal_gap check. Not together with goal_funnel_id.
goal_funnel_idNoOptional key action to judge against: a funnel's id, from list_funnels (a goal, is_goal true, is the natural one); adds its funnel_steps to a site or page review. Not for scope flow, whose funnel is its key action already; not together with goal_feature.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

With readOnly and idempotent already in annotations, the description still adds substantial behavior: views exclude automated visits while flow numbers include them, data notes surface automated share, origins that began reporting mid-period, non-comparable previous periods, and bursts, and checks are described as sorted by affected views. It also pins down calendar-day/timezone semantics and that timestamps are UTC. This is output-shaping context an agent could not get from the annotations.

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

Conciseness3/5

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

Every sentence carries technical content, but the whole description is one dense, comma-chained paragraph with an indirect opening. Key operational constraints (defaults, 92-day limit) are buried mid-paragraph rather than front-loaded, making it harder to scan than its length warrants.

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

Completeness4/5

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

For a 9-parameter tool with no output schema, the description does real work: it names the response sections, explains what checks and data notes contain, and states date/timezone rules and the automated-traffic caveat. It stops short of describing the concrete response shape or any pagination/size limits for large scopes, leaving a modest gap.

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 100%, so the baseline is 3, but the description adds consequence-level meaning: goal_feature 'adds key action clicks per page and the goal_gap check,' goal_funnel_id 'adds its funnel_steps to a site or page review' and is not for scope flow, and date defaults are restated compactly. It largely mirrors the schema on scope/page fields, which caps it below 5.

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

Purpose4/5

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

The description identifies the resource concretely: the data an AI review of one scope is built on, with fixed sections (scope summary, checks, data notes) and scope options (site, page, flow). It also distinguishes itself from save_review, which 'builds the same data again and stores it with the review.' The opening phrase is abstract and there is no crisp verb, which keeps it from a 5.

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

Usage Guidelines3/5

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

It explains the save_review relationship and gives a default window (omit from/to for the last 28 complete days) plus a 92-day cap, which is real usage guidance. However, it never says when to pick this over get_overview, get_flow, get_funnel_trend, or run_insights_query, and there are no explicit when-not conditions beyond the goal_* exclusions.

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

All Privatrak toolsInspect
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.

Resources