SuprAnalytics

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description goes beyond them by disclosing the output shape and ordering ('worst first', what's expected, the first step, a paste-ready AI prompt), which matters because no output schema exists. It omits edge cases such as behavior when no audit has run or how many findings are returned, keeping it short of a 5.

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 sentence, front-loaded with the core payload ('latest audit's scores and what needs fixing, worst first') followed by an efficient enumeration of the fields returned. No filler or repetition.

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, no-output-schema, richly annotated read tool, the description covers the essential contract: what comes back and in what order. It would be fully complete with a note on what happens when no audit exists and roughly how many findings to expect.

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?

There is a single parameter with 100% schema description coverage (website id or domain, with an example and a pointer to list_websites). The description adds no extra meaning about the parameter, which is the expected baseline when the schema fully documents it.

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 specifically what is returned: the latest site audit's scores plus remediation items, ordered worst-first, including finding, expectation, first step, and an AI prompt. The verb+resource is clear ('get latest site audit findings'). It doesn't explicitly contrast with any sibling, but no sibling covers site audits, so disambiguation is implicit 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?

Usage is implied by 'the latest site audit' — an agent can infer this is for reviewing current audit results — but there is no explicit when-to-use/when-not guidance, no mention of prerequisites (an audit must have run), and no pointer to alternatives for historical audits or individual checks.

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, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds useful return-content context (visitors, revenue, conversion rate) in the absence of an output schema, but says nothing about the limit cap, how revenue attribution model affects numbers, or how filters interact with sort.

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 wasted wording; the dimension examples and metric names are dense and useful. The trailing ellipsis is slightly informal but harmless.

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 10 parameters (2 required), 4 enums and no output schema, the agent gets enough to call the tool, but the definition omits the key disambiguation against get_breakdown_compared and does not mention limit/sort interaction. Adequate but with clear gaps for a tool of this complexity.

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 80%, so the schema already documents period, from/to, filters, model, search, website and dimension. The description adds only the dimension example set and the metrics available for sorting, which is marginal beyond the enum and the sort enum already in the schema. Baseline 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 concrete operation — returning top values of a single dimension — plus example dimensions (traffic sources, pages, countries, devices, UTM tags) and the metrics returned (visitors, revenue, conversion rate). That is specific verb+resource, though it never names the near-identical sibling get_breakdown_compared, so the agent must infer the distinction.

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 when-to-use or when-not guidance, and no mention of alternatives such as get_breakdown_compared (period comparison), get_pages, or get_timeseries. Usage is only implied by the parenthetical dimension examples.

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, idempotentHint=true, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description adds only that setting `previous`=1 extends the read to the preceding period; it says nothing about row ordering, pagination, or what metrics accompany each dimension value.

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, with the core purpose front-loaded and the comparison behavior second. Slightly redundant with the schema's own `previous` description, but nothing is padded or buried.

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 an 11-parameter analytics tool with no output schema, the description leaves a meaningful gap: it never says which metrics (visitors, revenue, conversions) accompany each dimension row, nor how comparison results are shaped. The safety and parameter sides are well covered by annotations and the schema, but the return-value side is not.

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 every parameter including `previous`, `dim`, `period`, and `filters` is already documented in structured form. The description's mention of `previous` set to 1 merely restates the schema text and adds no new meaning such as how comparison rows are labeled or what extra fields appear.

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 a concrete resource — the top values of a chosen dimension — and lists example dimensions (channel, referrer, campaign, page, country, device), so an agent knows what comes back. It never names the closely related sibling get_breakdown, so the differentiating feature (comparison against a prior period) is only implied via the `previous` parameter note.

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 and no exclusions. With a sibling literally named get_breakdown, the agent must infer from the parameter note alone that this is the comparison variant; the description should say 'use get_breakdown for a single period' but does not.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description adds no behavioral traits such as pagination, aggregation granularity, or how categories narrow results. The enumeration of crawler types is mildly useful for interpreting the data but is definitional rather than behavioral.

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 a single short sentence with no padding, but it is structured as a fragment rather than a front-loaded statement of purpose, which makes it under-specified rather than genuinely concise. Nothing is wasted, yet nothing is anchored by a verb.

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 five parameters, one required, no output schema, and no annotations explaining results, the description should clarify what is returned (per-crawler counts, time series, category grouping) and that website is mandatory. None of that is present, leaving the agent to guess at the shape and scope of the response.

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 five parameters including website, period, from/to and category are documented in the schema itself. The description adds no additional meaning about how period interacts with from/to or what values category accepts, so 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 text is a noun phrase fragment ('AI assistants, search engines and training crawlers requesting the website's pages') with no verb, so it describes the data domain rather than stating an action like 'list crawler requests'. An agent can infer the resource is crawler traffic for a site, but it gets no explicit statement of what the tool does and nothing distinguishes it from siblings such as get_pages or get_breakdown.

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 at all: no mention of choosing this over get_pages or get_breakdown, no note that a website is required, and no context about what question this tool answers. The agent must infer usage entirely from the tool name.

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 readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the tool has a listing mode when no funnel or steps are supplied, and it defines what the computation yields (per-step reach and drop-off). It omits step-count limits, how step order affects results, and how the listing mode's output differs from an 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?

Two sentences, both front-loaded with the highest-value information: what the tool computes, then how to invoke each mode. There is no redundant restatement of the name or title and 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?

With seven parameters, no output schema, and date/filter complexity, the description covers the two modes and the shape of the result well enough for a correct call. Gaps remain around the from/to and period interplay and around what listing mode actually returns, which matters more given there is no output schema.

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 baseline is 3, but the description earns a bump by explaining the mutual exclusivity between funnel_id and steps and by surfacing the zero-argument listing behavior, which is not obvious from the schema. It adds no detail on periods, filters, or website resolution beyond what the schema already states.

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 gives a specific verb-and-resource framing: conversion analysis through ordered steps, reporting visitors reaching each step and drop-off. It also names the supported step types (page visits, goals, payment). It does not distinguish itself from the sibling list_funnels, which appears to overlap with the no-argument listing mode.

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 clearly states two invocation modes: pass a saved funnel's id/name, or supply your own steps, and notes that omitting both returns the saved funnel list. That is concrete guidance on how to call it. It never says when a caller should prefer get_funnel's listing mode over list_funnels, leaving a real ambiguity for an agent choosing between siblings.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine value with 'Needs people:read', an auth requirement not encoded in annotations, and flags PII sensitivity by noting that goal values are whatever the website sends, emails included. It does not disclose default period behavior, pagination, or what an empty result means.

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?

At roughly 45 words it wastes little space, but the structure is poor: four parallel sentence fragments followed by a confusingly worded rationale ('Personal because a goal's values are whatever your website sends, emails included'). The most actionable fact, the permission requirement, is buried at the end rather than front-loaded.

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, three result modes, and no output schema, the description should explain how the view parameter selects among the three result shapes it names; it never makes that linkage explicit. Date handling, filters, and goal scoping are left entirely to the schema, which is acceptable but leaves the definition only minimally sufficient for a multi-mode analytics 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 description coverage is 100%, so the schema already documents period, from/to, filters, goal, and the view enum. The description reinforces that results vary by view but adds no syntax, default, or precedence detail beyond the schema, which is the expected baseline when the schema carries the load.

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 lists what the goal is about (completions over time, top traffic sources and pages, values sent with a goal), which hints at the three result shapes. But it is written as disconnected noun fragments with no verb or resource framing, so an agent cannot tell that this is a retrieval tool that returns one of three views. It also doesn't distinguish itself from list_goals, which is the natural companion for resolving goal names.

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 statement of when to prefer a sibling such as get_timeseries or get_breakdown, and no indication that list_goals should be called first to obtain a goal name. The only conditional information is the access-scope note, which is a prerequisite rather than usage guidance.

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, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds almost nothing beyond that: it never says whether a path is required for click data, that sites without heatmap tracking may return empty results, or what the payload looks like — only the oblique fragment 'The pages with heatmap data' gestures at data availability.

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, which is good. But the second sentence is a dangling noun phrase ('The pages with heatmap data') rather than a usable statement, so brevity comes at the cost of clarity rather than being earned conciseness.

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?

Seven parameters, a dual view mode, and date-range filtering with no output schema mean the description needed to do real work. As written it omits the interaction between 'view', 'path' and 'period', and says nothing about return shape or empty-data behavior, leaving significant gaps for an agent to discover by trial.

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 every parameter carries an inline description (including the view enum and the period vocabulary), so the schema does the heavy lifting. The tool description adds no parameter meaning beyond that, which is the expected baseline-3 outcome when coverage is complete.

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 fragments 'Where people click and how far they scroll on a page' convey the resource (click/scroll heatmap) and the second fragment hints at a page listing mode. However, the phrasing is disjointed and never states a specific verb or what the tool actually returns, and it does not differentiate from siblings like get_pages or get_recordings_summary, which also surface per-page engagement data.

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 alternatives. An agent cannot tell from the description whether to reach for get_heatmap versus get_pages when it needs page-level engagement, nor when the 'pages' view mode is preferable.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description only needs to add output context. It does add one genuinely useful behavioral fact — results are relative to 'the website as a whole' — but says nothing about how segments are ranked, how many are returned, or whether low-volume segments are suppressed or flagged.

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 tight sentence with zero filler, and the comparative framing is front-loaded. It loses a point only because the fragmentary, verbless phrasing reads as a label rather than an instruction to an agent.

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 small read-only analytics tool with complete schema descriptions and full annotations, this is adequate but thin. With no output schema, the description is the only place a caller could learn what an 'insight' record contains (segment value, conversion rate, delta vs site average), and it never says so.

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 every parameter (website, period, from, to) is documented inline, including a default of 30d and the custom-period pairing, so the description carries no additional burden. Its only contribution, 'for the period', merely echoes the schema's period parameter. 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 sentence describes the subject matter well — segment-level conversion compared to the site-wide baseline, scoped to a period — but it is phrased as a question fragment with no verb, so it reads like a report title rather than a stated operation. It also never names the siblings it overlaps with (get_breakdown, get_breakdown_compared, get_pages), leaving an agent to guess which of these returns 'insights'.

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 at all: nothing says whether this is a starting point for diagnosis, a follow-up to get_overview, or a replacement for get_breakdown. No prerequisites, no exclusions, no named alternative despite six sibling tools covering adjacent analytics territory.

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?

The annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and closed-world scope. The description adds almost no behavioral context beyond the basic concept: it does not mention defaults, period handling, filtering behavior, or what is 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?

The description is a single sentence fragment with no wasted words, but it is under-specified rather than concise. It is front-loaded with a vague concept and gives the agent no actionable structure for invoking the tool.

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 an eight-parameter analytics tool with no output schema, the description is far too thin. It should clarify the purpose relative to funnel and breakdown tools, explain important defaults such as period=30d, and describe journey step behavior.

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 eight parameters are documented in the schema, including period, filters, steps, and goal inclusion. The description adds no parameter meaning, so the baseline of 3 is appropriate when the schema does the explanatory work.

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 'The routes visitors take through the website' names the resource concept but does not state an action such as retrieving, listing, or analyzing journeys. It largely restates the tool title and does not distinguish this tool from siblings like get_funnel or get_breakdown.

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 mention of alternatives such as get_funnel or get_breakdown, and no explanation of when journey analysis is appropriate versus other analytics tools. Usage is only implied by the tool name.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real value with the 5-minute recency definition and the shape of the returned data, but says nothing about result caps (how many concurrent visitors are returned), latency, or sampling, which matter for a live-data endpoint.

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 that defines the metric window first and then the payload. Every clause carries information, and the parentheticals are used to enumerate fields rather than to hedge.

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, single-parameter tool with no output schema, the description supplies the temporal definition and the return content, which is the right amount of coverage. The only real omission is any statement about result limits or ordering for the returned visitor list.

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 website parameter is already documented with an example ('example.com') plus a pointer to list_websites. The description adds no further meaning about the parameter, which is the expected baseline when the schema does the work.

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 and scope: visitors on the site right now, with the recency window pinned down as 'seen in the last 5 minutes', and it enumerates the returned dimensions (page, source, location, device, activity). This distinguishes it from historical siblings like get_overview and get_timeseries, though no sibling is named 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?

Usage context is clear: this is the real-time tool, selected when the question is about who is on the site at this moment rather than over a date range. It stops short of explicit exclusions or naming the alternative to use for historical traffic, so an agent must infer the boundary itself.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context at all: nothing about return shape, volume, ordering, or whether notes are per-website or per-chart.

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 a single short fragment, but that brevity comes from under-specification rather than efficiency. There is no front-loaded statement of action or scope.

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 four-parameter tool with no output schema, the description leaves critical gaps: it never explains what a "note" contains, what "the chart" refers to given that no chart/dashboard parameter exists, or how the date range filters results. The definition is not usable without guessing.

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 website, period, from and to all documented in the schema, so the baseline of 3 applies. The description adds nothing about how date filtering interacts with notes, which is a missed opportunity given the time-range parameters.

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 is a noun fragment, "Notes the team made on the chart," that essentially restates the title "Notes" with a hint about origin. It never states a verb (list/retrieve) or what the notes are attached to concretely, and it is not distinguishable from siblings like get_insights or get_audit_findings.

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 exclusions, and no mention of any alternative among the many sibling get_* tools. An agent has no basis for choosing this over get_insights or get_audit_findings.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real context beyond them: it discloses the automatic previous-period comparison of equal length and enumerates the returned metrics, which matters because there is no output schema. Remaining gaps are minor (no note on how comparison handles "all" or partial periods).

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, and the core purpose is front-loaded ahead of the metric enumeration. The trailing "Also visitors online now" is a single clause that adds information rather than padding.

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 spends its budget on naming the return fields and the comparison-period behavior, which is the information an agent needs to decide whether it can answer a question with this single call. It stops short of explaining how the comparison is presented or how filters affect the headline numbers, but nothing essential for invocation is missing.

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 the schema itself documents period, from/to, filters, model and website. The description mentions "for a period" and a comparison period but adds no formatting, precedence, or defaulting rules beyond what the schema already states. 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?

"Headline metrics for a period" is a specific verb+resource, and the description enumerates exactly what comes back (visitors, sessions, pageviews, bounce rate, session time, revenue, customers, conversion rate). It does not, however, contrast itself with siblings like get_breakdown or get_timeseries, so an agent must infer that this is the aggregate summary rather than a sliced view.

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: the word "headline" plus the metric list suggests this is the entry-point dashboard call, but there is no explicit "use this when you want X; use get_breakdown instead for Y". The statement "Also visitors online now" overlaps with the get_live sibling without clarifying when to prefer one over the other.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds only that each row carries "numbers and trend"; it says nothing about default period (30d per the schema), pagination via limit/offset, row caps, or sort defaults, all of which matter for a 12-parameter analytics query.

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 a single front-loaded clause with zero padding, which is good, but it is under-specified rather than concise and the word "numbers" is too vague to convey what metrics come back. Brevity here costs information rather than saving 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?

For a 12-parameter, multi-enum analytics tool with no output schema, the description leaves the agent guessing about return shape (columns, trend semantics), default date range, and pagination. Annotations carry the safety story, but the functional story is essentially absent.

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 every parameter — period presets, filters triplets, by=path|url, sort/dir, limit/offset — is already documented in the schema. The description adds no syntax, defaults, or interaction rules 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?

The fragment "Every page viewed, with its numbers and trend" identifies the resource (pages) and hints at per-page metrics plus a trend column, but supplies no verb and never says it returns a ranked/tabulated list of pages for a website. It does not distinguish itself from siblings like get_breakdown, get_performance, or get_breakdown_compared, which plausibly also return per-dimension metrics.

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 at all: nothing tells the agent to pick this over get_breakdown or get_performance, nor any prerequisite such as needing a website id from list_websites (that hint lives only in the schema). Usage must be inferred entirely from the tool name.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is real: it discloses that results are aggregated across all history into a single week-long hourly bucket and rendered in the website's own time zone, which matters for interpretation. It stops short of saying how ties/peaks are determined or how large the response is.

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 what the caller gets, followed by the default-range caveat. Phrasing is slightly compressed ('The website's data as one week') but nothing is wasted or buried.

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, five-parameter analytics query with no output schema, the description conveys the essential return shape (7x24 hourly buckets, site time zone) and the default time span. It leaves the precise response structure and the meaning of 'peak' implicit, but nothing critical to invoking it correctly is missing.

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 the schema already documents model, range, metric, filters and website. The description only restates the metric set and the default range behavior, adding no syntax, filter semantics, or interaction detail beyond what the schema provides.

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 a clear resource and shape: the website's data collapsed into one week, hour by hour, in the site's own time zone, for one of four metrics. It does not, however, distinguish itself from plausible siblings like get_heatmap or get_timeseries, which an agent could easily confuse with a 7x24 hourly grid.

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; the only guidance is an implicit default ('All time unless `range` says less'). An agent must guess whether this or get_heatmap/get_timeseries is appropriate for hourly-pattern questions.

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 this as a read-only, idempotent, non-destructive operation. The description adds useful content context by specifying real-visitor Core Web Vitals and audit history, but it does not clarify date-range behavior, return granularity, or how the audit history is bounded.

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 one compact sentence with no filler and puts the key returned resources up front. Its extreme brevity makes it slightly less clear as a standalone statement, but it is appropriately concise.

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 schema and annotations cover invocation and safety well, and the description states the broad return categories. However, with no output schema, it does not explain the shape or detail of the performance and audit data, and it offers no usage context for this multi-parameter 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 description coverage is 100%, so all seven parameters including website, period, filters, device, and model are already documented in the schema. The description adds no parameter-level meaning beyond that, making the baseline score 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?

The description names the specific resource returned: real visitors' Core Web Vitals plus the latest daily site audit and its history. It is clear what data the tool exposes, though it does not explicitly differentiate it from related siblings such as get_audit_findings.

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 guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. With many performance- and audit-related siblings, the agent is left to infer routing on its own.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context with 'Nobody is identified', telling the agent the result is aggregate and cannot be tied to individual users or sessions — a constraint that affects how the output may be used. It stops short of describing return shape or whether per-tag counts are exclusive.

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 puts the primary quantity first, then the breakdown dimension, then the key caveat. No filler, no restating of the title, and the most decision-relevant information is front-loaded.

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 four-parameter read-only aggregate tool with a fully documented schema and full annotation coverage, the description covers what is counted, the breakdown dimension, and the anonymity constraint. Minor gaps remain around the exact result shape and edge cases (empty period, disabled recordings), but nothing essential to selecting or invoking the tool is missing.

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 period/from/to/website semantics (timezone, dashboard-style ranges, custom pairing, website id or domain) are fully documented in the schema. 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?

The description states a specific verb-and-resource pair: it counts recorded sessions in a period and returns per-problem-tag counts (rage clicks, errors, slow pages). That is distinguishable from list-style siblings like list_websites or get_pages, though it never names a sibling (e.g. get_overview or get_insights) that would cover similar ground.

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 by the interrogative framing — an agent can infer it answers 'how much recording activity and what problems occurred'. There is no explicit when-to-use, when-not-to-use, or pointer to alternative tools, and no prerequisite (such as recordings being enabled) is 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 already declare this a safe, idempotent read (readOnlyHint=true, destructiveHint=false, idempotentHint=true), so the safety profile is covered. The description adds one genuinely useful behavioral trait: 'Totals only' tells the agent the response is aggregate rather than per-user rows. It says nothing about permissions, defaults, or how the returned periods are shaped.

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 with the core concept front-loaded and no filler, so nothing needs trimming. The compression is, however, achieved partly by omitting information rather than by efficient phrasing.

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 six-parameter cohort analytics tool with no output schema, the description is thin: it never states what the result looks like (cohort rows by period, which measure is returned) or how 'every' and 'mode' affect output shape. 'Totals only' partially covers the return format but leaves an agent guessing about the response structure.

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% -- mode, every, cohort, return, filters, and website all carry their own explanations, including the enum meanings. The description contributes 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?

The description defines retention conceptually ('Of the people who first came in a period, how many came back'), which lets an agent infer a cohort-retention computation, but it never states a verb or names the resource explicitly. It also doesn't differentiate itself from siblings like get_breakdown or get_funnel beyond the vague 'Totals only'.

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 named alternative. With 24 sibling analytics tools, an agent has to guess whether retention belongs here versus get_breakdown, get_timeseries, or get_funnel; the only hint is the implicit contrast in 'Totals only'.

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, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds one genuinely useful trait, 'as last synced', warning that data is not live, but omits the connection/permission prerequisite and any note on data gaps or 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?

A single compact sentence with no wasted words and the key object ('Google searches') front-loaded. The trailing qualifiers stack awkwardly but the sentence still earns its place.

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 is the only place an agent could learn what is returned, but it never says which metrics or dimensions come back (clicks, impressions, positions, query rows) or the row shape. Annotations cover safety and the freshness caveat is present, leaving a real gap for a data-retrieval 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 description coverage is 100%, with website (id or domain, pointing to list_websites) and period (enumerated ranges) already documented in the schema. The description adds no meaning beyond that, 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 specific resource: Google search queries that drove traffic to a connected website. An agent can distinguish this as query/search-console data rather than general traffic metrics, though the phrasing is slightly awkward and does not name which sibling (get_pages, get_performance) covers related data.

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 or when-not guidance and no named alternative. The only implicit signal is 'for a connected website', which hints at a Search Console integration prerequisite, but nothing tells the agent when to prefer this over other traffic tools or what happens if no site is connected.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. With no output schema, the metric list does useful work by telling the agent roughly what comes back per bucket. However, nothing is said about return shape (rows vs. series), limits on range size, or timezone handling, which the schema only partly covers.

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 with no wasted words, and the metric enumeration is front-loaded. It is efficient but reads as a bare list rather than a directive, so structure is good, not exemplary.

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 7-parameter analytics tool with no output schema, the description usefully enumerates what each bucket contains, which compensates somewhat. It still omits how this differs from the breakdown/overview siblings and gives no indication of result volume or granularity behavior, leaving real gaps for tool selection.

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 the baseline is 3; the description adds a little by tying 'hour, day, week or month' to the interval parameter's meaning. It adds no further meaning to period, filters, or model beyond what the schema already documents.

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 lists the metrics returned (visitors, sessions, pageviews, bounce rate, session time, revenue, new customers) and the bucket sizes, which conveys the resource but never uses a verb or states that it returns a time series. It does not distinguish it from siblings like get_overview, get_breakdown, or get_peak_hours, so an agent must infer the difference from the name alone.

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 when-not-to-use, and no named alternative among the many sibling analytics tools. The agent is left to guess whether this or get_overview should be called for a trend question.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context about how broad the returned payload is, which helps an agent anticipate a multi-section response. It says nothing about caching or rate limits, how stale 'last check' data is, or what happens when the domain is unknown.

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 a single front-loaded sentence that states the core question first and then enumerates payload sections. The comma-separated list is dense but every item carries information. Minor redundancy: the opening 'whether the website is up' is restated by the later 'status'.

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 2 parameters, no nested objects, and no output schema, the description does a good job substituting for the missing output schema by enumerating what an agent will receive. Remaining gaps are the default range behavior and sibling routing, which keep it short of a 5.

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 the baseline is 3. The description adds little beyond the schema, and in fact introduces friction: it mentions 'uptime over 7 to 365 days' while the schema's range enum is 1h/24h/7d/30d plus peak-hours values, which can mislead an agent about valid inputs.

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 and scope: 'whether the website is up' plus an enumerated payload of status, last check, 24h, 7-365 day uptime, response times, incidents, and domain/SSL expiry. It is descriptive rather than verb-led, and it does not differentiate itself from the sibling get_uptime_incidents, even though 'latest incidents' overlaps with that tool.

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 guidance on when to use this tool versus get_uptime_incidents, get_performance, or get_websites_summary. The description also does not say what happens for a website that is not yet monitored, or which range value to pick. A reader must infer all of this.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new behavioral facts: reverse-chronological ordering and page-at-a-time pagination. However, it omits page size, how to detect that more pages exist, and what an incident record actually contains beyond 'causes'.

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 short fragment with zero filler, and the ordering and pagination facts are front-loaded. It is efficient, though its terseness means a couple of clarifying clauses could have been added without bloat.

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 full schema coverage and annotations, the description is adequate as far as it goes. With no output schema, it should say more about the shape of an incident entry (timing, duration, resolution) and whether an empty page signals the end of 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 description coverage is 100%, so both parameters are already documented, including the cursor semantics of 'before'. The description's 'newest first, a page at a time' reinforces why the cursor walks backwards, but adds no format or syntax detail 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 resource precisely ('Outages with their causes') and adds scope details (newest first, paginated). It is clear what the tool returns, but it never distinguishes itself from the sibling get_uptime, leaving the agent to infer which one to call when.

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 prerequisites, and no mention of alternatives such as get_uptime. The paginated framing implies iterative paging, but nothing tells the agent when this tool is the right choice over its closest sibling.

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?

The read-only, idempotent, non-destructive annotations already establish the safety profile. The description adds useful content about what is returned, including live visitors and uptime, but does not discuss freshness, permissions, rate limits, or pagination behavior.

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 wasted wording. The colon and semicolon structure efficiently separates purpose from returned metrics.

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 tool with one optional parameter and no output schema, the description adequately lists the returned metrics and scope. It could be more complete by clarifying whether all websites are returned unpaginated or whether data freshness varies by metric.

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 only parameter, period, is fully documented in the schema with examples and a default. The description mentions 'for the period' but adds no syntax or semantic detail beyond the schema.

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 (all websites) and the summary contents, including Home-card metrics, live visitors, uptime, and site score. It implicitly differentiates from list_websites by emphasizing metric summaries, though it does not explicitly name sibling alternatives.

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: use this when you need a summary of every website for a period. However, there is no explicit when-to-use or when-not-to-use guidance, and no direct comparison with sibling tools such as list_websites or get_overview.

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, idempotentHint, non-destructive, and closed-world, so the safety profile needs no restating. Beyond annotations the description adds only the word "saved," which hints these are pre-configured funnels rather than computed ones but does not say whether the list is paginated, whether it can be empty, or what each entry contains.

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 a single short fragment with no wasted words, but this is brevity by omission rather than a front-loaded, information-dense lead. There is no structure to speak of beyond one noun phrase.

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 list call with full schema coverage and complete annotations, the definition is thin but not blocking: an agent can invoke it correctly. What is missing is conceptual context, namely what a funnel is in this product and how list_funnels relates to get_funnel, which keeps it from a higher score.

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?

There is a single parameter with 100% schema description coverage, and that description already explains the id-or-domain format and points to list_websites. The tool description adds nothing beyond the schema, 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 is a noun fragment, "The website's saved funnels," that essentially restates the tool name and title without a verb. It does add the scoping notion (per-website, "saved"), but it never says it returns a list, and it does not distinguish itself from the sibling get_funnel.

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 mention of get_funnel as the alternative for a single funnel, and no prerequisites. The agent must infer from the name alone that this is the enumeration step preceding get_funnel.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds useful return-value context by naming the goal types and metrics included, but does not discuss pagination, date-range effects on metrics, or result structure.

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 that efficiently states what is returned. There is no redundant or filler wording.

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 list tool with full schema coverage and annotations covering safety, the description is nearly complete. Because there is no output schema, the description helpfully names the returned metrics, though it does not explain the response shape or edge cases such as goals with zero completions.

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 five parameters are already documented in the schema. The description adds no additional parameter-level meaning, which makes the baseline score of 3 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?

The description clearly indicates it returns every goal with completions, unique visitors, conversion rate, and revenue from converters. It does not explicitly name or distinguish the sibling get_goal_details, so it is clear but lacks sibling differentiation.

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 guidance on when to use this tool versus alternatives such as get_goal_details or other list tools. Usage is only implied by the phrase 'Every goal'.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the word "team's," which implies workspace/team scoping but is too vague to pin down the access boundary. It says nothing about ordering, empty results, or what a segment contains.

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?

There is no filler, but this is under-specification rather than conciseness: a four-word fragment with no verb and no front-loaded statement of what the tool returns. Brevity here comes at the cost of usability.

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 tool the bar is low, and rich annotations and full schema coverage help, but the description still omits anything an agent could not guess: that it returns the saved segments for the given website, their id/name fields, and behavior when none exist. With no output schema, some of that burden should have been carried here.

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% for the single `website` parameter, which even points to list_websites for resolving ids. The description contributes 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 is a noun phrase, "The team's saved filters," which glosses the term "segments" but never states an action verb such as list or return. It hints that the resource is a collection scoped to a team, but an agent gets no explicit signal that calling this yields the segment list rather than metadata about segments.

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 when another tool should be preferred. Siblings like list_funnels and list_goals are structurally identical in shape, and the description does nothing to help an agent choose among them.

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 establish readOnly, idempotent, non-destructive, and closed-world behavior, so safety is covered. The description adds the only return-shape information available (there is no output schema) by naming the five exposed fields, plus the cross-tool contract that ids/domains flow into other tools. It does not say whether the list is paginated or how many sites typically return.

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 with no filler; the payload (what you get back) is front-loaded and the downstream id/domain contract follows immediately. Every clause earns its place.

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 zero-param, read-only discovery tool this covers purpose, returned fields, and how the results feed sibling tools. The only meaningful gap is the absence of any note on result size or pagination, which matters if a user belongs to many sites.

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 and additionalProperties is false, so there is nothing for the description to disambiguate. Baseline of 4 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 states the resource ('the websites you can open in SuprAnalytics') and the exact fields returned (id, name, domain, timezone, currency), so an agent knows precisely what it gets. The verb 'list' comes from the name rather than the prose, and no sibling is named, but the resource is distinct from list_funnels/list_goals/list_segments.

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?

'Other tools take a website id or domain' implicitly signals this is the discovery step before calling analytics tools, which is useful routing context. However, it never explicitly says 'call this first when you lack a website id', and offers no when-not guidance or comparison against get_websites_summary.

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