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

No annotations provided, so description must carry the burden. It explains nesting behavior and filter compatibility with get_report, but lacks details on authentication, rate limits, or exact response 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?

Two sentences plus a filter note. Front-loaded with the core purpose, no unnecessary words. Highly efficient.

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?

Given 8 parameters and no output schema, the description adequately covers the nesting behavior and filter capability. It could be more complete by hinting at the output format, but it is sufficient for an agent.

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 baseline is 3. The description adds context like nesting and filter support, but does not significantly enhance parameter understanding beyond the schema's detailed descriptions.

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 states it provides a per-project breakdown for a single app, with nested sub-projects. Specific examples like 'what was I working on in After Effects this week?' make the purpose unambiguous and differentiate it from sibling tools.

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?

Explicit use cases are given (e.g., 'which YouTube videos did I watch today?'), guiding when to invoke. However, it does not explicitly state when not to use or provide alternatives.

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?

With no annotations, the description fully describes the tool's behavior, listing the output categories in detail (lifetime totals, period totals, etc.). It does not disclose side effects, authentication needs, or data freshness, but for a read-only statistics tool, the main behavior (what it returns) is well covered. The lack of side effects is implied.

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 concise paragraph that front-loads the main purpose, then lists the output categories, and ends with practical usage examples. Every sentence earns its place with no redundancy.

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

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

Given the tool's three parameters, no output schema, and no annotations, the description adequately covers what the tool does and the kinds of results it produces. It provides enough context for an AI agent to understand the tool's role among siblings and its typical use cases.

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 input schema has 100% coverage, so each parameter already has a good description. The tool description adds context about the output types (e.g., 'period totals' enriches the meaning of the 'period' parameter), but does not directly explain parameter values or constraints beyond what the schema provides. Baseline 3 is appropriate as the description adds some value but not significantly beyond 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 specifies that the tool provides 'deeper statistics for a single app' and enumerates the specific types of statistics (lifetime totals, period totals, top projects, daily series, hour-of-day distribution, weekday distribution). It uses compelling example queries like 'when do I usually use Cursor?' to illustrate its purpose, distinguishing it from sibling tools that likely offer simpler or aggregated 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?

The description explicitly states when to use the tool: 'for usage-pattern questions'. It provides concrete examples. However, it does not mention when NOT to use it or alternatives (e.g., simpler app breakdowns), which would have made the guidance more complete.

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?

With no annotations, the description carries the full burden. It discloses that both active and passive seconds are returned and that zero-activity days are included. However, it does not describe potential large data sizes, rate limits, or authentication needs. The return format (e.g., structure of each day entry) is implicit but not explicit.

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 two sentences long, front-loading the core purpose in the first sentence. Every sentence adds meaningful information without redundancy. It is succinct yet informative.

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?

Given no output schema, the description reasonably covers the type of data (active/passive seconds per day) and a key constraint (inclusion of zero-activity days). However, it lacks details on the exact format of each day entry (e.g., date format, units). For a tool with multiple siblings, it does not specify how it differs from get_focus_heatmap or other calendar-like endpoints, slightly reducing completeness.

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 parameters are already well-documented. The description adds value by explaining the default 'year' period analogy to GitHub heatmap and advising on other period usage for narrower windows. It also hints at the benefit of including zero-activity days for streak analysis, which helps the agent understand the period parameter's effect.

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 states the tool returns 'Dense per-day series of active and passive seconds for a period'. It distinguishes from siblings by mentioning the default 'year' period for a GitHub-style heatmap and explicitly including zero-activity days for streak analysis. The verb 'get' and resource 'daily totals' are unambiguous.

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

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

The description provides useful context on when to use different periods (default 'year' for heatmap, other periods for narrower windows) and notes zero-activity inclusion for streak/gap analysis. However, it does not explicitly tell the agent when to prefer this tool over alternatives like get_focus_heatmap or other breakdown tools, nor does it mention any prerequisites or limitations.

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?

With no annotations provided, the description carries the full burden. It discloses that the tool performs a roll-up aggregation, uses a fixed taxonomy, and has a fallback mapping (unmapped apps go to 'other'). This covers the key behavioral traits for a read-only aggregation tool. It doesn't detail error handling or output formatting, but those are not critical for this type of operation.

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 exactly two sentences, front-loaded with the core action and taxonomy list. The second sentence adds a necessary usage note about label usage and the 'other' fallback. There is no redundant information or fluff, making it highly efficient.

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?

Given that all parameters are optional and thoroughly described in the schema, and the tool is a simple read aggregation with no output schema, the description covers the essential behavioral details: it aggregates by category, uses a specific taxonomy, and handles unmapped apps. It is complete for an agent to understand and invoke the tool 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?

The input schema provides comprehensive descriptions for all 5 parameters, achieving 100% coverage. The description adds no parameter-specific information beyond what the schema already states (e.g., device filters, period formats, hour ranges). Per the rubric, with high schema coverage the baseline is 3, and the description does not need to compensate further.

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 states the tool's function: it 'rolls up app totals into Vetroscope activity categories', listing the exact categories (coding, creative, etc.). This is a specific verb+resource (app totals to categories) and distinctly differs from sibling tools like get_app_breakdown (per-app breakdown) or get_tag_breakdown (tag-based). The taxonomy reference to Charts and Settings reinforces its unique scope.

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

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

The description provides context by mentioning the same taxonomy as Charts and Settings, implying this is the canonical category aggregation. It also instructs to 'prefer category labels from the result verbatim' and notes that unmapped apps land in 'other'. However, it does not explicitly mention when to use this over get_app_breakdown or get_device_breakdown, or provide exclusions, so it lacks explicit alternatives.

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?

No annotations provided, so description carries full burden. It describes the output fields and states clearly, implying a read-only operation with no side effects. It does not mention any destructive behavior, which is acceptable for a status 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?

The description is two sentences with no waste. The first sentence provides detailed output information, and the second gives a concrete use case. It is front-loaded and efficient.

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?

Given no parameters and no output schema, the description fully explains what the tool returns and when to use it. For a simple status tool, this is completely adequate and leaves no ambiguity.

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 has no parameters, so schema coverage is 100%. The description adds meaning beyond the schema by explaining the output structure and what the states signify, which indirectly clarifies that no input is needed.

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

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

The description clearly states the tool returns the most recent activity including app/project/sub-project, seconds ago, and state (tracking vs idle). It distinguishes itself from siblings by focusing on current status, while others like get_app_breakdown provide breakdowns over time.

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

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

The description explicitly says 'Use this for 'what am I doing right now?' questions', providing clear context for when to use the tool. It does not mention alternatives explicitly, but the use case is well-defined.

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?

With no annotations provided, the description carries the full disclosure burden. It does this excellently by specifying what each device reports (active/passive seconds, days active, first/last seen, platform, isCurrent flag) and, most importantly, revealing the DISTINCT 30s-bucket counting semantics and the resulting double-counting caveat versus get_report. This is critical behavioral information an agent needs to interpret results correctly.

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

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

The description is efficient and well-structured. Four sentences, each earning its place: scope, per-device fields, the isCurrent flag, and the crucial bucket-counting caveat. Information is front-loaded with the primary purpose and no filler or redundancy.

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

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

For a single-parameter read-only breakdown tool with no output schema and no annotations, the description is remarkably complete. It covers the intended audience, output fields, the special isCurrent marker, and the mathematical semantics that prevent misinterpretation. An agent has everything needed to call the tool and interpret 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% for the single 'period' parameter, so the schema already fully documents the allowed values. The description adds no additional parameter-level meaning, but it doesn't need to; the baseline of 3 applies because the schema does the heavy lifting.

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 states the tool's function: 'Time per device for users who run Vetroscope across multiple machines (or paired with the browser extension).' It identifies the resource (devices) and distinguishes itself from get_report by explicitly noting that summing device totals can exceed get_report.totalSeconds, separating it from the total-report sibling.

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

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

The description gives a clear context for when the tool is relevant: users running Vetroscope on multiple machines or with the browser extension. It implies this is the device-level breakdown tool and references get_report as the total counterpart, but it does not explicitly state 'use this when you need device-level detail' or name all alternatives. Still, the context is sufficient for an agent to select it appropriately.

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?

With no annotations provided, the description carries the full burden and does so well: it discloses the exact cell ordering, weekday numbering (0=Sunday), tag matching semantics, include_descendants behavior, and the nature of the data (active foreground seconds). No contradictions or missing critical behaviors.

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 compact and front-loaded: the first sentence states the core output, the second explains value, and the third covers parameter behavior and indexing. Every sentence earns its place with 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?

Despite having no output schema and six optional parameters, the description provides a complete mental model: output shape, cell ordering, filter semantics, and descendants behavior. It also adds practical indexing guidance that compensates for the missing 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 schema already documents all six parameters with descriptions. The description adds a few clarifying examples and reiterates tag matching/descendants, but these are largely redundant with the schema, so the 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?

The description uses a specific verb ('Returns') and precisely names the resource ('dense 168-cell grid of active foreground seconds'), which clearly distinguishes it from sibling breakdown/stat tools. The added context about revealing interaction patterns further reinforces its unique purpose.

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

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

The description explains when to use this tool ('Reveals when you usually do specific kinds of work') and contrasts it with marginal distributions, implying a comparison to aggregate breakdown tools. However, it does not explicitly name alternatives or state when not to use it, so it stops 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?

With no annotations, the description carries full burden. It discloses that each row carries a snapshot of the goal as it was when achieved, handling renamed/deleted goals. This adds key behavioral context beyond the tool name.

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, no wasted words. Front-loaded with the core purpose, followed by a behavioral note and practical use cases. Every sentence adds value.

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 tool with one optional parameter and no output schema, the description sufficiently explains the data structure (rows per goal per day) and use cases. Could be more explicit about return format, but adequate.

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 one parameter well-described in the schema. The description does not add additional meaning to the parameter beyond what the schema provides, hence the baseline score of 3.

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?

Clearly states the tool returns historical records of achieved goals, one row per goal per day with a snapshot. Distinguishes from sibling tools like 'get_goals_progress' by focusing on achievements, not progress.

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?

Provides explicit use cases for streak questions and summaries, giving context for when to use. Does not explicitly state when not to use or name alternatives, but the context is clear.

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?

With no annotations provided, the description must disclose behavioral traits. It only states that the tool returns 'current progress' and defaults to today, but does not mention read-only status, error behavior, or potential side effects. For a read operation, safety is implied but not explicit.

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, focused sentence (15 words) that front-loads the main purpose. Every word contributes meaning, with no redundancy or unnecessary detail.

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 tool with one parameter and no output schema, the description is adequate. It explains the scope (per-app and overall) and default period. However, it omits details about the return format, metric units, or how progress is calculated, which would be helpful for an agent.

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 parameter 'period', so baseline is 3. The description adds value by explaining that progress is broken down 'per-app and overall', which is not in the schema and helps clarify the output structure. This extra context earns a 4.

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 states that the tool returns 'current progress on the user's configured Vetroscope goals' and specifies 'per-app and overall', which distinguishes it from siblings like get_goal_achievements. However, the description is a noun phrase without an explicit verb, and it could be more precise about what 'progress' means.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_goal_achievements or get_current_status. It only mentions a default value for the period parameter but lacks exclusion criteria or usage context.

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?

With no annotations, the description carries full burden. It explains the parsing convention and override mechanism, but omits details on authorization, rate limits, response structure, or potential side effects. The read-only nature is implied but not stated.

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 efficiently convey purpose and technical details. The first sentence front-loads the core function, and the second provides necessary context without extraneous words.

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?

Given no output schema, the description adequately covers the returned data categories (top tracks, top artists, per-day minutes). It explains parameter overrides and parsing. However, it does not describe response structure, which could be helpful for an agent.

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 baseline is 3. The description adds value by explaining the 'Artist — Title' parsing convention and the default lists for music_apps/music_browser_projects, supplementing the schema descriptions.

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 states the tool retrieves 'top tracks and top artists' and 'per-day listening minutes'. It specifies the source (native apps and browser music sites) and the parsing convention, making the purpose unambiguous. It also references the sibling tool get_music_split for the classifier, aiding 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?

The description implies usage for retrieving aggregated listening history but does not explicitly state when to use this tool versus alternatives like get_music_split. It provides context on overriding music apps but lacks clear when-to-use or when-not-to-use 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?

With no annotations, the description must cover all behavioral traits. It discloses URL filtering (no ads/shorts), version requirements, response conditions (available: false), sorting by total time, and time column behavior with/without period.

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 dense paragraph but contains no wasted sentences. It is front-loaded with the purpose. Could be slightly more structured with bullet points, but remains 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?

Given no output schema, the description explains row contents (time data, webUrl). It covers version checks, filtering behavior, and data source. For a complex list tool with 8 parameters, it is fully informative.

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%, but the description adds significant context: examples for search, explanation of hour_start/hour_end interaction, device options with concrete values, and period effect on lifetime totals. This greatly aids correct parameter usage.

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 explicitly states it lists canonical deep-links for media played, specifying Spotify URIs and YouTube URLs. It clearly differentiates from sibling tools like get_listening_history by focusing on direct links.

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 provides concrete example queries ('what YouTube videos did I rewatch this week') and mentions prerequisites (Vetroscope version, setting). However, it does not explicitly state when not to use or name alternative tools.

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?

With no annotations provided, the description effectively discloses behavioral traits: the classification logic (native apps vs. browser sites), override mechanisms, and filter inheritance from get_report. It lacks details on data freshness or rate limits, but is transparent about core 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 moderately concise, containing multiple sentences that each add necessary context (buckets, overrides, filters). It is front-loaded with the core purpose. Slightly verbose due to detailed filter explanations, but still efficient.

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?

Given no output schema, the description explains the return value structure (three buckets plus per-source totals). It covers all key aspects for a complex tool with 7 parameters and no required fields. Could specify return units (hours/minutes), but overall complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant meaning by explaining how parameters like music_apps and music_browser_projects override defaults, and how hour, weekday, and device filters work. This exceeds the schema's minimal descriptions.

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 states the tool splits tracked time into three specific buckets ('work with music', 'music only', 'work without music') and returns per-source totals. It distinguishes itself from sibling tools like get_report by detailing the unique classification logic and honoring the same filters.

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

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

The description explains when to use this tool (to analyze music vs. work split), including how to override default music classification. It references get_report for filter consistency, but does not explicitly list when not to use it or suggest alternatives like get_app_breakdown.

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?

With no annotations provided, the description carries full behavioral burden and does so excellently. It reveals non-obvious overlap semantics (30s buckets counted once for totalSeconds, per-app buckets may exceed totalSeconds), warns against summing app rows to equal the header, discloses inherited SQLite settings, and mentions display_name 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 moderately long but information-dense, with the core purpose front-loaded in the first sentence. The subsequent caveats about overlap and summing prevent misuse rather than padding, making the length justifiable.

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 8-parameter tool with no output schema and no annotations, the description covers output categories, filter behavior, inherited settings, nested sub-projects, and a critical data-integrity warning. An agent has enough context to invoke the tool correctly and interpret its results safely.

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 input schema covers 100% of the 8 parameters with detailed descriptions, so the baseline is 3. The tool description adds useful global context about filter layering and dashboard settings, but it does not add per-parameter semantics beyond what the schema already 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 opens with 'Aggregate Vetroscope time report' and enumerates the returned aggregates (total active seconds, top apps, top projects), making the action and resource clear. It does not explicitly contrast with siblings like get_app_breakdown or get_app_stats, so it stops short of full 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?

The description makes the intended use context clear: a period-level aggregate report with optional hour-of-day, weekday, and device filters layered over standard dashboard settings. It does not name alternatives or state when not to use it, but the usage context is strong.

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?

No annotations exist, so the description carries full burden. It explains session definition and metadata returned, but lacks details on edge cases or limitations.

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?

Description is efficient and front-loaded with the core purpose, though the second sentence could be slightly more 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?

For a tool with 10 parameters and no output schema, the description adequately explains what sessions are and what metadata is returned, making it complete.

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

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

Schema coverage is 100%, so the baseline is 3. Description adds context about session granularity but does not significantly enhance parameter meaning 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 states the tool reconstructs continuous activity blocks from raw entries, which is specific and distinct from sibling tools like get_app_breakdown or query_entries.

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?

Implies usage for answering 'what did I work on this morning?' but does not explicitly contrast with alternatives or state when not to use.

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?

With no annotations provided, the description carries the transparency burden. It discloses the tag matching behavior (case-insensitive), the descendant roll-up semantics, and the report's constituent elements, going beyond the schema. It does not describe response format or error/auth behavior, but for an evidently read-only report tool this is largely acceptable.

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 three concise sentences, each earning its place: the first defines the report, the second covers tag identification, and the third explains parent-tag usage. No filler or redundancy, and the main purpose 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?

Given the 9-parameter complexity, the fully-detailed schema covers most parameter semantics, and the description adds the essential usage context and report components. The only notable gap is the lack of explicit output format description, but the report's components are enumerated in the first sentence, making it reasonably complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by explaining how to identify tags ('call list_tags first', case-insensitive) and when to use include_descendants for parent tags, effectively enriching the tag and include_descendants parameters. The other parameters rely on their already-detailed schema descriptions.

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 tool as a time-spent report for a single tag, enumerating its specific outputs (top apps/projects, daily series, active/passive split). This distinguishes it from sibling tools like get_tag_stats or get_app_breakdown by the combination of tag-level scope and breakdown components.

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

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

The description explicitly advises calling list_tags first when the tag name is unknown, and gives a concrete usage rule for include_descendants with parent tags. It does not explicitly contrast with alternatives, but the provided context is sufficient for basic tool selection and invocation.

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?

With no annotations, the description carries the full behavioral burden and does well: it discloses that the default counts only directly-assigned time, that children are reported separately, and that parent tags can roll up the whole subtree. It also explains case-insensitive name or numeric-id identification and the aggregation surfaces offered.

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 but each sentence earns its place: purpose, output scope, then aggregation semantics escaped/include_descendants. It is front-loaded with what the tool does and avoids filler or tautology.

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 description is complete enough for a complex statistics tool with no output schema and no annotations: it describes return contents, default vs. subtree behavior, how to refer to a tag, and when to use include_descendants. The agent can select the tool and construct a correct call with confidence.

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 input schema already provides detailed descriptions for all 4 parameters, so the baseline is 3. The description adds meaningful guidance beyond the schema, especially the real-world 'how did I spend time under this parent tag?' example and the default direct-assignment behavior, which helps an agent reason about include_descendants more concretely.

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 opening 'Deeper statistics for a single tag' names the exact purpose, and the parallel to get_app_stats positions it clearly within the tool family. The explicit list of lifetime totals, distributions, and hierarchy details makes the tool's behavior unambiguous and distinguishes it from simpler stats or breakdown tools.

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

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

The description clearly explains when to use include_descendants, especially for parent tags, and suggests calling list_tags first when identification is uncertain. It does not explicitly name get_tag_breakdown as an alternative to avoid, but the 'deeper' framing plus the detailed use case covers most of the needed when-to-use context.

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?

No annotations are provided, so the description carries the full burden. It explains the taxonomy is the same one Charts/Settings use, which helps the agent understand the data source and trust the ids. However, it doesn't mention whether the taxonomy is static (e.g., whether categories are fixed or user-customizable), potential errors, or what happens if the taxonomy is empty—though at only one sentence, it's relatively rich for the information provided. The lack of annotations doesn't harm the tool but also doesn't yield extra credit beyond what's useful.

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. First sentence states the resource, lists example categories, and mentions the response fields. Second sentence gives usage guidance. Zero filler words, no repetition, and the most important information is front-loaded. Every word 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-parameter, no-output-schema tool, this is completely specified. The description covers what the tool returns, gives an example of the taxonomy, and tells the agent when to call it relative to siblings. There's no ambiguity left for the agent. A 5 is appropriate for a tool this simple.

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?

With zero parameters, there is nothing the description needs to add syntactically. The description confirms the only output is a list of categories with label and color, which is the primary purpose. The baseline for 0 params is 4, and the description adds the detail about 'label and color' and the id usage, which is useful semantic context even though there are no params. Not a 5 because there's nothing particularly clever needed here.

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 states what the tool does: returns Vetroscope's activity-category taxonomy with label and color. It names specific categories (coding, creative, productivity, etc.), distinguishing it from siblings like get_category_breakdown. The verb 'Returns' plus the resource 'activity-category taxonomy' is specific, and the mention of ids used by Charts/Settings adds clarity without being verbose.

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

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

The description explicitly tells when to call this tool: 'Call before get_category_breakdown when you need the full list of labels.' This directly identifies the tool as a prerequisite to a sibling, which is exactly the kind of contextual guidance agents need to select between similar tools. It implies for other cases you might not need it, and it names the alternative sibling explicitly.

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?

Discloses marker structure, overlap logic for regions, and parameter behavior. Without annotations, this provides adequate transparency for agent decision-making.

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 concise sentences effectively convey purpose and usage. No redundancy or wasted words.

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?

Covers all necessary aspects: what the tool does, what markers contain, how period scoping works, and return behavior. Complete for a simple list tool.

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

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

Schema coverage is 100%, but description adds valuable semantics: overlap behavior and valid period values (today, yesterday, date ranges), beyond schema's list.

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?

Clearly states it lists user-placed markers on the Vetroscope timeline, detailing marker components (timestamp, optional end_timestamp, label, color, icon). Distinct from siblings as the only tool for timeline markers.

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 explains when to use period parameter (scope to a window) and when to omit it (list all). Lacks explicit alternatives but clear context makes it sufficient.

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?

With no annotations, the description carries the behavioral disclosure burden. It reveals that the tool returns an empty array on installs that predate note folders, which is a valuable edge case. It also hints at the nested/hierarchical nature of the data. Though it doesn't cover sorting or performance, for a straightforward list operation this is adequate and transparent.

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 two sentences, front-loaded with the subject and data fields. It then provides usage context and an edge case. Each sentence adds essential information without redundancy, making it highly concise and well-structured.

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?

Given the simplicity of the tool (no params, no output schema), the description is fairly complete. It explains the data returned (fields and nesting), the usage context, and a potential empty result scenario. It could clarify the exact structure (e.g., flat list vs. nested tree) or mention ordering, but for a list tool it is sufficiently informative.

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 has zero parameters, so the description adds no parameter semantics beyond the schema. The baseline for zero parameters is 4, and the description appropriately does not invent any parameter explanations. It remains consistent with the empty 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 states it lists note folders, the specific resource and verb. It differentiates itself from siblings by specifying 'Nested note folders' and listing the data fields (uuid, name, parentUuid, path, color). It also indicates integration with list_notes, which helps identify its role among the many list tools.

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

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

It explicitly states when to use this tool: 'Use with list_notes when organizing or filtering by folder.' This provides clear context. It also notes behavior on older installs, implying it may not be applicable there. However, it doesn't explicitly mention when not to use it or name alternatives, but the guidance is sufficient for a simple parameterless tool.

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?

With no annotations, the description carries the transparency burden. It discloses meaningful behaviors: period filters use region overlap, timeless notes are excluded from period filters, and old installs return an empty list. This goes beyond the bare minimum, though it omits details like pagination or ordering.

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 compact and information-dense, with no filler. It front-loads the core resource definition, then explains optional filters and edge-case behavior in a logical order. Every sentence contributes meaningful guidance.

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?

Given the tool has only two optional parameters and no output schema, the description provides sufficient context: what notes contain, how filtering behaves, how to list everything, and a backwards-compatibility edge case. It is complete for an agent to select and invoke this tool confidently.

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 adds value by explaining overlap semantics for the 'period' parameter, the 'none' folder sentinel, and the distinction between timed and timeless notes, all of which complement rather than merely repeat schema descriptions.

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 tool's purpose as listing user notes, with a specific verb and resource. It details note contents (title, body excerpt, timestamps, folder, pin) and distinguishes it from sibling list tools like list_categories and list_tags.

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?

Provides clear usage guidance: using 'period' to scope timed notes, omitting it to list all notes, and using folder filters with the special 'none' value. Does not explicitly name alternatives or state when not to use the tool, but the contextual direction is strong.

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?

With no annotations, the description adds behavioral context: it returns all-time historical data, is a read-only operation, and supports case-insensitive search. However, it omits details like default limit or ordering.

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 efficient sentences: first describes output clearly, second gives intuitive usage examples. No wasted words, 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?

No output schema, but description explicitly states returned fields (totals, days active, first/last seen) and search capability. Fully covers what an agent needs to know for this simple list operation.

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% for both parameters. Description adds context for 'search' (case-insensitive substring match) but does not describe 'limit' beyond what schema already provides, adding moderate value.

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 states the tool lists all (app, project) pairs with all-time totals, days active, and first/last seen. It specifies optional substring search, distinguishing it from siblings like get_app_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?

Provides concrete use cases like 'have I ever worked on something called X?' or 'what's my biggest project all-time?' This implies when to use it, but lacks explicit when-not-to or alternative tool mentions.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It usefully states that soft-deleted events and notification icon data are omitted, and its read/list nature is clear. However, it does not disclose ordering, default time-window behavior, output shape, or whether any permissions are required.

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 two sentences long and front-loads the essential purpose and filters, then adds a brief behavioral caveat. There is no redundant repetition of schema or title content.

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 list/history tool with no required parameters and 100% schema coverage, the description and schema together cover the main invocation decisions. It could be more complete by describing the event fields or ordering behavior, but it is sufficient for the tool's 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?

All four parameters have detailed descriptions in the input schema, including defaults and allowed period formats. The description names the same filter categories but adds little semantic value beyond the high-coverage 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 clearly identifies this as a 'History of reminder notifications that fired' with a concrete resource scope and optional filters. This distinguishes it from sibling tool list_reminders, which refers to configured reminders rather than fired notification events.

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

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

The description provides clear context for when to use the tool: retrieving historical reminder notification events with optional time-window, unread-only, or reminder UUID filters. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent can select it appropriately.

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?

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states that disabled reminders are hidden by default and that notification icon data is not returned, which are meaningful omissions and filtering behaviors. It does not mention ordering or return format, but for a read-only list tool this is substantial coverage.

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 compact and organized, with the main reminder-type enumeration followed by two short behavioral clauses. The first sentence is somewhat dense due to the parenthetical qualifiers, but every clause adds substantive information and no space is wasted.

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

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

For a tool with one optional parameter and no output schema, the description is reasonably complete: it covers what is included, what is excluded by default, how to include disabled reminders, and one notable data omission. It does not address potential sibling overlap or sorting, but the core behavior is adequately specified.

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% and the sole parameter include_disabled is already described in the schema, giving a baseline of 3. The description adds value beyond the schema by explaining the audit use case ('audit them') and tying the parameter to the default omission behavior.

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 tool as listing configured Vetroscope reminders and enumerates the specific reminder types included, providing more detail than the title alone. This scope distinguishes it from sibling tools like list_reminder_events, which would cover events rather than configured reminder definitions.

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

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

The description gives clear context around the default behavior (disabled reminders omitted) and when to set include_disabled for auditing, but it does not explicitly discuss when to choose this tool over sibling alternatives such as list_reminder_events or get_goals_progress. Usage is implied rather than explicitly contrasted.

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?

No annotations are provided, so the description carries the burden. It discloses that archived tags are hidden by default and how to include them, plus mentions nesting details. This is good for a read-only tool.

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

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

Two sentences, front-loaded with what is returned, then default behavior and usage tip. No wasted words.

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?

Without an output schema, the description lists all returned fields, explains default behavior, and suggests when to use it. It lacks mention of pagination or errors, but those may not be relevant for this simple list operation.

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% (include_archived has a description). The tool description repeats the concept but adds context about default behavior and usage, though not much beyond 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?

The description clearly states the tool lists the user's tags with specific fields (id, name, color, sticky, archived, parentId/parentName), distinguishing it from analytics siblings like get_tag_breakdown and get_tag_stats.

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

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

It explicitly says 'Useful as a reference before calling get_tag_breakdown / get_tag_stats or filtering entries by tag,' naming alternatives and giving context. It does not explicitly state when not to use, but the guidance is clear enough.

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?

With no annotations, the description must cover behavioral traits. It discloses default mode ('active'), row limits (5000 max, 200 default), period-dependent exclusions, and optional filters. It does not explicitly state if the operation is read-only, but that is implied.

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 paragraph that efficiently conveys key details. However, it mentions the default limit twice ('default 200' appears at both the start and end), which slightly reduces 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?

For a tool with 11 optional parameters and no output schema, the description covers all necessary behavioral aspects: filtering semantics, period behavior, mode, limits, and special parameter values. An agent can confidently select and invoke this tool 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?

The schema covers 91% of parameters with descriptions. The description adds significant value beyond schema: it explains period exclusions, default mode, how hour_start/hour_end combine, and special device values like 'current'. This additional context is highly informative.

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 states 'Filtered list of raw tracking entries,' identifying the specific verb and resource. It further explains use cases like digging into projects and tags, distinguishing it from sibling tools that provide aggregate breakdowns.

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

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

The description explains when to use the tool (for specific searches) and contrasts behavior with/without a period filter. However, it does not explicitly state when not to use it or name alternative tools for other purposes.

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