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

The description discloses the visual effect (orange glow), its purpose (feedback for automated actions), and the return type (success/error message). No annotations are provided, but the description adequately covers the basic behavior without contradictions.

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 concise with three sentences plus a returns line. The important usage note is highlighted with 'IMPORTANT', making it well-structured and easy to parse.

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 fully covers what the tool does, when to use it, and what it returns. It is complete for a simple tool with no parameters and a clear purpose, especially given the existence of a complementary sibling tool to remove the glow.

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 the schema coverage is trivially 100%. Following guidelines, the baseline is 4. The description does not need to add parameter information since none exist.

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 adds an orange glow around screen edges to indicate automated actions in progress. It uses a specific verb 'add' and resource 'screen glow', and the purpose is distinguishable from its sibling 'remove_screen_glow'.

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 instructs to call this tool FIRST before performing automated actions, providing clear usage context and timing. It implies when not to use (after actions) and the complementary sibling tool is implied.

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

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

No annotations are provided, so the description carries full behavioral disclosure. It states it appends plain text but fails to disclose important traits: behavior when note does not exist, handling of identifier ambiguity (multiple notes with same title), impact on rich text notes, or if it creates the note if missing. Error handling is not detailed.

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 concise at two sentences plus bullet-style Args and Returns. It is front-loaded with the main action. Every sentence provides value, though the Args section could be integrated for brevity. Overall efficient and clear.

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?

An output schema exists, so return value details are not needed. However, given the tool's simplicity and lack of annotations, the description omits critical behavioral context: what happens if identifier matches multiple notes, if note not found, or if body is not plain text. It is minimally viable but leaves gaps.

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 has two required string parameters with 0% description coverage. The description adds meaning: 'identifier' can be a note id or title, and 'body' is plain text. This clarifies usage beyond the schema. However, it could specify the expected format for identifier (e.g., UUID) or constraints on body length.

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?

Description clearly states 'Append plain text to a note by id or title.' This specifies a concrete verb 'append' and resource 'note,' with the method 'by id or title.' It distinguishes from sibling tools like 'update_note' (which likely modifies or replaces content) and 'create_note' (which creates a new note).

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

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

The description implies usage for appending text, but it does not explicitly state when to use this tool over alternatives like 'update_note' (which might replace content) or 'create_note.' No guidance on prerequisites (e.g., note must exist) or exclusion criteria. Usage is implied but not clarified.

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 description discloses that it captures the display of the frontmost app and returns a text status plus image. It does not mention permissions or side effects, but for a read-like screenshot tool, this is largely sufficient.

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 concise, front-loaded with the main purpose, and uses a clear Args/Returns structure. 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, the description covers the main function, parameter, and return format. It could mention prerequisites like permissions, but overall it is sufficiently 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 0%, so the description must add meaning. It clearly explains the single optional parameter 'output_path' as a file path for output PNG, which the schema lacks.

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 captures a full screenshot of the display containing the frontmost app and shares it with the model, which distinguishes it from sibling tools like chrome_screenshot that capture specific browser content.

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

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

No guidance is given on when to use this tool versus alternatives such as chrome_screenshot or save_clipboard_image. The description lacks explicit context or exclusions for usage.

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 for behavioral disclosure. It explains centering behavior, optional resizing before centering, and return value. However, it omits edge cases like what happens when multiple selection params are provided (e.g., window_id vs. app_name) or precise error conditions.

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 concise (two sentences plus bullet-like list) and front-loaded with the core action. Every sentence serves a purpose; no fluff.

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

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

The tool has 6 optional parameters, no annotations, and an output schema. The description covers each parameter and the return format. It is nearly complete, but a note on selection precedence when multiple window identifiers are given would elevate it.

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

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

The schema has 0% description coverage, so the description's parameter explanations add significant value, specifying the meaning of each field (e.g., app_name can be name, bundle id, or process name). However, it lacks clarity on how parameters interact (e.g., selection priority).

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 verb 'center' and the resource 'macOS window', and distinguishes it from sibling tools like 'move_window' (move without centering) and 'resize_window' (resizing only). The action is precise and 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 no guidance on when to use this tool vs. alternatives such as 'move_window' or 'resize_window'. It lists parameters but does not explain conditions for choosing this tool over siblings, leaving the agent to infer.

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 discloses that the tool returns 'Structured JSON with availability and conflicts or an error message', providing insight into the tool's behavior. It also lists parameters with format hints. However, it does not mention any side effects, though for a read-only check like this, that is acceptable. The transparency is good but not exhaustive.

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 extremely concise: a one-sentence summary followed by a brief list of arguments. Every sentence adds value, and the key purpose is front-loaded. There is no fluff or repetition, making it efficient for an agent to parse.

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

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

The tool has 3 parameters, all described; an output schema is mentioned (though not shown); and the description explains return values. However, it lacks details such as whether checking applies to all calendars or just the specified one, timezone handling, or how conflicts are determined. For a simple checking tool, it is largely complete but has minor gaps.

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 0% description coverage, meaning no parameter descriptions. The tool description compensates fully by explaining the format for 'start_datetime' ('YYYY-MM-DD HH:MM'), the unit for 'duration_minutes' (in minutes), and that 'calendar_name' is optional. This adds significant meaning beyond the raw schema types and defaults.

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 purpose: 'Check whether a Calendar time slot conflicts with existing events.' It uses a specific verb ('check') and a well-defined resource ('Calendar time slot'). This purpose is distinct from sibling tools like 'create_calendar_event' or 'list_calendar_events', as it focuses on conflict detection rather than creation or listing.

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 the tool is used for checking availability, but does not explicitly provide guidance on when to use it versus alternatives (e.g., before creating an event). There is no mention of when not to use it or references to other tools. The usage is clear from context but lacks explicit direction.

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 but only mentions 'Click an element' and return type. It fails to disclose behaviors such as effects on page state, timing, error handling (e.g., element not found), or whether it uses native events vs JavaScript.

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 concise (two sentences plus Args/Returns), front-loaded with the core purpose, and contains no superfluous information. Every sentence is necessary.

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 simplicity, the description covers the basic action and parameters. However, it omits usage guidelines, behavioral details, and fails to fully describe error states or return value format, leaving some gaps for an AI 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 0%, but the description explains session_id as 'Session returned by chrome_open_session' and selector as 'CSS selector for target element'. This adds basic meaning beyond the schema (which only has types), but lacks details like selector format or session_id validation.

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 'Click an element in an active Chrome CDP session using a CSS selector,' clearly specifying the action (click), target (element), context (active Chrome CDP session), and method (CSS selector). It distinguishes from sibling tools like chrome_type (typing) and chrome_navigate (navigation).

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 does not explicitly state when to use this tool versus alternatives like chrome_type or chrome_wait_for. It implies a requirement for an active session from chrome_open_session but offers no guidance on exclusions or comparative use cases.

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; description carries full burden. Discloses that it closes a session and returns success/error, but does not mention side effects, state requirements, or error 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?

Very concise: one-line purpose, then args and returns. No redundant information, easy to parse.

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 close operation with one parameter and an output schema, the description covers purpose, argument, and return. Could mention that the session must be open, but still 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?

Input schema only specifies 'session_id' as string; description adds 'Session returned by chrome_open_session', providing important context beyond the schema. With 0% schema description coverage, this compensates well.

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 verb 'Close' and resource 'Chrome automation session'. Distinct from siblings like chrome_open_session and chrome_list_sessions.

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?

Advises that session_id should come from chrome_open_session, but does not explicitly state when to use or alternatives. Implicitly, use when you want to close a session, but no guidance on prerequisites or 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?

No annotations are provided, so the description carries full burden. It discloses that output is JSON or error message but fails to clarify precedence when both selector and javascript_expression are provided, or behavior when neither is specified. Side effects are not addressed.

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 concise with a clear purpose statement, an args list, and return info. It is front-loaded with the main action. Minor formatting (bullet-like lines) but 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?

Given 0% schema coverage and no annotations, the description should cover parameter interactions and error scenarios. It explains basic usage but lacks details on mutual exclusivity of selector and javascript_expression, and does not describe potential failure modes or output schema content.

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 0%, so description must compensate. It explains each parameter (session_id, selector, attribute, javascript_expression) briefly, adding meaning beyond empty defaults. However, it does not clarify mutual exclusivity or dependency requirements, leaving ambiguity.

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 'Extract data from a page by selector or by JavaScript expression,' clearly specifying the verb (extract) and resource (data from a page). It distinguishes the two methods, avoiding tautology and providing specific 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 implies usage for extracting data but provides no explicit guidance on when to use this tool versus siblings like chrome_click or chrome_screenshot. No exclusions or alternative tools are mentioned.

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 accurately states the return type but offers no additional context about side effects, safety, or operational characteristics.

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 extremely concise with two sentences that convey the tool's purpose and output without any 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?

Given the lack of parameters and the presence of an output schema, the description is sufficient to understand what the tool does and what it returns, completing the picture 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?

There are no parameters, so the baseline score of 4 applies. The description does not need to compensate for missing parameter information.

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 verb 'List' and resource 'active Chrome automation sessions,' which distinguishes it from sibling tools like chrome_open_session and chrome_close_session.

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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention scenarios where it should not be used. The purpose is implied but not clarified.

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 must fully disclose behavior. It only mentions navigation to a URL, but omits details like whether it waits for page load, handles redirects, or reports errors. This is insufficient for an agent to predict side effects.

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 extremely concise: three clear sentences in a structured format. Every word is necessary; no redundant information. It earns its brevity.

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 simplicity and presence of an output schema (describing return values), the description provides minimally viable information. It mentions inputs, output type, and session dependency, but lacks detailed behavior or error handling context.

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 has 0% description coverage, so the description must compensate. It explains that 'session_id' comes from 'chrome_open_session' and 'url' is a URL to load, which adds meaningful context beyond the schema's type-only definitions. However, it could specify expected URL format or call 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 states the action ('Navigate') and the resource ('an active Chrome CDP session to a URL'). It distinguishes from sibling tools like 'chrome_click' or 'navigate_safari' by specifying Chrome CDP context.

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 does not provide any guidance on when to use this tool versus alternatives, prerequisites (e.g., needing an active session from 'chrome_open_session'), or scenarios where it should be avoided. It only states inputs and outputs.

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 fully disclose behavioral traits. It mentions starting a session and debugging port, but lacks details on side effects (e.g., launching a new Chrome process), resource usage, or error conditions beyond a generic error message.

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 concise and well-structured, with a clear purpose statement followed by an Args/Returns section. No extraneous information.

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

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

While the description covers basic purpose, parameters, and return type, it omits important context like persistence of the session, prerequisites (Chrome installation), or how it interacts with existing sessions. An output schema exists but does not compensate for these gaps.

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 0%, so the description bridges the gap by explaining each parameter's purpose (e.g., debug_port for CDP sessions, headless launch if debugger needed), adding meaning beyond the schema's types and defaults.

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 verb 'Open' and resource 'Chrome automation session', which is distinct from sibling tools like chrome_click or chrome_navigate that operate within a session.

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 when to use this tool (to start a session for browser control), but does not explicitly state when not to use it or mention alternatives like reusing an existing session via chrome_list_sessions.

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 description discloses basic behavior (capture screenshot) and return type, but lacks details on what exactly is captured (viewport vs full page), side effects, permissions required, or state dependencies (e.g., session must be open). No annotations are provided to compensate.

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 very concise: a single sentence for purpose, followed by structured Args and Returns sections. No unnecessary information is present, and the most important details are 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 simple screenshot tool with an output schema (suggested by context), the description is adequate but not complete. It covers purpose and parameters but lacks behavioral details like what happens when output_path is empty, whether errors are specific, or how the screenshot is captured (e.g., viewport only).

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 description explains that 'session_id' is the session returned by chrome_open_session and 'output_path' is an optional file path for output PNG. This adds meaning beyond the schema, which only defines types and default values. Schema description coverage is 0%, so the description effectively compensates.

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 captures a screenshot of the active page in a Chrome CDP session, distinguishing it from sibling tools like capture_active_screen. However, it does not explicitly differentiate from other Chrome-specific tools like chrome_navigate or chrome_click.

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

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

No guidance is provided on when to use this tool versus alternatives like capture_active_screen or other screenshot tools. There is no mention of prerequisites or when to avoid using 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?

With no annotations, the description must carry the behavioral disclosure burden. It mentions 'clear_first: Clear existing value before typing,' which is a useful trait. However, it does not describe side effects such as error handling (e.g., if element not found), timing (e.g., waits for element), or whether it simulates keypresses versus setting value. The return is vaguely 'Success or error message.'

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, purpose-defining sentence followed by a clear, bullet-like list of parameters. Every sentence is informative, no filler. The structure is front-loaded with the main action.

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 simplicity (4 parameters, no annotations, output schema exists), the description covers the essential aspects: purpose, parameter explanations, and return value. It lacks details on prerequisites (must have active session) and error scenarios, but overall is adequate for an agent to use 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 0%, so the description compensates well by explaining each parameter: session_id (returned by chrome_open_session), selector (CSS selector), text (text to type), clear_first (clear existing value). This adds meaning beyond the property names, though further specificity (e.g., 'valid CSS selector') would improve it.

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

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

The description clearly states 'Type text into an input element in an active Chrome CDP session,' specifying a verb ('type'), resource ('input element'), and context ('active Chrome CDP session'). This distinguishes it from sibling tools like chrome_click (click) and chrome_extract (extract).

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. It does not mention prerequisites (e.g., session must be open), exclusions, or conditions under which other tools might be preferred. The agent must infer usage context from the tool name alone.

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?

Without annotations, the description covers basic behavior: it waits for a selector to exist and be visible, returning success or error. However, it omits details like whether it scrolls to element, what 'visible' means (e.g., in viewport), or specific timeout 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 well-structured with a clear first line, followed by an Args list and Returns. Every sentence is informative and there is no redundancy.

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

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

For a wait tool with 4 parameters and an existing output schema (as indicated), the description adequately covers purpose, parameters, and return behavior. It lacks some nuance but is largely sufficient.

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

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

Although schema coverage is 0%, the description explicitly explains the role of each parameter (session_id, selector, timeout_ms, poll_ms) beyond the schema's types and defaults. This adds meaningful usage context.

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 verb 'wait for' and the resource 'CSS selector', specifying existence and visibility. It distinguishes itself from sibling tools like chrome_click or chrome_extract which perform different actions.

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 waiting on element presence before interaction, but does not explicitly state when to use or when not to use it compared to alternatives. As the only wait tool among siblings, it scores a moderate 3.

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 description discloses the action and return format (JSON with operation metadata or error), which is sufficient for a simple tool with no annotations. It doesn't conflict with any annotations.

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

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

Two sentences, front-loaded with the action, no filler. 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 simple tool with no parameters and output schema implied, the description covers the action and return value adequately. No missing information.

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?

No parameters exist, so schema coverage is 100%. The description correctly has no param details, meeting the baseline for zero-parameter tools.

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 'Clear clipboard contents' with a specific verb and resource, distinguishing it from sibling tools like get_clipboard_text or set_clipboard_text.

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

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

No guidance on when to use this tool vs alternatives like get_clipboard_text or set_clipboard_text. The description lacks context for when clearing is appropriate.

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 mentions the return type ('Success or error message') but does not disclose potential side effects, such as whether closing the last tab closes the window, or any permissions needed.

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 short and front-loaded with the core action. The docstring format with Args and Returns is clear, though slightly verbose for such a simple tool.

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

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

For a simple tool with one optional parameter, the description is mostly complete. However, it could mention that Safari must be running and what happens if an invalid index is provided. The output schema is not explicitly defined, but the description covers the return type.

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 description explains the meaning of 'tab_index' and its special value -1, adding context beyond the input schema (which only specifies type and default). This is valuable for the agent.

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 action ('Close') and the resource ('a Safari tab'), and specifies how to use the parameter (-1 for current tab, 1-based index). This distinguishes it from sibling tools like 'close_safari_window' and 'switch_safari_tab'.

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 how to specify the tab index, including the special -1 value for the current tab. However, it does not explicitly state when to use this tool versus alternatives like 'switch_safari_tab' or 'close_safari_window', leaving some ambiguity.

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 should disclose behavioral traits. It only states it returns a success or error message but does not mention if unsaved changes are handled, if confirmation is needed, or any side effects.

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 short and front-loaded, but the return value line is redundant given the output schema. 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?

For a simple tool with no parameters and an output schema, the description provides the essential purpose. However, it lacks context about when the action might fail or behave unexpectedly (e.g., minimized windows).

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?

No parameters exist, so the schema already fully defines the interface. The description adds no additional parameter information, but baseline is 4 due to 100% schema coverage.

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 action (close) and the resource (Safari window), distinguishing it from sibling tools like close_safari_tab. However, 'current' could be more precise (e.g., 'frontmost').

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

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

No guidance on when to use this tool vs alternatives like close_safari_tab. The description does not mention context or prerequisites.

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 must cover behavior. Does not disclose side effects, uniqueness handling, or error conditions beyond 'error message'.

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?

Concise, structured with Args and Returns sections. 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?

Output schema exists but not detailed; description summarizes return. Lacks clarity on uniqueness constraints and error scenarios. Adequate but incomplete.

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 0% schema coverage, description adds meaning: identifier can be id or text, list_name narrows search. Lacks details on case sensitivity or id format.

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 action ('Mark as complete') on resource ('reminder') with specificity ('exact or uniquely matching'). Distinguishes from siblings like delete_reminder and update_reminder.

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 parameter usage hints ('id or name/title text', 'optional list name') but lacks guidance on when to use this tool over update_reminder or other 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 explains failure behavior on existing destinations and the dry_run option. However, it lacks details on merging semantics, permissions, or potential side effects, leaving some ambiguity.

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 concise, with a front-loaded purpose statement and clear bullet-pointed arguments. Every sentence adds value 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?

Given the presence of an output schema (implied), the description adequately covers core behavior and arguments. It could mention error handling more explicitly, but overall is sufficient for a directory copy 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?

The description explains each parameter in the Args block, adding meaning beyond the empty schema descriptions. However, source and destination descriptions are minimal ('existing source directory path').

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 copies a directory tree, which is a specific verb (copy) and resource (directory tree). It is distinct from sibling tools like copy_file and move_file.

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 notes that existing destinations fail unless overwrite is true, providing a clear condition for use. It does not explicitly compare with siblings but implies context through the action and arguments.

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 discloses that the tool copies with metadata, supports overwrite and dry-run, and returns a JSON string. It does not mention potential side effects (e.g., overwrite deleting destination) but these are implied by the overwrite parameter.

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 very concise: one sentence summarizing the action, followed by a structured Args and Returns block. Every sentence is necessary and earns its place. No redundant or vague text.

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 simplicity (copy file with options), the description covers parameters and output reasonably well. The output schema existence is noted but not detailed. Missing error cases or exactly what 'metadata' includes, but overall 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 0%, so the description must compensate. It provides clear explanations for all four parameters: source, destination, overwrite, and dry_run. This adds value beyond the schema, though could include format expectations (e.g., absolute paths).

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 'Copy a file with metadata' and explicitly distinguishes from 'copy_directory' for directories. The verb 'copy' and resource 'file' are specific, and the sibling differentiation is explicit.

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 a clear when-not-to-use guideline: 'Directories require copy_directory.' However, it does not differentiate from 'move_file' or other file operations, which could cause confusion. The parameter descriptions (overwrite, dry_run) imply 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?

No annotations are provided, so the description carries full burden. It does not disclose permissions needed, whether it overwrites existing events, error handling for invalid calendar names, or synchronization behavior. Only return type (success/error) is mentioned.

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 concise, uses clear bullet points for args and returns, and front-loads the main action. No superfluous text, but could be slightly more structured (e.g., grouping optional params).

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 creation tool with 4 parameters and an output schema, the description covers basic usage but lacks behavioral details. Given no annotations, it is adequate but leaves gaps about edge cases (e.g., invalid calendar name, event conflicts).

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?

Input schema has 0% description coverage, so the description adds substantial value by explaining the format for start_datetime (with example), duration in minutes, and optional calendar_name. This helps the agent correctly format parameters.

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

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

Description clearly states it creates a calendar event in the macOS Calendar app. However, it does not differentiate from the sibling 'create_recurring_event' tool. Distinguishing between simple and recurring events would improve clarity.

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

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

No explicit guidance on when to use this tool versus alternatives. For example, there is no mention of conditions for using 'create_recurring_event' or handling of default calendars. The description only notes that calendar_name is optional.

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 only states creation but does not disclose potential side effects, ID generation, or whether existing contacts are checked. No contradiction with annotations.

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

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

The description is concise with clear Args and Returns sections. Every sentence adds value. Minor redundancy: defaults in schema could be inferred, but not burdensome.

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 an output schema (though not provided), the description adequately describes return as 'Structured JSON with the created contact'. Parameter descriptions are complete for required and optional fields.

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 0%, so the description's parameter list is essential. It adds meaning: e.g., 'optional organization/company', 'optional phone number to add with mobile label', and 'optional email to add with home label'. This contextualizes the parameters beyond the schema's type/default.

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 'Create a Contacts record' and lists specific optional fields. It distinguishes from sibling tools like update_contact, get_contact, and search_contacts by focusing on creation.

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 use when creating a new contact but does not explicitly state when to use alternatives or conditions for use. No exclusion criteria or when-not-to-use guidance is provided.

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?

Returns only 'success or error message' without details. No disclosure of overwrite behavior, concurrency, or limitations. Annotations absent, so description should carry more burden.

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?

Single sentence followed by clear Args block. No waste, but could be more 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?

Covers 3 parameters, but output is vague. Output schema exists, so return value details are less critical, but still lacks specifics on error types or response structure.

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

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

Schema descriptions are absent (0% coverage), but the description explains each parameter: name, body, and folder with default folder behavior. Adds significant meaning beyond bare 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?

Clearly states 'Create a note' with verb and resource. Distinguishes from siblings like update_note and delete_note.

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

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

No guidance on when to use this tool versus alternatives like append_to_note or move_note. Only default folder behavior mentioned.

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 tool creates a recurring event and returns structured output, but lacks details on side effects, required permissions, default calendar behavior, or error handling. The parameter list and return type are covered, but behavioral traits beyond creation are omitted.

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 well-structured with Args and Returns sections, front-loading the purpose. It is clear but a bit verbose; each line contributes meaning. Minor redundancy (e.g., 'Optional' for count is clear from schema). Overall 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 the tool's complexity (10 parameters) and the presence of an output schema (though not shown), the description covers required and optional parameters, return type, and format hints. It lacks information about timezone handling or default calendar, but is sufficient for an AI agent to understand input expectations.

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 0%, so the description compensates well by listing all parameters with brief explanations, formats (e.g., YYYY-MM-DD HH:MM for dates), and allowed values (daily, weekly, monthly, yearly for frequency). This adds meaning beyond the schema's type and range constraints, though defaults are not explicitly stated.

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 creates a recurring Calendar event. It uses a specific verb ('Create') and resource ('recurring Calendar event'), distinguishing it from sibling tools like create_calendar_event (non-recurring) and update_calendar_event.

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 use for recurring events but does not explicitly specify when to use this tool over alternatives like create_calendar_event or provide exclusion criteria. No guidance on prerequisites or scenarios where this tool is appropriate.

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?

Describes the basic behavior (decreases brightness) and return type (success/error), but with no annotations, lacks details on side effects, prerequisites, or scope (e.g., display support). Adequate but minimal.

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?

Docstring format with Args and Returns sections, no unnecessary words. All sentences add 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?

Complete for a simple brightness adjustment tool. Output schema exists, so return format is handled. Could mention display compatibility but not essential.

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 description fully explains the 'amount' parameter with scale, default, and percentage, while the input schema only provides type, default, min, max with no description. Fully compensates for 0% schema description coverage.

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 action 'decrease screen brightness' with a specific verb and resource. Distinguishes from sibling 'increase_brightness' and other volume/brightness tools by naming the resource.

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

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

No explicit when-to-use or alternatives guidance. The context implies decreasing brightness when needed, but no comparison with 'increase_brightness' or 'turn_down_volume' is provided.

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 takes on the full disclosure burden. It explains the dry-run default and returns JSON with details, but does not mention irreversibility, permissions, or behavior on ambiguous matches (e.g., multiple events with same title).

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 front-loaded with the core action, followed by a clean list of arguments and return value. Every sentence adds value with no redundant or verbose phrasing.

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

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

Given the output schema exists (though not shown), the description appropriately notes the return type. It covers the main parameters and their roles, but could better explain edge cases like multiple matches or calendar_name scope.

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 description adds significant meaning beyond the schema: it explains the purpose of each parameter, provides date format hints ('YYYY-MM-DD'), and clarifies the dry_run flag's effect. Since schema coverage is 0%, this compensation is strong, though it could be more explicit about optional filtering 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 uses a specific verb ('delete') and resource ('Calendar event'), and clarifies it can delete an exact or uniquely matching event. This clearly distinguishes it from sibling tools like 'update_calendar_event' or 'create_calendar_event'.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., 'update_calendar_event', 'list_calendar_events'). The description does not specify when not to use it or what to do if multiple events match.

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?

Given no annotations, the description carries the full burden. It discloses the crucial safety feature of a dry-run default and explains the behavior of the dry_run parameter. However, it omits details on permanence of deletion and error handling.

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 concise and well-structured with clearly separated sections (Args, Returns). Every sentence contributes essential information without 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?

The description covers the core functionality, parameters, and return value. It is sufficient for a delete tool, but could mention error cases like note not found. The presence of an output schema mitigates this gap.

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

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

With 0% schema description coverage, the description fully compensates by clearly explaining what 'identifier' (note id or title text) and 'dry_run' (return matching note without deleting) mean, adding significant value beyond the schema's type-only definitions.

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 action ('Delete'), the resource ('a note'), and the method ('by id or title'). It effectively distinguishes from sibling tools like 'create_note', 'update_note', and 'move_note'.

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

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

The description implies usage for deleting notes, but does not explicitly state when to use this tool versus alternatives like 'trash_file' or when not to use it. There is no guidance on prerequisites or 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 burden. It discloses the dry-run default behavior and that it returns structured JSON with deletion details or error. This is good transparency for a destructive 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 well-structured with Args and Returns sections, each sentence is informative and concise. No unnecessary 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 the tool's complexity (3 parameters, output schema present), the description covers purpose, parameters, default behavior, and return type adequately. No gaps for an agent to invoke 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 0%, but the description adds meaningful semantics: identifier is 'Reminder id or name/title text', list_name is optional list name, dry_run returns matching reminder without deleting when true. This compensates well for the missing 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 'Delete an exact or uniquely matching reminder' with a specific verb and resource. It distinguishes from sibling tools like 'complete_reminder' or 'update_reminder' by focusing on deletion.

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 explains defaults and parameter usage (identifier as id/name, optional list_name, dry_run). While it doesn't explicitly compare to alternatives, the context makes it clear this is for deletion. Could improve by mentioning when not to use (e.g., if you only want to mark 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?

Describes the search mechanism (Spotlight first, fallback) and return format (JSON with metadata or error). Lacks disclosure of permissions needed or side effects, but covers key behavioral aspects beyond no annotations.

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

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

Well-structured with Args and Returns sections. Front-loaded with main purpose. Every sentence adds value; no fluff.

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 parameters and return type. With output schema present, doesn't need to detail return structure. Lacks error handling or performance limitations, but sufficient for correct invocation.

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 0% schema description coverage, the description provides essential one-line explanations for all 5 parameters, including allowed values for 'kind', making the tool usable.

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 finds files by name using Spotlight first with Python fallback. Distinguishes from sibling tools like list_directory and search_notes by emphasizing name-based search across a filesystem.

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 file name searches but does not explicitly say when to prefer this over alternatives like list_directory or when to use different search backends. No '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?

No annotations are provided, so the description carries the burden. It mentions the frontmost fallback behavior and return format (metadata or error), but does not disclose side effects (e.g., brings window to front, changes keyboard focus), permissions needed, or potential failure modes beyond an error message.

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 concise and front-loaded with the core purpose. Parameters and return value are clearly listed in a structured format. No unnecessary words 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?

Given the three optional parameters and the existence of an output schema, the description covers the main functionality well. It explains the three ways to specify the target window and notes the return value. However, it could be strengthened by clarifying what 'focus' means in practice (e.g., bringing to front) and providing minimal usage context.

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 0%, but the description adds meaning for all three parameters: app_name (optional app name, bundle id, or process name), window_id (CoreGraphics id), and window_index (1-based index). It explains their optionality and default values, compensating for the schema's lack of inline documentation.

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 purpose: 'Focus a macOS window by window id, app name, or frontmost fallback.' It specifies the verb (Focus) and the resource (macOS window), distinguishing it from siblings like move_window or resize_window.

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 list_windows or minimize. It lists parameters but does not explain prerequisites or scenarios where one parameter combination is preferable over another.

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 states it returns file paths or an error, but does not explicitly disclose that the operation is read-only (non-destructive) or mention any privacy/security concerns. It is adequate but minimal.

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 extremely concise: two sentences, one for purpose and one for return format. Every sentence adds value with no waste.

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 no parameters and an output schema (though not provided), the description is complete. It explains what the tool returns (file URLs or error message), covering all necessary context for a simple read 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?

There are zero parameters and schema coverage is 100% (trivially). The description does not need to add param info. Baseline for zero parameters is 4, and the description is correct and sufficient.

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 file URLs from the macOS clipboard. It uses a specific verb ('Return') and resource ('file URLs on macOS clipboard'), which distinguishes it from siblings like get_clipboard_text (returns text) and set_clipboard_files (sets files).

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 when to use (when file URLs are needed from clipboard), but does not explicitly state when not to use or mention alternatives. No guidance on distinguishing from get_clipboard_text or set_clipboard_files, though the name and description hint at the distinction.

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 discloses that the tool reads plain text and returns a JSON with truncation metadata or an error message, which is adequate for a read-only operation. No contradictions.

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 extremely concise with two sentences plus structured args/returns. No irrelevant information, and the key purpose and parameters are 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 simple read tool, the description covers the return format and error handling. With an output schema present (though not shown), it is sufficiently complete. Could optionally specify the JSON keys for truncation metadata.

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 has zero description coverage for parameters. The description adds 'Maximum number of characters to return' for max_chars, which provides clarity beyond the schema's type and bounds. However, it does not explain truncation metadata or the exact JSON structure.

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 'Read plain text from the macOS clipboard', specifying the verb 'read' and resource 'clipboard'. This distinguishes it from sibling tools like get_clipboard_files and set_clipboard_text.

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 the tool is for reading clipboard text, and the context of siblings (e.g., get_clipboard_files for files) provides implicit differentiation. However, no explicit guidance on when not to use or alternatives is provided.

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 burden. It mentions return structure ('structured JSON with contact fields, phone numbers, and emails') but doesn't disclose read-only nature, permissions, or side effects. Adequate but could improve.

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 concise (two sentences plus docstring-style args/returns) with no wasted words. Front-loaded key information and efficiently 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 tool's simplicity (1 parameter, output schema exists), the description adequately covers purpose, parameter semantics, and return structure. No gaps remain.

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 0%, so description adds crucial meaning: 'identifier: Contact id or name text' clarifies the flexible input type. This compensates for the schema gap well.

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 'Get a unique Contacts record by id or name match,' which specifies the verb (get), resource (Contacts record), and method (by id or name). This distinguishes it from sibling 'search_contacts' for listing.

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 indicates usage via 'by id or name match,' implying use when you have a specific identifier. Although it doesn't explicitly exclude alternatives, the context with sibling tools makes it clear when to use this vs. 'search_contacts'.

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, but the description discloses that the tool handles missing paths (returns error) and returns a JSON string with metadata. This is adequate for a simple read-only tool, though it could be more specific about what 'metadata' includes.

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 front-loaded with the purpose, followed by clear Args and Returns sections. Every sentence is necessary and there is no redundancy or irrelevant information.

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

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

Given the tool's simplicity (one required parameter, no nested objects, output schema present), the description covers purpose, parameter, and return format adequately. The output schema can provide further metadata field details, so this is complete.

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

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

Schema coverage is 0%, so the description must compensate. It adds 'File or directory path' for the single parameter, which clarifies its context beyond the bare 'string' type. However, this is minimal and avoids further detail like format or examples.

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 verb 'Get' and the resource 'metadata', and specifies it applies to 'a file, directory, or missing path.' This distinguishes it from sibling tools like 'find_files' (search) or 'list_directory' (list contents).

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

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

No explicit guidance on when to use this tool versus alternatives. Context signals show many file-related siblings, but the description does not mention when to prefer 'get_file_info' over 'find_files' or 'list_directory'.

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 burden. It states returntype (JSON string) and error handling, but lacks disclosure of platform dependency (macOS Finder), requirement for Finder to be running, or behavior when nothing is selected.

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

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

Two sentences, no redundancy, perfectly sized for a zero-parameter read tool.

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

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

With no parameters and no annotations, the description is nearly complete: it explains purpose and output. Missing platform context or edge cases, but sufficient for a simple read 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?

No parameters, so baseline is 4. The description adds value by specifying return content (paths and metadata) 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 uses specific verb 'Get' and resource 'currently selected Finder items as paths and metadata', clearly distinguishing it from sibling tools like get_file_info (single file) and list_directory (directory contents).

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

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

No guidance on when to use this tool vs alternatives such as get_file_info or list_directory. The description does not mention any preconditions or context for 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?

No annotations are provided, so the description must disclose behavior. It states the return type and fields, but does not mention any permissions needed, side effects, or edge cases. The behavior is simple and read-only, but the description lacks full transparency beyond the return.

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

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

The description is extremely concise, with two sentences covering the action and return value. Every word adds value, and it is front-loaded with the main purpose.

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 getter with no parameters and an output schema, the description covers the key return fields. It is complete enough for a straightforward tool, though some edge case handling is missing.

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

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

With zero parameters, the baseline is 4. The description adds meaning beyond the empty schema by specifying the purpose and return, justifying the score.

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 purpose: 'Get the currently frontmost macOS application.' It uses a specific verb and resource, and distinguishes it from sibling tools which perform different actions.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of context or exclusions, leaving the agent without clear direction.

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 discloses return format (JSON with content or error) but does not mention behavior on missing note or duplicate titles.

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?

Extremely concise: two purposeful sentences with Args/Returns. No fluff, front-loaded with action.

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 simple tool with one param and output schema hinted, description is adequate but could clarify return format specifics (e.g., full note vs summary) and error handling.

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

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

Only parameter 'identifier' with 0% schema coverage. Description adds meaning: 'Note id or title text' beyond type=string, helping agent understand acceptable values.

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

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

Clearly states 'Get a note by id or title.' This is a specific verb+resource and distinguishes from search_notes and create_notes.

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

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

No guidance on when to use this tool vs alternatives like search_notes or list_notes. Missing when-not-to-use and 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 provided, the description carries the full burden. It does not disclose whether the tool is read-only, requires Safari to be frontmost, or what happens if no page is loaded. It only mentions error message return, leaving significant behavioral gaps.

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

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

Two sentences, no wasted words. Purpose is front-loaded, return format briefly described. Exceptionally 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 the tool has no parameters and an output schema exists (context signal true), the description adequately lists return fields. However, it omits contextual prerequisites like requiring Safari to be open or active, and does not specify whether it works for all page types.

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 schema coverage is 100% trivially. Per calibration, 0 params yields baseline 4. The description does not need to add parameter info and it doesn't.

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 gets information about the current Safari page, listing specific fields (URL, title, text, source). It distinguishes itself from sibling tools like get_safari_tabs, which lists tabs, and reload_safari_page, which refreshes.

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

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

No guidance on when to use this tool vs alternatives. For example, it does not mention that for dynamic content run_safari_javascript might be more appropriate, or that it requires Safari to be active.

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?

Without annotations, the description discloses that it returns a list of tabs or an error. It does not mention whether it covers all windows or only the frontmost, nor does it address side effects. Adequate but not thorough.

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 very concise—two clear sentences with a separate 'Returns' line. No wasted words, and the structure is easy to parse.

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 an existing output schema, the description adequately covers the tool's function. It specifies the returned data (list of tabs with URLs and titles) and that an error message is possible. Slight improvement could clarify window scope, but it's mostly 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?

With zero parameters, the schema provides full coverage. The description adds no parameter information, which is acceptable here. Baseline of 4 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 retrieves a list of all open Safari tabs with URLs and titles. It uses a specific verb ('Get') and resource ('Safari tabs'), distinguishing it from siblings like 'navigate_safari' or 'close_safari_tab'. There is no ambiguity.

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

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

The description explains what the tool does but does not provide guidance on when to use it versus alternatives like 'get_safari_page_info'. Since it has no parameters, usage is straightforward, but explicit context is missing.

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 must disclose behavior. It states it hides an app and returns metadata or error. However, it does not detail side effects (e.g., reversibility, impact on windows). Adequate but not thorough.

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 very concise: two sentences for purpose, then clearly structured Args and Returns. No unnecessary words. Front-loads key info.

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?

Simple tool with one parameter. Description covers what the parameter accepts and the return type. Could specify return format more precisely, but sufficient for a straightforward action.

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 only defines 'app_name' as string. Description adds valuable context: 'App name, bundle id, or process name.' This expands meaning beyond schema. With 1 parameter and 0% schema coverage, description compensates well.

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?

Description clearly states 'Hide a running macOS app.' The verb 'hide' and resource 'app' are specific. Distinguishes from siblings like 'quit_app' (quits) and 'minimize' (minimizes window).

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

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

No guidance on when to use this tool versus alternatives like 'quit_app' or 'minimize'. Does not specify prerequisites or 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?

No annotations provided, so description bears full burden. It discloses the mutation nature and parameter details, but does not mention side effects, permissions, or limits. Adequate but minimal.

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?

Concise: one-line purpose followed by Args and Returns sections. Front-loaded and no extraneous text.

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?

Simple tool with one parameter and output schema (not provided). Description explains parameter adequately but returns only 'Success or error message' without elaboration. Adequate for this complexity level.

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 has 0% description coverage, but the description adds clear meaning for the 'amount' parameter: range (0.0 to 1.0), default (0.0625) with percentage explanation. This compensates well.

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?

Description clearly states 'Increase screen brightness' which is a specific verb and resource. It directly distinguishes from the sibling 'decrease_brightness' tool.

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

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

No guidance on when to use this tool versus alternatives. No mention of context, prerequisites, or 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?

With no annotations, the description should disclose behavioral traits. It only states it lists events and returns JSON/error, lacking details on read-only nature, authentication, pagination, timezone, or response structure beyond a generic 'Structured JSON.'

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 extremely concise: one purpose line followed by a bullet-like Args block. Every sentence adds value, and the most important info 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 tool's simplicity and presence of output schema, the description is adequate but not fully complete. It lacks usage guidance and behavioral details (e.g., date range limits, recurrence handling) that would help an agent decide to invoke it reliably.

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 description compensates for 0% schema coverage by documenting all three parameters with format ('YYYY-MM-DD') and optionality, adding significant meaning beyond the bare schema types.

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 'List Calendar events across a date range,' which is a specific verb+resource and distinguishes from the sibling tool 'list_calendar_events_for_day' that operates on a single 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?

No usage guidelines are provided. The description does not mention when to use this tool instead of alternatives like 'search_calendar_events' or 'check_calendar_availability,' nor does it give any conditions or 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?

No annotations are provided, so the description must carry the full burden. It states it returns a list or error, but does not confirm read-only nature, side effects, or required permissions. For a list 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?

Extremely concise: three sentences covering purpose, parameter format, and return type. No wasted words, front-loaded with action and resource.

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 simplicity (single param, list output) and presence of an output schema (unseen but noted), the description adequately covers purpose, param format, and return type. Error conditions and event fields are not detailed, but acceptable for a straightforward 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?

The schema coverage is 0%, but the description adds a clear date format ('YYYY-MM-DD') and an example. This provides meaningful guidance beyond the simple string type in 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?

Clearly states it lists calendar events for a specific day, using the verb 'list' and resource 'calendar events for a specific day'. This distinguishes it from siblings like 'list_calendar_events' (likely for ranges) and 'check_calendar_availability'.

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 a single day via the date parameter, but does not explicitly mention when to use this versus alternatives (e.g., 'list_calendar_events' for ranges, 'check_calendar_availability' for time slots). No exclusions or guidance on prerequisites.

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 states the action and return format, which is adequate for a simple listing tool. However, it does not disclose potential implications like requiring calendar access or that it only returns names, not full details.

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 extremely concise, with only two sentences that convey the essential information without any filler. 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?

Given the lack of parameters and the presence of an output schema, the description is adequate but lacks context about when to use this tool over sibling calendar tools or about potential limitations (e.g., listing only calendars the user owns).

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

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

There are no parameters, so the description does not need to explain them. The schema coverage is 100%, and the baseline for zero parameters is 4. The description adds minimal value beyond the schema by mentioning the output format, which is sufficient.

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 verb 'List' and the resource 'Apple Calendar calendars', making the purpose obvious. However, it does not differentiate from sibling tools like list_calendar_events or search_calendar_events, which also operate on calendars.

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

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

No guidance is provided on when to use this tool versus alternatives, such as list_calendar_events for events or create_calendar_event for creation. There is no mention of prerequisites or context for 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?

No annotations provided, so description bears full burden. It mentions output structure but does not disclose any side effects, required permissions, or failure modes. It implies read-only but not explicitly.

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?

Very concise with no extra words. Uses bullet points for arguments and returns, making it easy to parse.

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 tool, the description adequately covers purpose, parameter, and output. Could mention relationship to read_recent_messages for completeness, but not necessary.

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 has 0% description coverage, but the tool description explains the 'limit' parameter meaning and default behavior. Adding return value description compensates for missing schema notes.

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?

Description clearly states 'List Messages chats available to the macOS Messages app.' It is a specific verb+resource and distinguishes from siblings like read_recent_messages or send_imessage.

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

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

No guidance on when to use this tool versus alternatives. Does not mention prerequisites, context, or complementary 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?

No annotations are present, so the description must carry full behavioral disclosure. It mentions returning a JSON string with directory entries or an error message, but lacks details on side effects, permissions, or what metadata is included, which is minimal for a list 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 concise, front-loaded with a clear one-liner purpose, followed by structured Args and Returns sections. Every sentence is necessary and there is 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 has 3 parameters and an output schema, the description provides adequate purpose and parameter details. However, it does not specify the structure of the returned JSON or what 'metadata' includes, which could aid the agent in understanding the output without inspecting the 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?

With 0% schema description coverage, the description compensates by providing an 'Args' section that clearly explains each parameter (path, include_hidden, max_results) with their purposes and defaults, adding significant value beyond the input 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 'List immediate children of a directory with metadata,' specifying the verb 'List' and resource 'immediate children,' distinguishing it from recursive file search tools like 'find_files' and other file operations.

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 listing directory contents but does not provide explicit guidance on when to use this tool versus alternatives like 'find_files' or 'get_file_info', 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?

No annotations are provided, so the description must convey behavioral traits. It only mentions return type (structured JSON with folder names or error). It does not state that it is read-only, or any authorization or side effects. For a tool with no annotations, this is insufficient.

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 exceptionally concise—two sentences—and front-loaded with the primary action. Every word is necessary, no filler.

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

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

For a simple parameterless tool with an output schema, the description is minimally adequate. It states the action and return type, but lacks any additional context about folder hierarchy, scope, or error handling beyond the 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?

There are zero parameters and schema coverage is 100%. With no parameters to describe, the description need not add parameter details. Baseline for 0 params is 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 the action (list) and resource (Apple Notes folders). It is specific and distinguishes this tool from siblings like list_notes or search_notes which operate on notes, not folders.

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

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

No guidance on when to use this tool versus alternatives such as list_notes or search_notes. No context about prerequisites, when not to use it, or which sibling tools might be more appropriate.

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 full burden. It states a read operation ('List'), but does not disclose any behavioral traits such as authentication requirements, rate limits, performance implications, or whether the operation is safe. Minimal transparency.

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 short and well-structured: a one-line purpose, then Args section, then Returns. Every sentence provides necessary information, no redundancy. Front-loaded with the main action.

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 2 optional parameters, no annotations, and an output schema present (so return values are covered), the description is adequate for a simple listing tool. However, it lacks details on pagination, ordering, or whether folder supports wildcards. Given many sibling tools, slightly more context would improve 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 description coverage is 0%, so description must compensate. It explains 'folder' as an optional folder name and 'max_results' as a maximum notes limit (with default 25, max 200). This adds meaning beyond the schema's property definitions. However, it doesn't clarify if folder is name or ID, or any format constraints.

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 'List Apple Notes, optionally filtered by folder.' The verb 'list' and resource 'Apple Notes' are specific. It distinguishes from sibling tools like 'search_notes', 'get_note', 'create_note', etc., which have different purposes.

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 (listing notes, optionally filtering), but does not explicitly state when to use this tool vs alternatives like 'search_notes' or 'get_note'. No prerequisites or exclusions are mentioned. Adequate but lacks explicit 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 carries the full burden. It only states it returns structured JSON or an error, but does not disclose whether the operation is read-only, requires permissions, or has side effects. Basic transparency is lacking.

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 concise with two sentences, front-loading the purpose. However, it could be slightly more structured, but for a simple tool it is adequate.

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 simplicity (no parameters, output schema mentioned), the description is minimally complete. It does not cover error conditions or edge cases, but for a list operation it is sufficient.

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

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

The input schema has no parameters, and schema description coverage is 100% (vacuously). The description adds no parameter info because none is needed. Baseline 4 is appropriate for a no-parameter tool.

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

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

The description clearly states the tool's action: 'List Apple Reminders lists.' It uses a specific verb (List) and resource (Apple Reminders lists), distinguishing it from sibling tools like 'list_reminders' which lists reminders within lists.

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 like 'list_reminders' or 'search_reminders'. There is no context about prerequisites or typical scenarios.

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, and the description does not disclose whether the tool is read-only, destructive, or any behavioral traits such as error handling, rate limits, or side effects. The read-only nature 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 concise, with a single sentence and a brief docstring for parameters and return value, front-loading the core function without unnecessary verbosity.

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 tool with an output schema, the description adequately covers the basic functionality but omits details on error handling, pagination, or behavior when no matches are found.

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 description adds meaning to the parameters beyond the schema (which has no descriptions), specifying list_name as an optional list name and include_completed as including completed reminders. However, it lacks details on format or allowed values.

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

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

The description clearly states the verb 'List reminders' and specifies optional filters by list and completion state, differentiating it from sibling tools like list_reminder_lists and search_reminders.

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 reminders with optional filters but does not provide explicit guidance on when to use this tool versus alternatives like search_reminders, nor 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?

No annotations are provided, and the description fails to disclose behavioral traits such as performance impact, permissions required, or what 'manageable' means. It only states the action and return format.

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

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

The description is concise with four sentences, front-loaded with the main purpose. No redundant information.

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

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

With an output schema present, the description provides sufficient context for the return value listing. However, it lacks explanation of 'manageable' and edge cases, but overall is reasonably complete for a simple listing tool.

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

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

Schema coverage is 0%, but the description adds meaningful context for both parameters: app_name accepts multiple identifier types, and include_minimized explains its purpose. This compensates well for the lack of 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 'List manageable macOS windows' with a specific verb and resource. It distinguishes from sibling window manipulation tools like focus_window or move_window by focusing on listing.

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 listing windows but does not explicitly state when to use or when not to use it, nor does it mention alternatives. However, the sibling tools context provides some differentiation.

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; description only states basic action and return type. Does not disclose safety, permissions, or effects like whether the window becomes hidden.

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 short, front-loaded with purpose, and efficiently lists parameters. No unnecessary 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?

Adequate for a simple tool with optional parameters and an output schema. Lacks detail on parameter selection logic and return metadata beyond minimal description.

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?

Adds basic semantics for each parameter (app_name, window_id, window_index) beyond the schema, which has 0% description coverage. However, does not explain interaction or priority.

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?

Description clearly states 'Minimize a macOS window' with a specific verb and resource. Distinguishes from sibling window tools like focus_window, move_window, resize_window.

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

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

No guidance on when to use this tool versus alternatives or how to choose among parameters. Lacks when-not-to-use or preferred usage context.

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