Cookieless web analytics your AI agent can read: traffic, spikes and what caused them, funnels.
Scored across 16 tools
Most tools have clearly distinct purposes: the top_* breakdowns target different dimensions, and spike detection vs. spike explanation are well differentiated by their descriptions. However, query_visits can reproduce what top_sources, top_countries, and top_pages return (its own examples show group_by=source/country), and get_whats_working vs. get_growth_actions both deliver marketing-planning insight, so a few selections could be confused.
Almost all tools follow a clean snake_case verb_noun pattern (get_overview, list_events, find_traffic_spikes, explain_spike, query_visits). The top_* group uses a noun-first 'ranking' label rather than a verb, but it is applied consistently across all five of those tools, so it reads as an intentional convention rather than a break.
At 16 tools this sits at the upper edge of the ideal 3-15 range, but the domain (analytics overview, time series, dimension breakdowns, funnels, campaigns, spikes, mentions, queries) is genuinely broad and each tool covers a distinct slice. No tool appears redundant enough to cut, though it is heavier than a minimal surface.
The read-only analytics surface is thorough: overview with period-over-period comparison, time series, all major top_* dimensions, custom events, funnels, campaign tracking, spike detection and explanation, external mentions, and a flexible filter/group query tool. No obvious analysis workflow hits a dead end.
Ranked causes for one spike: which referrers/UTM sources, landing pages and custom events rose above baseline (with lift, % and share of the spike), plus annotations (deploys, posts, emails) in the preceding 24h.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. | |
| spike_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the output includes lift/%/share metrics and annotations (deploys, posts, emails) are drawn from the preceding 24h window, which tells the agent the scope of the analysis.
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 front-loaded sentence that leads with the core purpose ('ranked causes for one spike') and packs the remaining detail into a compact parenthetical. Dense but with no filler sentences.
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 usefully enumerates what is returned (ranked dimensions with lift, %, share, plus recent annotations), which is what an agent needs to judge relevance. The main remaining gap is the undocumented spike_id input.
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 only 50%: the domain parameter is documented in the schema, but spike_id has no description anywhere. The description does not explain what a spike_id is, where it comes from, or how it relates to the returned ranking, so it fails to compensate for the coverage gap.
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 states precisely what the tool produces for a single spike: ranked causes across referrers/UTM sources, landing pages and custom events, with lift, percentage and share. It is clearly the 'explain one spike' counterpart to find_traffic_spikes, though it never names that sibling explicitly.
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 prerequisite (e.g. 'obtain spike_id from find_traffic_spikes'), and no alternatives named. The required spike_id and the 'one spike' phrasing only weakly imply the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detected traffic jumps (hourly pageviews far above the same hour in prior weeks), biggest first, each with its likely causes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows. Default 10. | |
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower. The description still adds real value beyond them: the detection method, the 'biggest first' ordering, and the fact that each result carries its 'likely causes' — a return-content trait the annotations say nothing about.
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 sentence that front-loads what the tool detects, then the ordering, then the payload. No filler, nothing 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 read-only analytical tool with no output schema and full parameter documentation, the description covers the essential ground: what counts as a spike, ordering, and the inclusion of causes. It stops just short of helping an agent decide between this and explain_spike.
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 each of the three parameters (limit, range, domain) is fully documented in the schema, including defaults and bounds. The description adds nothing about parameters, 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?
States a concrete verb-resource combination ('Detected traffic jumps') and defines the detection criterion precisely: hourly pageviews far above the same hour in prior weeks. It implicitly separates itself from raw-view siblings like get_timeseries by framing the output as anomalies with 'likely causes', but it never names an alternative explicitly.
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 when-to-use, when-not-to-use, or prerequisite guidance. With a sibling named explain_spike sitting right next to it, the definition leaves the relationship between detecting a spike and explaining one entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Traffic and same-day conversions per tracked campaign link, newest first. Omit campaign for all.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. | |
| campaign | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and closed-world behavior, so the safety profile is covered. The description adds genuine behavioral detail beyond that: result ordering ('newest first') and the default scope when campaign is omitted. It still says nothing about the time window covered or result volume/limits.
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 sentences, no filler, with the returned content front-loaded before the parameter behavior. Every clause carries information.
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 two-parameter read tool with no output schema, the description covers the return grain, ordering, and the one undocumented default. The notable remaining gap is the time period the conversions and traffic cover, since no date parameter exists to imply it.
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 50%, and the description goes directly at the undocumented parameter: 'Omit campaign for all' explains what a missing campaign value does, which the schema does not. The domain parameter is already well described in the schema, so the description adds value exactly where it is needed.
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 resource (traffic and same-day conversions per tracked campaign link) rather than a vague 'get data'. It is distinguishable from most siblings, though it never explicitly contrasts itself with get_timeseries or get_overview, which also report traffic.
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 only guidance is 'Omit campaign for all,' which describes a parameter default rather than when to choose this tool over alternatives. With 15 siblings, no condition for selecting get_campaign_results versus get_timeseries or top_sources is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where visitors drop off. Shows, for each step, how many visitors reached it, the share of the first step and of the previous step, how many were lost, and the biggest drop. Pass name or id for a saved funnel, steps to try an unsaved one, or nothing to get every saved funnel.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| name | No | ||
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| steps | No | Unsaved funnel: pages start with /, anything else is an event name. | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered structurally. The description adds value beyond that by disclosing the computed outputs (reached count, share of first/previous step, lost count, biggest drop) and the fact that an empty argument set fans out over all saved funnels — a behavior an agent would otherwise have to guess.
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 sentences, zero filler. The purpose leads, the metric enumeration follows, and the invocation modes close — a well front-loaded structure where every clause carries information.
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 correctly takes on the burden of describing the return shape, and it does so per-metric. Defaults for range and domain live in the schema. What is missing is precedence/conflict behavior when id, name and steps are combined, and any hint about error handling for invalid step paths.
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 only 60%, and the two undocumented-in-schema params (id, name) are the ones the description clarifies by tying them to the saved-funnel retrieval mode. It also explains the saved-vs-unsaved distinction for steps, which the schema does not. The remaining gap is the interaction when id/name and steps are both supplied.
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 headline 'Where visitors drop off' plus 'Shows, for each step, how many visitors reached it...' gives a specific verb+resource and even enumerates the computed metrics. The resource (funnel) is inherently distinct from every sibling in the list (top_pages, query_visits, get_timeseries), so an agent can route here without ambiguity.
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?
It explicitly defines the three invocation modes — pass name/id for a saved funnel, steps for an unsaved one, or nothing for all saved funnels — which is real when-to-use guidance. It does not, however, contrast this tool against adjacent analytics siblings like query_visits or get_overview, so the alternative-selection half of the guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked, concrete growth actions derived from this site's data (channels to double down on, pages to promote, what caused past spikes, best time to publish), each with evidence, steps, a suggested tracked link and how to measure it.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context by spelling out the shape of each returned item (evidence, steps, suggested tracked link, measurement method), which matters because there is no output schema. It does not mention compute cost, latency, or whether results are cached, which is a minor gap for what is likely an expensive derived-analysis call.
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 front-loaded sentence that leads with the value proposition and then lists the deliverable contents; nothing is wasted. The parenthetical enumeration is dense but earns its place given there is no output schema describing the return shape.
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 does the heavy lifting on return values and does it reasonably well, and both parameters are schema-documented. The remaining hole is the absence of any when-to-use routing against the 15 sibling tools, which for a recommendation-style tool is a meaningful omission.
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 both parameters (range with its max-90d/default-7d, domain with its sign-in default) are fully documented in the schema. The description adds no additional meaning about how range or domain affect the ranking, 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?
States a specific resource — ranked, concrete growth actions derived from the site's data — and enumerates the sub-types (channels, pages, spike causes, publish timing), which lets an agent distinguish it from data-listing siblings like top_pages or get_timeseries. It stops short of explicitly contrasting itself with the closest siblings (get_whats_working, explain_spike), whose territory it partially overlaps with 'what caused past spikes'.
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 never says when to reach for this tool versus the many alternatives in the sibling list, nor does it state any preconditions. An agent must infer from the name and content list that this is the prescriptive/recommendation tool rather than a raw-data tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Visitors and pageviews for the range, change vs the previous equal-length period, plus top sources, pages and events.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds one useful behavioral detail — the delta is computed against the previous equal-length period — and it sketches the returned payload, which matters because there is no output schema; however it omits how many top sources/pages/events are returned and how they are ranked or limited.
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 dense sentence with no filler, and the core metrics are front-loaded ahead of the breakdowns. It reads as a fragment rather than a sentence with a verb, but nothing 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?
With only two optional, fully documented parameters, complete annotations and no output schema, the description covers the return contents adequately for correct invocation. The one real gap is routing relative to overlapping sibling tools.
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%, with range syntax and the domain defaulting both fully documented in the properties. The description only echoes the range scoping ('for the range') and never mentions domain, so it adds nothing beyond the schema. 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 description names the concrete metrics (visitors, pageviews), the period comparison, and the three top-N breakdowns, so an agent knows exactly what comes back. It is clear but does not explicitly distinguish itself from overlapping siblings like top_sources, top_pages, or get_timeseries.
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 when-to-use guidance and no mention of alternatives, despite the sibling list containing several tools that return subsets of this same data. The agent must infer that this is the first-look aggregate because the name contains 'overview'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pageviews and unique visitors over time, bucketed by hour or day.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. | |
| granularity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing further — no note on return shape (series of buckets), pagination, or what happens with an out-of-range window beyond the schema's 90d cap.
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 front-loaded sentence that states the metrics and the bucketing dimension with no filler. It is efficient, though it is terse enough that it could have afforded one more clause of context.
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?
Three optional parameters, no output schema, and a read-only analytics purpose — the essentials are present but thin. Without an output schema, the description should ideally sketch what a result looks like (hourly/daily buckets with two metrics), which it only hints at.
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 67%: range and domain carry descriptions, while granularity is only an enum with no prose. The description's 'bucketed by hour or day' supplies the missing meaning for granularity, keeping this at the baseline 3 with a modest addition.
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 specific metrics (pageviews, unique visitors) and the time-bucketing behavior, which is more concrete than a tautology. It does not, however, explicitly distinguish itself from close siblings like get_overview or query_visits, so the agent must infer the boundary.
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 when-to-use guidance, no prerequisites, and no mention of alternative tools such as get_overview for a summary or query_visits for raw rows. The agent is left to infer that this is the time-series variant of the traffic tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evidence for marketing planning: channels ranked by conversions with growth and conversion rate, growing pages, and spike causes that recur.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered without the description. The description adds content-level transparency (what the report aggregates) but says nothing about freshness, caching, or how 'spike causes that recur' is determined. A 3 fits given annotations carry the behavioral load.
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 front-loaded sentence that leads with the purpose and then lists the three content groups. No filler, though the trailing clause 'spike causes that recur' is slightly cryptic and could be sharper.
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 describing returns, and it does enumerate the three report sections. Annotations cover safety and both parameters are documented in the schema. The only gap is that the boundaries against overlapping aggregate siblings remain unstated.
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 both parameters document their format and defaults ('24h'/'7d'/'30d' max 90d; domain defaulting to the sign-in site). The description adds no parameter detail, 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 description names the resource precisely and enumerates its contents: channels ranked by conversions with growth and conversion rate, growing pages, and recurring spike causes. An agent can tell it produces a synthesized 'what's working' report. It does not, however, differentiate itself from overlapping siblings like get_overview, get_growth_actions, or find_traffic_spikes.
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 phrase 'Evidence for marketing planning' implies the use case, giving implied rather than explicit guidance. There is no statement of when to prefer this over get_overview or get_growth_actions, and no exclusions or prerequisites. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Custom events (from measuremysite.track) ranked by count.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows. Default 10. | |
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=false). The description adds one genuinely useful behavioral trait beyond them: results are ranked by count. It says nothing about response shape, whether zero-result domains return empty, or how 'custom' events are defined, so it is minor value on top of annotations.
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 front-loaded sentence with no filler and no repetition of schema or annotation content. It is efficient, though arguably too terse to carry everything this tool needs.
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 simple, all-optional three-parameter read tool with full schema coverage and annotation-backed safety, the description is minimally adequate. However, there is no output schema, so the description could reasonably have said what an event row contains; it only notes the ordering, leaving return shape unexplained.
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 100% with documented defaults, ranges, and the max 90d constraint, so the schema does the heavy lifting and baseline 3 applies. The description adds no parameter meaning of its own.
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 a specific resource (custom events from measuremysite.track) and its ordering (ranked by count), so an agent can tell this apart from generic listing siblings like top_pages or query_visits. It does not explicitly contrast itself with those siblings, but the scope is unambiguous.
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 when-to-use guidance, no alternates named, and no prerequisites stated. The purpose implies a listing use case, but nothing tells the agent when to pick this over top_pages, query_visits, or the other analytics siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public posts and comments on Hacker News, Lobsters (and Reddit when enabled) that link this site, newest first, with score, comments and an estimate of the visitors that platform sent in the 48 hours after. The visitor figure is an estimate; campaigns created as tracked links have exact numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows. Default 10. | |
| range | No | Lookback window such as "30d" or "90d" (max 90d). Default "30d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. | |
| platform | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-open-world), and the description adds genuinely useful context: results are ordered newest first, the visitor figure is a 48-hour estimate, and tracked-link campaigns yield exact numbers instead. Rate limits and pagination behavior are not mentioned, but the estimate-versus-exact caveat is a meaningful disclosure beyond the annotations.
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 sentences, with the resource and source platforms front-loaded and the estimate caveat placed last where it matters. Nothing is padded, though the platforms parenthetical slightly muddies the opening sentence.
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 return-shape burden and does name the key fields (score, comments, visitor estimate) plus ordering. It lacks any note on pagination or result limits beyond the schema's default, but is largely sufficient for a simple read-only listing tool.
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 75%, with limit, range, and domain already documented in the schema, so the baseline is 3. The description adds the data window for the visitor figure but omits half the platform enum (x, linkedin, bluesky, youtube, web) while naming only hn, lobsters, and reddit, which could mislead an agent about valid values.
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 a specific verb and resource ('public posts and comments ... that link this site') and enumerates what comes back (score, comments, visitor estimate), which clearly separates it from sibling aggregations like top_sources or query_visits. An agent can identify the tool without 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?
Usage is only implied: it shows inbound-link mentions over a lookback window, but never states when to prefer this over top_sources, query_visits, or get_campaign_results. No exclusions or prerequisites are given, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer questions about this site's visits: count pageviews (or custom events) and unique visitors that match filters, optionally grouped. Examples: iOS visitors from the US last week (os=iOS, country=US); where Firefox users come from (browser=Firefox, group_by=source); signups per country (event=signup, group_by=country); /pricing views per day (page=/pricing, group_by=day). Only counts are returned; the site stores no IP addresses or user agents.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | e.g. Windows, macOS, iOS, Android, Linux. | |
| page | No | Exact path like /pricing, or a prefix ending in * like /blog/*. | |
| type | No | Default pageview, or event when you filter or group by event. | |
| event | No | Custom event name, e.g. signup. | |
| limit | No | Max rows. Default 10. | |
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. | |
| source | No | UTM source, else referrer host, else "(direct)". | |
| browser | No | e.g. Chrome, Firefox, Safari, Edge. | |
| country | No | ISO code (US) or name (United States). | |
| group_by | No | Break the matches down by one dimension. Default none. | |
| referrer | No | Referring host, e.g. news.ycombinator.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds valuable non-redundant context: only counts are returned, and no IP addresses or user agents are stored, which sets correct expectations about output and privacy.
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?
Front-loads purpose, then illustrates with compact examples, then closes with output and privacy caveats. Every sentence carries information and nothing is padded.
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 compensates by stating that only counts are returned and that no IPs/user agents exist, and the examples cover the filter-plus-group idiom end to end. All 12 parameters are schema-documented, so the description does not need to repeat them.
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 100%, so the schema establishes the baseline. The description goes beyond it by showing parameters in realistic conjunctions (os=iOS + country=US; group_by=source) that convey how filters compose, which is real added meaning rather than restatement.
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: count pageviews/custom events and unique visitors matching filters, with optional grouping. The four concrete examples (iOS+US, Firefox by source, signups per country, /pricing per day) make the tool's reach unambiguous. It does not explicitly distinguish itself from overlapping siblings like top_pages, top_countries, or top_browsers, which the examples actually overlap with, 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?
Four worked examples give clear contextual guidance on how to combine filters and group_by for real questions, which is strong 'when to use' signaling. However, no exclusions or named alternatives are given, leaving the agent to infer when to prefer this over the preset top_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browsers ranked by pageviews: Chrome, Firefox, Safari, Edge, Opera, Samsung Internet, Other. Visits recorded before browser tracking began are Unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows. Default 10. | |
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and a closed-world scope, so the safety profile is covered. The description adds real value beyond that by disclosing the fixed bucket set and the data-quality caveat that pre-tracking visits land in Unknown, which an agent would otherwise not know.
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 short sentences, front-loaded with the ranking definition and followed by the single important caveat. No filler and nothing redundant.
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 covers the essential return semantics (ranked browser buckets plus the Unknown bucket) and the parameters are complete in the schema. It omits whether values are raw counts or shares and any pagination detail, but for a simple read-only top-N tool it is close to sufficient.
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 limit, range and domain are fully documented in the schema with defaults and bounds. The description adds nothing about ordering, counting unit or format, so the baseline 3 holds.
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: browsers ranked by pageviews, and enumerates the exact bucket values (Chrome, Firefox, ... Other), which lets an agent tell it apart from top_systems, top_countries and top_sources without opening any schema. It stops short of naming an alternative explicitly, so it is clear rather than perfectly differentiated.
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 reach for this tool versus the many sibling top_* tools, nor of prerequisites. Usage is only weakly inferable from the range/domain/limit parameters, leaving the agent to guess between browser and OS or source dimensions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Visitor countries ranked by pageviews, with the country name ("XX" is unknown).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows. Default 10. | |
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world, so safety is covered. The description adds real behavioral context beyond that by disclosing the "XX" unknown-country sentinel, which an agent needs in order to interpret results 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?
A single front-loaded sentence that states the ranking dimension first and appends the data-quirk caveat. No filler, nothing to trim.
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?
No output schema exists, but the description conveys the result shape (countries ranked descending by pageviews) and the sentinel value, while the schema and annotations cover inputs and safety. Sort direction and result count are left implicit, a minor gap for a simple analytics list tool.
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 100%, so limit, range, and domain are already fully documented (defaults, max 90d, sign-in fallback) in the schema. The description adds no parameter-level meaning beyond that, 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?
States a specific resource (visitor countries) and the ranking metric (pageviews), which clearly separates it from top_browsers/top_pages/top_sources/top_systems. It does not explicitly name a sibling it excludes, but the resource noun does the differentiating work.
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?
No explicit when-to-use, prerequisites, or alternative is given. Usage is only implied by the naming convention shared with the other top_* siblings, so an agent can infer the context but gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pages ranked by pageviews.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows. Default 10. | |
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that – no ordering/tie-break rule, no note that results are capped by the limit parameter, no indication of whether all pages or only top-N are returned.
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 four-word fragment with no waste and the metric front-loaded, but it is under-specified rather than concise-with-substance; there is no runway for the context an agent would need before calling it.
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 does at least characterize the return as ranked pages, and the schema fully documents defaults for limit/range/domain while annotations cover safety. It remains thin for a tool whose whole purpose is a ranked list — nothing about ordering guarantees or result shape beyond the one clause.
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 all three optional parameters (limit, range, domain) have documented defaults and constraints in the schema. The description provides no additional parameter meaning, 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?
States the resource (pages) and the ranking metric (pageviews), which the sibling names top_sources/top_countries/top_browsers share in convention but don't spell out. An agent can tell this returns a page-level ranking, though the description stops short of naming the scope (site, window) that would fully separate it from siblings.
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 when-to-use guidance and no mention of alternatives such as get_timeseries, get_overview, or query_visits for more granular page analysis. The agent must infer applicability from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Traffic sources (UTM source, else referrer host, else direct) ranked by pageviews.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows. Default 10. | |
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent, bounded read (readOnlyHint, idempotentHint, openWorldHint=false), so the safety profile is covered. The description adds genuinely useful behavior: the source-resolution fallback chain (UTM source, else referrer host, else direct) and the ranking basis (pageviews). It stops short of describing return fields or ordering ties.
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 14-word sentence with the resource and ranking metric front-loaded and the parenthetical resolution rule placed inline where it is needed. 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 simple read-only analytics tool with a fully documented 3-parameter schema, the description covers what the tool returns and how sources are classified. With no output schema, it could specify the returned shape (source label plus pageview count), which is the only real gap.
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% — limit, range and domain each carry their own defaults and bounds — so the schema does the heavy lifting. The description adds no parameter detail (no mention of limit/range/domain semantics or defaults), making 3 the correct baseline.
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 resource (traffic sources) and the ranking metric (pageviews), plus an unambiguous definition of how a source is resolved (UTM source > referrer host > direct). It is clearly distinct from top_pages/top_browsers/top_countries by resource, though it never explicitly names those siblings.
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 when-to-use guidance and no exclusion or alternative named, despite siblings like get_campaign_results, get_overview and get_whats_working covering adjacent traffic-reporting questions. The agent must infer selection context from the resource name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Operating systems ranked by pageviews: Windows, macOS, iOS, Android, Linux, ChromeOS, Other. Visits recorded before this tracking began are Unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows. Default 10. | |
| range | No | Lookback window such as "24h", "7d" or "30d" (max 90d). Default "7d". | |
| domain | No | Which of the account's sites, like example.com. Defaults to the site chosen at sign-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent and closed-world behavior, so the safety profile is covered. The description adds genuinely useful non-obvious context: the fixed category set and the 'Unknown' caveat for visits predating tracking, which prevents misreading the data.
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 short sentences, front-loaded with the core purpose, then the data-quality caveat. Every clause earns its place with no redundancy.
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 simple read-only breakdown with no output schema, the description covers what is returned (the category list) and the key data caveat. With 100% schema coverage on inputs, nothing material is missing, though it does not mention result sizing or ordering ties.
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%, with limit, range and domain all documented in the schema (including defaults and the 90d cap). The description adds nothing about parameters, so the baseline of 3 is appropriate.
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-dimension ('ranked by pageviews') on a specific resource (operating systems), and enumerates the categories returned. It is immediately distinguishable from sibling breakdowns like top_browsers, top_countries and top_pages.
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?
Usage is implied by the name and the enumerated categories, but there is no explicit statement of when to pick this over top_browsers/top_countries or any prerequisite (e.g. auth/site scope). The agent can infer the context but is not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
explain_spikefind_traffic_spikesget_campaign_resultsget_funnelget_growth_actionsget_overviewget_timeseriesget_whats_workinglist_eventslist_mentionsquery_visitstop_browserstop_countriestop_pagestop_sourcestop_systemsCookieless web analytics and AI Visibility: traffic, funnels, errors, and which AI bots read you.
Web analytics for AI agents: realtime visitors, revenue, funnels and AI-detected site issues
Cookieless web analytics your coding agent reads: traffic answers, deploy impact, what broke.
Privacy-first product analytics. Your agent sets up tracking and answers questions about traffic.
Add one secure layer between your agents and this server.
