Skip to main content
Glama
Sign In

Privatrak

by com.privatrak
OverviewDiscussionsAdmin

Feature usage over time

get_feature_timeseries
Read-onlyIdempotent

Daily or hourly usage counts for the top features in a date range, plus totals (interactions, visitors, interactions per visitor) for the range and for the equally long period before. Features are only events with a data-track name or matched by a feature rule; untagged clicks are not features. By hour: the current hour is incomplete, later hours read 0. 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. 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.

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

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'.
limitNoHow many of the top features to chart, 1-20. Default 5.
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).
granularityNoday (default) or hour. hour needs a range of at most 31 days, from and to both included; its points are the hours of the project's timezone (23 or 25 on a day the clocks change), each with date (its day) and start (the hour with the project's UTC offset). Totals are the period's either way.

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 cover the read-only/idempotent/closed-world profile, yet the description adds substantial behavior beyond them: the approximation model for unique_sessions (per-day rotating hash summed over days, merging/splitting visitors), incomplete current-hour reads of 0, calendar-day vs UTC timestamp handling, and the effect of inclusive partial ranges. This is exactly the kind of behavioral context annotations cannot express.

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 the core purpose, then dense but load-bearing caveats about feature definition, hour incompleteness, defaults, and the visitor approximation. Every sentence carries information, though the run-on density of the timezone/visitor sentences slightly hurts readability.

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?

For a 6-param, no-output-schema analytics tool, the description covers inputs (date semantics, granularity, feature definition), outputs (counts, totals, interactions per visitor), and known data-quality caveats (approximate visitors, incomplete hours, partial today). Nothing an agent needs to call and interpret it correctly 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 100%, so the schema already documents each parameter; the description adds meaning on top by explaining the default window logic, the prior-period comparison for totals, and the hour-granularity offset/total semantics (23/25-hour days). It does not, however, address every parameter individually (e.g. trait, limit), so it exceeds the baseline without fully covering all params.

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+resource+scope: 'Daily or hourly usage counts for the top features in a date range, plus totals... for the range and for the equally long period before.' This clearly separates it from siblings like list_features (enumeration) and get_funnel_trend (funnel-specific), and even defines what counts as a 'feature' (data-track name or feature rule, not untagged clicks).

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 concrete usage conditions: omit from/to for the last 28 complete days, hour granularity requires a range of at most 31 days, and warns that including today reads as a drop. It does not, however, explicitly name an alternative sibling (e.g. get_funnel_trend) or state when this tool should be avoided in favor of one, so it stops short of the top score.

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