Measure.events Analytics

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds scope information beyond the annotations — the exact set of report sections returned — which is genuinely useful, but it says nothing about payload size, latency, or whether the large combined response is expensive to fetch.

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

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

A single compact sentence, front-loaded with the key value proposition ('Everything in one call') followed by a dense enumeration of contents. No filler sentences and nothing repeated from the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 burden of explaining return contents, and it does so thoroughly by listing all report sections. It is only slightly short of complete in that it omits any signal about response size or whether results are scoped to a time window it chooses itself vs. one the caller supplies.

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

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

Schema description coverage is 100%: the single site_key parameter is fully documented in the schema, including that it comes from list_sites. The description adds no additional meaning about the parameter, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (an agent report) and enumerates its contents — 7/30-day traffic, daily series, pages, referrers, channels, agents, insights, check-ins, recommendations — so an agent knows exactly what data comes back. It doesn't use an explicit verb and only implicitly distinguishes itself from granular siblings like get_site_summary, get_breakdown or get_insights via the phrase 'Everything in one call'.

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

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

'Everything in one call' hints that this is the bundled alternative to the granular sibling tools, which is an implied use case. However, there is no explicit when-to-use or when-not-to-use guidance (e.g., 'prefer get_site_summary for a lightweight check'), so the agent must infer the selection logic.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful return-field context by naming operator, purpose, requests, and top page, but it does not describe pagination, ordering, defaults, or result format.

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

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

The description is a single front-loaded sentence with no filler. It efficiently lists the key returned attributes and earns every word.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only analytics tool with full schema coverage and clear annotations, the description is nearly complete. It lists the returned fields, though it omits return format and pagination details that could matter since no output schema exists.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description adds no parameter-level meaning beyond what the schema provides, which is acceptable but not additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource and returned fields: every AI agent that fetched the site, with operator, purpose, requests, and top page. It does not explicitly distinguish this from the sibling get_agent_report, so it stops short of a 5.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as get_agent_report or get_site_analytics. It also does not mention date-range or period selection behavior, leaving usage entirely implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered, but the description adds no behavioral context at all. It does not say what is counted, how results are ordered, what the default limit is, or that period is ignored when from/to are supplied (that only appears in the schema).

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

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

One front-loaded sentence with no filler, which is appropriate for a simple read tool. The enumerated dimension list is slightly redundant with the schema enum but does aid quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With seven parameters, no output schema, and no return-shape documentation, the description needs to explain what a 'breakdown' row contains and how it is sorted. It omits the metric being aggregated, ordering, and default limit behavior, leaving an agent unable to predict results.

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

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

Schema coverage is 71%, so most parameters (to, from, period, traffic, site_key) already carry their own descriptions. The only thing the description contributes is the dim value list, which merely restates the enum, and it leaves 'limit' unexplained. This meets the baseline but adds no meaning beyond structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It says it returns 'top values of one dimension' and enumerates the dimensions, which gives a rough sense of an aggregation call. But it never names what is being ranked (visits? pageviews? unique visitors?) and does not distinguish it from analytics-flavored siblings like get_site_analytics or get_site_summary.

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

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

There is no statement of when to pick this over get_site_analytics, get_site_summary, or get_agent_report, and no prerequisites or exclusions are given. The agent must infer the use case entirely from the name and enum list.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the description only adds the temporal framing ('now', 'latest requests'). It does not define the real-time window (e.g., last 5 minutes), whether results are polled/sampled, any row limits on 'latest requests', or what an empty site returns — all behavior an agent needs to interpret the output correctly.

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

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

It is short and front-loads the core concept, so nothing is wasted, but it is a noun phrase rather than a sentence and omits the action entirely. Brevity here trends toward under-specification rather than economy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description must convey what comes back; 'visitors and latest requests' gives only a vague shape with no field names, counts, or ordering. For a real-time endpoint whose return semantics are the whole point, the definition leaves too much for the agent to guess.

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

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

Only one parameter exists and the schema documents it fully at 100% coverage, including where to obtain it ('from list_sites'). The description adds nothing about site_key, but with a single fully documented parameter the schema carries the burden, warranting the baseline of 4 for a 1-param tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The fragment 'Visitors on the site now and the latest requests' identifies the resource (live visitor count plus recent requests) but supplies no verb and no scope statement, so it reads as a data blurb rather than an action. It is distinguishable in spirit from historical siblings like get_site_summary or get_site_analytics, but that distinction is inferred from the word 'now' rather than stated.

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

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

There is no explicit when-to-use guidance, no mention of when to prefer get_site_summary or get_site_analytics instead, and no prerequisites. The only cue is the implicit 'now' in the description, leaving the agent to infer that this tool is for real-time rather than historical data.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds two real facts: the window is fixed at the last 30 days and the payload comes back as short Markdown. It does not say how short, what metrics are included, or whether output is truncated, which matters for a context-window-targeted tool.

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

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

One short sentence with no filler, and the two most decision-relevant facts (30-day window, Markdown format) are front-loaded. It is terse to the edge of under-specification, but nothing in it is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only tool with no output schema, the description covers the essentials: fixed window and return format. It leaves unclear what analytics content the document actually contains and how large it is, which is the main open question for a tool explicitly aimed at context windows and one of a dozen analytics siblings.

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

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

Schema description coverage is 100% and the single site_key parameter is already documented in-schema, including its cross-reference to list_sites. The description adds nothing about the parameter, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"The last 30 days as a short Markdown document" conveys the output shape and window, but it is a noun phrase with no verb or resource — the agent must infer from the name and title that this retrieves site analytics. With siblings like get_site_summary, get_site_analytics, and get_agent_report, there is no differentiation at all, so distinguishing it requires opening the schema.

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

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

"for context windows" implies a use case: call this when you need compact text to feed an LLM rather than structured data. That is a genuine (if terse) usage hint, but it never names an alternative or states when-not to use it versus get_site_summary or get_site_analytics, which overlap heavily.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context about what comes back (tracking script, 7-day pageview window), but says nothing about scope limits, auth requirements, or whether the list is truncated for large accounts.

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

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

A single well-formed sentence with the verb and return payload front-loaded. Every clause (site_key, tracking script, last-7-day pageviews) earns its place by previewing output the schema cannot express.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and no output schema, the description carries the burden of describing return values, which it does partially by naming three fields. It's adequate for a trivial listing tool, though it could note whether results are paginated or ordered.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly signals the no-argument nature by implying a simple full listing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List your sites') and goes further by naming the fields returned (site_key, tracking script, last-7-day pageviews), which separates it from siblings like get_site_analytics or get_site_summary. It doesn't explicitly name those siblings, so it stops short of a 5.

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

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

The listing nature plus the mention of site_key implies the discovery/entry-point role, but the description never says when to use this instead of a per-site tool or what to do with the returned site_key. The usage is inferable but not stated.

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

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

Annotations only say readOnlyHint=false and openWorldHint=false; the description adds the material side effects: a 14-day trial begins, an API key and tracking script are issued, and the billing contact receives an out-of-band email with a claim link and card prompt. It also discloses that no API key is required for the call itself, which is the auth-model detail an agent most needs.

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

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

Two dense sentences, front-loaded with the action and then the lifecycle and side effects. Every clause carries information an agent needs (trial length, returned credentials, claim flow, no-key access) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nested-object, no-output-schema mutation tool, the description covers the account lifecycle and the pre-claim state well, so an agent knows the account is not fully usable until billing claims it. Gaps remain around the `site`/`agent` object semantics and failure modes (e.g. duplicate domain or invalid domain), but the core behavior is complete.

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

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

Schema description coverage is only 25%: the `site` object (with required `domain`) and `billing_contact_name` are undocumented, and the description compensates for none of them. What it does say about the billing contact ('emailed a link to claim the account and add a card') largely restates the schema's own description of billing_contact_email, so it adds little beyond structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a Measure account') and immediately qualifies the unusual agent-initiated variant ('without a human'). It also names the concrete outputs (API key, tracking script, claim email), so an agent knows exactly what this does and what it yields, with no sibling tool in the list offering anything similar.

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

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

'Without a human' plus 'No API key needed' tells the agent this is the unauthenticated, agent-driven entry point, which is the key selection condition. It stops short of explicit when-not guidance (e.g. what to do if an account already exists, or which sibling to use after signup), leaving that to inference.

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