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

Annotations are present but all false, so the description carries a moderate burden. It adds valuable behavioral context beyond the annotations: process launched without a shell, minimal environment, namespaced tools as <connector>__<tool>, and the allow_connectors prerequisite. These details help the agent predict side effects and operational 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?

Three short sentences, front-loaded with the primary purpose, and no filler. Every clause adds meaningful information without redundancy.

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

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

Covers the core purpose, a prerequisite, and important operational details (no shell, minimal env, namespacing). However, it omits parameter behavior and explicit usage distinctions, and with no output schema, the agent has limited understanding of what will be returned or how to handle failures.

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 only 40% (command and inherit_env have descriptions) and the description does not compensate. It provides high-level context about the process environment but never explains key parameters like name, args, or enabled. The agent must rely on sparse schema descriptions for most 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?

States a specific action ('Configure') on a specific resource ('external stdio MCP server'). Differentiates from sibling tools that list/remove/refresh connectors by clearly implying this creates/configures one.

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

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

Implies usage via 'Configure an external stdio MCP server' and mentions a prerequisite ('Requires allow_connectors'), but does not explicitly state when to use this over sibling tools like list_connectors, remove_connector, or refresh_connectors. No exclusions or when-not-to-use guidance.

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

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

Annotations indicate readOnlyHint=false, but the description adds the important context of persistence ('future session') and the constraint of brevity. It does not contradict annotations and provides extra behavioral context beyond the raw 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?

Two sentences, front-loaded with the action and resource, no fluff. Every sentence adds value: what it does, when to use it, and how to format the note.

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 one-parameter tool with annotations and complete schema coverage, the description fully explains the tool's purpose, usage trigger, and content constraints. No output schema is needed, and the description covers the essential context.

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

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

Schema coverage is 100% with a clear param description. The tool description adds the specific guideline of '1-3 sentences', which goes beyond the schema's 'be concise' and provides additional semantic meaning for the note parameter.

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 a specific verb ('Append') and resource ('persistent memory file'), and distinguishes from sibling read_memory by focusing on writing. It also defines the type of content (concise notes, key facts).

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

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

Explicitly states when to use the tool ('when the user shares a preference, important system fact, or decision'). It does not mention alternatives, but no obvious alternative exists for writing memory besides this tool. Slight deduction for not stating when not to use.

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

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

Annotations already indicate non-read-only, open-world, and non-idempotent behavior. The description adds valuable context beyond these by disclosing the authentication prerequisite and the underlying OS-specific commands, which could affect failure modes. It does not contradict annotations and enriches the behavioral picture, so a 4 is appropriate.

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, both information-dense. The first sentence states the primary action and permission requirement; the second adds platform-specific commands. Every clause contributes to understanding the tool, and there is no repetitive 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 parameter set (1 param), no output schema, and existing annotations, the description covers the essential operational aspects: action, permission prerequisite, and platform behavior. It could mention potential error handling or return status, but for a straightforward browser-opening tool, the context is sufficiently complete.

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

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

Schema description coverage is 100% and the only parameter, 'url', already has a thorough description including the https:// default assumption. The tool description adds no additional parameter semantics beyond referencing 'URL' in the action. With full schema coverage, the baseline of 3 applies.

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

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

The description clearly states the tool's action with a specific verb and resource: "Open a URL in the user's default browser as a new tab/window." This distinguishes it from siblings like web_fetch (which retrieves content) and open_file_at_path (which opens local files), leaving no ambiguity about its purpose.

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

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

The description provides explicit context for when to use the tool by noting the prerequisite: "Requires prior browser permission (grant_browser_access)." It also adds platform-specific implementation details (macOS `open` vs. webbrowser module), but does not explicitly contrast it with alternatives or state when not to use it. This is clear usage context without formal exclusions, fitting a 4.

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 the operation is not read-only and not destructive. The description adds the context that it targets a pending reminder and requires an ID, but it doesn't disclose potential side effects, error behavior, or idempotency. This is sufficient for a simple cancel operation but lacks deeper behavioral detail.

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 that immediately communicates the purpose and the key procedural detail (where to get the ID). No unnecessary words or repetition.

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

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

Given the tool's simplicity (one parameter, no output schema, and annotations provided), the description covers the essential aspects: what it does and how to obtain the required ID. It doesn't mention return values or edge cases (e.g., reminder not found), but these are less critical for a straightforward cancel 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?

The schema already provides a complete description of the 'id' parameter (8-character hex string). The description adds significant value by explicitly telling the user to get the ID from set_reminder or list_reminders, which clarifies the parameter's origin and format beyond 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 clearly states the action (Cancel), the resource (a pending reminder), and the mode of identification (by its ID). It also distinguishes itself from sibling tools like set_reminder and list_reminders by indicating the ID can be obtained from those 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 by specifying that the tool is for canceling a pending reminder and instructs how to acquire the necessary ID. While it doesn't explicitly discuss when not to use it or alternatives, the guidance is specific and actionable, making the usage context 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 idempotentHint=true. The description adds valuable behavioral context: the tools it uses (Homebrew, mas, system updates), the platform restriction, and the output format (lists with current vs available versions). This goes beyond 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?

Two concise sentences pack all essential information: platform, sources, dependencies, and return detail. Front-loaded with the most important scoping ('macOS only') and 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?

For a tool with no parameters and no output schema, the description fully covers platform, dependencies, sources, and output structure. It is enough for an agent to know exactly when to invoke it and what to expect.

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

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

There are zero parameters, so the baseline is 4 per rubric. The description mentions the output format (lists of outdated apps with versions), which is useful even without parameters. No parameter details 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 states a specific verb ('checks for outdated applications') and clearly enumerates the resources covered (Homebrew formulae+casks, Mac App Store via mas, macoS system updates). It distinguishes itself from sibling tools like get_cpu_usage or get_system_alerts by focusing on application update status.

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

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

It provides clear platform context ('macOS only') and notes the mas CLI dependency for Mac App Store checks. While not explicitly naming alternative tools, the scope is distinct enough from siblings that usage context is clear. No exclusions are given, but none are needed for a read-only check tool.

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

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

Beyond the destructiveHint annotation, the description adds critical safety context: it defaults to dry_run so nothing is removed without explicit opt-in, and it requires allow_file_write when dry_run is false. This discloses auth needs and default behavior, going beyond what annotations alone 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 two sentences, front-loaded with the action, and every word earns its place. It avoids fluff while conveying purpose, safety, and permissions.

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

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

For a tool with only two simple parameters, an existing output schema is not necessary. However, the description doesn't explicitly state what the dry-run output looks like (e.g., list of files). Still, it covers safety and permission, making it adequately complete for this complexity level.

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

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

Schema description coverage is 0%, so the description must compensate. It names 'dry_run' and implies 'older_than_days' via 'N days', but doesn't fully explain the parameters or their constraints. The defaults are already in the schema, but the description adds some meaning by explaining the effect of dry_run.

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: 'Find or delete files in ~/Downloads older than N days.' It specifies a specific verb (find/delete), a resource (files in ~/Downloads), and a condition (older than N days), making it distinct from sibling tools like delete_file or find_large_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 usage for batch cleanup of old downloads but does not explicitly contrast with alternatives or define when not to use it. The dry-run default and permission requirement provide context, but there's no mention of when to prefer this over delete_file or find_large_files.

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 present (readOnlyHint=false, destructiveHint=false), the description adds value by disclosing the configuration requirement and clarifying behavior when dst is a directory. It does not mention overwrite behavior details, but annotations already signal non-read-only and non-destructive, so this is acceptable.

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

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

The description is two sentences long, front-loaded with the core action, and every sentence provides relevant information 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?

The tool has no output schema and the description does not mention what happens on success, errors, or the default overwrite behavior when dst exists. Given the low complexity and good annotations, this is a clear gap but not severe.

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 documented. The description adds extra meaning for dst by explaining that if it's a directory, the source filename is preserved, which goes beyond the schema's simple type/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's action ('Copy a file to a new location') with the resource (file). It distinguishes from sibling tools like move_file by explicitly using 'copy' rather than 'move', and from write_file by implying an existing source.

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 useful context about destination behavior and a prerequisite (allow_file_write), but it does not explicitly mention when to prefer this tool over alternatives like move_file. The usage context is implied rather than explicitly contrasted.

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

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

Annotations indicate readOnlyHint=false, which aligns with a creation operation. The description adds valuable context beyond annotations: the need for allow_automations, the restriction to read-only tools, and the local and recurring nature of the automation. This enriches the behavioral profile without contradicting the structured hints.

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 action and purpose, followed by essential constraints. Every sentence carries meaningful information without redundancy.

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

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

Given the tool has 4 parameters, no output schema, and moderate annotations, the description covers the core behavior, permission, and restrictions. It does not explain return values or edge cases, but the presence of sibling automation tools and the clarity of the creation task make this sufficiently complete.

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

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

Schema description coverage is 75% (name, tool, interval_minutes all have descriptions; arguments lacks one). The description adds context about the tool parameter being read-only but does not elaborate on the arguments object or other parameters. At 75% coverage, the baseline of 3 is appropriate; the description contributes only marginal additional meaning.

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

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

The description begins with a specific verb and resource: 'Create a recurring local automation that runs a read-only SysControl tool.' It clearly distinguishes this from sibling tools like list_automations, update_automation, and delete_automation by focusing on creation and adding constraints (recurring, local, read-only tool).

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

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

It explicitly states the permission requirement 'Requires allow_automations' and specifies what cannot be scheduled ('Mutating, destructive, extension, and automation tools cannot be scheduled'). This gives clear boundaries on when to use the tool, though it does not name alternative tools for retrieval or updates.

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 recursive creation of parent directories and the permit requirement, adding value beyond annotations. However, it does not mention behavior when the directory already exists or error handling, but the key behavioral traits are covered.

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 that immediately states the primary action, then adds the parent-directory nuance and permission requirement with 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?

For a simple tool with one parameter and no output schema, the description covers purpose, permissions, and recursive behavior adequately. It does not specify return values or existence-handling, but these are not critical for a basic directory creation 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?

The input schema already fully describes the path parameter as 'Absolute or home-relative path for the new directory.' The description adds no additional parameter context beyond this, so the schema carries the semantic load, matching the baseline score.

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

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

The description specifies 'Create a new directory' with the additional detail of creating missing parent directories, clearly distinguishing it from sibling file tools like list_directory or delete_file. The verb+resource is explicit and unambiguous.

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

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

The description clearly indicates this tool is for creating directories and notes the prerequisite allow_file_write permission, providing clear context. It doesn't explicitly state when not to use it or name alternatives, but for a directory creation tool this is sufficient context given 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 indicate this is not read-only, not idempotent, and not destructive. The description adds valuable context beyond annotations by noting the permanent installation, the required config flag, and the need to restart the agent. This is genuine behavioral disclosure.

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

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

The description is three concise sentences, each adding unique information: the core action, the prerequisite, and the post-condition. No redundant filler or repetition of schema details.

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

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

For a tool with five parameters, a nested schema, and no output schema, the description provides the key operational context: persistence, configuration prerequisite, and restart requirement. It does not explicitly describe error behavior or return values, but the absence of an output schema reduces the need. Overall adequate and well-rounded.

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 parameter meanings are fully documented in the schema itself. The description does not add extra parameter-specific guidance, but the high coverage means the schema carries the burden. 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 action with a specific verb and resource: 'Generates, validates, and installs a new MCP tool permanently into the server.' This is unique among siblings, none of which create tools. No ambiguity or tautology.

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 usage by stating the prerequisite configuration ('Requires allow_tool_creation: true in ~/.syscontrol/config.json') and the post-condition (tool available after restart). It does not explicitly name alternatives or exclusions, but no sibling tool offers equivalent functionality, making the intended use 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 adds substantial context beyond the annotations: it discloses the multi-step process (planning subquestions, searching multiple sources, extracting claims, cross-verifying), the output format (citation-backed), the time cost, and a prerequisite (allow_deep_research in config). This is exactly the kind of behavioral detail that helps an agent understand the trade-offs.

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 dense sentences, each earning its place: first explains what it does, second gives usage guidance, third states time and permission requirements. No fluff, front-loaded with the primary 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 complex research tool with no output schema, the description covers the process, duration, return value (citation-backed answer), and prerequisites. It fully compensates for the lack of an output schema and gives the agent enough context 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?

The input schema already provides 100% description coverage for all three parameters, including defaults and ranges. The description does not add parameter-level semantics beyond what the schema provides, but it also doesn't need to. Baseline 3 is appropriate.

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

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

The description clearly states the tool's verb ('conduct deep, multi-step web research'), the resource (web/topic), and the output (citation-backed answer). It distinguishes itself from siblings like web_search and web_fetch by emphasizing multi-step planning, cross-verification, and synthesis.

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

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

It explicitly says when to use it: 'for questions needing current information, evidence verification, or multiple perspectives.' It also gives a time expectation (1-3 minutes) which helps the agent decide if this heavy tool is appropriate. It does not explicitly name alternatives or exclusion criteria, but the contrast with simpler search tools is implied.

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

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

Annotations include destructiveHint=true, and the description's 'Delete' aligns with that. The description adds the permission requirement (allow_automations), providing extra context beyond annotations. However, it does not disclose other potential behavioral traits like irreversibility or cascading effects on related runs.

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, front-loaded sentences: 'Delete a scheduled automation.' and 'Requires allow_automations.' Every word is purposeful, with no wasted text.

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

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

For a simple one-parameter destructive tool, the description plus annotations (destructiveHint=true) cover the essentials: what it does and a key prerequisite. It could add details about permanence or effects on associated runs, but the tool's simplicity and context make it adequately 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 does not explicitly explain the 'id' parameter, but the phrase 'Delete a scheduled automation' implies the id refers to the automation to be deleted. With schema description coverage at 0%, the description provides minimal parameter guidance, though the single parameter's meaning is easily inferred.

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 'Delete a scheduled automation' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_automation, update_automation, and list_automations.

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 prerequisite ('Requires allow_automations') but does not explicitly discuss when to use this tool versus alternatives, such as using update_automation to disable instead. The intended use is clear from the name and description, but no explicit when/when-not guidance is given.

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 destructiveHint annotation, the description discloses important behavioral traits: default recoverability on macOS (Trash), a permanent deletion flag, a safety scope limited to home directory, and an authorization prerequisite (requires allow_file_write). This adds significant context about consequences, permissions, and constraints that annotations alone do not 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 concise and well-structured: a clear first sentence ('Delete a file or directory.'), followed by two compact sentences providing platform-specific behavior and safety/permission context. Every sentence adds value without redundancy.

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

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

For a simple two-parameter tool, the description covers the core behavior, platform nuance, a safety limitation, and an authorization requirement. The only notable gap is that non-macOS behavior is not addressed (it says 'On macOS' but doesn't state default behavior on other operating systems). Overall, it is sufficiently complete given the tool's simplicity and existing annotations.

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

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

The input schema already documents both parameters with descriptions: 'path' and 'permanent' (including its default false and meaning). The description repeats the permanent/Trash behavior but adds no new semantic detail beyond what the schema provides. Since schema coverage is 100%, a 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 action ('Delete a file or directory') with the specific resource and additional scope ('only allows deletion within the home directory'). While it does not explicitly name sibling tools or contrast with alternatives, the verb+resource combination is unambiguous and effectively distinguishes this from move/copy operations.

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

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

The description implies usage by stating the core function and provides useful context (macOS Trash behavior, safety restriction to home directory, and the require allow_file_write permission). However, it does not explicitly state when to choose this tool over alternatives or list exclusions (e.g., when to prefer move_file). The safety and config notes offer implied conditions, but no direct 'use this when...' guidance.

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

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

With all annotations false, the description carries the burden of behavioral disclosure. It explains the three edit operations, the input structures, and the prerequisite 'Requires allow_file_write in ~/.syscontrol/config.json'. It does not mention in-place modification or error handling, but the provided details are adequate for a mutation tool.

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

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

The description is a concise four-sentence block. It leads with the purpose, then explains each parameter group in a structured manner, and ends with the configuration requirement. No useless words or repetition.

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

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

The description covers the purpose, all operation modes, parameter shapes, and the configuration prerequisite. It does not explain return values, but no output schema is provided and the tool is a simple mutation, so the description is reasonably complete for its 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?

The input schema already provides 100% coverage with detailed descriptions and examples for all four parameters. The tool description merely restates these parameter formats in prose, adding no new semantic meaning beyond the schema, 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's purpose: 'Edit a Word document (.docx)' with three specific operations: find-and-replace, overwrite a paragraph by index, and append new paragraphs. This precise verb-resource pair and the enumerated operations distinguish it from sibling tools like edit_file and read_document.

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 the tool by specifying the .docx file type and the available operations. It does not explicitly exclude plain-text editing (which edit_file might handle) or contrast with read_document, but the context is clear enough for an agent to select this tool for Word documents.

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 (which provide no safety hints), the description discloses that old_string must be unique and the tool fails if ambiguous, that replace_all changes this, and that allow_file_write permission is required. It stops short of detailing error handling for not-found text or return format.

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

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

Four sentences, front-loaded with the action, and every sentence earns its place by conveying usage, requirements, or failure modes. No redundant or fluff 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 tool's complexity and the absence of an output schema, the description covers the core editing workflow, prerequisites, and a key failure mode. Minor gaps remain around return values and what happens when old_string is not found, but it's sufficient for typical 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 already covers all four parameters, but the description adds meaningful nuance: 'fails if ambiguous' for old_string and 'By default' for uniqueness behavior. It also reinforces the role of replace_all, adding error behavior not present in schema.

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

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

Clearly states the tool performs targeted find-and-replace edits on files, distinguishing it from sibling tools like write_file or delete_file. The verb 'Make' plus 'targeted edits' and resource 'file' are specific.

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 instruction to ALWAYS read the file first to get exact text, and explains the uniqueness requirement and replace_all behavior. Does not explicitly name alternative tools or exclusions, but the context makes the appropriate use case 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?

Beyond annotations, the description discloses the configuration requirement (allow_file_write) and the .xlsx-only restriction for create_if_missing. It does not explicitly warn that updates overwrite existing cell values, but this is largely inferred from the word 'write'.

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 efficiently structure the description with the main action first and parameter details following. Every sentence provides useful information without any wasteful repetition.

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

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

For a 5-parameter write tool, the description covers the core workflows, parameter formats, configuration requirement, and format limitations. It is sufficiently complete for practical use, despite lacking an 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?

The schema descriptions cover all parameters, and the description adds concrete examples for updates and append_rows, clarifies A1 notation, and explains the create_if_missing behavior. This adds meaningful value beyond the schema.

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

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

The description clearly states the tool writes cells or appends rows to spreadsheet files and specifies the supported formats (.xlsx or .csv). This distinguishes it from sibling file operations like write_file or edit_file.

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

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

The description implies usage for spreadsheet modification but does not explicitly state when to prefer this tool over alternatives like edit_file or write_file. No exclusions or alternative mentions are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds beyond annotations by listing skipped directory types (e.g., .git, node_modules), which is useful behavioral context. 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?

Two sentences, front-loaded with the core function, and every sentence adds value without redundancy.

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

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

For a simple tool with 2 optional params and no output schema, the description is complete: it states the purpose, default behavior, exclusions, and usage scenario. Could mention output format, but not critical given no 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?

Input schema covers 100% of parameters with detailed descriptions, including defaults and ranges. The description adds little beyond what the schema already provides, so baseline 3 applies.

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

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

The description uses the specific verb 'Finds' with a clear resource ('top N largest files under a directory'). It distinguishes from siblings like get_disk_usage and search_files by specifying the exact scope and output.

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

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

Explicitly states 'Use when the user asks what is using disk space or wants to free up storage,' providing clear context. Lacks discussion of alternatives or when not to use, so not 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 provide minimal behavioral context (readOnlyHint=false, idempotentHint=false). The description adds meaningful context beyond annotations: it states the return format ('inline PNG for the GUI/chat') and an auth requirement ('Requires an OpenAI image API key'). It does not contradict annotations, so no annotation 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?

The description is three sentences, front-loaded with the purpose, followed by usage guidance, an alternative, and a requirement. Every sentence provides distinct value with no unnecessary fluff, making it highly concise and well-structured.

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

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

Given the tool has 5 parameters with a fully descriptive schema, the description covers the key contextual elements: what it does, when to use it, a critical alternative, an auth prerequisite, and the output format. It does not explain error handling or cost, but for a simple generative tool with rich schema, this is sufficiently complete.

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

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

Schema coverage is 100%, with all five parameters having descriptions. The description itself does not elaborate on parameter details but does mention 'text prompt' and 'return as PNG', adding slight context. Since the schema already documents parameters thoroughly, 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 says 'Generate a new visual image artifact from a text prompt and return it as an inline PNG for the GUI/chat.' This is a specific verb+resource statement that clearly defines the tool's function. It also distinguishes itself from sibling system data tools by noting a preference for chart-returning metric tools for system data, 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?

The description explicitly states when to use this tool: 'Use when the user asks for an image or when a small visual artifact would clearly make the answer more useful.' It also provides an exclusion: 'Prefer built-in chart-returning metric tools for system data.' This gives clear guidance versus alternatives and includes a prerequisite (OpenAI API key).

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 the tool read-only, idempotent, and non-destructive. The description adds valuable context about privacy-preservation and the specific data retention policy, which goes 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 a single, front-loaded sentence that conveys the core purpose and a key constraint. Every word adds value, with no repetition 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 and the annotations cover safety, but the description omits parameter semantics and return format. It is minimally adequate for a read-only getter but lacks detail for full comprehension.

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?

Param schema has 0% description coverage, and the description does not explain either parameter ('tool' filter or 'limit'). Without any compensation, the agent has no information about how to set or use these 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 uses a specific verb ('Return') and resource ('local privacy-preserving tool audit log'), and clearly distinguishes this from sibling resource-monitoring tools by detailing what is recorded (argument names, risk, status, errors) and what is not (argument/result values).

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only states what the tool returns, leaving usage context implicit.

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 established. The description adds useful behavioral context by specifying the return values and the error case for desktops with no battery, which goes beyond 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 two concise sentences. The first sentence front-loads the primary purpose and returned data, and the second covers the error condition. 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?

For a simple read-only status tool with no parameters and no output schema, the description adequately covers the key return values and an important edge case. It lacks exact formatting details (e.g., units or response envelope), but this is minor for such a straightforward tool.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters because there are none, and it correctly focuses on the output instead.

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 'returns' and clearly identifies the resource (battery status), listing the exact data items: percentage, charging state, and estimated time remaining. This distinguishes it from sibling tools like get_cpu_usage or get_ram_usage.

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 use case (when battery information is needed) and states an exclusion/error condition for desktops with no battery. However, it does not explicitly name alternative tools or elaborate on when not to use it beyond the no-battery limitation.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds valuable context: the platform dependency (macOS only) and the underlying command (pbpaste), which are 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?

The description is a single, front-loaded sentence with no superfluous words. It conveys the action, resource, and platform constraint efficiently.

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

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

For a simple tool with no parameters and robust annotations, the description covers the essential behavior: return type (text), platform (macOS), and implementation (pbpaste). It does not mention error cases (e.g., non-text clipboard), but that is a minor gap given the tool's simplicity.

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

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

There are zero parameters, so the baseline is 4. The description adds semantic clarity by specifying the content type as 'text', which clarifies what the clipboard returns beyond an empty schema.

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

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

The description clearly states the tool returns the current text content of the system clipboard, using a specific verb ('Return') and resource. It also distinguishes itself from the sibling 'set_clipboard' by being a read operation, and mentions platform (macOS).

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 clipboard text is needed, but does not provide explicit when-to-use vs alternatives or exclusions beyond the macOS-only constraint. No alternative tools are named, so guidance is minimal.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing safety. The description adds value by specifying the return format (inline bar chart) and the exact data points (per-core and total percentage, core count, frequency), which is behavior beyond 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?

A single, well-structured sentence front-loads the primary purpose ('Returns CPU usage percentage') and then lists additional details. Every phrase is informative and there is no redundancy or extraneous text.

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

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

Without an output schema, the description bears responsibility for explaining return values. It covers the key elements: total and per-core usage, core count, frequency, and the bar chart. Minor ambiguities like frequency units and sampling methodology prevent a perfect score, but it is complete for a simple monitoring tool.

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

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

The tool has zero parameters, so the schema is trivially complete (100% coverage). The description does not need to explain parameters, and it instead provides useful output details. Baseline for zero-parameter tools is 4, which is appropriate here.

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

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

The description uses a specific verb ('Returns') and identifies the resource ('CPU usage') with detailed scope: total and per-core percentage, core count, frequency, and inline bar chart. This clearly distinguishes it from sibling tools like get_ram_usage and get_gpu_usage.

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 intended use is evident from the description: it provides CPU metrics. While it doesn't explicitly name alternatives or exclusions, the context is clear within the system-monitoring tool family. The lack of explicit when-not-to-use is a minor gap, but the description is sufficient for a simple read-only metric.

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 idempotentHint=true, so safety is covered. The description adds the 'static' characteristic, suggesting stable data, but provides no other behavioral context such as permission requirements or potential platform differences.

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 concisely lists all returned content with no filler or redundancy. Information is front-loaded with the action and resource.

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

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

For a simple, static, read-only tool with no parameters and no output schema, the description fully enumerates what is returned. No further context is needed; annotations cover safety.

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. The description correctly indicates no inputs are needed by not mentioning any, and the empty schema is self-explanatory.

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 static hardware specifications' and enumerates the exact attributes (CPU model, core count, RAM, GPU, disk, OS). This verb+resource phrasing distinguishes it from dynamic usage tools like get_cpu_usage or get_ram_usage.

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 word 'static' implies use for one-time hardware queries rather than real-time metrics, but the description does not explicitly mention alternatives or when to prefer this tool over similar siblings like get_hardware_profile. Usage context is implied rather than 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by specifying the exact data returned (partition usage and I/O counters), but does not disclose further behaviors such as permission requirements or output format. Given the rich annotations, 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?

The description is a single, clear sentence with no filler, front-loading the purpose immediately. Every word contributes to understanding the tool, making it highly concise and well-structured.

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

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

For a simple read-only tool with no parameters and no output schema, the description is complete: it clearly states what the tool returns. There are no prerequisites, side effects, or return format details that need explanation, and the annotations cover safety. The description fully supports an agent in deciding when to invoke this 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?

With zero parameters, the input schema provides no information, so the baseline is 4. The description adds meaning by explaining the tool's output, which helps the agent understand the tool's semantics despite the absence of parameters. It does not over-explain or repeat schema content.

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 'Returns' and identifies the resource clearly as 'disk partition usage and I/O counters'. This clearly distinguishes it from sibling monitoring tools like get_cpu_usage, get_ram_usage, and get_realtime_io, which focus on other system metrics.

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

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

The description implies usage for disk-related queries but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. For example, it does not clarify the difference from get_realtime_io, leaving the agent to infer the appropriate context based on the name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds valuable behavioral context by specifying the exact returned fields and, importantly, that it returns an actionable error if Docker is not installed or the daemon is not running. This goes beyond the structured annotations and provides practical expectations.

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 contains no redundant information. Every sentence earns its place: the first states the core output, the second adds the count and error handling. There is no wasted text.

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

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

Given no parameters, a simple read-only output, and the presence of rich annotations, the description is complete. It states exactly what is returned and how failures are reported. No output schema exists, but the description adequately covers the return content, so no further 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 baseline is 4. The description does not need to explain parameter semantics, and the schema confirms no parameters are required. No further parameter-specific detail is expected, so the score aligns with the baseline.

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 all running Docker containers with specified fields (CPU%, memory usage, image, status, ports) and total container count. This is a specific verb+resource combination that distinguishes it from sibling system metrics tools like get_cpu_usage or get_ram_usage, which cover host-level resources rather than Docker-specific data.

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

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

The description does not explicitly state when to use this tool versus alternatives or mention exclusions. However, the specific reference to Docker containers and the inclusion of an error for Docker-specific issues implies the intended use case. No explicit guidance on alternatives is provided, so it earns only the implied-usage 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the scope of the snapshot (which subsystems are included) but does not disclose potential performance impact or the point-in-time nature beyond the word 'snapshot'. It adds some context but not rich behavioral detail.

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 that front-loads the primary action and lists components with no wasted words. Perfectly structured for quick comprehension.

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

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

With no output schema and no parameters, the description adequately explains what the tool returns. It is complete enough for a simple snapshot tool, though it could optionally mention the output format or note that it is a combined call. The annotations cover safety, making this sufficient.

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

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

The tool has zero parameters, and the schema is empty with 100% coverage. Baseline for 0 params is 4, and the description does not need to explain parameters. No additional semantic value is required.

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 a full system snapshot' and explicitly lists the included components (CPU, RAM, GPU, disk, network, top processes). This distinguishes it from sibling tools like get_cpu_usage and get_ram_usage, which are individual metric getters.

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

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

The description implies use for a comprehensive overview but does not explicitly state when to prefer this over individual getter tools. No alternatives or exclusions are mentioned, so guidance is only implied by the 'full system snapshot' wording.

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 read-only and non-destructive behavior. The description adds valuable context beyond annotations: the dependency on nvidia-ml-py and NVIDIA hardware, and the fact that it returns an inline grouped bar chart. This gives the agent a better sense of prerequisites and output format without contradicting 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 that front-loads the core purpose, then adds dependency and output details. It is concise with no redundant information, making it easy 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 simple read-only tool with no parameters and no output schema, the description fully covers the necessary context: what is returned, the hardware/software requirements, and the format (chart). An agent can confidently invoke this tool based on this description alone.

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 schema is empty and description coverage is 100%. The baseline for no parameters is 4, and the description adds meaning by specifying what metrics are returned (load, VRAM, temperature), which is relevant context even without 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 what the tool does: returns GPU load, VRAM usage, and temperature. It uses a specific verb and resource, and the mention of GPU-specific metrics distinguishes it from sibling system monitoring tools like get_cpu_usage and get_ram_usage.

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 by naming GPU metrics, making it clear this is for GPU monitoring. However, it does not explicitly state when to use this tool instead of alternatives or mention any exclusions. The dependency note (requires nvidia-ml-py) gives a prerequisite but not explicit guidance on tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful context about what the tool returns, including 'live pressure' and 'overclocking capability (where supported),' which helps set expectations. It does not contradict annotations.

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

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

Two sentences, front-loaded with the main verb and resource, then a useful usage directive. No filler or redundant information. 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 tool is complex and has no output schema, but the description covers the key return categories and usage scenarios. It doesn't explain nuances like whether the profile is real-time or cached, but given the annotations and simple schema, it is sufficiently complete for an 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 parameter 'use_case' is fully described in the schema with examples. The description adds slight context by linking the parameter to user intents like upgrading or overclocking, but it doesn't substantially enrich beyond the schema. Baseline 3 applies.

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

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

The description clearly states the tool returns a 'full hardware profile' for a use-case, listing specific contents (specs, live pressure, overclocking capability, upgrade feasibility, bottleneck analysis). This distinguishes it from sibling tools like get_cpu_usage or get_device_specs, which cover narrower or different scopes.

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 when to use the tool: 'when the user asks about speeding up a specific task, upgrading their machine, or overclocking.' This gives clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't repeat safety traits. It adds context about data provenance (scheduled automations), but doesn't disclose behavior such as time ranges, empty results, or how many trends are summarized.

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 concise sentence that front-loads the verb and resource, with no wasted words. It efficiently conveys the tool's function and data source.

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 summarization tool with one optional parameter and good annotations, the description adequately explains the core purpose and data source. It doesn't describe the output format, but for this simple case it's reasonably complete.

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

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

The single 'limit' parameter is not mentioned in the description, and schema description coverage is 0%. With low coverage, the description should compensate but fails to explain what the limit applies to (e.g., number of data points, days). The schema's default/min/max help but don't fully clarify semantics.

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 'Summarize' and clearly identifies the resource as 'CPU, RAM, disk, and alert trends.' It also names the source data (scheduled get_full_snapshot or get_system_alerts automations), which distinguishes it from sibling tools that report real-time usage.

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 phrase 'captured by scheduled automations' implies this is for historical trend summaries rather than real-time queries, giving clear context relative to siblings like get_cpu_usage and get_ram_usage. It doesn't explicitly state when not to use it, but the intended scenario 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, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the specific data fields (local/remote addresses, status, owning process name), which is useful but does not reveal additional behavioral traits such as performance impact or permission requirements. This aligns with the calibration example where annotations cover safety and description adds some context.

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, well-structured sentence that immediately states what the tool returns with no filler. It is front-loaded and every word contributes 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?

For a zero-parameter read-only tool, the description covers the return contents clearly (connections, addresses, status, owning process). No output schema exists, but this description, combined with the safety annotations, is sufficient for an agent to know what to expect and when to use 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 has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 is appropriate for a no-parameter tool, as there is no additional meaning to provide beyond what the empty schema shows.

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

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

The description uses a specific verb ('Returns') and resource ('all active TCP/UDP connections') with details on addresses, status, and owning process. This clearly distinguishes it from sibling tools like get_network_usage, which focuses on bandwidth metrics.

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

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

The description implies usage for inspecting network connections and the returned fields make the tool's purpose clear. However, it does not explicitly mention when to use this tool over alternatives like get_network_usage or get_process_details, so it lacks explicit exclusions or alternative 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it reports byte counts and interface status, but does not clarify whether 'total' is since boot, session, or a cumulative counter, nor what interface status entails.

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 concise sentence that front-loads the purpose. No wasted words, easy to scan.

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 there is no output schema, the description does a decent job stating what is returned. However, 'total bytes' and 'interface status' are underspecified—could benefit from defining the time period or exact status values. Still, for a simple read-only getter, it's 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?

The tool has zero parameters, and the schema coverage is 100% (empty schema). Baseline for 0 parameters is 4; the description doesn't need to elaborate on 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 it returns total bytes sent/received and network interface status, using the specific verb 'returns' and a clear resource. This distinguishes it from sibling tools like get_network_connections (which covers connections) and network_latency_check (which covers latency).

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

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

No guidance is provided on when to use this tool versus alternatives like get_network_connections or network_latency_check. The description simply states what it does without implying a specific context or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds useful context about the return content but does not disclose potential edge cases such as behavior for nonexistent PIDs or permission requirements. This adds some value beyond annotations but lacks rich behavioral detail.

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, well-structured sentence that front-loads the main action and includes a concrete list of return fields. There is no filler or redundancy, making it highly concise and effective.

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 simple interface (one parameter, well-annotated as read-only) and the schema covering the only parameter, the description is nearly complete. It lists many return fields but uses 'and more' without enumerating everything, and there is no output schema to fill that gap. Minor incompleteness, but still sufficient for correct invocation.

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

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

Schema coverage is 100% for the single pid parameter, with a clear description including type, constraints, and source guidance. The tool description adds nothing beyond restating 'by PID'. Since the schema handles the parameter semantics completely, 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 returns detailed information about a specific process by PID, listing concrete details like executable path, command line, and memory breakdown. This distinguishes it from sibling tools like get_top_processes and search_process, which operate at a process-list level rather than a single process detail level.

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 main description does not explicitly state when to prefer this tool over alternatives. However, the input schema's pid parameter description notes to obtain the PID from get_top_processes or search_process, implying a sequential workflow. This is helpful but not an explicit 'use this tool when' guideline, so it remains implied rather than fully 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: it returns both RAM and swap metrics and includes a chart, which hints at visual formatting. It does not describe return structure or units, but the annotation coverage lowers the burden.

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

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

The description is a single, front-loaded sentence that wastes no words. It conveys the resource, the exact data points, and a visual feature in under 20 words, making it ideal for quick agent comprehension.

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, no-parameter, read-only tool, the description fully covers what the tool does and what it returns. No output schema exists, but the description lists the output contents (metrics and chart), making it self-sufficient. There are no missing operational prerequisites or complex edge cases to disclose.

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?

This tool has zero parameters, so the input schema is trivially complete (100% coverage). There are no parameter details to add; the description's mention of the metrics returned is additional context beyond parameter semantics. Baseline for 0 params is 4, and no further param info 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 a specific verb ('Returns') and resource ('RAM and swap memory usage'), including the exact metrics (total, used, available, percent) and a distinctive feature (inline stacked bar chart). It differentiates from sibling tools like get_cpu_usage and get_disk_usage by its resource focus.

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?

While no explicit 'when to use vs alternatives' is stated, the context is unambiguous: this tool is for RAM/swap information, and siblings cover other resources. For a simple read-only getter, the usage context is clear, though it stops short of explicitly naming alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate these. It adds valuable context about the sampling method (twice over an interval) and the output units, which aligns with the annotations and provides behavioral insight beyond 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 long, front-loaded with the core function and output, and every sentence earns its place. It includes usage guidance without any 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 tool's low complexity (one optional parameter), the description fully covers the return values (units for both disk and network), the measurement methodology, and the usage context. No output schema exists, so the detailed output description compensates adequately.

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 full coverage (100%) for the single parameter 'interval', including a description. The tool description adds the nuance that sampling occurs 'twice over an interval', which enriches understanding of the parameter's behavior, so it goes beyond the schema baseline.

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 with a specific verb ('Measures') and resource ('actual disk and network I/O throughput'). It explicitly differentiates from sibling tools by naming get_disk_usage and get_network_usage, 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 provides explicit guidance on when to use this tool vs. alternatives: 'Call this instead of get_disk_usage or get_network_usage when the user asks about current speed or throughput.' This clearly indicates the intended use case and excludes other scenarios.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds value by specifying exact scan locations on each OS (macOS LaunchAgents/Daemons, Windows Run keys, Linux autostart), which is useful context beyond annotations. It does not mention potential permission concerns or output structure, but the extra platform details are solid.

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, with the purpose stated first, then platform specifics, then usage guidance. Every sentence earns its place with no fluff or repetition.

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

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

For a parameterless read-only tool, the description covers purpose, platform locations, and usage context. It does not explicitly describe the return format, but given the tool's simplicity and the lack of an output schema, this is a minor gap rather than a critical omission.

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 baseline 4 applies. The description correctly focuses on the platform-specific scanning behavior instead of parameter explanations, which is appropriate for a no-parameter tool.

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

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

The description clearly states the tool's function with a specific verb ('Lists') and resource ('applications and services configured to launch automatically at startup/login'). It also provides platform-specific details, making it immediately distinguishable from sibling monitoring tools like get_cpu_usage or get_process_details.

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

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

Explicit usage guidance is given: 'Use when the user asks what runs at startup or wants to speed up boot times.' This tells the agent when to invoke the tool, but it does not mention alternatives or when not to use it, which prevents a perfect 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?

Annotations already cover read-only, idempotent, and non-destructive traits. The description adds value by disclosing that output is a prioritized list of critical/warning alerts and that it covers multiple metrics (CPU, RAM, swap, etc.), which is not implied by annotations alone.

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 and usage. Every word earns its place—no fluff, no repetition of the tool name, and it adds essential guidance without being verbose.

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 read-only tool with no output schema, the description is complete. It explains what it does, what it returns, and when to use it. No additional details about return format or edge cases are necessary for effective tool selection.

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

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

The tool has zero parameters, so the baseline for parameter semantics is 4. The description doesn't need to explain parameter usage, and the schema is empty with 100% coverage. It appropriately focuses on the tool's scope of metrics scanned.

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 scans all key system metrics and returns a prioritized list of critical/warning alerts. It uses specific verbs ('scans', 'returns') and differentiates itself from sibling tools like get_cpu_usage by acting as a general triage tool.

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

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

It explicitly says 'Call this first for general why is my machine slow? questions as a quick triage tool', which gives clear when-to-use context. It does not explicitly mention when not to use or name alternative specific metric tools, but the guidance is unambiguous enough.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is established. The description adds value by specifying what data is returned (uptime duration, boot time, load averages), which is transparent about the tool's output without contradicting 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, well-structured sentence that front-loads the verb and subject, then lists the three return components. Every word adds information, with 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 zero-parameter, read-only tool with no output schema, the description fully conveys what the tool does and what it returns. The listed components (running time, last boot time, load averages) are sufficient for an agent to invoke it correctly without further context.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it doesn't; it focuses on the return values instead, which is appropriate.

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

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

The description uses a specific verb 'Returns' with a clear resource (system uptime) and enumerates the exact data returned (running time, last boot time, load averages). This distinguishes it from sibling tools like get_cpu_usage and get_ram_usage, which target different metrics.

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

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

The description clearly communicates that this tool is for retrieving uptime and load average information, making its usage context obvious. It does not explicitly exclude alternatives or mention when not to use it, but for a simple read-only system metric tool, the context 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 already signal readOnly (readOnlyHint=true) and idempotent, but the description adds valuable behavioral detail beyond that: platform-specific behavior on macOS vs Linux/Windows, and the nature of returned data (groups with current, high, and critical thresholds). This goes beyond the annotations and helps set expectations.

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 purpose, then adds platform-specific nuances. Every sentence contributes meaning—no fluff, no redundancy with the schema or annotations.

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 low complexity (no params, no output schema, clear annotations), the description fully covers what the agent needs: what it returns, platform differences, and the threshold information. There are no significant gaps for a read-only monitoring tool.

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

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

The tool has zero parameters, so the schema covers everything trivially (100% coverage). Per the rubric, a baseline of 4 is appropriate since the description need not explain parameters that don't exist. The description focuses on behavior rather than irrelevant parameter details.

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's function: 'Returns CPU and motherboard temperature sensor readings.' The verb 'Returns' plus the specific resource (temperature sensors) makes the purpose unambiguous and distinguishes it from sibling tools like get_cpu_usage or get_gpu_usage.

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 implicitly conveys when to use the tool (for temperature readings) and explicitly notes platform limitations (macOS returns alternatives). However, it does not name any specific alternative tool or state explicit 'use this when / not when' guidance, leaving the agent to infer context from the sibling list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context about sorting by CPU or memory and the top-N concept, which goes beyond the annotations without contradicting them. It does not disclose return format, but that is low risk for a read-only query.

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

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

The description is a single sentence that is front-loaded with the core action and valuable details. It is concise with no unnecessary words 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?

For a low-complexity read-only query tool with full schema annotations and no output schema, the description is complete enough. It clearly conveys what the tool returns and the key options, and the annotations cover safety and idempotency. No additional context 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?

Schema description coverage is 100%, with each parameter (n and sort_by) fully documented including defaults and constraints. The description adds minimal extra meaning beyond the schema, essentially restating the sorting behavior. Baseline 3 is appropriate since schema carries the heavy lifting.

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

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

The description clearly states the tool returns the top N resource-hungry processes sorted by CPU or memory usage, which is specific and distinct from sibling tools like get_cpu_usage or get_ram_usage that report system-wide usage rather than per-process lists. It uses a specific verb ("Returns") and names the resource and sorting criteria.

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

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

The description implies usage for viewing top resource-consuming processes but does not explicitly mention alternatives or when not to use it. Given the sibling tools include get_process_details, search_process, and process_tree, the lack of explicit guidance leaves room for ambiguity, though the purpose is fairly 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 state readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers safety traits. The description adds valuable behavioral context beyond annotations: IP-based auto-detection of location and the inclusion of clothing suggestions, which are not inferable from 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 two sentences, front-loaded with the primary function, then adds location handling details. Every sentence contributes meaning without redundancy.

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

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

For a simple read-only weather tool with no output schema, the description adequately covers what the tool does, how location is determined, and what it returns (conditions and suggestions). No critical information is missing for 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?

The schema describes both parameters with 100% coverage, including the enum for units and the default behavior for location. The description adds examples (e.g., 'Tokyo' or 'London, UK') and reinforces the auto-detect aspect, providing extra clarity beyond the schema.

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

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

The description clearly states the tool 'returns current weather conditions and clothing suggestions,' using a specific verb and resource. It distinguishes itself from sibling tools like get_temperature_sensors (hardware temperature) by explicitly focusing on weather and clothing.

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 auto-detects location from IP if none is given, and instructs to pass a city name for a specific location. It does not explicitly rule out alternatives, but there are no weather-related sibling tools, making the context sufficient.

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

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

Annotations already indicate a safe read-only operation. The description adds useful behavioral detail: defaulting to unstaged changes, the staged flag, and file path scoping, which goes beyond the annotation hints.

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 concise, front-loaded sentences with no wasted words. Each sentence adds meaningful information: purpose, default mode, and optional scoping.

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 git command, the description is complete. Both parameters are covered, no output schema is needed, and annotations cover the safety profile. No gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra clarity by explaining the default for staged (false) and the meaning of path scoping, which enriches the parameter semantics beyond the schema's own descriptions.

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

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

The description clearly states the tool shows git diff output for a repository, with a specific verb and resource. It distinguishes from generic system tools but does not explicitly contrast with the sibling git_status, 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 explains the default behavior (unstaged changes) and how to switch to staged changes, plus path scoping. However, it does not provide explicit guidance on when to use this over git_status or other alternatives, only implying usage context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds valuable behavioral context by noting that it auto-detects the repo root and limits output to the 5 most recent commits. It does not detail error behavior (e.g., when not in a repo), but the annotation coverage lowers the bar, and the added context justifies a 4.

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, well-structured sentence with no redundancy. It front-loads the action and resource, then lists specific outputs, making it highly efficient and easy to parse.

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

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

The tool is simple, has good annotations, and no output schema. The description clearly states what the tool returns (branch, file states, commits) and adds the auto-detection behavior. There are no obvious gaps that would prevent an agent from using or understanding 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 description coverage is 100% for the single parameter 'path', which is fully described. The description adds no additional parameter semantics beyond what the schema already provides, 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 uses a specific verb 'Show' with a clear resource ('git repository status') and enumerates the exact contents: current branch, staged/unstaged/untracked files, and recent commits. This clearly distinguishes it from sibling tools like git_diff, which focuses on changes, and from system monitoring tools like get_cpu_usage.

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 implies its use case: checking the overall state of a git repository. It does not explicitly name alternatives or mention when not to use it, but the context is unambiguous given the sibling list and the direct phrasing. A score of 4 is appropriate because there is clear context but no explicit exclusions or alternative recommendations.

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 behavioral detail beyond the annotations: it searches recursively and skips .git, node_modules, .venv, and __pycache__ directories. Since annotations already declare read-only and non-destructive, this is valuable complementary context.

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 only two sentences, front-loaded with the action and examples. Each sentence provides necessary information—what the tool does and what it skips—with 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, read-only glob search tool, the description captures the primary use case, the recursive behavior, and directory exclusions. The schema fully documents parameters and annotations cover safety, making the definition complete for its 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 coverage is 100%, with both 'path' and 'pattern' already described. The description reinforces parameter meaning with examples and the phrase 'base path,' but does not add meaningful new semantic information beyond the schema, so it earns 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 it finds files matching a glob pattern, with concrete examples. The verb 'Find' plus resource 'files' and the pattern syntax distinguish it from content-search tools like grep_files, though it does not explicitly name alternatives.

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

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

The description conveys clear usage context: use this for locating files by path pattern, with recursion and base path behavior. It does not explicitly state when not to use it or mention alternative tools, so it lacks the explicit exclusions needed for 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?

Discloses that the tool writes a permission flag, which is a side effect not captured in the annotations. It also emphasizes the consent requirement, adding context about authorization. This is valuable transparency beyond the raw hints.

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

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

Two sentences, front-loaded with the main purpose, and directly followed by the critical usage constraint. Every sentence earns its place—no fluff or repetition.

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

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

For a zero-parameter, no-output-schema tool, this description is complete. It tells the agent what the tool does, when it may be called, what it does internally, and the resulting effect. No missing information is needed for correct and safe 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?

There are zero parameters, so the schema is trivially covered. The description adds nothing about parameters because none exist. Baseline for 0 params is 4, and the description provides no unnecessary 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 tool's purpose: granting the agent permission to control the user's browser. This is a specific verb+resource combination that distinguishes it from all sibling tools, which are either system monitoring, file operations, or browser actions themselves (e.g., browser_open_url).

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

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

Explicitly states the only condition for use: after the user has explicitly said yes/granted/allow. It also explains the consequence of use (subsequent browser_* calls will then work), giving clear when-to-use guidance and implying it should precede any browser_* calls.

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 (readOnly, idempotent, non-destructive), the description discloses important behavioral traits: skips binary files and common exclude directories (.git, node_modules, .venv, __pycache__). It also explains the output format (matching lines with paths and line numbers) and the context-lines option. This adds substantial behavioral context beyond 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 purposeful sentences: what it does, what it returns, and how it filters/excludes. Every sentence adds value and the most core information comes first. No fluff or repetition.

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

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

Given the annotations, a fully descriptive schema, and the absence of an output schema, the description is complete. It explains the search scope, return format, filtering, and skip behavior. Enough for an agent to select and invoke correctly without ambiguity.

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

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

The input schema already covers all five parameters with 100% description coverage, including defaults, ranges, and regex syntax. The description adds no extra parameter-specific meaning; it merely restates the glob and context-lines concepts already present in the schema. Per the baseline for high schema coverage, this scores a 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 'Search file contents for a regex pattern, like grep/ripgrep', naming the resource (file contents) and the verb (search). It also distinguishes itself from sibling file tools by specifying output (matching lines with file paths and line numbers) and filtering options. This is a specific, non-tautological purpose statement.

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 when to use the tool: searching file contents with regex, optionally filtering by glob and adding context lines. It does not explicitly name alternatives or state when not to use it, but the 'like grep/ripgrep' reference and included options provide strong usage guidance. No explicit exclusions, but the context is sufficient.

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

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

The annotations already mark destructiveHint=true, but the description goes far beyond by explaining the signal behavior (SIGTERM vs SIGKILL), the critical process safelist, and the user-confirmation requirement. This adds significant behavioral context that is not present in 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, each earning its place: purpose, signal behavior, and safety guardrails. Front-loaded with the core action, and no unnecessary verbiage.

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

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

For a two-parameter destructive tool with no output schema, the description covers purpose, method, safety restrictions, and required user consent. It is complete for an AI agent to understand invocation and constraints.

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 descriptions for both pid and force. The description reinforces the force semantics ('SIGKILL if force=True') but does not introduce new parameter-level details beyond the schema. The baseline of 3 applies.

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

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

The description opens with 'Terminates a process by PID', which is a specific verb+resource+method. It clearly distinguishes kill_process from sibling tools like get_process_details or process_tree, as it is the only one that performs termination.

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

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

Provides clear usage guidance: confirms with user before calling, defaults to SIGTERM, and refuses to kill critical system processes. It does not explicitly reference alternatives, but the context is sufficient 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?

Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds that results include 'names and descriptions' and clarifies that only 'available' sub-agents are listed, which is useful contextual detail beyond 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?

Two sentences, front-loaded with the primary purpose, followed by a specific usage directive. No waste 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 list tool with no params and no output schema, the description is complete: it states what is returned (names and descriptions), the scope (all available sub-agents), and when to use it. No further explanation is needed.

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 there is no parameter burden. Per rubric, baseline is 4, and the description appropriately omits parameter details, adding value through usage context instead.

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

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

The description clearly states 'List all available sub-agents with their names and descriptions'—a specific verb and resource. It distinguishes the tool from siblings like run_agent (execution) and list_skills (skills) by clarifying exactly what is listed.

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 instructs to 'Call this before run_agent if you are unsure which agent to delegate to,' providing a clear when-to-use scenario and naming the relevant sibling tool. This is direct, actionable guidance.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that it focuses on 'scheduled' runs and 'recent' results, but doesn't define 'recent' or describe the return format, so additional context is limited.

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 states the verb, object, and purpose without any redundancy. It is appropriately sized for the tool's simplicity.

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 conveys the tool's primary purpose but leaves out important context such as the return value structure (no output schema present) and the definition of 'recent'. It is adequate but not fully complete for agent decision-making.

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

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

The schema has 0% description coverage, and the description does not mention the 'limit' parameter at all. It fails to compensate for the lack of schema descriptions, despite the parameter being straightforward.

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 scheduled automation results, using a specific verb ('Return') and resource ('scheduled automation results'). It distinguishes from the sibling 'list_automations' (which likely lists automation definitions) by specifying 'runs' and 'scheduled'.

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 phrase 'for audit and diagnosis' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it falls short of the highest rating.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that automations are 'persisted' and that next run times are returned, but provides no extra side-effect, permission, or rate-limit context. With strong annotation coverage, this is adequate but not rich.

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 concise, front-loaded sentence with no redundant content. It clearly states the action, target, and what information is included.

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

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

With no output schema, the description partially explains return values by mentioning next run times. For a simple zero-parameter list operation with strong annotations, this is sufficient context, though it could be more explicit about the full list structure (e.g., IDs, names, schedules).

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, and the schema is empty with 100% coverage. Since there are no parameters, the description cannot add parameter semantics, and the 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 uses a specific verb 'List' with a clear resource ('persisted scheduled automations') and includes return details ('next run times'). It distinguishes itself from sibling list_automation_runs by focusing on automation definitions rather than run history.

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

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

The description implies usage for viewing all scheduled automations but provides no explicit when-to-use or when-not-to-use guidance. There is no mention of alternatives like list_automation_runs or relationship to create_automation, so the agent must infer context from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns 'latest connection state', which is a useful output detail, but it does not disclose any additional behavioral traits (e.g., network calls, freshness of state). With annotations present, this is adequate but not exceptional.

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 that immediately states the action and object. It is front-loaded, contains no filler, and every word contributes to the 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?

For a simple list tool with no parameters, robust annotations, and no output schema, the description is nearly complete. It specifies the resource and the kind of state returned, though it could optionally elaborate on the structure of the 'connection state' data, but this is not required for basic use.

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 input schema is empty and covers 100% of the inputs. Per the baseline for 0 params, the description need not add parameter details; however, it adds context about what is being listed (configuration and connection state), which is meaningful 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 states a specific verb ('List') and resource ('configured external MCP connectors') and adds 'their latest connection state' to clarify the scope. It clearly distinguishes from sibling tools like add_connector, remove_connector, and refresh_connectors, which are mutations.

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 as a read-only listing operation, but it does not explicitly state when to use it vs alternatives or mention that add/remove/refresh are for modifications. With sibling tools present, more explicit guidance would improve this.

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

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

Annotations already declare read-only and non-destructive behavior. The description adds a valuable permission requirement ('Requires allow_file_read in ~/.syscontrol/config.json') and lists the exact return fields, providing context beyond 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 and front-loaded with the primary action. It includes essential return fields, use case, and permission requirement without any redundant or irrelevant information.

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

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

For a simple tool with no required parameters and no output schema, the description covers return fields, permission needs, and a use case. It does not explicitly state that listing is non-recursive, which could be ambiguous, but sibling tools like search_files cover recursive cases, making this acceptable.

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 clear descriptions for both parameters (path defaults to home directory, show_hidden includes dotfiles). The description does not add parameter-specific detail, but the schema already handles it, 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's verb and resource ('List the contents of a directory') and specifies the returned fields. It is easily distinguished from sibling tools like read_file or search_files by its focus on directory browsing.

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 context: 'Use to browse the filesystem or verify file presence.' However, it does not mention when to use an alternative tool (e.g., search_files for recursive searches) or any exclusions, so it lacks full alternative guidance.

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