Tracklution

query_events

Note: this tool holds data for a limited timeframe — only the last ~7-14 days are available, depending on the container.

Paginated list of raw events for a date range, with filters (event_name, source, status, and 10 has_* click-ID presence flags).

DATA RETENTION: the v2 store currently holds only the last ~7-14 days. Older date_from values pass validation but return empty rows. A "warnings" array is added when date_from is outside the retention window.

USE WHEN:

User wants to loop through all events for a given date range, inspecting data from each one in detail.
User wants to enumerate events matching a filter (e.g. "show all Purchase events with gclid this week", "list error events from yesterday").
User explicitly wants raw event records, not aggregates.

DON'T USE for counts, totals, top-N rankings, breakdowns by source/day — use get_report (orders of magnitude faster on aggregates). For a single event by ID, use list_events.

STATUS FILTER: defaults to "processed" — these are the real, successfully-recorded events that nearly every analytics question is about. Only set status explicitly when debugging delivery/ingestion issues: "pending" (queued, not yet processed), "error" (processing failed), "rejected" (validation/spam blocked). Asking for non-processed events without a debugging reason will mislead the user.

Pagination is cursor-based: pass the returned meta.cursor.next_cursor back as cursor on the next call. Stop when has_more is false. Backend caps date range at 30 days.

Input Schema

TableJSON Schema

Name	Required	Description
`cursor`	No	Pagination cursor from a previous response's meta.cursor.next_cursor.
`source`	No	Filter by traffic source
`status`	No	Filter by event status. Default: "processed" (real, successfully-recorded events — what nearly every analytics question is about). Override only for debugging: "pending" (queued), "error" (processing failed), "rejected" (validation/spam blocked).
`date_to`	Yes	End date (YYYY-MM-DD)
`has_epik`	No	Only events arriving with a Pinterest epik
`per_page`	No	Items per page (default 50, max 1000 on v2). v2 SQLite reads are fast enough to prefer larger pages over more cursor round-trips.
`date_from`	Yes	Start date (YYYY-MM-DD)
`has_adfcd`	No	Only events arriving with an Adform adfcd
`has_gclid`	No	Only events arriving with a Google Ads gclid
`event_name`	No	Filter by event name
`has_fbclid`	No	Only events arriving with a Facebook fbclid
`has_lsclid`	No	Only events arriving with an lsclid
`has_scclid`	No	Only events arriving with a Snapchat scclid
`has_ttclid`	No	Only events arriving with a TikTok ttclid
`has_ga4clid`	No	Only events arriving with a GA4 client ID
`has_msclkid`	No	Only events arriving with a Microsoft msclkid
`has_rdt_cid`	No	Only events arriving with a Reddit rdt_cid
`server_name`	No	Server name (required when connected to multiple servers).
`container_id`	Yes	Container ID (starts with "trc_").
`has_li_fat_id`	No	Only events arriving with a LinkedIn li_fat_id

Output Schema

TableJSON Schema

Name	Required	Description	Default
`meta`	Yes
`events`	Yes
`warnings`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the 7-14 day retention window, the fact that older date_from values pass validation but return empty rows, the warnings array behavior, the default status filter, and cursor-based pagination semantics (pass next_cursor, stop when has_more is false, 30-day backend cap). This is rich behavioral context beyond what the schema could convey.

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?

The description is well-structured with clear sections (retention note, USE WHEN, DON'T USE, STATUS FILTER, pagination) and front-loads the most critical caveat (limited timeframe). It is longer than average, but every section earns its place given the tool's complexity and the absence of annotations. Minor redundancy exists between the opening retention note and the DATA RETENTION section.

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 20-parameter tool with no annotations, the description covers all the non-obvious context an agent needs: retention limits, status semantics, pagination mechanics, and sibling routing. The output schema exists, so return-value details don't need to be in the description. The only minor gap is that it doesn't explicitly state the default per_page value, but the schema already documents that.

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. The description adds meaningful value beyond the schema by explaining the status default and its debugging-only use case, the retention-window interaction with date_from, and the per_page performance guidance. It doesn't enumerate every has_* flag, but the schema already documents those clearly, so the description doesn't need to.

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 specific verb and resource ('Paginated list of raw events for a date range') and immediately distinguishes it from siblings by naming get_report and list_events as alternatives. It also clarifies the scope (raw events, not aggregates), which prevents confusion with query_sessions and get_summary.

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

Usage Guidelines5/5

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

The description provides explicit USE WHEN and DON'T USE sections, naming get_report for aggregates and list_events for single-event-by-ID lookups. It also gives detailed guidance on the status filter, warning that non-processed statuses should only be used for debugging. This is exemplary routing guidance.

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

All Tracklution 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?