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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the output data points (title and app path) but does not disclose potential edge cases such as empty titles, permission failures, or platform-specific behavior. This is acceptable but not richly transparent.

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

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

A single, front-loaded sentence that states exactly what the tool returns with no filler or repetition. Every word contributes useful 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 zero-parameter, read-only tool, the description is complete: it names the resource ('focused window') and the output fields ('title and app path'). No output schema exists, but the description adequately covers what an agent will receive.

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 are no parameter semantics to explain. The description correctly requires no arguments, and the baseline for zero-parameter tools 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 ('Get') with a precise resource ('currently focused window') and names the returned data ('title and app path'). It is clearly distinct from sibling tools like minimize_window or close_window, which perform actions rather than report state.

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 when to use it: when the currently focused window's title or app path is needed. It doesn't explicitly name alternatives or exclusions, but for a simple read-only status tool, the intended usage 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 convey readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the description does not need to restate safety. It adds the 'available' qualifier, but does not mention what the returned list contains (e.g., names, IDs, default device) or whether it includes both sinks and sources in a single merged list or separate structures. This leaves some behavioral ambiguity 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 entire description is a single compact sentence that front-loads the action ('List') and the object ('available audio sinks and sources'). There is no filler, repetition, or extraneous information.

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

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

For a zero-parameter, read-only list tool, the description states enough to invoke the tool correctly. However, since there is no output schema, the lack of any detail about the returned structure (field names, whether it's a combined list, how to identify devices) is a small gap. The openWorldHint suggests the output may vary, but the description adds no guidance there.

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 zero propertieston, so there are no parameter semantics to clarify. The description's brevity is appropriate; no parameter information could add value here, and the baseline of 4 is justified.

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') and a precise resource ('available audio sinks and sources'), making it clear what the tool does. It naturally distinguishes itself from siblings like get_volume, set_output_device, and mute_audio by referring to the enumeration of sink/source endpoints rather than volume or device selection.

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 a use case (listing devices before selecting an output with set_output_device) but does not explicitly state when to use it versus alternatives, and it offers no exclusion criteria. For a simple list operation, the usage context is reasonably obvious, but the description itself provides no direct 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 description adds the context that this is a 'simple notification beep' rather than media playback, which is useful beyond the raw annotations. However, it does not disclose details like volume dependence, return behavior, or what happens if no audio device is available. Annotations already indicate side effects (readOnlyHint=false), so the bar is lower.

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 filler. Every word contributes to understanding the tool's purpose.

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

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

For a zero-parameter utility that plays a beep, the description is essentially complete. It does not describe the return value or failure modes, but given the trivial nature of the tool and the annotations covering side-effect behavior, no critical information is missing.

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

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

With zero parameters and a fully covered empty schema, the description does not need to explain parameter meanings. The baseline for no parameters is 4, and the description adds no unnecessary param 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?

The description clearly states the action ('play') and resource ('a simple notification beep sound'), which is specific enough to distinguish it from audio-related siblings like set_volume, mute_audio, and search_and_play. It conveys exactly what the tool does without ambiguity.

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

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

No guidance is provided about when to use this tool versus alternatives such as send_notification or audio playback tools. The description implies basic usage but does not state any context, prerequisites, 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 convey the mutation profile (readOnlyHint=false, idempotentHint=false), so the description carries a lighter burden. It adds the scheduled-task scope but does not explain effects on a running task, whether the schedule entry is removed, or error behavior; no contradiction with annotations.

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

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

One short, front-loaded sentence with no filler. Every word earns its place.

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

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

For a simple one-parameter cancellation tool, the core call is clear, and annotations cover the safety profile. However, the description omits expected behavior after cancellation and source of task_id, leaving minor but real gaps for an agent.

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

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

With 0% schema description coverage, the description must compensate. It does tie the single task_id parameter to 'a scheduled task,' but it does not say where the ID comes from or what format it uses. The parameter name itself is self-explanatory enough to make this minimally viable.

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 ('Cancel') and resource ('a scheduled task'), making the operation immediately clear. It is semantically distinct from sibling tools like schedule_job, list_jobs, and run_job_now without needing to inspect their schemas.

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 context of a task being scheduled implies when to use the tool, but the description gives no explicit guidance on prerequisites or alternatives. It does not tell an agent to use list_jobs to find the task_id or mention differences from run_job_now, leaving usage to inference.

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?

Even though annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the description adds valuable behavioral context: it reads configuration from .env and requires no caller-supplied email. This external dependency and the absence of parameters go beyond what annotations alone convey.

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 tightly written sentences deliver all essential information: what is checked, the source of the email, and the absence of required input. There is no filler, and the most actionable detail (no email input needed) is front-loaded.

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

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

For a zero-parameter, read-only status tool with no output schema, the description is complete. It enumerates the status components returned and removes ambiguity about input and configuration source, so an agent can call it correctly without further investigation.

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

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

With zero parameters, the baseline is already 4, and the description exceeds it by explicitly addressing why no email parameter exists and where the recipient email comes from (RECIPIENT_EMAIL in .env). This prevents an agent from inventing or expecting an email 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 names a specific verb ('Check'), a clear resource ('the monitoring system status'), and the concrete facts it returns: spike alert and daily summary scheduling, today's alerts, and the configured recipient email. This is more specific than any sibling tool and establishes a distinct identity.

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

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

The description clearly states that no email input is needed because RECIPIENT_EMAIL is read from .env, which is useful usage context. However, it does not explicitly say when to prefer this tool over related tools like send_test_spike_alert, send_daily_summary_now, or check_vnstat_status; usage guidance is only 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is well covered. The description adds supported package managers but does not disclose the result format, behavior for unknown packages, or how the manager is selected. 'Check whether' implies a boolean result but it is not explicit.

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

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

The description is a single short sentence with a helpful parenthetical listing supported package managers. It is front-loaded with the action and target, and contains no filler or redundant content.

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

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

For a simple, single-parameter, read-only check with strong annotations the description is mostly sufficient, and naming supported managers adds useful context. However, with no output schema it does not explicitly state the return type or behavior when the package is not installed, leaving some ambiguity. A brief note on the expected result would make it fully complete.

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

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

The schema has 0% description coverage and only a required string 'name'. The description implies that 'name' is a package name and hints at package managers, which partially compensates for the missing schema description. It does not specify format, case sensitivity, or which package manager is used for a given system.

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 ('Check whether') and target resource ('a package is installed'), and lists supported package managers (apt/dnf/pacman), making the purpose unambiguous. It does not explicitly differentiate from siblings like list_installed_applications or check_updates, though the intent is distinct.

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

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

No explicit guidance is provided on when to use this tool versus alternatives. Siblings such as list_installed_applications and check_updates exist, but the description does not mention them or state when this tool is preferred. Usage is only implied by the name and verb.

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 non-destructive behavior, so the bar is lower. The description adds value by stating the output: 'Returns PID, process name, and command line.' It does not cover edge cases like an unoccupied port or permission restrictions, but the safety profile is fully covered by annotations.

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

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

Three sentences, each earning its place: purpose, usage trigger, and return value. The example is embedded efficiently. 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 one-parameter read-only tool with strong annotations, the description covers what it does, when to use it, and what it returns. The main missing piece is behavior when nothing is listening on the port, but this is a minor gap and likely inferable from the operation.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that the port is a TCP port and gives a concrete example (8765). For a single integer parameter, this is sufficient practical guidance, though it does not specify valid ranges or behavior on invalid input.

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 opens with 'Find what process is listening on a TCP port on this machine,' naming a specific verb, resource, and scope. It clearly distinguishes itself from network connectivity tools like ping_host and process tools like list_processes, and includes a concrete example (Vela API port 8765).

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

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

The description provides explicit usage triggers: 'when the user asks what service/app uses a port, what's on port X, or if a port is open.' It stops short of naming alternative tools or exclusion criteria, but the use cases are concrete enough for an agent to route correctly.

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, covering the safety profile. The description adds no further behavioral context (e.g., network dependence, return format), relying entirely on annotations. Since annotations carry the burden, the description meets the baseline but adds nothing extra.

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, front-loaded sentence with no redundancy. It communicates the core purpose efficiently without extra 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 no-parameter, read-only tool with robust annotations, the description covers the essential purpose. The only gap is the unspecified return format (e.g., boolean, list), but this is minor for such a simple check operation.

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

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

There are zero parameters, so the description has nothing to explain beyond the tool's purpose. The schema is empty and the description correctly states the operation without needing 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?

The description states a specific verb ('Check') and resource ('system updates'), clearly distinguishing it from the sibling tool 'run_update' which applies updates. The name reinforces the action, making the tool's intent 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?

Usage context is implied by the name and the presence of 'run_update' as a sibling, but the description does not explicitly state when to check vs. apply updates. An agent could infer it, but no direct guidance is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful detail about what the tool checks (installation, version, interfaces) but does not describe output format or behavior when vnstat is absent. This is consistent with annotations, so 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?

A single, clear, front-loaded sentence conveys the full purpose and output scope with no filler or repetition. Every element earns its place.

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

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

For a zero-parameter, read-only status check with no output schema, the description is sufficiently complete: it names all three pieces of information the agent can expect. Annotations cover side-effect safety, and no further prerequisites or return-value details are necessary 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?

The tool has zero parameters, so the description does not need to explain argument semantics. Baseline for 0 parameters is 4, and there is no missing parameter-level information.

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

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

The description uses a specific verb ('Check') and clearly identifies the resource (vnstat) plus the exact information returned: installation status, version, and monitored network interfaces. This distinguishes it from related tools like get_vnstat_data, which would focus on traffic data rather than 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?

The description implies use when you need vnstat installation/version/interface status, but it provides no explicit guidance about when to prefer this tool over alternatives such as check_package_installed or get_vnstat_data. There are no exclusions or conditions stated.

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 establish that this is not read-only and not idempotent; the description adds the concrete target directories, which is useful. However, it does not disclose whether the directories are emptied recursively, whether running applications are affected, or what the result looks like, leaving some behavioral ambiguity.

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

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

The description is a single short sentence with no filler. It is front-loaded with the action and immediately identifies the affected paths.

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-argument maintenance operation with annotations covering the safety profile, the description covers the essential information: what is cleared. It does not specify current-user vs. all-user cache scope or the return value, but those are minor gaps for this simple tool.

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

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

The tool has zero parameters and schema coverage is 100%, so there is no parameter documentation burden. The description adds no parameter-level detail, but none is needed; the baseline for a no-parameter tool is a 4.

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

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

The description names a specific verb ('Clear') and specific resources ('/tmp and user cache directories'), so an agent can tell what the tool targets. It is slightly less crisp than a full sentence with intended effect, but it is not a tautology and does not overlap ambiguously with delete_path in the sibling list.

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

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

There is no guidance about when to call clear_cache instead of related tools such as delete_path or clear_clipboard. The description implies the use case for freeing temporary storage but never states it, and no exclusions or alternatives are mentioned.

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

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

Annotations already declare readOnlyHint=false, indicating a mutation, so the description adds no new behavioral information beyond what the name implies. It does not disclose whether clearing is irreversible, whether it affects clipboard history, or any side effects. Since the description adds no context beyond the structured fields, it scores low.

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, direct sentence with no wasted words. It is front-loaded and appropriately sized for a zero-parameter tool that performs one simple action.

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

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

Given the tool's simplicity (no parameters, no output schema) and the annotations covering safety, the description is largely sufficient. It doesn't explain return values or side effects, but for a straightforward clipboard clear operation, nothing else an agent needs to call it correctly is missing.

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

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

The tool has zero parameters and the schema fully covers this (100% coverage). The baseline of 4 applies because there are no parameters to document; the description appropriately has nothing to add.

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 ('clear') and resource ('clipboard contents'), and clearly distinguishes itself from sibling tools like read_clipboard and write_clipboard by indicating a mutating action that empties the clipboard. Even without referring to alternatives, the purpose is unambiguous and differentiated.

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 no guidance on when to use this tool versus alternatives. It does not mention that read_clipboard is for retrieving contents or write_clipboard for setting them, nor does it state any prerequisites or conditions. The agent must infer usage solely from the tool 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 signal a mutating, non-idempotent operation, so the description's main added value is the scope: all desktop notifications are affected. This tells the agent the blast radius. It does not disclose whether the clear is permanent, whether it clears only the current user's session, or what happens if there are no notifications, but the annotations lower the bar for additional 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 a single focused sentence with no filler or repetition. It is front-loaded with the verb and resource and every word earns its place. It is an exemplary model of concise tool description.

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

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

For a zero-parameter tool with no output schema, the core operation is sufficiently stated. Minor ambiguities remain, such as whether 'desktop notifications' means all operating-system notifications or only notifications from this app, and what the tool returns on success. These are small gaps for such a simple mutation, so the description is nearly 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?

There are zero parameters and schema coverage is 100%, so the schema already fully defines the input surface. The description adds no parameter-level detail, but none is needed. The baseline of 4 applies.

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

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

The description uses a specific verb, 'Clear,' with a clear resource, 'all desktop notifications.' It unambiguously distinguishes this tool from siblings like send_notification, read_notifications, and list_notifications, which create, read, or list rather than clear. The intent is immediately obvious.

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 no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It does not mention that read_notifications or list_notifications would be better for inspecting notifications first, nor whether clearing only affects this app's notifications or all system notifications. Usage context is only implied by the name and phrasing.

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 indicate non-read-only and non-destructive, and the description adds context about how the application is identified (by exec binary and process name) and that it uses friendly names. It doesn't disclose potential side effects like unsaved data loss, but given annotations, the extra detail is adequate.

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

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

Two sentences, front-loaded with the core action, and no filler. The naming resolution reference is efficient and relevant.

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

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

For a one-parameter tool with no output schema, the description covers identification and matching. It could mention behavior when the app isn't running or multiple instances, but that's a minor gap.

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

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

With 0% schema coverage, the description fully explains the 'name' parameter by stating it accepts friendly names and .desktop resolution, with examples 'Chrome' and 'firefox', and clarifies the matching logic. This compensates for the missing schema documentation.

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

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

The description clearly states it closes a desktop/GUI application, distinguishing it from process-killing tools by specifying its scope and naming resolution. It also mentions matching by exec binary and process name, making its purpose unambiguous.

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

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

It references open_application for name resolution, implying a similar usage pattern, but it does not explicitly compare to alternatives like kill_process or close_window, nor does it state when to prefer this over them. The guidance is implicit 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?

The description adds no behavioral context beyond the annotations already declaring this is not read-only and not idempotent. It does not disclose whether closing is graceful or forced, whether unsaved changes are at risk, or whether the action is reversible. No annotation contradiction exists.

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

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

A single, front-loaded sentence with no filler. Every word contributes to the tool's purpose and required parameter.

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

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

For a one-parameter tool, the description is minimally viable: it names the action and the required input. However, with no output schema, it does not explain what the tool returns or how success/failure is reported, and it leaves the agent to infer prerequisites like how to obtain a valid window ID.

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. Saying 'by window ID' confirms that window_id selects the target window, but it repeats essentially what the parameter title already implies and offers no format, source, or acquisition guidance.

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

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

Description states a specific verb ('Close'), a specific resource ('a window'), and the key identifier ('by window ID'). This clearly distinguishes it from sibling tools like close_application, minimize_window, and active_window.

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

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

No guidance is given on when to use this tool vs alternatives, nor does it mention that a window ID must already be known or obtained (e.g., via active_window). The description implies the need for a window ID but provides no routing or prerequisite information.

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 description need not re-state the safety profile. It adds the Docker Compose project scope, but it does not disclose whether the result includes service statuses, how the project is resolved, or any other behavioral details 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 with no filler: the verb, object, and scope appear immediately. It is easy to scan and every word earns its place, even though other dimensions penalize the omitted 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 simple read-only tool with rich safety annotations, the one-line description is minimally viable, but it leaves out how the two optional parameters map to a specific compose project and what the returned list contains. Without an output schema, the description should at least clarify the return shape or parameter selection to be fully complete.

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

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

Schema description coverage is 0%, and the description does not explain the difference between `project` and `project_directory` or what values they accept. The property names are somewhat self-explanatory, but the description fails to compensate for the complete lack of schema-level guidance.

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 'List' and identifies the resource as 'services from a Docker Compose project,' so an agent knows exactly what the tool acts on. It is clear and distinct enough by resource type, though it does not explicitly differentiate itself from sibling tools like list_services or get_service_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?

The description provides no guidance on when to prefer compose_status over sibling tools such as list_services, get_service_status, or list_docker_containers. The 'Docker Compose project' qualifier implies a use case, but there are no explicit exclusions or alternative routing cues.

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, but the description adds no behavioral context beyond the action itself. It does not mention side effects such as disconnecting from an existing network, whether the connection persists, or what happens on failure. The description neither contradicts nor meaningfully extends the annotation information.

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

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

The description is concise and front-loaded, with no wasted words. However, it is under-specified relative to the tool's needs; brevity here comes at the cost of omitting parameter and usage guidance. It is not excessively verbose, but it is not appropriately sized for a tool with behavioral and parameter complexities.

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

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

Given the lack of output schema, 0% parameter coverage, and the presence of WiFi-related siblings, the description is incomplete. An agent knows this tool connects to WiFi but lacks the context needed to invoke it correctly, such as required versus optional parameters and how the operation interacts with the current network state. The description is minimally viable but leaves meaningful gaps.

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

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

With 0% schema description coverage, the description needed to explain parameter behavior, but it says nothing about ssid or password. The schema only provides names and types, leaving critical semantics undocumented, such as whether password is required for secured networks, whether null is acceptable for open networks, or what values ssid should take. This is a significant gap for a tool that is unusable without understanding 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 states a specific verb and resource: 'Connect to a WiFi network.' This clearly identifies the primary action and is immediately distinguishable from sibling commands like list_wifi_networks, disconnect_wifi, and get_wifi_status. It lacks detail about scope or behavior, but the core purpose is 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 offers no guidance on when to use this tool versus alternatives such as toggle_wifi or list_wifi_networks. It does not mention prerequisites like WiFi being enabled, how to discover SSIDs, or when disconnect_wifi would be more appropriate. Usage context is entirely left to inference.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds the contextual notion that the count reflects tools 'available on this host,' which is useful but not deeply behavioral. No contradictions exist.

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 short sentences with no filler. The core action is stated first, and the usage trigger follows immediately. Every word earns its place.

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

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

For a zero-parameter, simple counting tool with rich annotations, the description is fully complete. The absence of an output schema does not hurt because the expected return is naturally a count, and no additional context is required 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?

The tool has zero parameters, so there is nothing for the description to add about parameter meaning. The schema coverage is effectively total, and the description's framing of counting available tools is sufficient for invocation.

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 ('Count') with a clear resource ('assistant tools available on this host'), making its function immediately obvious. It also differentiates itself from sibling tools like list_tools by focusing on the count rather than enumeration.

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

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

The description explicitly states when to use the tool: 'Use when the user asks how many tools/capabilities/commands you have, or how many things you can do.' It does not mention alternatives or exclusions, but for this simple counting use case, the guidance is clear and 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 declare destructiveHint=true and readOnlyHint=false, so the description adds no behavioral context beyond what is structured. It does not mention irreversibility, recursive deletion of directories, or potential side effects, which would be valuable for a destructive 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?

A single sentence with no filler, front-loaded with the core action. Every word earns its place, and the description 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?

For a destructive filesystem operation with no output schema and one parameter, the description omits important operational details such as whether directory deletion is recursive, whether files are permanently deleted or moved to trash, and any permission requirements. The annotations cover only the destructive flag, leaving the description incomplete for 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?

With schema description coverage at 0%, the description must compensate for the undocumented 'path' parameter. It only clarifies that path refers to a file or directory, which is minimal and does not explain path format, wildcards, or scope. The added meaning is thin.

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 ('Delete') and resource ('file or directory'), making the tool's purpose immediately clear. It is distinguishable from sibling tools like rename_path, open_path, and make_directory without needing to inspect schemas.

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 about when to use this tool versus alternatives, nor any exclusions or warnings. The description only states what it does, leaving the agent to infer usage context from the tool name and siblings.

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 a mutating readOnlyHint=false, non-idempotent, non-destructive operation, so the description does not need to restate those. It adds the specific target ('default microphone source') but does not disclose side effects, persistence, permissions, or failure behavior beyond the bare action.

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, front-loaded sentence conveys the action and target with no filler. Every word earns its place, and the description is appropriately sized for the tool's trivial parameter surface.

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

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

Given the tool has no parameters, a simple action, and annotations covering mutation and destructiveness, the description is nearly complete for calling the tool correctly. It lacks explicit return-value or unmount/mute-undo guidance, and the absence of usage alternatives is a minor gap, but nothing essential for invoking a parameterless mute action is missing.

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

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

The tool has zero parameters, so the description cannot add parameter meaning and the schema needs no supplementation. This is the baseline case where no parameter documentation 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 uses a specific verb ('Mute') and resource ('default microphone source'), making the tool's core function clear. It is distinct from broad audio tools like 'mute_audio' because it explicitly targets the microphone, though it does not explicitly contrast itself with that sibling.

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

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

The description gives no guidance on when to use this tool versus alternatives such as 'mute_audio' or how to undo the action via 'enable_mic'. It states only the action itself, leaving the agent to infer appropriate usage.

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

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

Annotations already signal a non-read-only, non-idempotent, open-world operation. The description adds meaningful context by explaining the mechanism—unloading the kernel module—which implies a system-wide hardware disable rather than a user-level software toggle. It does not mention privilege requirements or re-enablement, but this is not contradicted by annotations.

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

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

A single, front-loaded sentence conveys both the action and mechanism with no redundant words or filler.

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

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

For a parameterless mutation with no output schema, the description provides the core behavior and mechanism. It could note expected output or prerequisites such as root privileges, but the low complexity and clear sibling context make that a minor gap.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameter meaning. The mechanism statement helps explain why no parameters are needed: the action applies to the whole device webcam.

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 names a specific action ('Disable'), a clear resource ('the webcam'), and the mechanism ('unloading the kernel module'). This makes it immediately distinguishable from sibling tools like enable_webcam and webcam_snapshot.

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

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

The description implies the tool should be used whenever the webcam needs to be disabled, but it provides no explicit when-to-use conditions, exclusions, or alternatives. The intended context must be inferred from the verb and 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 state readOnlyHint=false, so the write nature is known. The description adds that the operation targets the current network, but it does not disclose side effects such as whether the WiFi adapter remains on, whether the network profile is forgotten, or whether a no-op error occurs. This is a small gap given annotations cover the overall safety profile.

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

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

The description is a single sentence with no wasted words and the main action appears first. It is appropriately terse for a parameterless operation.

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

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

For a zero-parameter tool, the description is minimally viable, but it lacks context about success output, already-disconnected behavior, and the distinction from toggle_wifi. Since there is no output schema to describe return values, the description would need to carry that information; it does not.

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

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

There are zero parameters and schema coverage is 100%, so there is nothing for the description to add semantically. The baseline of 4 for parameterless tools applies because the tool is correctly callable without further field explanations.

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 direct verb and a specific resource: disconnecting from the current WiFi network. It is distinct from siblings like connect_wifi and toggle_wifi, although it does not explicitly name those alternatives. The phrase 'current WiFi network' narrows the scope sufficiently.

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 about when to choose disconnect_wifi over connect_wifi, toggle_wifi, or list_wifi_networks. The description does not state that it leaves the WiFi radio enabled or what happens if already disconnected. Agents must infer usage from 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?

The annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description does not contradict them. It adds a useful behavioral detail—the response is an MP4 returned as base64—but otherwise reveals no constraints like maximum duration, resolution, or whether audio is captured.

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

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

One sentence with no filler; the essential action and return type are front-loaded. Every word earns its place.

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

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

For a one-parameter tool the core is present—what to do and what will come back—but missing parameter semantics and the vague 'short' upper bound leave gaps. There is no output schema to fill in return details, though the description does state MP4/base64.

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

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

Schema description coverage is 0% and the description never names or explains duration_seconds. The 'short' qualifier implies small values and the parameter name self-documents seconds, but there are no bounds, constraints, or additional semantics added by the description.

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

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

Names the action ('Record'), the resource ('screen clip'), and the exact return format ('MP4 as base64'). The verb is specific enough to distinguish from static-capture siblings like display_screenshot or get_snapshot.

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 no explicit when-to-use guidance or alternatives. It is possible to infer that this is for short video rather than still images, but no condition, exclusion, or alternative is stated, so agents must decide without support.

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 read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail: it uses flameshot, saves to ~/Pictures, compresses for relay, and informs the AI model only of success while delivering image data separately. This goes beyond the annotations without contradicting them.

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

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

Two focused sentences with no filler. The core action and delivery model are front-loaded, and every clause adds useful 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 parameterless tool with no output schema, the description covers what is captured, how it is delivered, and what the AI model will perceive. Nothing essential is missing for an agent to invoke it correctly.

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

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

The tool has zero parameters and the input schema is empty, so there is no parameter ambiguity to resolve. The description correctly implies no inputs are required, meeting the baseline for a parameterless 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 states a specific verb (capture), resource (current screen), and mechanism (flameshot to ~/Pictures), plus a clear delivery channel (base64 to client, separate from model confirmation). It is clearly distinct from sibling operations like webcam_snapshot or display_record.

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 the tool is for capturing the current screen, but it does not explicitly state when to choose this over alternatives such as get_snapshot or display_record. It provides functional context rather than explicit routing 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?

Goes well beyond the readOnlyHint/idempotentHint annotations by disclosing that images are shown in the UI rather than to the AI model, that the agent only receives a success confirmation with path/size, and that oversized files are rejected with size details. The retry prohibition is also behaviorally valuable.

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, each earning its place: purpose, UI-delivery behavior, size-limit rejection rule, and usage boundary. Front-loaded with the core action, 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?

Complete for a single-parameter tool with rich annotations. The description covers what the tool does, what the agent sees, how failures behave, and when to use it. No output schema is present, but the confirmation/rejection details are spelled out in prose.

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 adds meaning by framing 'path' as a file on the local filesystem and by referencing 'the same path' and 'path/size' in the confirmation output. It does not explicitly define path format (e.g., absolute vs relative), but for a single string parameter this is adequate.

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

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

The description opens with a specific verb and resource: downloads a file from the local filesystem and sends it to the UI. It distinguishes itself from siblings like upload_file (direction of transfer) and from content-reading tools by explicitly stating it is 'not for reading file contents yourself.'

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

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

Gives explicit when conditions ('transferring a file the user asked to see or receive') and when-not conditions ('not for reading file contents yourself'). Also provides a concrete operational rule: do not retry the same path after a size-limit rejection. While it does not name a specific alternative sibling, the context clearly routes the agent.

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 that this is a mutating, non-idempotent action with no destructive hint, so the description does not need to repeat that. The description adds only that it targets the default source; it does not disclose behaviors like whether it will fail if no microphone exists or what happens if already unmuted.

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, direct sentence with no filler or redundant terms. All words add meaning and the action is front-loaded.

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

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

For a zero-parameter action tool with annotations covering safety and mutation, this description is largely sufficient. It lacks only an explicit note about return value or error conditions, but the simplicity of the tool makes that a minor gap.

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

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

There are no parameters and the schema is fully covered, so the baseline is strong. The description's mention of 'default' provides the only selection context relevant to a zero-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 states a specific verb ('Unmute') and a specific resource ('the default microphone source'), making the action unambiguous. It is clearly distinguishable from sibling tools like mute_audio or disable_mic because it targets the microphone rather than speakers or hardware disable state.

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 clear: invoke when the user wants to unmute the default microphone. However, it does not explicitly contrast with alternatives such as mute_audio, disable_mic, or set_volume, nor does it 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 indicate this is a mutating, non-idempotent action, and the description adds the specific mechanism of loading a kernel module. It does not mention possible side effects, permission requirements, or failure conditions, but the annotations cover the basic behavioral profile.

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, direct sentence that immediately conveys the action and mechanism without wasted words. It is perfectly 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?

For a zero-parameter tool with simple semantics, this description is nearly complete: it states what happens and how. It could mention prerequisites like driver availability or permissions, but nothing essential is missing for basic 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 tool has zero parameters, so there is no parameter ambiguity to clarify. The baseline of 4 applies because the description does not need to compensate for schema gaps.

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 ('enable') and resource ('the webcam'), and clarifies the mechanism ('loading the kernel module'). This clearly distinguishes it from siblings like disable_webcam and webcam_snapshot.

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 implied: call this when the webcam needs to be enabled. However, it gives no explicit guidance on when not to use it, prerequisites, or how it compares to related webcam tools.

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

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

Annotations already indicate this is a mutating action (readOnlyHint=false), and the description adds valuable behavioral context: a non-empty reason is required and a confirmation gate applies. It also explains the consequence ('gates their site/API'). No contradiction with annotations. Could go further by noting reversibility or side effects, but the key behaviors are disclosed.

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, each adding new information: the action and effect, the required parameters, and the confirmation gate. No filler or redundancy. 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 simple mutation tool with two scalar parameters and no output schema, the description covers the core action, prerequisites, and confirmation behavior. However, it omits details like whether the action is reversible (via unblock), what happens to existing site access, or expected response. Given the low complexity and sibling context, it's adequate but not fully complete.

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

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

The input schema has zero description coverage for the two parameters. The description only states that slug is required and reason must be non-empty; it does not explain what a slug is or how to obtain it, nor what the reason should contain. This is insufficient compensation for the 0% schema coverage.

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

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

States a specific action ('block'), the resource ('Gatekeeper client project'), and the effect ('gates their site/API'). This is distinct from sibling tools like gatekeeper_unblock_project, gatekeeper_delete_project, and gatekeeper_update_project, so an agent can quickly identify what this tool does.

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

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

Gives clear context: it is a manual block action requiring a slug and non-empty reason, with a confirmation gate. However, it does not explicitly state when not to use it or mention alternatives like gatekeeper_unblock_project for reversal. Still, the context is clear enough to infer its purpose relative to siblings.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the domain-specific semantic but does not disclose additional behavioral context such as whether a network lookup is performed, what response is expected, or edge cases like invalid domains. It is not misleading, but adds little beyond the annotations and tool name.

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

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

The description is a single, clear, front-loaded sentence with no filler words. It is appropriately sized for a simple check tool 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?

With no output schema, the agent is left without any indication of what the tool returns: a boolean, a status string, certificate details, or an error object. The description also does not mention whether 'installed' means locally configured, publicly valid, or resolvable via DNS. For a status-checking tool, this missing output information is a significant gap.

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

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

Schema description coverage is 0%, so the description must compensate, but it only tells the agent that the check is 'for a domain'. It does not clarify expected format (e.g., bare domain, with protocol, www vs non-www), whether IP addresses are accepted, or how the domain argument affects the certificate lookup. The schema already labels the parameter as 'Domain', so the description adds almost no semantic value.

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

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

The description states a specific action ('Check whether') on a specific resource ('an SSL certificate') scoped to 'a domain'. This cleanly distinguishes it from sibling tools like gatekeeper_install_certificate, gatekeeper_remove_certificate, and gatekeeper_list_certificates, since it focuses on existence/status for one domain rather than management or listing.

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

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

The description implies use is appropriate when verifying whether a domain has a certificate installed, but it does not explicitly mention alternatives or when not to use it. No direct reference is made to gatekeeper_list_certificates or gatekeeper_install_certificate, so the guidance is implied rather than stated.

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

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

The annotations already declare readOnlyHint=true and idempotentHint=true, covering the safe, side-effect-free nature of the tool. The description adds that the check is against the local image store, which clarifies it won't contact remote registries. It does not describe the response/return format or what happens when an image is absent, so there is a small gap.

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

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

The description is a single, front-loaded sentence that wastes no words. The 'Wizard helper' prefix is slightly redundant but adds context. 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?

For a one-parameter read-only check with rich annotations, the description is largely complete: it states what it checks and when to use it. The main missing piece is the format of the image parameter, which the schema also fails to document. Overall it provides enough for an agent to invoke it correctly within the wizard flow.

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 explain the 'image' parameter, but it only restates the parameter name. It does not specify whether 'image' is a name, ID, tag, or registry path, or provide format examples. This is a meaningful gap for an agent selecting the correct value.

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

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

The description uses a specific verb ('check') and resource ('whether an image is available locally') and ties it to a clear purpose ('before attempting container creation'). It clearly distinguishes from sibling tools like gatekeeper_pull_image and gatekeeper_delete_image because it only checks availability rather than modifying images.

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 states when to use it: before attempting container creation, which is a clear usage context. It does not explicitly name alternatives or when not to use it, but the 'before container creation' phrase implies a preflight role. It does not mention when to pull first, so it is not full 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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the domain scope ('networks + internal network info') but does not detail return structure or potential variations, which is acceptable given the annotation coverage.

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

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

The description is a single, compact sentence with every phrase adding value: 'Wizard helper' gives usage context, and the parenthetical specifies the fetched data. There is no fluff or redundancy.

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

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

For a zero-parameter, read-only helper with rich annotations, this description is sufficient. It names the two main output categories and the wizard context, so an agent knows what it will receive and why to call it, even without 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 tool has zero parameters and the input schema is empty, so there are no parameter semantics for the description to explain. This matches the baseline for a parameterless tool; no further clarification 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?

Description states a specific action ('fetch') and a specific resource ('Docker container-creation context'), and further narrows scope to 'networks + internal network info.' This clearly distinguishes it from wizard validation/port-check siblings and from generic network listing 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 phrase 'Wizard helper' clearly situates this tool as a context-gathering step in the container-creation wizard flow. It does not explicitly list exclusions or alternatives, but the intended usage context is evident from the description and tool 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, so the safety profile is well covered. The description adds specific context about checking Docker-host port occupancy, but does not reveal deeper behavior such as whether it inspects containers, listeners, or kernel sockets. No contradiction is present.

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

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

The description is a single tight sentence with no filler, and the purpose is front-loaded. It could use the saved space to explain the parameter or expected result, but it is concise and well-structured as-is.

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

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

For a one-parameter, read-only helper with rich annotations, the core purpose is adequately conveyed. However, with no output schema and no parameter-format guidance, the agent is left guessing about the exact input expected and how the response communicates port availability.

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

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

Schema description coverage is 0%, and the description never explains the 'hostPorts' parameter beyond the schema's bare title. The integer type and plural naming are ambiguous, leaving the agent unsure whether a single port, a range, or multiple ports are expected.

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 ('check') and resource ('host ports on the Docker host'), making the tool's purpose immediately clear. The 'Wizard helper' prefix also ties it to the container-creation flow, distinguishing it from the more generic sibling check_port.

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 'Wizard helper' implies this belongs in the container wizard flow, so usage context is weakly established. However, it does not explicitly say when to use this tool over alternative port-checking or gatekeeper container tools, and it offers no exclusions.

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

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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description reinforces it with 'without applying changes', which is consistent. It adds the 'normalize' behavior, but does not disclose what normalization entails or what the tool returns on success/failure; the annotation burden is low, so a mid-range score 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 a single, front-loaded sentence with no filler. Every phrase earns its place ('validate', 'normalize', 'without applying changes'). Slight deduction because 'Wizard helper' is a vague category label that could carry more specific context about the wizard stage.

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 is the sole carrier of context, and it leaves notable gaps: it does not explain what 'normalize' produces, what the validation response looks like, or how an agent should interpret results. For a validation step that an agent must invoke correctly within a multi-step wizard, this is a meaningful shortfall.

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

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

The schema has zero parameters with 100% coverage, so baseline is 4. However, the description references a 'CreateContainerRequest' that the agent has no way to supply through inputs, creating ambiguity about where the request originates (presumably wizard state). The description names the object being operated on but fails to explain how it is provided.

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 action ('validate and normalize'), a concrete resource ('CreateContainerRequest'), and a key scoping constraint ('without applying changes'). This distinguishes it from mutation siblings like gatekeeper_create_container, so an agent can identify its role in the wizard flow, though the prefix 'Wizard helper' is somewhat generic.

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

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

No guidance is given on when to use this tool versus alternatives. It does not name sibling validation steps (e.g., gatekeeper_containers_wizard_ports_check) or explain its position within the wizard sequence, so the agent must infer intent purely from the name and the single-sentence description.

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 indicate non-read-only, non-idempotent behavior, and the description adds useful context: it is part of a 4-step deployment, envFilePath is loaded server-side by Gatekeeperd, and the container must be verified running afterward. However, it does not disclose what happens if a container with the same name already exists, what occurs if creation fails, or any cleanup or rollback 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?

Every sentence earns its place: the deployment ordering is front-loaded, required versus optional fields are stated compactly, and the env/envFilePath decision rule and post-creation verification are included without filler. It is dense yet structured for quick parsing.

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 container-creation tool with 9 underdocumented parameters, no output schema, and only sparse annotations, the description addresses ordering and env handling but misses parameter formats and failure behavior. It is a solid start, but the agent would still need Docker knowledge to correctly populate ports, volumes, network, and restartPolicy.

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% property description coverage, so the description carries the burden. It compensates by naming all optional parameters and providing meaningful guidance on env vs envFilePath. Still, it gives no format or semantic details for ports, volumes, network, or restartPolicy, leaving the agent to infer Docker conventions.

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 action ('Create and start') and resource ('a new Docker container'), with the scope 'with custom configuration.' This clearly distinguishes it from siblings like start_container, stop_container, and restart_container, and the 'step 1 of 4' label reinforces its entry-point role.

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

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

The description explicitly says this is step 1 of 4, instructs the agent to do it first, and directs verifying the container is running before proceeding to project creation. It also gives conditional guidance for choosing env vs envFilePath. It does not explicitly name when not to use this tool, but the creation semantics make the intended 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 indicate this is a non-read-only, non-idempotent, non-destructive operation, so the description does not need to restate that. It adds valuable behavioral context beyond the annotations by disclosing the required container state and the strict step ordering, which helps the agent understand side-effect dependencies.

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

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

The description is compact and well-structured, front-loading the core purpose before the prerequisite and deployment order. The numbered workflow is somewhat long but each step earns its place by giving the agent actionable sequencing 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?

Despite useful deployment-order context, the tool has 11 parameters, no output schema, and zero schema descriptions, yet the description explains none of the parameter semantics, required field formats, or expected output. An agent would struggle to construct a valid call without additional information.

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

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

Schema description coverage is 0%, and the description provides no detail about any of the 11 parameters such as slug, domain, type, amountDue, currency, or dueDate. Since the schema carries no descriptions, the tool description was the only place to compensate, but it does not explain the meaning, format, or accepted values of any 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 opens with 'Create a new Gatekeeper project registration', which is a specific verb and resource. It is clearly distinguished from sibling tools like gatekeeper_update_project, gatekeeper_delete_project, and gatekeeper_list_projects by the 'Create' action and 'new project registration' object.

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

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

The description explicitly states the prerequisite (Docker container must exist and be running) and names the tool to use first (gatekeeper_create_container). It also provides a numbered deployment order showing exactly where this step fits, and closes with the business context 'Use for onboarding new clients.'

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds 'permanently', which conveys irreversibility beyond the generic destructive hint. However, it does not disclose side effects (e.g., whether related data or configuration is removed) or any prerequisites, so it adds only marginal value over 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 five-word sentence with no filler, front-loading the action and object. It is appropriately short for a simple tool, though it could have included parameter clarification without becoming 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?

Despite the tool being simple (one parameter, no output schema), the description is incomplete for reliable invocation because it does not clarify what value 'name' expects. Annotations cover the destructive behavior, but the agent is left to guess the parameter semantics, which is a significant gap even for a simple tool.

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

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

The schema description coverage is 0% and the description does not explain the 'name' parameter at all. It is unclear whether 'name' refers to a container name, ID, or a label, and there is no guidance on format or how to obtain valid values. The description fails to compensate for the missing schema descriptions.

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

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

The description states a specific verb ('Delete'), resource ('a container'), and scope ('permanently'), which clearly distinguishes it from sibling tools like stop_container or restart_container. It also contrasts with file deletion tools like delete_path, making the target resource unambiguous.

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

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

The description provides no when-to-use or when-not-to-use guidance. It does not reference alternatives like gatekeeper_stop_container or gatekeeper_restart_container, nor does it clarify that this is the irreversible removal option versus a temporary stop. The word 'permanently' hints at intent but does not explicitly guide 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 supply destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is known. The description adds the local-host scope but does not disclose behavior around the force flag, tag handling, or failures caused by images in use.

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, front-loaded sentence with no redundant words or restatement of the name. It efficiently conveys the core action and scope.

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 destructive, has no output schema, and offers no parameter documentation, yet the description does not mention what happens on success or failure, or the role of `force` and `tag`. An agent may call it with only `image` and be surprised by behavior when the image is in 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?

Schema description coverage is 0%, so the description needed to clarify `force` and `tag`, but it mentions neither. The required `image` parameter is self-explanatory from its name, but the optional parameters' semantics and defaults remain ambiguous.

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

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

The description states a specific verb ('Delete'), resource ('Docker image'), and scope ('local Docker host'). This clearly differentiates it from sibling tools such as gatekeeper_delete_container or gatekeeper_delete_project, which target different resources.

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 implied by the action and resource: use this when a Docker image on the local host must be removed. However, there is no explicit when-not guidance, prerequisite information such as image existence, or mention of alternatives.

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

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

Annotations already mark this as destructive, and the description adds important nuance: the operation archives rather than permanently destroys and preserves payments and audit log. This goes beyond the annotations by clarifying what will and will not be affected.

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

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

The description is two short sentences with no filler. It front-loads the core operation (archive/soft delete), then adds the key preservation behavior and the primary use case, all relevant and necessary 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?

The description covers purpose, use case, and behavioral nuance well, and the annotations supply the destructive/read-only profile. However, it omits any explanation of the required 'slug' parameter and the return value or confirmation behavior, leaving a small but real gap 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?

The sole parameter 'slug' is completely undocumented in the description, and schema coverage is 0%. While 'slug' may be a common identifier concept, the description does not connect it to the project or explain how to source it, so the agent receives no additional semantic guidance.

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 ('Archive') and resource ('Gatekeeper project'), and immediately clarifies that this is a soft delete rather than a permanent deletion. It distinguishes the operation from the tool's name and from other Gatekeeper management tools, making the intent 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 the tool: 'Use when removing a client while keeping historical data.' It does not name an alternative for permanent deletion, but the soft-delete framing implies the exclusion, providing clear contextual 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety behavior is covered. The description adds useful context about matching by exact name or ID prefix, but it does not disclose what 'details' are returned or how errors like not-found are handled.

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 filler. Every phrase contributes meaning: operation, resource, cardinality, and identifier matching.

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 read-only lookup, the description is largely complete: it says what the tool does and how the parameter is interpreted. The absence of output/return details is mitigated by the lack of an output schema, and the annotations cover the safety profile.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does this by clarifying that the single 'name' parameter can accept either a container name or an ID prefix, which is valuable beyond the plain 'Name' title in the schema. It stops short of giving examples or format 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?

The description uses a specific verb ('Get') and a clear resource ('details for a single container'), with an explicit identifier scoping ('by name or ID prefix'). It is distinguishable from list-oriented siblings like list_docker_containers and gatekeeper_list_containers, though it does not explicitly contrast with get_container_status or gatekeeper_get_container_health.

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 no guidance on when to use this tool versus alternatives such as get_container_status, get_container_logs, or gatekeeper_get_container_health. There are no when-to-use, when-not-to-use, or alternative-selection hints.

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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds little beyond saying it retrieves health/running state, but it does not contradict the annotations and there are no hidden side effects to disclose.

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 filler or redundant details. It is appropriately concise for a simple read operation, though the brevity contributes to some of the semantic gaps noted in other dimensions.

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 operation is simple and the annotations cover side effects and safety, so the description is minimally adequate. However, there is no output schema and no mention of what the health response contains, and the overlapping siblings make selection less certain. More context about return values or distinctions from `get_container_status` would improve completeness.

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

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

The schema has 0% description coverage for the single `name` parameter, and the description does not explicitly define it as a container name, ID, or label. The meaning is inferable from the tool name and context, but the description fails to compensate for the schema gap, especially given the low coverage.

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

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

The description uses a clear verb ('Get') and a specific resource ('container health/running state'). It is not a tautology and conveys the operation well. However, it does not explicitly differentiate this from sibling tools like `get_container_status` or `gatekeeper_get_container`, so it stops 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?

There is no guidance on when to use this tool versus alternatives such as `get_container_status` or `gatekeeper_list_containers`. No exclusions, conditions, or comparison context are provided, leaving the agent to infer the appropriate use case.

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 non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context by revealing that the response bundles payment history and audit log, which is not visible from the schema.

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

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

Two concise sentences with no filler. The key action and selection criterion are front-loaded, and every word adds value.

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

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

For a simple single-parameter read-only lookup, the description is largely complete. It names the resource, the selection parameter, and the included related data. It could be slightly more precise about what 'slug' refers to, but nothing critical is missing.

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

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

With 0% schema description coverage, the description must compensate for the 'slug' parameter. It does connect slug to a specific client site/project, giving basic meaning. However, it does not explain the slug format, where to find it, or clarify that it is the identifier used to select the project.

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

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

The description clearly identifies the action ('Get') and resource ('one Gatekeeper project'), and adds that it includes payment history and audit log. This distinguishes it from sibling tools like gatekeeper_list_projects and gatekeeper_get_project_audit.

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

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

The description explicitly states when to use the tool: when the user asks about a specific client site or slug. It does not explicitly mention when not to use it or name alternatives, but the condition is clear enough to route an agent correctly.

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 description does not need to restate safety. It adds the scoping detail that the audit log is project-specific, but does not disclose any additional behavioral traits such as access requirements, log format, or ordering.

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

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

One short sentence that front-loads the action, resource, and scope. Every word earns its place, 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 one-parameter, read-only audit retrieval tool with strong annotations, the description is nearly complete. It lacks details about the return shape, pagination, or filtering options, but the name and description convey the essential purpose well enough 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 description coverage is 0%, so the description should compensate for the undocumented 'slug' parameter. It does not explicitly explain that 'slug' identifies the project or describe the expected slug format. The parameter is simple and inferable, but the description adds no direct parameter guidance.

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

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

The description uses a specific verb and resource: 'Get audit log' and scopes it to 'a specific project.' This clearly distinguishes it from broader audit tools like gatekeeper_list_audit or project management tools like gatekeeper_get_project.

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 correct usage context: call this when you need the audit log for a particular project, identified by slug. It does not explicitly name alternative audit tools or state when not to use them, but the 'specific project' scope provides clear, actionable 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 indicate this is not read-only (readOnlyHint false) and not idempotent, but the description adds the key side effect: 'Creates a pending payment' and the return value 'checkout URL'. This goes beyond the annotations, though it omits details like authorization requirements or idempotency caveats.

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, no fluff, and the main action is front-loaded. Every word earns its place.

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

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

The description covers the essence: what it does, prerequisites, side effect, and return. But it lacks details on the exact definition of slug and email, potential failure conditions, or how to proceed after obtaining the checkout URL. Given the tool's relative simplicity and existing sibling context, this is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must clarify the parameters. It only says 'Requires slug and email' without explaining that slug likely refers to the project slug and email is the customer email. This adds minimal meaning beyond the schema's bare field names.

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 action ('Generate a Paystack payment link') on a concrete resource (a project), and distinguishes itself from sibling payment tools like gatekeeper_list_payments by focusing on initialization and returning a checkout 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?

It gives clear context by saying 'Requires slug and email' and 'for a project', which implies it is used to create a payment for a specific project. However, it does not explicitly mention when not to use it or any alternatives, leaving the agent to infer the appropriate usage from the sibling set.

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 flag readOnlyHint=false and idempotentHint=false, so the mutating nature is conveyed. The description adds useful workflow context (prerequisite nginx enable and completion of deployment), but does not disclose further behavioral details such as external certbot calls, rate limits, or post-install reloads, so it only partially surpasses the annotation baseline.

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

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

The description is compact and well-structured: a one-sentence purpose, then bolded DEPLOYMENT ORDER and PREREQUISITE callouts, then a closing note. Every sentence adds either scope or workflow context, with no filler.

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

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

For a 2-param certificate installation tool, the description provides the essential orchestration context: when to run it (last), what must be pre-enabled, and what is required. There is no output schema, and the description omits return-value or failure-mode details, but the deployment workflow context is strong enough to guide a correct call.

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

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

With 0% schema description coverage, the description must define the parameters, but it only says 'Requires domain and email,' restating the property names without explaining what the email is used for (e.g., certbot registration) or expected formats. An agent can infer that domain is the certificate target, but the parameters remain underspecified.

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

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

The description opens with a specific verb and resource: 'Install an SSL certificate for a domain using certbot.' It clearly distinguishes from sibling certificate tools (list/remove/check status) by stating it is the final deployment step that 'completes the deployment.'

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 labels the deployment order: 'step 4 of 4 — do this last,' and names the prerequisite tool (gatekeeper_nginx_enable first). This tells the agent both when to invoke it and what must happen before, giving clear usage context relative to sibling nginx/gatekeeper tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about recency and event scope, but it does not disclose return format, ordering, or pagination 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?

One compact sentence that front-loads the verb and resource, then adds scope and event types. Every word earns its place with no filler.

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

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

For a low-complexity, read-only list tool with rich annotations and a single nullable parameter, the description tells the agent what it returns and at what scope. The only notable gap is undocumented limit semantics, but the overall picture is clear enough 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?

The single parameter 'limit' is described only in the schema as nullable integer with default null; the description does not mention it. With 0% schema description coverage, the description was expected to compensate but does not explain what limit controls or what null means.

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 and resource: 'list ... audit log entries' with an explicit scope ('across all projects') and event categories ('block/unblock/payments'). This clearly differentiates it from sibling tools like gatekeeper_get_project_audit, which targets a single project.

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 'across all projects' implies this is the tool for a global audit view, and siblings like gatekeeper_get_project_audit exist for per-project queries. However, it does not explicitly state when to choose this tool over alternatives, nor does it mention 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 provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the specific path context (/etc/letsencrypt/live) and the fact that it lists installed certificates, which is beyond the annotations. It does not disclose the return format, but for a read-only list tool that 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 a single, concise sentence that front-loads the action and resource. There is zero wasted text, and every word contributes to clarity.

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

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

Given the simplicity of the tool (no parameters, no output schema, read-only annotations), the description is sufficient for an agent to know what it does and where. It could specify the return format, but for a list operation the expectation is clear. It covers the necessary context for invoking 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?

There are zero parameters, and the schema coverage is 100% vacuously. The description doesn't need to explain parameters. According to the rubric, 0 params gives a baseline of 4, and there is no additional semantic burden.

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

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

The description states a specific verb (List) and resource (installed SSL certificates) with a precise location (/etc/letsencrypt/live). It clearly distinguishes from sibling certificate tools like install, remove, and check status by focusing on listing.

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

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

The verb 'List' implies the usage is to enumerate certificates, but there is no explicit guidance on when to prefer this over alternatives like check_certificate_status or install_certificate. The context is clear enough for a simple read-only operation, but no exclusions or alternative conditions are mentioned.

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

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

Annotations already establish the operation as read-only, idempotent, and non-destructive. The description adds only the Gatekeeperd scoping detail and no further behavioral traits such as whether stopped containers are included or what fields are returned, which is acceptable but not especially 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?

A single sentence states the action, resource, and scope with no filler or repeated information. The most important qualifier ('all ... visible to Gatekeeperd') is included immediately with the verb.

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 enumeration, the description is sufficient to let an agent invoke it correctly. The missing return-value details are a minor gap because no output schema is provided, but the tool's purpose is simple and the result is implied by 'List'.

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

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

The tool takes zero parameters and the input schema is empty, so there is no parameter semantics for the description to supplement. This matches the baseline for parameterless tools.

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

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

The description uses a specific verb ('List') with a clear resource ('Docker containers') and scopes the result to those 'visible to Gatekeeperd on the host'. This is more specific than a generic container listing, though it does not explicitly contrast itself with the similarly named sibling list_docker_containers.

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 implied from the purpose: when you need all Docker containers as seen by Gatekeeperd. However, the description does not name alternative tools like list_docker_containers or state conditions under which one should be preferred, leaving some selection ambiguity.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the 'Docker networks' scope; it does not mention return format or any observable behavior beyond listing, but for a zero-argument read-only tool this is an acceptable baseline.

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 entire description is a single clear three-word sentence with no redundant phrases or repeated schema information. It is appropriately front-loaded 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?

For a parameterless listing operation, the description, along with the read-only/idempotent annotations, fully supports correct selection and invocation. There is no missing prerequisite, argument, or side-effect information that an agent would need.

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

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

The input schema has no properties, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because 0 parameters make documentation trivially sufficient.

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

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

The description uses a specific verb ('List') and a precise resource ('Docker networks'), so an agent can immediately identify the tool's domain and distinguish it from sibling tools like list_docker_containers or list_wifi_networks.

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 clear: call this tool when Docker networks need to be enumerated. No exclusions or alternative tools are stated, but there is no sibling that also lists Docker networks, so no further routing guidance is necessary.

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 non-destructive behavior, so the safety profile is covered. The description adds transparency about output ordering ('sorted by days overdue') and the filtering scope ('active projects past their due date'), 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?

Two concise sentences with no filler. The core function is stated first, followed by a useful triage use-case in the second sentence.

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 provides sufficient information: what is listed, what filtering applies, how results are sorted, and why the agent would use it. No output schema exists, but the tool's simple output nature makes this description 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?

There are zero parameters, so the schema already fully covers this dimension. The description doesn't need to add parameter details; the baseline of 4 applies since no parameters exist.

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

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

The description uses a specific verb ('List') with a precise resource ('active Gatekeeper projects past their due date') and an output ordering ('sorted by days overdue'). It clearly distinguishes this tool from broader siblings like gatekeeper_list_projects by focusing on overdue active projects.

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

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

The description explicitly states the intended use case: 'Use for payment triage — who is late and when auto-block kicks in.' This provides clear context for when to call the tool, though it doesn't explicitly name alternatives or exclusion conditions.

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 covered. The description adds useful context about the global scope and supported status values, but it does not disclose pagination behavior, default result size, or ordering. That is acceptable for a safe read-only list tool, but not especially 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?

The description is a single sentence that front-loads the action and resource, then packs all relevant filter information without redundancy. Every clause earns its place, and there is no filler or repetition.

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

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

For a six-parameter filtered list with strong annotations, the description is nearly complete: it covers scope, optionality, status vocabulary, date range, and pagination. It could be more explicit about date format and the from_path naming mismatch, and it does not state the default result set when no filters are provided, but these are minor for a read-only list tool.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It names status with its allowed values, project_slug, from/to dates, limit, and offset. The only weakness is the wording 'from/to dates' while the schema property is 'from_path', which introduces mild ambiguity about whether 'from' is a path or a date.

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 action ('List') and resource ('payments across all Gatekeeper projects'), and lists concrete filter dimensions. This clearly distinguishes it from sibling tools like gatekeeper_list_projects and gatekeeper_revenue_report, so an agent can tell what this tool does without opening the schema.

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

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

The description gives clear context: it is for reading payments across all Gatekeeper projects with optional filters, and the phrase 'across all Gatekeeper projects' signals that it is not scoped to one project. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full routing 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond those annotations by specifying the exact scope ('all Gatekeeper client projects') and the fields returned, which helps the agent anticipate the output.

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

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

The description is two short sentences with no filler. The core action and resource are front-loaded, the field list is compact, and the intended use case is stated in a single clause.

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, list-style tool, the description is complete: it names the resource, the exact returned fields, and the business purpose. No output schema exists, but the field enumeration compensates. The annotations cover safety and world context, so no critical information is missing.

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

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

There are zero parameters, so there is nothing for the description to explain about parameters. The description appropriately focuses on what the tool returns rather than input semantics, matching the baseline for a parameterless 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 opens with a specific verb and resource: 'List all Gatekeeper client projects', and enumerates the returned fields (slug, name, domain, status, due date, amount due). This clearly distinguishes it from more specific siblings like gatekeeper_get_project and gatekeeper_list_overdue.

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 a concrete intended use case: 'Use for billing/access overview across hosted clients.' This gives the agent clear context for when to select it, though it does not explicitly mention alternatives or exclusion criteria.

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 readOnlyHint=false and destructiveHint=false. The description adds meaningful context by specifying 'unlink' behavior and confirming the config file is preserved, which aligns with destructiveHint=false. It doesn't detail side effects like nginx reloads, but with annotations carrying the safety profile, this is sufficient.

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

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

A single sentence that conveys the action, the resource, and the key non-destructive constraint. No filler or redundancy; the most important scoping information ('without removing the config file') is placed at the end but still front-loads the core verb and object.

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

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

For a one-parameter mutation tool with no output schema, the description covers the essential semantics: disable/unlink, preserve config. It does not define 'slug' format or mention prerequisites (e.g., permissions), but these are minor for a tool of this simplicity and can be inferred from 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 0% and the description does not explicitly explain the 'slug' parameter. However, since there is only one required parameter and the context is 'nginx site', it is reasonable to infer that slug identifies the site. The description adds minimal semantic value beyond the schema, but the single-parameter design makes the meaning recoverable.

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 ('Disable') and a precise resource ('an nginx site'), and clarifies the operation as 'unlink' while explicitly noting 'without removing the config file.' This directly distinguishes it from siblings like gatekeeper_nginx_remove (which removes the config) and gatekeeper_nginx_enable (which activates the site).

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: use this tool to disable/unlink a site while preserving the config file. It doesn't explicitly name alternatives or state when-not-to-use, but the non-destructive phrasing implies the condition under which this tool is preferred over a full removal. This meets 'clear context, no exclusions' but stops short of explicit alternate routing.

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 communicate that this is a mutating, non-idempotent, non-destructive action. The description adds useful operational behavior: it generates and enables a config, requires a running container, and is part of a defined deployment pipeline. It could disclose more about exact effects, but the existing context plus annotations are 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 compact and front-loaded: the core action appears first, followed by prerequisites and ordering. Every sentence adds essential decision or sequencing information, with no filler or redundant restating of the tool name.

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

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

For a one-parameter action tool, the description covers the essential context: prerequisite conditions, exact placement in a 4-step workflow, and the next step. It does not describe return values or failure modes, but those are less critical given the clear workflow and absence of 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?

Schema coverage for the single parameter is 0%, so the description must compensate. It indirectly suggests that 'slug' identifies a project by saying the config is generated 'for a project,' but it never explicitly defines the slug format, valid values, or how it relates to the prerequisite project. This is minimally sufficient but not thorough.

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 action and resource: 'Generate and enable an nginx site config for a project.' This clearly distinguishes it from sibling tools like gatekeeper_nginx_disable, gatekeeper_nginx_validate, and gatekeeper_nginx_status, and the deployment-order context helps disambiguate it further.

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 explicit prerequisites and sequence: project must exist, container must be running, and this is step 3 of 4. It also names the tools to use before and after. It does not explicitly state when not to use this tool, but the clear step ordering provides strong 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 destructiveHint=true and idempotentHint=false, but the description adds beyond that by explicitly disclosing what gets destroyed: both the sites-available file and the sites-enabled symlink. This tells the agent the exact footprint of the destructive action, which is valuable context the annotations 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?

A single, tightly crafted sentence that front-loads the action and precisely scopes the deletion. Every word contributes meaning, with no filler or redundant restatement of the tool name.

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 single-parameter destructive operation, the description states the essential behavior. However, it does not mention how the slug is obtained, what happens if the site does not exist, or whether a reload/restart is triggered afterward — gaps that matter for an agent deciding how to invoke and verify the call.

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

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

Schema description coverage is 0% and the description does not explain the 'slug' parameter at all. An agent cannot determine what format the slug should take or where to obtain it, so the description fails to compensate for the complete lack of schema-level documentation.

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

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

The description states a specific verb ('Remove'), a clear resource ('an nginx site'), and the exact scope ('both sites-available file and sites-enabled symlink'). This distinguishes it from related gatekeeper_nginx tools like enable, disable, or status, leaving no ambiguity about what operation is performed.

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

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

The description makes clear that this tool is for complete removal, not mere disabling, which provides useful context against sibling tools like gatekeeper_nginx_disable. It does not explicitly name alternatives or state when not to use it, but the 'completely' phrasing gives adequate usage context for a straightforward removal operation.

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 the specific aspects it checks (configured, enabled, SSL), but does not disclose return format or behavior when the site is absent. It adds some context 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?

One concise sentence with no wasted words. The key action and scope are front-loaded, and it reads clearly.

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 one undocumented parameter, yet the description does not mention what the tool returns or how the results should be interpreted. It also does not clarify the meaning of 'configured and enabled' in practical terms. For a simple status check, this is still incomplete.

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

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

Schema description coverage is 0%, so the description should explain the single parameter 'slug'. It does not define what a slug is or how it should be formatted, only implies it identifies a project. This is a significant gap for a tool with an undocumented 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 states a clear action ('Check') on a specific resource ('nginx site configured and enabled') with additional detail about SSL. It is distinct from write operations like enable/disable/remove and from validation tools like gatekeeper_nginx_validate, though it doesn't 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 purpose implies a read-only status check, which is obvious from the name and description, but it does not explicitly state when to use this tool versus alternatives like gatekeeper_nginx_validate or gatekeeper_nginx_wizard_context. There is no exclusionary 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 description explicitly says the tool returns a config preview 'without applying changes,' but the annotation readOnlyHint=false marks the tool as non-read-only. This is a direct contradiction between the description's behavioral claim and the declared annotation, so the description cannot be trusted as a behavioral guide.

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 filler. 'Wizard helper' adds useful context, and every clause contributes either to what the tool does or to what it does not do.

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, the description covers purpose, output, and non-mutation, but it leaves the meaning of the required 'slug' parameter unexplained and omits any error or validation-behavior details. Combined with the annotation contradiction, the definition is not fully actionable.

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 one required parameter, 'slug', with zero description coverage, and the description does not explain what 'slug' refers to or how it relates to the nginx enable inputs. The description provides only a vague connection to 'nginx enable inputs' but leaves the required parameter semantically underdocumented.

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 names a specific action ('validate'), a specific resource ('nginx enable inputs'), and the output ('config preview'), while also stating that no changes are applied. This clearly distinguishes it from the sibling tool gatekeeper_nginx_enable, which applies changes.

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 'Wizard helper' plus 'validate nginx enable inputs' communicates that this is a preflight or preview step before enabling nginx. It gives clear context for when to call it, though it does not explicitly name 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, idempotentHint=true, and destructiveHint=false, so the read-only behavior is covered. The description adds value beyond the annotations by revealing that the tool is UI-oriented and that its result includes status, container hints, and certificate options. There is no contradiction with the annotations, and the safety profile is consistent with the 'fetch' wording.

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

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

The description is a single, front-loaded sentence that immediately identifies the tool as a wizard helper and the operation as fetching context. The parenthetical efficiently summarizes the expected fields without wasting words on redundant 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 one-parameter, read-only helper, the description is adequate but not complete: an agent can tell it fetches wizard context, but the exact return structure is vague and there is no output schema to fill the gap. The slug semantics are also left to inference, and the phrase 'status, container hints, certificate options' does not clarify the shape or types of the returned data.

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 carries the burden of explaining the 'slug' parameter, but it never mentions slug at all. The wording 'fetch project + nginx context' lets an agent infer that slug likely identifies a project, but no format, example, or value source is given. This is a meaningful gap for a required 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 states a specific verb and resource: 'fetch project + nginx context' and explicitly frames the tool as a 'Wizard helper' for a step-by-step UI. It also enumerates the content dimensions (status, container hints, certificate options), which separates it from mutating or validating nginx siblings. This is enough for an agent to distinguish it from gatekeeper_nginx_validate, gatekeeper_nginx_enable, and similar 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 'Wizard helper' framing implies when to use it—when driving the step-by-step UI—but the description never explicitly says when not to use it or which sibling to prefer instead. There is no exclusion such as 'for direct nginx status, use gatekeeper_nginx_status.' The usage context is clear but only implied, not stated.

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 a mutating (readOnlyHint=false), non-idempotent operation. The description adds nothing beyond that: no warning that pulling can be slow, consume significant disk, require network access, or fail on missing tags. With annotations present the bar is lower, but zero additional behavioral context is provided.

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 clean sentence with no wasted words and the core action front-loaded. It earns conciseness points, though the brevity stems as much from under-specification as from deliberate economy.

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 3-parameter tool with no output schema and zero schema descriptions, this is thin. An agent gets no information about return behavior, error cases (image not found, auth failure), duration/disk impact, or the meaning of pullViaCli — all relevant for a potentially long-running, mutating Docker operation.

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

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

Schema coverage is 0%, so the description must compensate — but it names no parameters. 'image' and 'tag' are self-evident from their names, but 'pullViaCli' is genuinely ambiguous (CLI vs what alternative? Docker API? gated wrapper?), and the description does nothing to clarify it.

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

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

States a specific verb and resource: 'Pull a Docker image from a registry.' This distinguishes it from siblings like gatekeeper_delete_image and gatekeeper_check_image_status. However, 'a registry' is generic and doesn't clarify whether this targets a specific configured registry or the local Docker daemon.

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

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

No guidance on when to use this tool vs alternatives such as gatekeeper_check_image_status or gatekeeper_create_container. The description doesn't mention prerequisites (e.g., registry auth, daemon availability) or the role of pullViaCli, which implies a meaningful method choice the agent must guess about.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, covering the mutation and irreversibility aspects. The description adds the domain scope but does not disclose additional behaviors such as whether the private key is also removed, what happens if the certificate is in use, or any error conditions. Given the annotation coverage, the description adds modest context beyond the structured fields.

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

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

The description is a single sentence with no redundant words. It is front-loaded with the action and resource, and it fits the tool's simplicity. Every word earns its place.

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

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

For a one-parameter destructive tool with annotations covering safety and idempotency, the description is minimal but arguably sufficient for a straightforward removal operation. However, it lacks details like whether the certificate must exist, side effects on dependent services, or error scenarios. Given the absence of an output schema, a slightly richer description would improve completeness, but the current level is acceptable for a simple tool.

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

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

Schema description coverage is 0%, so the description must compensate for explaining the 'domain' parameter. It only restates that the certificate is for a domain, which mirrors the parameter name and adds no detail about expected format (e.g., FQDN, with or without protocol), validation rules, or examples. This is insufficient for an agent to correctly format the input.

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

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

The description clearly states the verb 'Remove' and the resource 'SSL certificate for a domain'. It is specific and distinguishes from related tools like gatekeeper_install_certificate and gatekeeper_check_certificate_status. However, it does not explicitly contrast with sibling gatekeeper_nginx_remove, though that likely refers to nginx config rather than certificates. Overall, the purpose is 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?

No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites mentioned (e.g., verifying the certificate exists before removal). The agent is left to infer that removal is the inverse of installation. There is no mention of when not to use it or what conditions must hold.

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 call is not read-only and is not marked destructive, and the description does not contradict that. But the description adds no behavioral context: no mention of container downtime, effect on running processes, requirement that the container exist, or what happens on failure.

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 short sentence with no filler, and the action is front-loaded. It is concise, though the brevity comes from under-specification rather than deliberate completeness.

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

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

For a one-parameter tool this is near-minimal, but it omits the operational context an agent needs: how the container is identified, prerequisite state, and how this relates to the many sibling start/stop/restart container tools. With no output schema, some effect or return information would meaningfully improve completeness.

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

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

The schema has one required string parameter `name` with 0% description coverage. The description does not clarify whether `name` is a Docker container name, a container ID, or a Gatekeeper-managed container handle, and it gives no format or example.

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?

Uses an explicit verb + resource ('Restart a container'), so the core operation is clear. However, it does not distinguish this tool from sibling tools like restart_container, start_container, or gatekeeper_start_container; it mostly restates the tool name.

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

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

No guidance is given about when to use restart versus start or stop, nor when to prefer this gatekeeper-specific variant over the generic restart_container sibling. The description leaves all selection logic to inference.

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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds modest context about what data the report contains (current month, previous month, monthly breakdown) but does not disclose further behavioral details such as data scoping, currency, or what 'open world' hints imply. This is acceptable 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?

The description is two short sentences, front-loading the core output summary before parameter defaults. Every word earns its place, with no filler or redundant restatement of the tool name.

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 zero required parameters and strong safety annotations, a minimal read-only report description can be viable. However, the ambiguity around period and months, plus the lack of an output schema, leaves gaps for an agent trying to customize the report correctly. It is adequate for a default invocation but incomplete for parameter-aware 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?

Schema description coverage is 0%, so the description must compensate. It only says 'period (default month)' and 'months (default 6)', which restates defaults rather than explaining what values period accepts or what months actually controls (e.g., how many months to include in the breakdown). An agent cannot confidently know valid period formats or the exact meaning of months from this 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 identifies the tool's purpose as a Gatekeeper revenue summary, listing specific outputs: total this month, last month, and monthly breakdown. It does not contain an explicit verb, and it does not differentiate itself from related gatekeeper tools such as gatekeeper_list_payments, but the resource and metrics are unambiguous enough for an agent to understand what it does.

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?

There is no guidance about when to use this tool versus alternatives like gatekeeper_list_payments, gatekeeper_list_overdue, or other gatekeeper reporting tools. The description states defaults but does not mention use cases, exclusions, or selection criteria.

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 indicate a non-read-only mutation (readOnlyHint=false). The description adds no behavioral context beyond that, such as what happens if the container is already running, whether it is reversible, or what side effects starting a container may have.

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 redundant wording. It is appropriately short for a simple one-parameter action, though it is brief to the point of under-specification.

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

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

For a one-parameter mutation tool, 'Start a stopped container' is minimally adequate, but it lacks information about expected output, error behavior, and how it differs from the similarly named sibling 'start_container'. Given the large sibling list, more context would help disambiguate.

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 needed to clarify the 'name' parameter, but it does not explicitly state that 'name' is the container name. While inferable from context, the description does not add value beyond the schema's minimal 'Name' title.

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

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

The description uses a specific verb and resource: 'Start a stopped container.' It clearly communicates the action, but it does not distinguish this tool from the sibling 'start_container', which appears to have the same 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?

There is no guidance on when to choose this tool over alternatives like 'start_container', 'gatekeeper_restart_container', or 'gatekeeper_stop_container'. The phrase 'stopped container' implies a precondition, but no explicit when-to-use or when-not-to-use 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?

Annotations already convey that this is a state-changing operation (`readOnlyHint: false`) and non-idempotent. The description adds the useful constraint that the target must be a running container, which suggests behavior if the container is already stopped. It does not describe side effects or failure modes, but the annotations lower 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 with no filler: 'Stop a running container.' Every word earns its place, and there is nothing redundant or irrelevant for such a simple operation.

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, but the description is too thin given the surrounding toolset. It does not clarify whether this applies to Docker containers, gatekeeper-managed containers, or how it differs from the sibling `stop_container`. With no output schema and no parameter documentation, the description leaves the agent without enough context to reliably distinguish and invoke this tool in ambiguous situations.

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 for the undocumented `name` parameter. It only says 'a running container,' which weakly implies `name` identifies that container, but it does not explicitly explain what value to provide, such as container name, ID, or a gatekeeper-specific identifier.

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 clear verb and resource: 'Stop a running container.' It is unambiguous about the action, but it does not distinguish this tool from the sibling `stop_container` or related `gatekeeper_*` container tools. It is clear but lacks sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives such as `stop_container`, `gatekeeper_restart_container`, or `gatekeeper_delete_container`. The description implies using it when you want to stop a container, but it provides no exclusions, prerequisites, or comparisons to sibling tools.

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

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

Beyond the annotations, the description discloses that a non-empty reason is required and that a confirmation gate applies. These are useful behavioral traits not visible in the schema or annotations. There is no contradiction with the annotations.

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

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

Three short sentences, each adding distinct value: the action and context, the parameter requirement, and the confirmation gate. No redundant wording or filler.

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

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

For a simple two-parameter mutation with no output schema, the description covers the key invocation requirements and expected context. The meaning of the 'confirmation gate' and the exact response format are not detailed, but these gaps are minor for 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 0% schema description coverage, the description partially compensates by naming both parameters and specifying that 'reason' must be non-empty. It does not explain what a valid slug looks like or where to source it, leaving some semantic ambiguity.

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

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

The description uses a specific verb ('unblock') and resource ('Gatekeeper client project') and adds the triggering context 'after payment or agreement.' This clearly distinguishes it from the sibling gatekeeper_block_project and other gatekeeper actions.

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

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

The description gives clear context for when the tool should be used: when a project needs manual unblocking after payment or agreement. It does not explicitly name alternatives or exclusion criteria, but the 'after payment or agreement' condition is sufficient situational 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 description adds meaningful behavioral context beyond annotations: PATCH semantics (partial update), optionality of body fields with at least one required, and null-to-clear behavior for dueDate. It also warns against sending unrequested fieldskus. These details help the agent predict mutation behavior, though it does not mention side effects or response shape.

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

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

The description is dense yet well-organized: purpose first, followed by PATCH semantics, then a compact list of fields with constraints, and a final caution. Every sentence earns its place without redundant filler. The structure front-loads the most critical information (update existing project, PATCH partial semantics) before enumerating 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?

The description covers all calling requirements: target slug, optional fields with types/formats, and usage expectations. With no output schema, it does not describe return values, but for an update operation this is a minor omission. Error behavior on invalid slug or validation failures is also unspecified, though overall the tool is adequately documented.

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 schema description coverage at 0%, the description compensates by enumerating every editable field, specifying types (number, integer), value constraints (frontend|backend for type), format guidance (YYYY-MM-DD for dueDate), currency examples (KES/USD), and semantics (null to clear). It also clarifies the required target parameter (slug). This is strong compensation for the schema's lack of 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 states an explicit verb ('Update'), resource ('Gatekeeper project fields'), and scope ('existing client project'), clearly distinguishing it from create/delete/get siblings. The PATCH semantics further clarify the intent of partial modification. An agent can immediately tell this is the update tool among the gatekeeper family.

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

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

The description clearly states when to use this tool (update existing project) and gives concrete rules: provide slug, send only fields the user asked to change, at least one field required. It does not explicitly name alternative tools like gatekeeper_create_project, but the 'existing client project' wording and PATCH semantics imply the appropriate context without ambiguity.

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

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

Annotations already declare this tool read-only, idempotent, non-destructive, and open-world. The description adds the concrete returned fields, which is useful but not extensive behavioral context. 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?

The description is extremely compact and front-loaded, listing exactly the three key output values with no redundant wording. 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 parameterless read-only tool, this is complete: the agent knows exactly what values to expect and that no input is required. The annotations cover safety and idempotency, so no additional context 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?

There are zero parameters, so there is nothing for the description to explain. The baseline of 4 applies, and the description sensibly focuses on the tool's output rather than inventing 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?

The description clearly enumerates the tool's output: battery percentage, plugged state, and remaining seconds. It does not use an explicit verb but the name 'get_battery' plus these data fields makes the purpose clear. It does not differentiate itself from the sibling 'monitor_battery_health'.

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