local-mcp

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

Annotations already provide readOnlyHint=false and destructiveHint=false. The description adds that it returns tag name/visible text for confirmation and can wait up to 3s for navigation, which are useful behavioral details not covered by annotations. No contradiction.

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

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

Three sentences covering purpose, return value, and wait behavior. No redundancy, front-loaded with purpose, and 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 single-click tool, description covers purpose, confirmation output, and optional wait. With output schema and annotations present, it is sufficiently complete; minor gap is lack of error-handling detail (e.g., element not found), 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?

Schema has 100% coverage with detailed descriptions for selector, nth, and wait_for_navigation, so baseline is 3. The description only reiterates wait_for_navigation and 'first element' (nth default), adding little beyond schema.

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

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

Description states 'Clicks the first element matching a CSS selector in the current Google Chrome tab' – a specific verb+resource+scope. It distinguishes from sibling tools by specifying Chrome, current tab, and 'first element', differentiating it from safari_click and web_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 explicit when-to-use/when-not-to-use or alternatives. The description implies usage for Chrome-specific clicks and mentions waiting for navigation, but does not contrast with chrome_query_selector_all or other browser-click 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?

Annotations already convey readOnlyHint=false and destructiveHint=false. The description adds the useful 'current Google Chrome tab' and 'one shot' behavior, but does not disclose what happens on missing selectors, whether it submits the form, or if it disturbs other page state. This is minimal but not contradictory.

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 purpose and parameter format. Could be more precise about the string/JSON encoding, but otherwise every sentence earns its place.

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

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

With a simple single parameter and an output schema present, the description is mostly complete. However, the ambiguous fields type (string vs object) and lack of clarification about JSON encoding leave a gap for correct invocation, making it not fully 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 description coverage is 0%, so the description must carry full parameter meaning. It says 'Pass fields as a JSON object mapping CSS selector to value,' which is helpful, but it conflicts with the schema declaring fields as a string. It does not clarify whether the JSON should be stringified, nor provide an example, creating 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 states a specific verb and resource: 'Fills multiple form fields in one shot in the current Google Chrome tab.' This clearly distinguishes it from siblings like chrome_type (single field) and safari_fill_form (Safari).

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 context: use when you need to fill multiple form fields at once in the current Chrome tab. However, it does not explicitly mention alternatives or when not to use it, such as preferring chrome_type for a single field.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it operates on the 'current' tab, which is useful context. However, it does not disclose potential side effects like losing form data or clearing transient state, though these may not be relevant for a simple back navigation.

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

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

The description is a single, front-loaded sentence with no fluff or extraneous information. Every word contributes to understanding, earning a perfect score.

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 is simple and the description captures the core action. However, due to missing parameter semantics and no explicit mention of the optional window_index, the contextual completeness is only adequate. The presence of an output schema reduces the need to explain return values, but the description still leaves some gaps for the parameter.

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 one parameter, 'window_index', with 0% schema description coverage and no description text. The description does not mention this parameter at all, leaving the agent without any guidance on what window_index means, its format, or why it might need to be set. With such low coverage, the description should compensate but fails to.

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 the tool's function: 'Navigates the current Google Chrome tab back to the previous page.' It uses a specific verb ('navigates') and resource ('current Google Chrome tab') and clearly distinguishes it from sibling tools like chrome_navigate (which would load a specific URL), chrome_history, and safari_go_back.

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

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

The description provides clear context for when to use the tool: when you need to go back to the previous page in the current Chrome tab. It does not explicitly mention alternatives or exclusions, but the use case is sufficiently clear for such a simple navigation action.

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?

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds meaningful behavioral disclosures: 'read-only — no page is opened,' 'Requires Full Disk Access,' and 'Returns url, title, visit_count and last_visit (ISO), newest first.' This gives the agent crucial context about permissions and output without relying solely on 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 three sentences, front-loaded with purpose, and every clause adds useful information. It covers operation, query behavior, return fields, ordering, permissions, and the Safari alternative without any 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 simple list/search tool with no output schema, this description is fully complete: it covers permissions, behavior, return shape, ordering, query semantics, and the relevant sibling alternative. No critical information is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by noting 'case-insensitive' matching and that results are 'newest first,' which are not in the schema. It also reinforces the semantics of omitting query, but does not explain 'limit'—though the schema already does that adequately.

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 verbs 'Lists or searches' and clearly identifies the resource: the user's Google Chrome browsing history. It further differentiates from the sibling 'safari_history' by explicitly naming it as the Safari alternative, making the tool's scope unmistakable.

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 explicit usage guidance: 'Optional `query` matches the URL or page title' and 'Omit to list the most recent history.' It also names the alternative for Safari users ('For Safari use safari_history.'), satisfying the when-to-use vs. alternatives criterion.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by specifying the exact data returned (title, URL, active status) and scope (all windows). No contradictions 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?

Single sentence, no fluff, front-loaded with the verb. Every word earns its place; it is concise and well-structured.

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

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

With an output schema present and no parameters, the description fully captures what the tool does. It mentions the key output fields and scope, making it complete for an agent to select and 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?

The tool has zero parameters, so the baseline is 4. No parameter explanation is needed, and the description appropriately focuses on the output.

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 ('Lists'), names the resource ('every open tab across all Google Chrome windows'), and specifies the returned fields ('title, URL, and whether it is active'). This clearly distinguishes it from siblings like chrome_search_tabs and safari_list_tabs.

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

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

The description clearly indicates when to use the tool (when you need an enumeration of all open tabs across Chrome windows). It does not explicitly mention alternatives or exclusions, but the use case is unambiguous.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the description doesn't need to re-explain side effects. It adds the new_tab behavior context, which is useful. However, it does not disclose what happens to the current tab, whether navigation waits for page load, or how window_index is used beyond the schema.

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

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

Two sentences, with the main action first and a helpful hint second. Every word earns its place; no filler or redundancy.

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

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

Despite having an output schema and three parameters, the description is missing important context: when to use Chrome navigation vs. web_navigate or safari_navigate, behavior of window_index, and what happens to the current page. It provides only a minimal functional 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?

Schema description coverage is 0%, so the description must compensate. It explains new_tab but provides no meaning for url format or window_index. The required parameter url lacks any semantic guidance, and window_index is completely undocumented.

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 navigates Google Chrome to a URL, which is a specific verb+resource. It does not explicitly distinguish from sibling tools like web_navigate or safari_navigate, so it misses an opportunity for differentiation, but the name includes 'chrome' making it clear enough.

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 web_navigate or safari_navigate. The only usage hint is about new_tab, which is a parameter behavior rather than a usage guideline.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context: it runs in the current tab and returns summaries rather than full elements. No contradiction; the added detail goes beyond annotation basics.

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

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

One sentence, no wasted words, front-loaded with the action and key details. Perfectly concise structure.

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

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

The tool is simple, and the output schema covers return format. However, the missing parameter semantics for 'limit' leaves an agent uncertain about behavior. The description covers what it does and where, but not enough about how to control it.

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

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

Schema description coverage is 0%, and the description does not explain either parameter. While 'selector' is implied by querySelectorAll, 'limit' is entirely unexplained (no mention of capping results or default behavior). The description fails to compensate for empty 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?

Description clearly states the tool runs document.querySelectorAll in the current Chrome tab and returns a compact summary of each match. This specific verb+resource+scope distinguishes it from siblings like chrome_read_tab (reads whole page) and safari_query_selector_all (different browser).

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

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

The description gives clear context: use this to extract multiple matching elements via CSS selector from the current Chrome tab. It does not explicitly mention alternatives or when-not-to-use, but the context is sufficient given the sibling tool names.

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

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

Annotations already convey read-only safety, and the description adds valuable behavioral context: text cap via max_bytes, opt-in HTML/links, the critical 'Allow JavaScript from Apple Events' permission, and the suggestion to run chrome_setup_check on empty reads. This goes well beyond the structured annotations with 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 compact and front-loaded: core function stated first, followed by identification methods, options, and a critical prerequisite. Every sentence adds distinct useful information without filler.

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

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

With an output schema present, return values are already covered elsewhere. The description fully equips an agent to select tabs, choose optional outputs, understand the size cap, and handle the JavaScript permission prerequisite, making it self-sufficient for a tool of this complexity.

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

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

Schema covers all 6 parameters with descriptions, but the description enriches them with inter-parameter relationships not present in the schema: url_match takes precedence, substring matching with first-hit-wins, default max_bytes value, and the pairing of window_index/tab_index. This adds meaningful selection logic beyond the raw parameter 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?

Specific verb 'Reads' plus resource 'rendered text content of a Google Chrome tab' clearly states the function and differentiates it from sibling tools such as chrome_list_tabs (metadata) and chrome_search_tabs. The additional mention of optional HTML and link extraction further pins down its capabilities.

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

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

Provides explicit guidance on how to identify tabs (url_match vs window_index+tab_index), explains precedence, lists optional flags, and even notes a prerequisite and a diagnostic fallback. However, it does not explicitly name alternatives or state when not to use this tool compared to safari_read_tab or web_read.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable context: it searches 'rendered text' (not just titles/URLs) and discloses a prerequisite: 'Requires "Allow JavaScript from Apple Events" (Chrome → View → Developer).' This goes beyond annotations to inform the agent about setup requirements and the nature of the 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 two sentences, front-loaded with the core functionality and outcome, followed by a use case and requirement. Every sentence earns its place; no fluff or redundancy.

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

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

The tool has an output schema, so return values are covered elsewhere. The description explains scope, use case, and prerequisites. The only minor gap is that 'every open tab' is contradicted by max_tabs defaulting to 30, but that limitation is visible in the schema. Overall, it is complete enough for a read-only search tool.

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

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

Schema description coverage is 100%, so the input schema already fully documents query, context, and max_tabs with descriptions. The description does not add additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate because the schema carries the burden.

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 and resource: 'Searches the rendered text of every open Google Chrome tab for a substring.' It also specifies the output ('Returns each matching tab with the surrounding snippet'), distinguishing it from sibling tools like chrome_list_tabs (which lists without searching) and safari_search_tabs (which targets Safari).

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 use case: 'Useful for "do I have a tab open with X?" across many tabs.' This gives context for when to use the tool. It does not explicitly mention alternatives or exclusions, so it doesn't reach the 'explicit when/when-not/alternatives' bar, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: it returns setup instructions if JavaScript from Apple Events is not enabled, which tells the agent about a failure mode and the tool's diagnostic nature. This exceeds the baseline but isn't exhaustive (e.g., doesn't describe the output schema, but that's covered by the output schema).

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

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

The description is two sentences and every word earns its place. It states the core purpose first, then adds the key failure-mode behavior. No redundancy or 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?

The tool is simple (no parameters, low complexity) and an output schema is present, so the description doesn't need to explain return values. It fully covers the tool's role as a prerequisite check for Chrome interactive tools, including what happens when setup is incomplete. This is complete for an agent to select and 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?

With zero parameters, the baseline is 4 per the rubric. The description correctly doesn't waste space inventing parameter details. The schema already covers parameter definitions (there are none), so no additional semantics are needed.

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

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

The description uses a specific verb ('Reports') and a specific resource ('whether Google Chrome is ready for interactive tools'), and explicitly lists the dependent tools (chrome_click, chrome_type, chrome_evaluate_js, chrome_read_tab). It clearly distinguishes itself from sibling safari_setup_check by focusing on Chrome.

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 should be used before Chrome interactive tools by framing it as a readiness check for those exact tools. It provides clear context for when to invoke it, though it doesn't explicitly state alternatives or when not to use it. The sibling safari_setup_check is not mentioned, but the Chrome-specific naming and tool list make the usage clear.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description focuses on adding the behavioral detail that it fires input/change events. This gives valuable context about side effects on the page, which is not covered by the annotations and helps the agent anticipate event-triggered 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?

A single sentence conveys the core purpose with no fluff or redundant details. Every phrase contributes meaning, making it an ideally concise description.

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 moderate complexity, an output schema, and annotations, the description provides a reasonable but minimal summary. It misses key context such as the meaning of the 'clear' parameter and does not discuss expected failures or edge cases, but it covers the essential action sufficiently for a simple tool.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'value' and 'CSS selector' implicitly, but does not explain the 'clear' parameter (e.g., whether it clears the existing field before typing). The parameter names are self-explanatory to some degree, but the description adds little beyond the schema names and leaves 'clear' ambiguous.

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

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

The description clearly states the tool's function: it sets the value of an input/textarea matching a CSS selector in the current Chrome tab and fires input/change events. This makes it distinct from sibling tools like chrome_click and safari_type by specifying the exact action, target element, and browser.

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

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

The description provides clear context for use (current Chrome tab, CSS selector, input/textarea elements) but does not explicitly mention alternatives or exclusions. It implies usage when you need to set form field values in Chrome, but lacks direct comparison to similar tools like chrome_fill_form.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it 'polls' (repeated checks), explains the conditional interaction between selector and text_match, and states the requirement to pass at least one. This goes beyond the annotations and schema.

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

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

Two sentences with no redundancy. The first sentence encapsulates the core logic, and the second provides a concrete usage example. 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?

The description covers the tool's main behavior, parameter relationships, and a typical use case. With an output schema present, it doesn't need to explain return values. It lacks detail on timeout behavior, but that's a minor gap given the schema documents timeout_ms.

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

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

Schema coverage is 100% with descriptive parameter docs. The description adds a cross-parameter constraint ('Pass at least one of selector/text_match') and clarifies that text_match can be scoped inside selector, which is not fully obvious from the schema descriptions alone.

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 polls the current Chrome tab for a CSS selector or text match. It uses a specific verb ('polls') and resource ('current Google Chrome tab'), and the behavior is unambiguous, distinguishing it from sibling wait tools like safari_wait_for or web_wait_for.

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

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

The description explicitly says 'Useful after chrome_click to wait for the next page or a modal to render', giving a clear when-to-use context. It doesn't explicitly mention alternatives or exclusions, but the Chrome-specific scope and practical example provide solid guidance.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context by emphasizing the confirmation requirement ('Requires confirm=true'), which is a guardrail not captured by annotations. It also discloses the dual identification method. The preview behavior is left to the schema but the confirmation requirement is highlighted.

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

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

The description is two short sentences with no filler. It front-loads the verb and resource ('Marks an OmniFocus task as complete') and immediately follows with the critical confirmation constraint. 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?

The description covers the essential aspects: purpose, identification method, and the confirmation requirement. An output schema exists, so return values need not be described. It does not explicitly explain the preview behavior, but that is captured in the schema's confirm parameter, and the tool's simplicity makes this 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 description coverage is 100%, so the baseline is 3. The description repeats the ID/name OR relationship and the confirm requirement without adding new meaning beyond what the schema already provides. It succinctly summarizes but does not improve upon the parameter 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 action (marks as complete) and the specific resource (OmniFocus task), distinguishing it from sibling tools like create_omnifocus_task, complete_reminder, and todoist_complete_task. The phrase 'by task ID or name' further specifies the scope of operation.

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

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

The description provides clear context for when to use the tool (completing an OmniFocus task) and how to identify the target (by ID or name). However, it does not explicitly mention alternatives or situations where another tool should be used, pulling back from a 5.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, already conveying mutation without destruction. The description adds a meaningful guardrail by stating that confirm=true is required before the action will execute, which is a behavioral constraint beyond the structured 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 two short sentences with the action front-loaded. Every phrase earns its place: the platform, the mandatory confirm flag, and the pointer to the To Do alternative. No redundancy or 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 two-parameter mutation tool with a full output schema and annotations, the description covers the essential context: platform, required confirmation, and a cross-platform alternative. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'Requires confirm=true' reinforces the confirm parameter, and 'Reminder ID from list_reminders' in the schema already documents the ID source. No additional parameter meaning is provided 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 a specific verb and resource: 'Marks a reminder complete in Apple Reminders (Reminders.app).' It also distinguishes itself from the sibling tool 'todo_complete_task' by directing Microsoft To Do users there, making the tool's scope 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 explicitly states 'Requires confirm=true' as a usage prerequisite and gives a clear alternative: 'For Microsoft To Do use todo_complete_task instead.' This tells the agent exactly when to use this tool versus a related sibling.

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

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

The description discloses key behaviors beyond annotations: it is a two-phase operation ('Read-only PREVIEW unless confirm:true') and details the return value (which clients were set up, already had config, not installed, and restart step). Annotations declare readOnlyHint=false and destructiveHint=false, consistent with the description; no contradiction exists.

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

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

The description is three sentences long, front-loading the core action, then covering behavior, return details, and a companion tool. Every sentence provides essential information without redundancy. Perfectly 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's complexity (multi-client installation, preview/confirm, return structure), the description covers the main points. The output schema exists to define return format, so the description need not detail it. Minor omission: what happens if no clients are installed (likely returns empty list), but this is implied.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal extra parameter meaning: it reiterates the optionality of 'client' and the preview/confirm behavior. It mentions the return value but does not elaborate on parameter details beyond the schema. No significant value added over the schema.

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

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

The description clearly states the tool's purpose: 'Adds Local MCP to the config of installed MCP-capable AI clients on this Mac ... so they can use LMCP's tools.' It specifies the exact verb (Adds) and resource (config of clients), and names the supported clients. No sibling tool performs this function, so it is well-distinguished.

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 explicit usage context: it automates what would otherwise require 'manual JSON editing,' and recommends pairing with 'list_missing_permissions for fully agent-driven setup.' It also clarifies the preview vs. confirm workflow. However, it does not explicitly state when not to use this tool or describe alternative approaches.

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 adds context about the authentication process (getting a login code and confirming), which goes beyond the minimal annotations. However, it does not disclose potential side effects like overwriting an existing connection or persistency.

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, and front-loaded with the core action. 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?

The description explains the key steps for connecting, and given the presence of an output schema (not shown) and the sibling disconnect tool, the context is sufficient. Minor gap: no mention of error conditions or prerequisites.

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 (100% coverage), and the description mentions a 'login code' from the first call, but does not explain how the code is handled in the second call. Given the high schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the verb ('Connect') and resource ('Microsoft 365 account'), and distinguishes it from sibling tools like 'disconnect_m365_account'. It also outlines the two-step process.

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 the two-step flow for connecting an account, providing clear context on when to call the tool. However, it does not explicitly state when not to use it or list 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?

Beyond the annotations, the description discloses a significant behavioral trait: 'Stored locally, never sent to Claude's servers.' This addresses privacy and data handling, adding valuable context that annotations do not capture.

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 accomplish both purpose and behavioral transparency. The first sentence fronts the primary action, and the second adds context. No wasted words; each sentence 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 one-parameter connection tool, the description covers how to get the token, what happens with it (stored locally), and privacy implications. With an output schema present, no further details about return values are needed. The tool is fully contextualized.

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 already describes the api_token as a 40-char hex string, but the description adds practical guidance on where to find it ('Todoist → Settings → Integrations → Developer'). This extraction guidance goes beyond schema, making parameter usage much clearer.

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 specific verb and resource: 'Connect Todoist using your personal API token.' This distinguishes it from siblings like disconnect_todoist and Todoist task tools, leaving no ambiguity about its role.

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

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

The description gives clear context for use, including the precise path to obtain the token, which is essential before invoking the tool. It doesn't explicitly mention alternatives or when not to use it, but as a connection/setup step, its use case is self-evident.

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

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

Annotations already mark this as a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), so the description doesn't need to restate mutation. It adds useful behavioral context: required fields, attendee constraints, recurrence options, and the M365 alternative. However, it fails to mention the `confirm` parameter's requirement (must be true to actually create the event), which is a notable omission from the description's 'requires' list.

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

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

The description is three sentences, front-loaded with the primary action, and includes a cross-tool pointer. It is concise, information-dense, and free of 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?

The description covers the main use case and constraints, and with an output schema and full parameter documentation, it doesn't need to describe return values. However, it omits the `confirm` guardrail, which could lead to failed calls if the agent doesn't infer it from the schema. Given the tool's 13 parameters, a bit more context about this effective requirement would make it more 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 description coverage is 100%, so all 13 parameters are already well-documented in the schema. The description merely highlights that title, start_date, and end_date are required and mentions attendees/recurrence as optional, adding no new parameter-level semantics beyond what the schema provides.

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

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

The description opens with a specific verb+resource: 'Creates an event in the Mac's Calendar app (Calendar.app).' It also distinguishes itself from the sibling m365_create_event by explicitly redirecting Microsoft 365 users, making the purpose 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 clearly states when to use the tool (for Mac's Calendar.app) and explicitly says 'For Microsoft 365 use m365_create_event instead,' naming the alternative. It also notes that attendees are only supported on CalDAV/Exchange calendars, providing a scope boundary.

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 annotations only indicating readOnlyHint=false and destructiveHint=false, the description adds valuable behavioral context: it never sends, it places drafts in the account's Drafts folder, and for multi-account Macs, behavior depends on whether account/from is provided, defaulting to the default account. It also discloses that attachments are attached to the saved draft. This goes well beyond the annotations, though it doesn't cover error handling or failure modes.

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 five sentences, each earning its place: core purpose, two usage modes, account selection, attachment behavior, and target user. It is front-loaded with the most critical fact ('never sends'), and the length is appropriate for a tool with 11 parameters and two distinct modes.

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 (11 optional parameters, two modes, multi-account concerns), the description covers the essential behavior: saving a draft, new vs reply, account selection, attachments, and the non-sending guarantee. An output schema exists, so return-value details are not needed. The description is complete enough for an AI agent to select and invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by grouping parameters into two modes: new draft (to/subject/body) and reply draft (reply_to_message_id plus body), and clarifies the account/from alternative. It also gives an example for attachments (a PDF quote). Though the schema already covers many relationships, the description reinforces and provides a mental model, meriting a 4.

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

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

The description clearly states the tool's purpose: 'Saves an email to the Mail.app Drafts folder... never sends.' It differentiates from siblings like send_email and reply_email by explicitly emphasizing that it never sends, and it distinguishes two modes (new draft vs reply draft) with specific parameters.

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

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

The description gives clear usage context: 'Use this for the cautious user who wants AI-composed mail but insists on sending it themselves.' It also explicitly says 'never sends,' which serves as a when-not-to-use. However, it doesn't explicitly name alternative tools like 'use send_email for direct sending,' so it stops short of full 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?

The description aligns with annotations (readOnlyHint=false, destructiveHint=false) by indicating a write operation that is not destructive. It adds the context that it targets Mail.app specifically, but it does not disclose that the 'confirm' parameter must be true or mention any side effects beyond folder creation.

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

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

The description is a single, focused sentence that front-loads the core action and resource. It contains zero filler or redundant content.

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

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

For a simple creation tool with full schema coverage and an output schema, the description provides sufficient context. It could mention the confirm requirement or account behavior, but those are already captured in the schema, and no return-value explanation is needed due to 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?

Schema description coverage is 100%, so the input schema already describes all three parameters clearly. The description adds no additional parameter-level detail, which is acceptable given the high schema coverage, but it does not compensate for any gaps either.

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 ('Creates') with a specific resource ('new mailbox folder') and scopes it to 'Mail.app'. This clearly distinguishes it from sibling tools like list_email_folders and move_email.

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_email_folders to inspect existing folders or move_email to manage messages. There is no mention of prerequisites, duplicate handling, 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds valuable behavioral context: Markdown conversion to native formatting and the requirement of confirm=true to execute. This communicates important execution conditions and output transformation not present in structured metadata.

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: the main purpose is stated first, followed by the most important behavioral detail (Markdown support) and the key execution requirement (confirm=true). Every sentence adds value with no redundancy.

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

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

The description covers the core action, important parameter semantics (body/confirm), and a key execution condition. With an output schema present, return values don't need description. The folder parameter is not explained, but overall the description is adequate for a creation tool with this complexity.

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

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

With 0% schema description coverage, the description compensates partially by explaining the body parameter's Markdown support and the confirm parameter's required value. However, it does not add meaning for the 'name' and 'folder' parameters, leaving gaps in parameter understanding.

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 starts with a specific verb+resource pair ('Creates a new note in Apple Notes'), clearly distinguishing this from sibling tools like update_note, list_notes, and create_reminder. It precisely identifies the target application and the action performed.

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

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

The description provides clear context for when to use this tool by specifying it creates notes in Apple Notes and supports Markdown formatting. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to select it over similarly named 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?

Although annotations already indicate destructiveHint=true and readOnlyHint=false, the description adds a valuable behavioral detail: 'Requires confirm=true to execute' and 'called without it, returns a preview.' This discloses the safety mechanism and preview behavior, which is not captured by 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 two sentences, front-loaded with the primary action and then a critical constraint. No unnecessary words, perfectly 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 complete schema (all params documented) and presence of an output schema, the description covers the essential behavioral aspect (confirm requirement) and is fully sufficient for an AI agent to select and invoke the tool correctly. No critical 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?

The input schema has 100% coverage with descriptions for all 7 parameters, so the baseline is 3. The description adds no extra parameter semantics beyond what is already in the schema; the confirm parameter is fully described 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?

The description states 'Creates a new task in OmniFocus' with a specific verb and resource, clearly distinguishing it from sibling tools like complete_omnifocus_task, list_omnifocus_tasks, and search_omnifocus_tasks. It precisely conveys the action and target, leaving 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 provides clear context for use by stating it creates a task, and highlights the confirm=true requirement, which is a critical execution condition. It does not explicitly discuss alternatives, but the self-explanatory name and the presence of dedicated sibling tools make the intended usage clear.

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

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

Annotations already indicate a non-read-only operation with no destructive hint, and the description adds valuable behavior context: the tool records invites and returns links but does not actually send anything. This clarifies side effects and what the caller must do next, which is useful beyond the structured annotation.

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

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

The description is three sentences, each earning its place: purpose/outcome, non-sending caveat, and param clarification. It is front-loaded with the most important information and contains 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 create-and-return tool with a full input schema and output schema, the description is complete. It covers what is recorded, what is returned, how the return value should be used, and one parameter's meaning. This is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the description only needs to add supplementary meaning. It clarifies the purpose of 'lang' ('records the language the invite is written in'), which slightly reinforces the schema, but it does not significantly extend parameter understanding beyond what the schema already provides.

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

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

The description uses a specific verb ('Records') and a clear resource ('referral invites'), and explains the output (unique referral link per person). It clearly distinguishes this create/record tool from siblings like list_referral_candidates by focusing on recording invited colleagues.

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

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

The description provides clear usage context: it is for colleagues the user chose to invite, and it explicitly notes that it does not send anything, so the returned links can be included in emails or messages. It does not name explicit alternatives or when-not-to-use conditions, but the context is strong.

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

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

The description adds no behavioral context beyond the annotations. Annotations indicate readOnlyHint=false and destructiveHint=false, which already imply a non-read-only write operation. The description merely restates the action without disclosing side effects like the need to set confirm=true or the default list behavior.

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

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

The description is a single concise sentence with no wasted words. It is front-loaded and immediately communicates the core 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?

The description is extremely minimal for a tool with 6 parameters and a confirm flag. It omits important usage context such as the confirm requirement and how list_name determines which list receives the reminder. The output schema exists, so return values are not required, but behavioral prerequisites and edge cases are undocumented.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description itself adds no parameter detail, so the baseline score of 3 applies.

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

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

The description clearly states the tool creates a reminder in Reminders.app, using a specific verb and resource. It distinguishes from sibling tools like create_reminder_list, complete_reminder, and delete_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?

No guidance is provided on when to use this tool versus alternatives such as update_reminder or complete_reminder. There is no mention of prerequisites, list selection, or the confirm requirement.

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

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

Annotations indicate a non-read-only, non-destructive mutation. The description adds the confirm constraint, which is useful, but lacks details on side effects, permissions, or behavior beyond creation.

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 sentences with no wasted words. The purpose is front-loaded and immediately 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?

With an output schema and full parameter schema coverage, the description is adequate but does not address prerequisites (e.g., Reminders.app access) or error scenarios. Lacks differentiation from create_reminder.

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

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

Schema coverage is 100%, and the description does not add beyond what the schema provides. The confirm requirement is redundant with the parameter's description.

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 new list in Apple Reminders and requires confirm=true. It specifies the target app and distinguishes from sibling tools like delete_reminder_list.

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 mentions the confirm requirement but does not provide guidance on when to use this tool versus alternatives like create_reminder or list management tools. Usage context is implied but not explicit.

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

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

Annotations already indicate readOnlyHint=true, so the description adds value by detailing the composition of the brief and the graceful handling of missing Mail app for emails. 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?

Two sentences, no wasted words. The first sentence immediately states the output composition, and the second provides the use case. Fully front-loaded and efficient.

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

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

Given that the tool has an output schema, the description adequately explains the return value without needing to detail structure. It covers all components and optionality, but could briefly mention the aggregated format for 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?

With 100% schema coverage, the baseline is 3. The description adds meaning by explaining that 'location' enables weather inclusion and 'include_emails' defaults to true with graceful failure, which is useful context 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 verbs ('Returns', 'combining') and clearly identifies the aggregated resources (calendar events, reminders, emails, weather). It distinguishes itself from sibling tools like list_calendar_events or get_weather by being a combined morning briefing.

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

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

The description explicitly states the ideal use case ('Perfect for starting each day') and provides context on what is included. While it doesn't explicitly state when not to use or list alternatives, the purpose is clear enough for an agent to decide appropriately.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds critical behavioral details: the confirm requirement, the distinction between deleting a single occurrence vs. the whole series with span='future', and the default behavior. This transparently discloses the destructive scope beyond what annotations provide.

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

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

The description is three sentences, each with a distinct purpose: the primary action, the critical confirm requirement, the recurring-series nuance, and the alternative for M365. It is front-loaded and every sentence earns its place without 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?

Given the destructive nature and the complexity of recurring events, the description fully covers the necessary context: the target app, the mandatory confirm flag, the span behavior, and the M365 alternative. With an output schema present and detailed annotations, nothing critical is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces key parameter behaviors (confirm must be true, span='future' deletes the series) but adds little new beyond what the schema already states. It provides no additional parameter details not already present in 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 the action ('Deletes an event'), the target resource ('Mac's Calendar app (Calendar.app)'), and the method ('by ID'). It also explicitly differentiates from the Microsoft 365 alternative, making the tool's scope 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 explicit usage guidance: confirm=true is required, span='future' is used for recurring series deletion, and it directly names the alternative tool (m365_delete_event) for Microsoft 365. This makes when-to-use and when-not-to-use very clear.

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

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

The description reinforces the destructiveHint=true annotation with 'Permanently deletes' and adds a mandatory confirmation guard ('Requires confirm=true'). This is valuable behavioral context beyond the annotations, though it does not detail failure modes or permission requirements.

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

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

Two concise sentences, each adding distinct value: the action and target, the ID source, and the confirmation requirement. No filler or redundancy.

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

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

For a simple destructive operation with a complete schema and output schema present, the description adequately covers the target, ID source, and confirmation gate. It could mention irreversibility more explicitly, but 'permanently deletes' already covers that.

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 already covers both parameters fully (reminder_id as identifier from list_reminders, confirm as boolean that must be true), giving 100% schema description coverage. The description mostly restates this information, adding no new parameter-level detail.

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 ('Permanently deletes') and target resource ('a reminder in Apple Reminders by ID'). It also tells the agent where to get the required identifier, distinguishing it from related tools like update_reminder, complete_reminder, and delete_reminder_list.

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 concrete execution guidance: retrieve reminder_id from list_reminders and set confirm=true. It does not explicitly compare with alternatives or list exclusions, but the delete semantics are unambiguous given the sibling tool names.

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

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

Annotations already mark destructiveHint=true, but the description adds significant context: it explicitly says 'cannot be undone' and that all reminders inside are deleted, which goes beyond just 'destructive'. It also specifies the confirmation requirement, making the irreversible behavior transparent. No contradiction with annotations exists.

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

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

The description is two sentences that front-load the action and critical warning, then provide usage details. Every clause adds value: what gets deleted, irreversibility, how to identify the target, and the confirmation gate.

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, the description doesn't need to explain return values. It covers purpose, scope, irreversibility, identifier options, and confirmation requirement. It lacks only edge-case behavior like conflicting name and list_id, but those are outside typical 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?

The schema already provides 100% coverage for all three parameters. The description reinforces the relationship between name and list_id as alternatives and points to get_reminder_folders as the source for list_id, adding a small sourcing hint. However, it mostly repeats schema information, so it meets but doesn't exceed the baseline for schema-covered params.

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 deletes an Apple Reminders list and all reminders within it, using a specific verb and resource. It distinguishes itself from sibling delete_reminder by emphasizing the cascading deletion and irreversibility.

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

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

The description provides clear context: this deletes an entire list, not just a single reminder, and cannot be undone. It instructs the agent to pass a name or list_id (sourced from get_reminder_folders) and requires confirm=true. While it doesn't explicitly name alternative tools like delete_reminder, the cascade warning implies when this 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?

The description discloses the key behavioral trait: it disconnects an account and removes tokens. With annotations providing no further behavioral hints (readOnlyHint=false, destructiveHint=false), the description adequately conveys the state change.

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

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

The description is a single concise sentence (10 words) that front-loads the purpose. 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?

The description completely covers the tool's purpose and effect for a simple action with no parameters. An output schema exists but is not needed here.

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

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

The tool has zero parameters, so schema coverage is 100%. The description adds no parameter information, but none is needed. 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 ('Disconnect your Microsoft 365 account') and the effect ('remove stored tokens'), distinguishing it from sibling tools like 'connect_m365_account'.

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 (when you want to disconnect) but does not provide explicit guidance on when to use or not use this tool versus alternatives. No exclusions 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?

Annotations already indicate readOnlyHint=false, and the description adds valuable behavioral detail by stating that the stored API token will be removed. This goes beyond the annotations to disclose the specific side effect, though it does not elaborate on further consequences.

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

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

The description is a single sentence, front-loaded with the action, and contains no filler words. It is maximally concise while conveying the core 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 zero-parameter tool with a non-destructive, non-read-only annotation and an output schema present, the description sufficiently explains the tool's purpose and effect. No further behavioral detail is 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?

The tool has zero parameters, so the description cannot add parameter-specific meaning. The baseline of 4 for zero-parameter tools applies, and the description provides a clear action statement that compensates for the absence of parameter 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 uses the specific verb 'disconnect' with the resource 'Todoist' and clarifies the action by adding 'remove the stored API token.' This clearly distinguishes it from the sibling connect_todoist.

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 usage guidance or alternatives are provided. The context implies this tool should be used when the user wants to disconnect Todoist and remove its stored token, but there is no explicit when-to-use or when-not-to-use statement.

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 does not disclose the confirm requirement (must be true to create), nor behavior if the file already exists. It only restates the basic create action, adding minimal context beyond the annotation that this is a write operation. The confirm flag is a notable behavioral gate not mentioned in the description.

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

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

The description is a single sentence, front-loaded with the action 'Creates a new Excel spreadsheet', and contains no fluff. Every word adds meaning.

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 an output schema and 4 parameters, but description omits the confirmation gate and fails to differentiate from excel_write_cell. It states the core purpose but leaves contextual gaps that are only partially filled by the schema and annotations. This is adequate but not complete for a write operation.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description mentions headers and optional data rows but adds no additional semantics about path format, row structure, or confirm requirement beyond what the schema provides.

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

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

The description clearly states the tool creates a new Excel spreadsheet (.xlsx) with headers and optional data rows, using a specific verb and resource. It distinguishes this tool from siblings like excel_read and excel_write_cell that operate on existing 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 this tool is for creating new spreadsheets but does not explicitly mention alternatives or when not to use it. It lacks guidance like 'use excel_write_cell to modify existing files' or mention of the confirm flag as a prerequisite.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral detail: the exact return structure (first row as headers, remaining as rows) and its compatibility with excel_create's parameter shape. This goes beyond what annotations provide, though it does not discuss edge cases 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?

The description is two sentences, front-loaded with the primary action and file type, and each sentence earns its place. It conveys purpose, return format, and a practical integration tip without any fluff. This is a model of conciseness.

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

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

With a rich output schema and full schema coverage for parameters, the description only needs to cover behavior, which it does efficiently. It explains the round-trip relationship with excel_create, which is valuable context. It could mention default sheet behavior, but the schema already states 'reads first sheet', so the description remains sufficient.

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

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

Schema description coverage is 100%, with clear descriptions for path, max_rows, and sheet_name. The description adds no new parameter-level semantics beyond what the schema already documents; it only explains the result structure (headers/rows), not parameter details. Thus the baseline 3 is appropriate because the schema carries the burden.

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

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

The description opens with a specific verb and resource: 'Reads data from an Excel spreadsheet (.xlsx file).' It clearly distinguishes itself from siblings like excel_create and excel_write_cell by focusing on reading and returning headers/rows. The explicit mirroring of excel_create's params also reinforces its unique role in read→create round-trips.

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: when you need to read an Excel file, especially to later create one via excel_create. It mentions the round-trip use case, providing context beyond the schema. However, it does not explicitly exclude alternatives like file_read or explain when not to use it, so a small gap remains.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, indicating this is a write operation. The description doesn't add detail about whether the file is created if missing, whether overwriting existing values occurs, or what happens with invalid addresses. The mention of two addressing alternatives is useful but not deep behavioral context. 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?

Two concise sentences that immediately state the action and the key usage flexibility. Every clause earns its place—no filler, no redundancy with the schema.

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 an output schema and 100% parameter coverage, so the description doesn't need to explain return values. It adequately covers the dual addressing modes and the sheet default. For a mutation tool with a confirm flag, slightly more guidance on the confirm behavior could help, but the description is reasonably complete given the richness of the annotations and schema.

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

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

Schema coverage is 100%, so all 7 parameters already have descriptions. The description adds value by explaining the dual addressing modes (cell vs row+column) and that sheet_name defaults to the first sheet, complementing the schema. The confirm parameter's requirement is stated in the schema but could benefit from more emphasis in the description.

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+resource combination ('Writes a value to a specific cell in an Excel file'), clearly distinguishing this from siblings like excel_create and excel_read. However, it doesn't explicitly differentiate from other mutation tools or note what makes it distinct beyond the basic resource and action.

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

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

The description clearly explains the two addressing modes (cell notation vs row+column integers) and when each applies. It also mentions the confirm flag requirement implicitly through the schema. It doesn't explicitly exclude alternatives like excel_read or state when NOT to use it, but the addressing guidance is genuinely useful for invocation.

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

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

Annotations already declare read-only and non-destructive behavior, and the description adds useful behavioral context: default path, inclusion of hidden files option, and deterministic sort order. It doesn't cover edge cases like permission errors, but given annotation coverage, this is adequate.

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

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

Two concise sentences front-load the core purpose, then add return fields, default behavior, and sorting. Every word earns its place with no redundancy or 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?

For a simple list tool with two optional parameters and an output schema, the description is fully complete. It covers default path, return fields, and ordering, leaving no important gaps for an agent to invoke 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 description coverage is 100%, so the schema already documents both parameters and their defaults. The description repeats the default behavior but adds no new parameter meaning beyond what's in the schema, matching the baseline for high 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 verb 'Lists' and the resource 'files and folders in a local directory', with explicit scope (local) that distinguishes it from cloud-based list tools. It also enumerates the return fields and sort order, making the purpose 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 clearly identifies the tool as listing local directory contents and defaults to the home directory, providing enough context for an agent to choose this tool for local filesystem listing. However, it does not explicitly name alternatives or state when not to use it, so it misses the top score.

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?

Beyond readOnlyHint/destructiveHint, the description discloses access-control behavior (allowed folder allowlist, actionable 'access denied' message), supported file types, and encoding auto-detection with fallback. This adds significant behavioral context not inferable from 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?

Every sentence serves a purpose—purpose, exclusions, path constraints, supported types, encoding, and alternative tool pointers—without redundancy. It is dense but well organized and front-loaded.

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

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

With a high-quality schema and annotations, the description covers purpose, usage boundaries, access control, file-type limits, encoding nuances, and clear alternatives, making it fully self-sufficient for an agent.

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

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

Schema coverage is 100%, and the description reinforces that path is absolute and inside an allowed folder, but does not add meaning to offset/max_bytes beyond their schema descriptions. Baseline 3 applies because the schema already documents these fully.

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

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

States a specific verb+resource ('Reads a plain text file from the local filesystem by its absolute path') and explicitly distinguishes from sibling readers by noting it is the default for local text files, with alternatives for PDF/Word/Excel and cloud storage.

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

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

Explicitly says 'use this unless the file is a PDF, Word, Excel, or PowerPoint document' and names alternatives like onedrive_read_file, gdrive_read_file, pdf_read, word_read, excel_read. Also defines the allowed-folder prerequisite.

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

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

Annotations already declare readOnlyHint and destructiveHint false, so the safety profile is known. The description adds valuable behavioral details: case-insensitive partial matching, root default, and returned fields (path, type, size), which go beyond the structured 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 clear sentences front-load the main action and key parameters. No unnecessary words; every clause adds valuable 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 full schema coverage and the presence of an output schema, the description is complete: it states the search behavior, defaults, and return types. The max_results and file_type filters are documented in the schema, so they need not be repeated here.

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

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

Schema description coverage is 100%, so parameters are fully documented. The description repeats some schema info (case-insensitive, partial, home default) but does not add significant extra meaning beyond the schema.

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

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

Description uses a specific verb ('Searches') with a concrete resource ('files and folders by name') and scope ('starting from a root directory'), while defining case-insensitive partial matching and output fields. This clearly distinguishes it from sibling tools like file_list or cloud-specific search tools.

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

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

The description provides clear context on how to use the tool (search by name, root directory defaults to home) and what results are returned. It does not explicitly name alternative tools or exclusions, but the local-file-context is strongly 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?

The description goes well beyond the sparse annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) by disclosing critical behaviors: overwrite requires confirm=true with a preview-first flow, append never requires confirm, missing parent folders are auto-created, and the path must be in an allowed folder. These are essential safety and execution details that the annotations do not convey. No contradiction with annotations is present.

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

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

The description is dense but well-organized, front-loading the core function and then systematically covering file types, alternatives, path restrictions, overwrite/append behavior, and folder creation. Every sentence adds necessary information, and the parenthetical for alternatives is efficient. No filler or redundancy.

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

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

Given the tool's moderate complexity (4 params, no enums, output schema present), the description covers all essential context: file types, alternatives, safety confirm flow, append semantics, path allowlist, and auto-creation of parent folders. The existence of an output schema means return-value details are not needed. This is a complete, self-contained 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?

Input schema already covers all 4 parameters at 100% coverage, so the baseline is 3. The description adds valuable parameter interplay: confirm is only needed for overwrite, append bypasses confirm, and content is treated as plain text. This enriches the schema descriptions, though not exhaustively (e.g., no examples of path format), so a 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's purpose: 'Writes text to a local file — create, overwrite, or append.' It identifies the resource (local file), the specific verb (write), and scope (create/overwrite/append). It also distinguishes itself from sibling tools for Word, Excel, and PowerPoint by explicitly naming alternatives, leaving 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?

Usage guidance is explicit and actionable. The description gives the when: for plain-text or code files, and the when-not: for Word, Excel, and PowerPoint, with specific alternative tool names. It also specifies path restrictions (same allowlist as file_read) and how to extend them, leaving no doubt about when 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the bar for transparency is lower. The description adds valuable behavioral context: it is Spotlight-free, paths are restricted to an allowlist, and access denied errors name the allowed folders. This goes beyond the annotations without contradicting them.

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

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

The description is two sentences, front-loaded with the main purpose, and every clause adds useful information (Spotlight-free, allowlist, error behavior). No redundant or filler content.

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

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

Given the simple nature of the tool, the rich annotations, and the presence of an output schema, the description is largely complete. However, the sibling list includes file_list and finder_search, and the description does not clarify how finder_list differs from these similar tools, leaving some potential for selection ambiguity.

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

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

Schema description coverage is 100% and both parameters have clear descriptions with defaults ('path' default ~, 'limit' default 100). The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists files and folders in a directory with the parenthetical 'Spotlight-free' adding a distinguishing characteristic. It does not explicitly differentiate from the sibling tool file_list, which likely performs a similar filesystem listing, so it falls short of a 5.

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

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

The description provides clear operational context: the path must be inside the allowed folder and paths outside it yield an actionable access denied error. However, it does not explicitly state when to use this tool over alternatives like file_list or finder_search, 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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses the use of Spotlight, the default home directory behavior, the ability to extend allowed folders, and the actionable 'access denied' error for paths outside the allowlist. This provides valuable behavioral context not captured by the annotations.

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

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

The description is three sentences long, front-loaded with the primary action, and every sentence adds value: purpose, scoping/default, and error behavior. There is no fluff or repetition of schema 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 presence of an output schema and annotations, the description covers the essential context: what it searches, how scoping works, and error behavior. It stops short of mentioning whether content search is included (schema says 'content' while description says 'by name'), a minor ambiguity, but overall it is complete for a read-only search 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?

All three parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds meaningful semantics for the path parameter, explaining it restricts the search to a specific allowed folder and how out-of-scope paths are handled. It does not add detail for query or limit, but the schema already covers those adequately.

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 'Searches for files by name within the allowlist' and names the underlying mechanism (mdfind/Spotlight). It specifies the resource (files), the action (search), the scope (allowlist), and an implementation detail, effectively distinguishing it from sibling cloud searches like gdrive_search_files and onedrive_search_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 provides clear context: it is scoped to allowed folders, defaults to the home directory, and can be limited to a specific folder via the path parameter. It explains how to extend the allowlist through Settings. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for an agent to understand when it applies.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the 'synced' context and a performance note, but does not detail return format or edge cases; output schema covers the return shape. This is minimal extra context, hence a 3.

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

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

The description is one succinct sentence that front-loads the purpose and includes a useful cost comparison. No redundant words or 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 tool with one parameter, an output schema, and clear annotations, the description is complete. It states what is returned, the target resource, and a key differentiator, which is enough for correct selection and 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?

Schema coverage is 100%: the single required 'path' parameter has a clear description. The description adds only a minor contextual note about the synced Google Drive, not materially expanding on the schema. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as returning metadata (size, dates, type) for a file/folder in the synced Google Drive, and it distinguishes itself from sibling tools by noting it is cheaper than listing the whole directory. This gives a specific resource and a differentiator.

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 implies when to use this tool: when you need metadata for a specific file/folder and want a cheaper alternative to listing a directory. However, it doesn't explicitly name sibling alternatives or provide exclusionary guidance, so it stops short of a 5.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description adds valuable context: it specifies the paths refer to the 'locally-synced folder' and that results are truncated to `limit` entries with a default of 1000. This gives the agent a more accurate behavioral model.

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

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

The description is three sentences long: the first states the core action, the second provides a prerequisite, and the third details the limit bound. Every sentence earns its place, and the text is front-loaded, making it easy for an agent to parse quickly.

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 list tool with an output schema and read-only annotations, the description covers all essential aspects: what it lists, where (locally-synced folder), how to get valid paths, and the result limit. It is sufficiently complete without needing to explain return values since an output schema exists.

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 fully describes both parameters (`path` and `limit`) with their types and limits. The description's mention of 'limit entries (default 1000)' simply restates schema information, adding no new semantic meaning. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's action ('Lists files and folders') and resource ('in a Google Drive path'). This distinguishes it from sibling tools like gdrive_search_files and gdrive_file_info, which serve 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 provides a clear prerequisite ('Use gdrive_root first for valid roots') and clarifies path structure ('My Drive' and 'Shared drives' are inside each mount). It does not explicitly mention alternatives, but the usage context is clear enough for an agent to decide when to invoke 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?

Beyond the readOnlyHint annotation, the description adds useful behavioral context: it auto-detects UTF-8 with Latin-1/CP1252 fallback, and warns about .gdoc/.gsheet pointer files. It does not contradict any annotation and enhances the agent's understanding of edge cases.

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

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

Three sentences, front-loaded with the main action, then important caveats, and closes with an alternative. 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?

Given the presence of an output schema, complete parameter documentation, and read-only annotations, the description covers all essential aspects: file types, encoding behavior, Google Drive specifics, and when to use a different tool. The tool is simple, and the description leaves no major questions.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters. The description's mention of auto-detected encoding aligns with the encoding parameter but adds no new syntax beyond the schema. This matches the baseline 3.

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

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

The description clearly states the tool 'Reads a text file from the synced Google Drive folder' with a specific verb, resource, and scope. It distinguishes itself from the sibling file_read by explicitly noting 'For files outside Google Drive, use file_read'.

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

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

Provides explicit when-to-use (text files in the synced Google Drive folder) and when-not-to-use (native Google Docs/Sheets/Slides, which sync as .gdoc/.gsheet pointers). It also names an alternative (file_read) for files outside Google Drive.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds meaningful behavioral context by explaining it reads the locally synced folder and requires no Google API or OAuth. This clarifies mechanism and side-effect-free nature beyond the annotation flags.

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

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

Three short sentences front-load the core purpose, then add usage guidance and technical context. Every sentence contributes new information with no redundancy or padding.

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

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

This is a simple zero-parameter listing tool with an output schema and safe-read annotations. The description covers what is listed, the entry-point role, and the local/no-auth mechanism, which fully satisfies the context needed for an agent to select and invoke 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 tool takes zero parameters, so the schema (100% coverage) fully defines the input contract. The description appropriately adds no parameter details; the baseline of 4 applies.

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

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

The description opens with a specific action ('Lists') and a precise resource ('Google Drive folders synced on this Mac'), enumerating My Drive, Shared drives, and per-account mounts. It clearly distinguishes this tool from sibling gdrive_* tools by positioning it as the root/entry point for valid paths.

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

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

It gives explicit context: 'Start here to get valid paths for the other gdrive_* tools,' and notes it reads the folder already synced by Google Drive for Desktop. It doesn't explicitly state when not to use it or name alternatives, but the intended sequencing is clear.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral details beyond the annotations: it is recursive, returns at most max_results (default 50), and searches by name. This provides meaningful context about the tool's behavior without contradicting the annotations.

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

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

The description is a single, front-loaded sentence that immediately states the tool's purpose and key constraints. Every phrase earns its place: 'synced Google Drive folder,' 'by name (recursive),' and 'max_results matches (default 50).' There is zero wasted wording.

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

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

Given that an output schema exists and annotations are present, the description does not need to explain return values or safety. It covers the essential action, scope, recursion, and result limiting. The only minor gap is that it does not clarify what 'the synced Google Drive folder' refers to (e.g., whether it searches all mounted Google Drives by default), but the root parameter and schema help fill that in.

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

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

Schema description coverage is 100%, meaning all three parameters are already documented. The description adds no new parameter-level details beyond what the schema provides—it only reiterates the 'by name' and 'max_results' concepts. Since the schema carries the full load, a baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Searches'), a specific resource ('the synced Google Drive folder'), and the scope ('by name (recursive)'). This clearly distinguishes it from sibling tools like gdrive_list_files or gdrive_read_file. The purpose is unambiguous and immediately understandable.

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 its usage context: searching for files by name in Google Drive. However, it does not explicitly mention alternatives or exclusions, such as 'use this instead of gdrive_list_files when you need to find a file by name.' The guidance is implied rather than explicit, so it earns a mid-range score.

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 says 'overwrites a text file', which is a destructive action, but annotations mark destructiveHint=false. This is a direct contradiction. The preview/confirmation workflow is helpful, but the contradiction with the annotation undermines trust and requires flagging.

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

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

The description is two well-structured sentences. The first sentence states the core purpose, and the second explains the confirmation requirement. No filler or redundant content is present.

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 sufficiently covers the core usage: writing/overwriting a file, auto-upload, and the confirmation flow. It does not detail edge cases like missing paths or permissions, but given the output schema exists and the description is focused, it is 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?

The description adds critical meaning to the confirm parameter by explaining the two-step preview-then-confirm workflow. While schema covers all three parameters at 100%, the description goes beyond by clarifying the sequence and purpose of confirm=true, which is not evident from the schema alone.

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 ('Writes or overwrites') and names the resource ('text file in the synced Google Drive folder'), clearly distinguishing it from read/list/search siblings like gdrive_read_file and gdrive_list_files. The mention of the official client and auto-upload further clarifies the tool's role.

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

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

The description clearly explains how to use the tool: first call returns a preview, then pass confirm=true to write. It provides clear context for writing to Google Drive, though it does not explicitly mention alternatives or when-not-to-use, so it falls short of a 5.

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

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

Annotations already declare read-only and non-destructive behavior. The description adds scope (recent, local) but no additional behavioral depth beyond that.

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

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

Two sentences with front-loaded purpose and no superfluous words; efficiently conveys what the tool does.

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 and three optional parameters, the description covers the key aspects. Could mention limit default/max, but generally complete.

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

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

Schema coverage is 100%, so parameters are fully documented in schema. Description adds no extra meaning or context about parameters.

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

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

The description clearly states the tool returns recent LMCP tool call history from the local audit log, listing specific fields. This distinguishes it from siblings as no other tool serves this 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?

Provides context for use (GDPR compliance reporting and debugging) but does not explicitly mention when not to use or 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?

The description adds the important detail that the API key is masked, which is beyond the readOnlyHint annotation. It also implies the returned configuration is current. No contradictions 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 a single sentence with no superfluous words. It is front-loaded and efficiently conveys the tool's 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?

Given the tool's simplicity (no parameters, has output schema), the description is complete. It specifies the return value and the masking behavior, while the output schema covers the 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?

The input schema has no parameters and schema coverage is 100%, so baseline is 3. The description does not add parameter-related information, but none is needed.

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

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

The description clearly states the tool returns the current LMCP configuration with the API key masked. It specifies the verb 'returns' and the resource 'LMCP configuration', distinguishing it from sibling tools like lmcp_state which likely provides a different view.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention context, prerequisites, or differentiate from tools like lmcp_state or other configuration-related 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?

Annotations already convey read-only and non-destructive behavior. The description adds valuable context beyond that by explaining that a name-based lookup may return a compact list if multiple people match, which is exactly the kind of behavioral nuance an agent needs. It does not contradict the annotations.

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

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

Three sentences with no wasted words. It opens with the primary purpose, then explains parameter usage, and closes with a clear sibling-tool pointer—all front-loaded and well-structured.

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

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

For a simple, read-only tool with an output schema and rich annotations, the description is fully sufficient. It covers purpose, usage alternatives, multi-match behavior, and sibling differentiation, leaving no significant 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 coverage is 100%, but the description enriches the parameters by explaining that name is a one-step path and contact_id is an exact identifier from list_contacts/search_contacts. It also reinforces the either/or relationship between the parameters, adding meaning beyond the schema.

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

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

The description clearly states it retrieves a contact from the Mac's Contacts.app by name or ID, which is a specific verb+resource. It also distinguishes itself from m365_get_contact and indicates there is no need to call search_contacts first, making its purpose 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?

It explicitly tells when to use this tool (local Mac contacts) and when not to (use m365_get_contact for Microsoft 365). It also explains the two usage modes (name for direct lookup, contact_id for exact lookup) and reassures the agent that prior search is unnecessary.

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