Measure.events Analytics

Track event

track_event

Record a pageview: an agent's own visit, or a request your server forwards. Pass user_agent to classify a forwarded request; otherwise it counts as an AI agent visit under agent (default: the API key's name).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site_key": "<site_key>",
      "path": "<path>"
    },
    "name": "track_event"
  }
}

Input Schema

Name	Required	Description
`path`	Yes	Page path, e.g. /about.
`agent`	No	Agent name for attribution.
`referrer`	No	Referring URL (only the host is kept).
`site_key`	Yes	The site's tracking ID (site_key), from list_sites.
`user_agent`	No	User agent of a forwarded request (classified, never stored).
`utm_medium`	No
`utm_source`	No
`utm_campaign`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 23, 2026

changedInput schema / properties / agent / description

Previous value: -"Agent name for attribution"New value: +"Agent name for attribution."

changedInput schema / properties / path / description

Previous value: -"Page path (e.g. /about)"New value: +"Page path, e.g. /about."

changedInput schema / properties / referrer / description

Previous value: -"Referring URL"New value: +"Referring URL (only the host is kept)."

changedInput schema / properties / site_key / description

Previous value: -"The site's tracking ID"New value: +"The site's tracking ID (site_key), from list_sites."

addedInput schema / properties / user_agent

Added value: +{
+  "description": "User agent of a forwarded request (classified, never stored).",
+  "type": "string"
+}

First observedMar 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=false; the description meaningfully adds the write's semantics: what gets recorded, how the classification branch works, that user_agent is only used for classification, and the default attribution source. It does not discuss failure modes, deduplication, or whether repeated calls double-count, which would matter for an ingestion tool.

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

Conciseness5/5

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

Two sentences, zero filler, with the core action and the key branching decision front-loaded ahead of the attribution detail. Nothing could be cut without losing decision-relevant information.

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 an 8-parameter write tool with no output schema and no return-value documentation need, the description covers the primary decision path and attribution model. Minor gaps (utm_* semantics, error/rate-limit behavior) keep it from full completeness.

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?

With 63% schema coverage across 8 params, the description adds real meaning beyond the schema by explaining the conditional relationship between user_agent and agent, and the default for agent. The three utm_* parameters remain undocumented in both schema and description, leaving a partial gap.

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?

Opens with a specific verb+resource ("Record a pageview") and immediately splits it into two concrete modes: the agent's own visit, or a forwarded server request. That scope distinction is unique among the siblings, which are all read-oriented (get_*, list_*), though the description never explicitly draws that contrast.

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 a clear conditional for the main usage decision: pass user_agent when the pageview is a forwarded request, omit it when recording your own visit. It also states the attribution fallback (the API key's name). It stops short of naming when NOT to call this tool (e.g., versus get_live or a batch path) or any prerequisites.

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

All Measure.events Analytics 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.