Skip to main content
Glama
Sign In

Privatrak

by com.privatrak
OverviewDiscussionsAdmin

Traffic overview

get_overview
Read-onlyIdempotent

Headline numbers for a date range (events, unique_sessions, feature interactions, active features) against the equally long period before, with the percentage change, a daily series, top pages (page views) and features. 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. Today is still in progress: a range including it reads as a drop against complete days. A period marked starts_before_data begins before the project has data (see data_from): those days read as zero, not as a quiet period. unique_sessions (visitors) is approximate: counted per day from a daily-rotating hash and summed over days, so a returning visitor counts once per day, and shared or changing networks merge or split people. Quote counts with every percentage; a big change on a small count is noise, not a finding.

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_overview"
  }
}

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'.
traitNoOnly count visitors carrying this session trait value.
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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/closed-world, yet the description adds substantial behavioral disclosure beyond them: the default date window, the in-progress-day caveat, the starts_before_data zero-read trap, and the approximate unique_sessions counting model (daily-rotating hash, summed over days, merges/splits on shared networks). It even warns how to interpret results, which is genuinely valuable context for a read-only report.

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-loaded with what the tool returns, then caveats. It is dense and long, but nearly every sentence (defaults, in-progress day, starts_before_data, approximate visitors, quoting counts against percentages) carries distinct information rather than 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?

With no output schema, the description still enumerates the return payload (headline metrics, percentage change, daily series, top pages and features) and explains the interpretation traps. An agent has everything needed to call it correctly and to read the result sensibly.

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 real meaning: dates are the project's calendar days in the project timezone (per get_project) while timestamps are UTC, and it reinforces the default from/to behavior. The trait parameter is left to the schema, but the added date/timezone semantics justify a step above baseline.

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?

The description states a precise verb and resource: headline numbers (events, unique_sessions, feature interactions, active features) for a date range, plus the comparison, percentage change, daily series, top pages and features. This scope is specific enough to separate it from siblings like get_feature_timeseries, get_dashboard and get_funnel without opening their schemas.

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?

It gives clear usage context: omit from/to for the last 28 complete days, today is still in progress so including it reads as a drop, and a starts_before_data period reads as zero. It never names an alternative tool to use instead, so the when-not/alternatives half of the dimension is missing.

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