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

No annotations are provided, so the description carries the full burden. It explicitly states that the tool mutates filesystem metadata via chmod but does not change file content. This is helpful, but it does not disclose required permissions or potential side effects like loss of access.

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

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

Two sentences with no wasted words. The first sentence gives the primary purpose, and the second provides usage constraints. Information is front-loaded and easily digestible.

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

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

Given the tool's simplicity, the description covers all necessary aspects: input requirements (path, mode format, constraints), and behavioral impact (metadata change, no content change). An output schema exists but is not described, which is acceptable for a mutation tool.

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

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

Schema coverage is 0%, meaning parameters have no description. The description compensates excellently by explaining that path must exist and be under allowed directories, and that mode must be a three or four digit octal string with examples. This adds essential meaning beyond the bare schema.

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

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

The description clearly states the tool changes Unix permission mode of an existing allowed path. It uses a specific verb (wijzig/modify) and resource (permissiemodus/file permissions), distinguishing it from sibling tools like chown_path which change owner.

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 constraints: path must exist and be under allowed_write_dirs, mode must be octal string (e.g., 755). It does not, however, explicitly mention when not to use this tool or direct to alternatives like chown_path for ownership changes.

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

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

No annotations provided, so description carries full burden. It discloses that the tool mutates filesystem metadata via chown and reports error conditions. It could be more detailed about side effects (e.g., symlink behavior) but overall it provides adequate transparency for a mutation operation.

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

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

Description is concise: two sentences plus a bullet-like note. Front-loaded with the main action. No redundant information.

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

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

Tool has low complexity (3 params), and output schema exists (not shown). Description covers prerequisites and error conditions. It is complete enough for a simple mutation 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 has no descriptions for parameters (0% coverage). The description adds meaning by specifying that path must exist and be under allowed_write_dirs, and owner and group must be existing local names, which is not in the schema.

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

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

Description clearly states the tool changes owner and group of a path, using specific verb 'wijzig' and resource 'eigenaar en groep van een bestaand toegestaan pad'. It distinguishes from sibling tools like chmod_file which deals with permissions, not ownership.

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?

Description specifies prerequisites: path must exist and be under allowed_write_dirs, owner and group must be existing local names. It also mentions error conditions for unknown users or missing permissions. However, it does not explicitly state when to avoid using this tool or mention 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?

Fully discloses filesystem modification, parameter constraints (valid local names for owner/group, octal mode), permission requirements, and both success and error response formats. With no annotations, the description carries the full burden and meets it excellently.

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

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

Well-structured with a clear one-liner followed by explanatory paragraphs. Some redundancy around permission mention, but overall efficient and front-loaded.

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

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

Covers all aspects: purpose, parameter details, prerequisites, restrictions, error cases, and return format. The output schema exists, so return value explanation is adequate.

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

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

All five parameters are explained in context beyond the schema, which has 0% coverage. The description clarifies defaults, allowed values, constraints (e.g., path must not exist), and behavior of parents. Adds significant value.

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

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

The description clearly states the tool creates a new directory with owner, group, and mode settings. It explicitly contrasts with modifying existing directories, distinguishing it from sibling tools like chmod_file or chown_path.

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

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

Provides clear conditions for use (path must not exist, parent under allowed_write_dirs) and warns against using it for modifications. However, it does not explicitly point to alternative tools for other tasks, though the context is sufficient.

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

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

With no annotations, the description carries the full burden. It discloses that the tool rewrites the root crontab, preserves lines outside the MCP-managed section, and replaces an existing job_id. This is good but could mention if there are side effects like overwriting other managed jobs.

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 clear and front-loaded with the purpose. It is concise but covers necessary constraints. Slightly verbose but every sentence adds value.

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

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

Given the presence of an output schema, the description adequately covers input constraints and behavioral traits. It is fairly complete for a tool that adds cron jobs, though it could mention the response or error conditions.

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

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

Schema coverage is 0%, so the description must compensate. It explains that job_id accepts only letters, digits, dots, underscores, and hyphens; schedule must have exactly five cron fields; and command's first word must be an absolute path. This adds significant meaning beyond the schema's type 'string'.

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 adds or replaces a root cronjob within the MCP-managed section, using a specific verb ('add or replace') and resource ('root cronjob'). It distinguishes from siblings like cron_remove (removes) and cron_list (lists).

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

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

The description provides constraints on job_id format, schedule format, and command path, which imply proper usage. However, it does not explicitly state when to use this tool versus alternatives (e.g., cron_remove) or when not to use it.

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

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

With no annotations, the description carries full burden. It discloses that the tool rewrites the root crontab, preserves lines outside the MCP section, comments out the line when disabled, and does nothing for nonexistent IDs. This provides good behavioral context beyond the basic mutation.

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 relatively concise, covering purpose, parameters, side effects, and edge case in a single paragraph. It could be slightly more front-loaded, but every sentence adds value.

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

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

Given no annotations and 2 required parameters, the description is thorough. It explains the tool's impact (rewriting crontab), safety (does nothing for missing ID), and behavior (preserving non-MCP lines). An output schema is present but not needed for completeness.

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

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

Schema coverage is 0%, so description must compensate. It fully explains job_id selects an existing job and enabled toggles activation, including the mechanism (commenting with '# '). This adds substantial meaning beyond the schema's type-only definitions.

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

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

The description clearly states the tool enables or disables an MCP-managed root cronjob. It specifies the verb and resource, but does not explicitly differentiate from siblings like cron_add or cron_remove, though the purpose is distinguishable.

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

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

The description explains how to use the parameters (job_id selects existing job, enabled=True/False). It notes that the tool does nothing if the ID doesn't exist, providing some guidance. However, it does not explicitly state when to use this tool over alternatives or provide when-not scenarios.

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

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

Without annotations, the description fully discloses behavior: it does not modify, returns both manual and MCP sections as raw text, and handles missing crontab by returning empty string. This is transparent for a read-only tool, though permission requirements are not mentioned.

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

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

The description is two sentences, front-loaded with the primary action, and every sentence adds critical detail (no parameters, no modification, output format). No unnecessary words.

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

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

Given the tool has no parameters and an output schema (as indicated by context), the description provides complete context: it explains the full output (both sections, empty for missing crontab) and confirms read-only nature. No gaps for effective usage.

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

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

No parameters exist, and the description explicitly states this. Since schema coverage is 100% (trivially), the description adds value by confirming absence of parameters and explaining the tool's input independence.

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

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

The description clearly states 'Read the full crontab' (verb 'Lees' is read), specifying the resource (crontab of local root user). It distinguishes from sibling modification tools like cron_add and cron_remove by implying read-only action.

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

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

The description indicates no parameters and no modification, which guides when to use (reading crontab). However, it does not explicitly mention alternatives for specific tasks like checking next runs (cron_next_runs) or enabling cron (cron_enable), so the guidance could be more 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?

With no annotations provided, the description carries the full burden. It discloses important behaviors: uses server time, local timezone, does not modify crontab, requires dependency 'croniter', and bounds parameter `n` to 1-20. It does not cover error handling for invalid schedules, but the key behavioral traits are well covered.

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

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

The description is a short, focused paragraph with each sentence adding value. It front-loads the purpose, then concisely explains constraints and behaviors. No wasted words.

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

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

Given the presence of an output schema (context signal), the description does not need to explain return values. It adequately covers input semantics, behavioral constraints, and dependencies. The tool's purpose is fully captured for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that `schedule` must contain exactly five valid cron fields and `n` determines the number of results (bounded 1-20). This adds significant meaning beyond the schema's type and default, though the exact cron format is not fully detailed.

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 ('Bereken' = calculate) and identifies the resource (future execution times for a cron schedule). It clearly distinguishes this tool from siblings like 'cron_list' (which lists existing cron jobs) and 'cron_add' (which adds jobs) by emphasizing that it does not modify anything.

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 the tool calculates future execution times and explicitly notes it does not modify the crontab, implying it is a read-only analysis tool. While it does not directly say when not to use it or explicitly name alternatives, the context of sibling tools and the nature of the computation provide sufficient guidance.

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

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

No annotations provided, so description carries full burden. It discloses that the tool rewrites root-crontab, removes MCP marker and cron rule, leaves other rules intact, and does nothing for unknown job_id. This covers key behaviors.

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

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

Two short, sentences each carrying essential information. Front-loaded with main purpose. No redundant or unnecessary text.

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

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

Given the tool's simplicity and presence of an output schema, the description covers all needed aspects: purpose, usage, parameter explanation, and behavioral details. No gaps.

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

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

Schema coverage is 0%, but description adds crucial meaning: job_id is the identifier saved by cron_add. This goes beyond the schema's bare type definition. Provides origin and safety note.

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

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

Description clearly states the action (verwijder/remove), resource (één job uit MCP-beheerde sectie), and distinguishes from sibling tools like cron_add and cron_list. The verb and resource are specific.

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

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

Description mentions that job_id comes from cron_add, and that unknown ID causes no removal. This provides context for proper use, though no explicit when-not or alternative tools are given. The context is clear.

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

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

With no annotations, the description covers key behaviors: command splitting (no pipes/redirects), sudo -u execution, system modification capability, timeout of 300 seconds, and return values (stdout, stderr, exitcode, user). However, it lacks details on security restrictions or behavior on command 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 highly concise, using a few short sentences and bullet-like dashes. Every sentence adds value: purpose, execution details, user handling, safety warning, and return values. No unnecessary words.

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

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

The description covers inputs, execution behavior, and return values (especially since an output schema exists). It alludes to safety and timeout. However, it does not mention prerequisites, failure modes, or interaction with sibling tools, leaving some gaps.

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

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

Schema coverage is 0%, so the description must compensate. It explains that 'command' is a program string split into arguments (no shell syntax), and 'user' defaults to null (root) and runs via sudo -u. This adds significant meaning beyond the schema types.

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

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

The description clearly states the tool executes a local program as root or a specified user. It uses a specific verb ('uitvoeren') and resource ('lokaal programma'), and distinguishes from sibling tools like python_run, wp_cli, and git_command which target specific runtimes.

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 appropriate use (simple commands without shell syntax) but does not explicitly state when to use this tool versus alternatives like python_run or git_command. No direct comparison or conditions for non-use are provided.

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

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

No annotations provided, so description carries full burden. It discloses the returned data (server type, IP, name) and implies a read operation. Does not mention side effects or failure modes, but for a simple info tool 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?

Two concise sentences in Dutch, front-loaded with the action. Every sentence provides value with no fluff. Highly efficient.

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

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

The description covers the essential information about what the tool returns. An output schema exists (though not provided), so return values are documented structurally. The tool is simple and the description is complete for its purpose.

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

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

No parameters exist, so baseline 4. The description adds no parameter info, but none is needed as the input schema is empty.

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

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

The description clearly states the tool returns server type, IP address, and name to identify the MCP server instance, with a specific verb 'Geef informatie' and resource 'deze MCP server instance'. It uniquely distinguishes from siblings which handle other tasks.

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 usage is implied: use to identify the server. No explicit when-not or alternatives are needed given the tool's uniqueness among siblings. The description is clear enough for an agent to infer usage context.

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

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

With no annotations provided, the description carries full burden. It only states 'list of services that this server may manage (status/restart)', but does not disclose if the operation is read-only, what the return format is, or any potential side effects.

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

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

A single sentence, front-loaded with the key action, no unnecessary words. Highly concise.

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

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

Given no output schema shown and no annotations, the description is minimally adequate. It covers the basic purpose but lacks details on return values or usage context.

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

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

There are no parameters (schema coverage 100% with empty object). The description adds no parameter info, but baseline for 0 parameters is 4.

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

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

The description clearly states that this tool lists services the server can manage (status/restart). It uses a specific verb 'list' and resource 'services', distinguishing it from sibling tools like restart_service or 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?

While the description implies usage for viewing manageable services, it lacks explicit guidance on when to use this tool versus alternatives (e.g., service_status for individual service status) and no when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool lists allowed sites (read-only), but does not elaborate on behavior such as whether the list is cached, dynamic, or requires specific permissions. The description is acceptable but minimal.

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

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

The description is a single, clear sentence with no unnecessary information. It is well-structured and front-loaded.

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

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

Given the tool has no parameters, an output schema is provided, and the description is simple, the description is adequately complete. It conveys the core purpose without missing critical details.

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 100% schema coverage, so the baseline is 4. The description does not need to add parameter information.

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

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

The description uses a specific verb 'List' and identifies the resource 'WordPress roots' with a clear scope 'for which WP-CLI is allowed.' It clearly distinguishes from sibling tools like wp_plugin_list or wp_user_list.

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

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

The description states what the tool does but provides no explicit guidance on when to use it versus alternatives, such as wp_cli or wp_plugin_list. Usage is implied by the tool's purpose.

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?

Despite no annotations, the description discloses blocked commands, mutation potential, timeout, and return values. It lacks detail on whether the tool changes working directory or has side effects beyond the repo, but overall provides strong behavioral context.

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

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

The description is concise (5 sentences) and front-loaded with purpose. Every sentence adds value (path constraint, command parsing, blocked commands, timeout, return). No unnecessary words.

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

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

Given 2 params, no annotations, and the presence of an output schema, the description sufficiently covers constraints, blocked operations, and return values. It is complete for the tool's complexity.

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

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

With 0% schema coverage, the description compensates by explaining path constraints (allowed_write_dirs, .git) and command structure (after git -C <path>, shell-like quoting, no expansion). It adds meaning beyond the schema, though an example would improve clarity.

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 executes a Git subcommand in an allowed local repository, distinguishing it from siblings like execute_shell_command. The verb 'uitvoeren' (execute) and resource 'Git-subcommando' are specific and unambiguous.

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

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

The description specifies when to use (Git operations in allowed repos) and provides explicit constraints: path must be under allowed_write_dirs and contain .git, blocked commands are listed, and quoting behavior is described. It could be improved by explicitly contrasting with execute_shell_command for non-Git tasks.

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

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

No annotations exist, so the description carries full weight. It discloses the directory restriction but lacks details on edge cases (e.g., n larger than file length), error handling, or performance. Basic behavior is covered, but not comprehensively.

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

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

Single sentence, front-loaded with the core action. Very concise, but the Dutch language may reduce readability for non-Dutch agents. No wasted words.

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

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

For a simple tool with only two parameters and an existing output schema, the description covers the primary function and a key constraint. It does not detail return format or errors, but those are likely covered by the output schema.

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

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

Schema has no descriptions (0% coverage). The description explains what 'n' represents (number of lines) and implies 'path' is the file. This adds basic meaning but could be more explicit, especially for 'path'.

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

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

The description clearly states the tool reads the first n lines of a file under allowed directories. It includes a key constraint (ALLOWED_READ_DIRS) and distinguishes itself from siblings like 'tail' or 'read_file' by specifying the head behavior.

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

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

The description implies when to use this tool (to view the beginning of a file) and mentions a restriction (only under ALLOWED_READ_DIRS). It does not explicitly mention when not to use it or alternatives, but the context is clear for a simple file utility.

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

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

No annotations present, so description fully covers safety (no modifications), behavior (error handling for inaccessible items), return data per item (name, path, type, modification time, size), and response format. This is thorough.

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

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

Well-structured with clear sections, but slightly verbose (e.g., 'Resultaten gebruiken de standaard...'). Still, every sentence adds value; no redundancy.

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

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

Given the output schema exists and description explains return fields and response structure, the tool is fully documented. All key behaviors and constraints are covered for an agent to correctly select and invoke it.

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

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

Schema description coverage is 0%, but description adds meaning for all 5 parameters: path constraints, pattern glob syntax, include_dirs/include_files toggles, max_items bounds. This fully compensates 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?

States explicitly 'Bekijk gefilterde directory-inhoud zonder het bestandssysteem te wijzigen' (view filtered directory contents without modifying filesystem). Differentiates from siblings like read_file, head, tail which read file contents.

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

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

Specifies prerequisites: path must be an existing directory under allowed_read_dirs. Provides pattern syntax guidance. Implicitly suggests use of read_file, head, tail for subsequent content reading, but lacks explicit when-not-to-use statements for other 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?

With no annotations, the description carries full burden. It explicitly states the tool is non-destructive and only returns a path, plus describes error handling. This adds behavioral context beyond basic functionality.

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 succinct at two sentences, with the main action upfront. It could be slightly tighter, but the structure is effective.

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

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

Given no parameters and an output schema (not provided), the description explains the core behavior, selection order, and error condition. It is complete enough for an agent to use correctly.

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

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

The tool has zero parameters, so schema coverage is 100%. The description does not need to add parameter details, and it correctly omits them.

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

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

The description clearly states the tool's purpose: selecting the first existing WordPress debug log path from a configuration list. It differentiates from sibling tools like log_tail by focusing on path discovery rather than reading the log.

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

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

The description explains the testing order from `wp_log_candidates` and return behavior, but does not explicitly contrast with alternatives. The implied usage is to obtain a path before using other log tools.

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

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

With no annotations provided, the description fully discloses behavioral details: it is read-only, case-sensitive, returns a specific output format {success, data, error, meta}, and handles missing files with a NOT_FOUND error. No contradictions.

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

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

The description is concise and well-structured, front-loading the main purpose and then detailing parameters and behavior in a logical order. Every sentence adds value without repetition or fluff.

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

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

Given the parameter count, lack of annotations, and presence of an output schema, the description covers all necessary aspects: input requirements, default behavior, error states, output format, and comparison to sibling tools. No gaps remain.

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

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

The schema has 0% description coverage, but the description explains all parameters: 'n' (number of lines to read before filtering), 'path' (specific file under allowed_log_dirs or default fallback), and 'keywords' (non-empty strings, case-sensitive matching). This adds critical meaning beyond the raw schema.

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

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

The description clearly states the tool's function: searching literal keywords in the last lines of a log file. It explicitly distinguishes from the sibling 'tail' tool, saying to use tail when no filtering is needed, which helps avoid ambiguity.

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

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

The description provides explicit guidance on when to use this tool versus alternatives, such as when filtering is needed, and gives specific instructions for each parameter, including the requirement that keywords must be non-empty and case-sensitive.

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

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

With no annotations, the description carries full burden. It discloses running as root, blocking destructive keywords, allowing other mutating statements, a 30-second timeout, and returning stdout. It could mention error handling or output format, but overall it is transparent.

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

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

The description is concise (5 sentences), well-structured, and front-loaded with the main purpose. Every sentence adds value without redundancy.

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

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

Given the output schema exists, the description adequately covers return (stdout). It also addresses security, timeout, and parameter constraints. It could mention multi-statement support or error messages, but it is sufficiently complete for a straightforward tool.

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

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

Schema coverage is 0%, so the description fully compensates. It explains that 'query' is the full SQL text and must not be empty, and 'database' optionally selects a database with a default context. This adds meaning beyond the schema types.

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

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

The description clearly states the tool executes SQL using the local MySQL client as root. It specifies the verb 'execute' and resource 'SQL', and provides details about the query and database parameters, making the purpose unambiguous.

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

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

The description explains when to use (for running SQL) and lists blocked keywords (DROP, TRUNCATE, DELETE, ALTER), giving clear constraints. No alternative tools are explicitly mentioned, but sibling tools are not similar, so no direct comparison is needed.

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

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

With no annotations, the description fully discloses behavioral traits: non-modifying, 60s timeout, and return of output/exitcode/success. This adds significant transparency beyond the schema.

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

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

Three sentences, front-loaded with purpose, no unnecessary words. Efficient and clear.

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

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

For a simple ping tool with an output schema (indicated), the description covers key aspects: purpose, input constraints, safety, timeout, and return values. Minor omission: does not specify whether host is IP or hostname, but overall complete.

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

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

Schema has 0% parameter descriptions, so the description compensates by specifying host format restrictions (letters, digits, dots, hyphens) and count limit (1-10). This adds meaning beyond the raw schema.

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

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

The description clearly states the tool tests network reachability via ICMP-ping, which is a specific verb+resource. No sibling tool has similar purpose, so it is well-distinguished.

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

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

The description provides constraints on input (host format, count range) but does not explicitly state when to use this tool vs. alternatives or when not to use it. Usage context is implied but not defined.

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

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

Without annotations, the description carries full weight. It details execution environment (minimal PATH, PYTHONUNBUFFERED, sandbox_cwd), timeout (8 seconds), side-effect potential within MCP service process rights, and explicit return fields (stdout, stderr, exitcode, success). This exceeds typical transparency.

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

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

The description is compact, front-loaded with purpose, and each sentence adds essential information (command, environment, timeout, side effects, output). No redundant or missing 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?

Given a single required parameter and an assumed output schema, the description provides complete context: input specification, execution behavior, environment constraints, timeout, and output summary. It is self-contained and 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?

With 0% schema description coverage, the description compensates by stating that `code` is mandatory Python source code executed via `-c`, adding meaning beyond the schema's plain string type. It could further clarify that the code must be a valid Python expression or statement, but the current explanation is sufficient.

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

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

The description clearly states it executes a short Python fragment in a configured sandbox directory using a specific interpreter invocation (`python -S -c`). This verb+resource combination distinguishes it from siblings like `execute_shell_command`, which runs arbitrary shell commands.

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

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

The description implies usage for Python code execution but does not explicitly state when to use this tool versus alternatives (e.g., `execute_shell_command`). No exclusion criteria or contextual hints are provided beyond the fact that it runs Python.

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?

Despite no annotations, the description thoroughly discloses behavior: no modification, file must exist and be regular, max_bytes clamping, UTF-8 decoding with replacement, truncation indicator, and error responses.

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

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

The description is a single paragraph but is well-structured: opening purpose, then constraints, behavior, response format, and finally alternative tools. It is concise yet comprehensive.

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

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

Given no annotations and the presence of an output schema, the description covers all necessary context: purpose, file requirements, parameter details, truncation behavior, error handling, and sibling tool distinctions.

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

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

Although schema coverage is 0%, the description explains both parameters: path must be an existing regular file, max_bytes has a default and is clamped between 1 and a configured limit. This adds meaningful context beyond the schema.

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

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

The description clearly states the tool reads a text file under allowed directories without modifying it. It distinguishes itself from siblings by indicating when to use head or tail instead.

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

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

Explicit guidance is given: 'Use `head` or `tail` when only lines at the beginning or end are needed.' This tells the agent when not to use this tool.

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

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

No annotations are provided, so the description carries the full burden. It mentions using systemctl reload, implying it is safe and non-destructive, but does not elaborate on other behavioral aspects such as connection handling or logs.

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

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

Two concise sentences that front-load the primary action and usage guidance. No extraneous information.

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

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

Given an output schema exists, return values need not be described. The tool is simple with one parameter; the description covers purpose and usage well. However, a bit more detail on what the reload does (e.g., reloads configuration) 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 single parameter 'name' is a string for the service name. The description does not add any additional meaning beyond the schema, but the schema is minimal and obvious. Schema description coverage is 0%, but the parameter is straightforward.

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

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

The description clearly states 'Herlaad een service via systemctl reload' which is a specific verb and resource. It also distinguishes from the sibling 'restart_service' by noting it is the preferred action.

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

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

Explicitly states to prefer reload over restart to minimize impact, and specifies the condition for using restart_service when reload is not supported or explicitly needed.

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

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

Describes default reload behavior, implications of force_restart (service interruption, process termination), permissions, timeout, blocked MCP service, and error conditions. No annotations provided, so description fully covers behavioral traits.

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

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

Single paragraph covering all aspects, but slightly dense. Could benefit from slight structuring, but every sentence adds value.

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

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

Covers purpose, parameters, behavior, prerequisites, alternatives, response format, and error conditions. No missing elements given the tool's complexity and absence of 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 has 0% description coverage; description explains name must be in whitelist and force_restart controls reload vs restart, adding critical meaning beyond schema.

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

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

The description clearly states the tool reloads or restarts a systemd service, with specific verbs and resource. It distinguishes from sibling tools reload_service and 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?

Explicitly states when to use (reload vs restart via force_restart), when not to use (prefer reload_service or service_status), and prerequisite (name must be in whitelist, consult get_service_whitelist).

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

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

With no annotations, the description fully discloses that the tool only runs 'systemctl is-active', does not modify the service, has a 10-second timeout, and returns both active and inactive messages as text.

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

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

The description is two sentences, front-loaded with the main action, and every sentence adds necessary information without verbosity.

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

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

For a simple read-only status check tool with an output schema implied, the description covers purpose, precondition, behavior, timeout, and return format. It is 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 one parameter ('name') with 0% coverage. The description adds crucial context: the name must exactly be in 'service_whitelist', which is not present in the schema.

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

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

The description clearly states it reads the active systemd status of an allowed service using 'systemctl is-active', distinguishing it from sibling tools like 'reload_service' or 'restart_service' which modify services.

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 specifies that 'name' must exactly be in 'service_whitelist', giving clear context for when to use. It does not explicitly list when not to use or alternatives, but the purpose is clear enough.

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

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

No annotations provided, so description carries the burden. It declares read-only, 10s timeout, and standard response format. However, it omits details like error handling for non-existent files or behavior with large files.

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

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

Three sentences, front-loaded with purpose, no fluff. Every sentence adds value: purpose, constraints, and behavioral notes.

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

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

With an output schema present, the description need not detail return values. It covers purpose, constraints, read-only nature, and timeout. Missing mention of what happens if file doesn't exist or n is invalid, but these are minor 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 coverage is 0%, so description compensates well: explains that 'path' must be an existing file under allowed_dirs, and 'n' is the number of lines passed to 'tail -n'. This adds meaningful context beyond the schema's type and default.

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

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

The description clearly states it reads the last n lines of a specific log file. While it distinguishes from siblings like 'head' and 'read_file' by specifying 'logbestand', it does not explicitly differentiate from similar 'log_tail' siblings.

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

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

No explicit guidance on when to use this tool versus alternatives like 'log_tail' or 'head'. Only constraints on path and n are given, but no 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?

With no annotations, the description fully discloses mutating behavior, execution as www-data or root, timeout, and return values.

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

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

Concise single paragraph, front-loaded with main action, logically ordered.

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

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

Covers purpose, prerequisites, parameters, execution details, and return values; output schema exists for return format.

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

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

Schema has no parameter descriptions (0% coverage); description adds meaning for site_path (prerequisite) and as_www_data (role switching).

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 'Wis' (clears) and resource 'WordPress-objectcache van één toegestane site', specific and distinct from siblings like wp_cli.

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?

Prerequisites are given (site_path in allowed_sites and contains wp-config.php), but no explicit guidance on when to use this vs alternatives like wp_cli.

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

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

With no annotations, description fully discloses constraints (allowed sites, wp-config.php), shell quoting (no expansion), potential site modification, user context (www-data vs root with --allow-root), timeout (60s), and return values (command, stdout, stderr, exit code). No contradictions.

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

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

Description is concise and front-loaded with the main action. Each sentence adds value, covering parameters, behavior, and constraints without unnecessary verbosity.

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

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

With an output schema present, description covers all necessary context: prerequisites (site_path constraints), execution behavior (shell quoting, user context, timeout), and result contents. Adequate for the tool complexity.

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

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

Schema coverage is 0%, but description adds meaning for all three parameters: site_path (required allowed site), args (shell-like quoting without expansion), as_www_data (default true, if false runs as root with --allow-root).

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

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

Description clearly states the tool executes WP-CLI arguments on allowed WordPress sites. It differentiates from sibling tools like wp_cache_flush, wp_plugin_list, and wp_user_list by specifying general WP-CLI command execution.

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

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

Provides clear prerequisites: site_path must be in wp_allowed_sites and contain wp-config.php. Explains argument quoting behavior and user context options, but does not explicitly state when to use this tool over 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?

With no annotations, the description reveals key behaviors: the command executed, default user (www-data) and root option, read-only nature, and 60-second timeout. This covers safety and execution context well, though error handling is not mentioned.

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

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

The description is efficient: four sentences in Dutch (similar length in English) that front-load the purpose and then detail prerequisites, execution, and behavior. No unnecessary words.

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

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

The tool has an output schema, so return values are not needed. The description covers prerequisites, parameter behavior, and execution context (timeout, user). It is adequately complete 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 coverage is 0%, so the description compensates by explaining site_path must be in allowed sites and contain wp-config.php, and as_www_data controls user context (www-data vs root). This adds meaning beyond type/optionality.

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 reads installed WordPress plugins of an allowed site (verb 'Lees' + resource 'WordPress-plugins'). It is specific but does not explicitly differentiate from sibling tools like wp_cli which can also run 'wp plugin list'.

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

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

The description provides prerequisites (site_path must be in wp_allowed_sites and contain wp-config.php) and states the operation is read-only. However, it lacks explicit guidance on when to use this tool vs. alternatives (e.g., wp_cli for custom plugin commands).

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 states the intended operation is read-only and provides a 60-second timeout. It details the underlying command and user execution context (`www-data` vs. root). This fully covers behavioral traits beyond what annotations (none were provided) would 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 concise (4 sentences) and front-loaded with the primary purpose. Every sentence provides essential information: output format, prerequisites, execution details, and behavioral notes. No redundant or filler content.

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

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

Given the tool's simplicity (2 parameters, no annotations, output schema exists but not described), the description is complete: it covers purpose, prerequisites, behavior, parameters, and constraints. The presence of an output schema in context reduces the need to detail return values here.

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

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

With 0% schema description coverage, the description fully compensates by explaining both parameters: `site_path` must be a valid WordPress site path, and `as_www_data` controls execution as `www-data` (default) or root. This adds meaningful guidance beyond the bare schema type/required flags.

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

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

The description clearly states the tool's purpose: reading WordPress users from a specified site and outputting JSON. It specifies the exact command (`wp user list --format=json`) and conditions (`site_path` must be in `wp_allowed_sites` and contain `wp-config.php`). The resource (WordPress users) is distinct from sibling tools like `wp_plugin_list` or `cron_list`, providing implicit differentiation.

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

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

The description explicitly states prerequisites: `site_path` must be in `wp_allowed_sites` and contain `wp-config.php`. It also mentions the default user context (`www-data`) and the option to run as root with `--allow-root`. While it doesn't compare to alternatives, the context is clear and actionable for deciding when to use this tool.

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