Privatrak

Elements people used

list_elements

Read-onlyIdempotent

What people clicked and submitted in a date range: one row per element (event type, page, text, tag, generalized selector), most events first. features lists every feature counting its events today, with via (data_track or rule): an event counts toward every feature naming it, so these can sum to more than events. unassigned_events: events no feature names; unassigned=true keeps only rows where that is all of them. total_events sums events over every matching row, all pages. Events, not visitors. Pageviews and custom events are not listed. At most 92 days per call. 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. 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": "list_elements"
  }
}

Input Schema

Name	Required	Description
`to`	No	Last day, YYYY-MM-DD in the project's timezone, inclusive. Default: yesterday, the last complete day.
`from`	No	First day, YYYY-MM-DD in the project's timezone, inclusive. Default: 27 days before 'to'. At most 92 days in one call.
`page`	No	Page number, from 1.
`limit`	No	Rows per page, 1-100. Default 50.
`search`	No	Case-insensitive substring of the element's text or generalized selector.
`project`	No	Project 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).
`page_url`	No	Only elements on this page, as a full URL (e.g. https://shop.example.com/pricing). Normalised like ingestion and matched on both origin and path, so staging and production stay apart. Not together with page_path or page_origin.
`page_path`	No	Only elements on this page path, exact, as stored (e.g. /products/:id). Alone it matches every origin; combine with page_origin when two hosts serve the same path. Not together with page_url.
`event_type`	No	click or form_submit. Default both.
`unassigned`	No	Only elements none of whose events belong to any feature.
`page_origin`	No	Only elements on this page origin, exact, as stored (e.g. https://app.example.com). Combine with page_path when two hosts serve the same path. Not together with page_url.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, closed-world), while the description adds substantial behavior: the 92-day cap, project-calendar vs UTC timestamp semantics, the default range, the unit of measure ('Events, not visitors'), and explicit exclusions ('Pageviews and custom events are not listed'). It also explains the non-obvious feature-assignment counting logic where per-feature events can sum above total events.

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 return shape and result ordering, and for an 11-parameter analytics tool the density is largely earned. It is a single dense paragraph that interleaves output-column explanation with usage constraints, so structure is serviceable rather than clean.

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 carries the return-shape burden and does so: it enumerates the per-row fields, the features/via structure, unassigned_events, and total_events semantics. Combined with date defaults, the 92-day limit, and the events-not-visitors caveat, an agent has what it needs to call and interpret the result.

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

Parameters3/5

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

Schema description coverage is 100%, so every one of the 11 parameters is already documented in the schema; baseline 3 applies. The description reinforces defaults and timezone handling but adds little parameter-level meaning beyond what the schema already states.

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?

States a concrete resource and output shape: 'one row per element (event type, page, text, tag, generalized selector), most events first' over a date range. An agent knows exactly what comes back, though no sibling tool (e.g. list_pages, list_click_problems) is named to sharpen the boundary.

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?

Operational guidance is present and useful: 'Omit from/to for the last 28 complete days', 'At most 92 days per call', and 'unassigned=true keeps only rows where that is all of them'. What is missing is selection guidance – nothing says when to reach for this versus list_pages, list_click_problems, or a feature-oriented tool.

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

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

Resources

Need Help?