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 real behavioral context on top: default ordering (newest day first), the backing route GET /errors/daily, the 1000-day cap, and that results include user counts and links. It does not describe pagination behavior, though the schema's page field covers that.

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?

Three sentences, front-loaded with what the tool returns and its default ordering, then usage, then the one parameter worth calling out. No filler, though the size sentence duplicates schema text and slightly dilutes the otherwise tight structure.

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 seven-parameter, all-optional read tool with rich annotations and full schema coverage, the description supplies what the structured fields cannot: return payload contents, default sort order, and intended analytical use. No output schema exists, and the description adequately previews the shape of results (totals, user counts, links).

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 is already documented, including the page/size/sort semantics. The description's note 'Set size to the number of days you need (max 1000)' largely restates the schema's own example, adding little new meaning. 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 specific resource and granularity — 'Daily error totals with affected-user counts and TrackJS links' — plus the underlying endpoint GET /errors/daily, which unambiguously separates it from siblings like list_errors or top_messages. The only gap is that the nearest sibling, errors_by_hour, is never named or contrasted, though 'Daily' implies 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?

Explicitly names use cases: 'Use for trends, spotting spikes and comparing before/after a deploy.' That is clear contextual guidance beyond the name. It stops short of exclusions or pointing to alternatives such as errors_by_hour for intra-day analysis, so it falls short of a 5.

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 read-only, idempotent, non-destructive behavior, so the description only needs to add what they don't cover. It does exactly that by disclosing the default ordering (newest hour first) and the returned fields (hourly totals, affected-user counts, links). Pagination behavior is left to the schema.

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

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

One tightly written sentence plus a usage clause; the return contents and default ordering are front-loaded before the guidance, and nothing is 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?

No output schema exists, so the description usefully enumerates what comes back, which is what an agent needs here. The remaining gaps (paging continuation, application scoping) are already fully handled by the 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%, with every parameter documented including enums, defaults and paging.nextPage guidance, so the baseline is 3. The description only echoes the date-time format already given in the schema's startDate/endDate descriptions and adds no new parameter meaning.

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: hourly error totals with affected-user counts and TrackJS links, and names the underlying endpoint GET /errors/hourly. It is clearly distinguishable from errors_by_day, but that distinction comes mainly from the name rather than the prose.

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?

"Use to pinpoint when a spike started" gives a concrete selection condition, and the date-time guidance tells the agent how to narrow the window. It does not name an explicit alternative (e.g. errors_by_day for trends) or state when not to use it.

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 bar is lower, and the description still adds real context: the default sort is count descending, results carry affected-user counts and a TrackJS deep link, and the backing endpoint is disclosed. It omits default time-range behavior when startDate/endDate are absent, which is the main residual gap.

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?

Three short sentences: what it returns, how it's sorted, and when to use it. The grouping dimension is front-loaded and nothing is repeated or 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 no output schema, the description usefully previews the return shape (error counts, affected users, TrackJS link) and default ordering, which is enough to call it confidently across 7 optional params. The one hole is what time window applies when no dates are supplied.

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 (page, size, sortBy, sortDirection, dates, application) is already documented. The description's 'sorted by count descending by default' merely restates the schema's default sortBy/sortDirection and adds no syntax or edge-case detail beyond it. 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 specific verb+resource ('error counts grouped by the page URL') plus the aggregation dimension, which implicitly separates it from top_messages (grouped by message) and list_errors (individual events). It also names the underlying endpoint and the returned fields. It never explicitly names a sibling, so it stops short of 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?

'Use to find which pages are most broken' gives a concrete selection context, which pairs naturally with top_messages for message-level triage. There are no explicit exclusions or named alternatives, so it lands at clear-context-but-no-exclusions.

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 read-only, idempotent, non-destructive and open-world behavior, so the bar is lower. The description still adds real context: result ordering, the fields each error carries, and the size cost of includeStack with maxStackLines trimming. It does not cover auth or rate limits, keeping it from 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?

Front-loaded with the verb, resource and ordering, then parameter guidance, then the sibling-routing tip. It is dense but every sentence carries information an agent 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?

No output schema exists, but the description enumerates the returned fields (message, URL, file:line:column, browser, user/session IDs, triage status, metadata, details link). Combined with the schema's pagination guidance for eight optional parameters, an agent has everything needed to call it correctly.

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; the description goes beyond by explaining what `query` actually matches (messages, URLs, metadata, user IDs) and warns to keep page size small when includeStack is on. Date range and application scoping are left entirely to 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?

States a specific verb and resource ('List individual JavaScript error occurrences captured by TrackJS'), adds ordering ('newest first') and the underlying endpoint (GET /errors). It is clearly distinguished from the aggregating siblings like top_messages and errors_by_day.

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?

Explicitly routes the agent: for 'what is breaking most' questions, call top_messages first, then return here with `query` set to a message to see examples. That names both the alternative and the condition that selects it.

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 ordering (newest first) and pins the metric definition, which prevents misreading 'page view' as user sessions. It does not mention result-set shape or paging beyond what the schema's page/size docs imply.

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 first defines the resource and its ordering, the second gives the actionable use case. Front-loaded with the core meaning before the analytical hint.

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 covers what the tool returns conceptually (daily counts, newest first) and how to use it with a sibling. The only gap is response envelope/pagination shape, which an agent must infer from the schema's paging hint.

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 with defaults, ranges, and formats. The description contributes no additional parameter guidance (e.g. how startDate/endDate interact with daily bucketing), 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?

Names a specific resource and granularity ('Daily page view counts'), defines the metric parenthetically ('times the TrackJS agent loaded'), and gives the backing endpoint (GET /hits/daily) plus sort order. An agent can distinguish it from page_views_by_hour on granularity and from errors_* on metric without opening a 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?

Explicitly states the analytical use case: combine with errors_by_day to compute an error rate and separate regressions from traffic changes. That is clear when-to-use guidance. It stops short of stating exclusions, e.g. 'use page_views_by_hour when hourly resolution is needed'.

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, open-world behavior, so the safety profile is covered. The description adds useful beyond-schema context: result ordering (newest first) and the fact that the metric counts agent loads rather than page renders, which affects interpretation.

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 definition and ordering come first and the cross-tool usage hint follows, so the most important identification 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 read-only list tool with a fully documented schema and no output schema, the description covers the metric definition, ordering, and a cross-referencing use case. Minor gap: it doesn't characterize the returned record fields, though the ordering note partly compensates.

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 a detailed description (including the paging.nextPage continuation hint), so the description's job here is minimal. It adds no parameter-level meaning beyond what the schema already provides, making the baseline 3 correct.

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 and granularity (hourly page view counts), defines the metric precisely ('times the TrackJS agent loaded'), and adds ordering plus the underlying endpoint GET /hits/hourly. The hourly granularity implicitly distinguishes it from page_views_by_day, but no sibling is named directly.

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?

Gives a concrete usage context: combine with errors_by_hour to distinguish an error spike from a traffic spike. That is genuine guidance on when this tool is the right one, though it stops short of exclusions or stating when to prefer page_views_by_day instead.

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 read-only, idempotent, non-destructive, open-world. Beyond that, the description discloses the return shape (counts, affected users, triage status, first/last seen, TrackJS link), the default sort order, and the endpoint. Missing pagination/result-set size behavior, though the schema hints at paging.

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?

Four sentences, front-loaded with what the tool returns, then default ordering, then the primary use case. Slight redundancy in restating sortBy guidance that the schema already carries, but 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?

No output schema exists, and the description compensates by enumerating returned fields. With fully documented parameters and rich annotations, the only meaningful gap is pagination/result-volume 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%, so parameters are already fully documented, and the description adds only the default sort and the usercount alternative, which largely duplicates the sortBy schema description. 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 specific operation: error counts grouped by error message, with a named list of returned fields and the underlying endpoint (GET /errors/messages). This clearly distinguishes it from sibling tools like list_errors (raw error list) and errors_by_url/day/hour (different grouping dimensions).

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?

Explicitly positions the tool as "best starting point for 'what are our most common / most impactful errors?'" and gives a concrete alternative sorting strategy (sort by usercount). It doesn't name sibling tools or state when not to use it, so it falls short of a 5.

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 establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond that: oldest-first ordering, exact returned metrics, UTC-day aggregation when granularity=day, and a warning that long hourly ranges produce many rows.

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 dense and front-loaded: it starts with the core resource and returned metrics, then adds scope constraints, use cases, granularity advice, and the row-volume warning. Every sentence contributes useful selection or invocation guidance without 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?

With no output schema, the description appropriately explains what the tool returns, including the metric set and ordering. It also covers the key invocation constraints around date windows, granularity, and long-range row volume, so an agent has enough context to call it correctly.

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 already documents all three parameters, making the baseline 3. The description adds meaningful practical semantics by explaining that granularity=day rolls hourly rows into UTC days and that a date window should always be 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 description states a specific resource and scope: account-wide hourly usage, with page views and several error metrics, and explicitly says it is not broken down by application. This distinguishes it from narrower siblings like errors_by_hour and page_views_by_hour, though it does not name those alternatives directly.

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 gives clear use cases such as checking plan usage, ignore-rule effects, and dropped over-quota errors, plus practical guidance to use granularity=day for long ranges and always pass a startDate/endDate window. It does not explicitly say when to choose this over the sibling hourly tools, so it stops short of full alternative routing.

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