DirectAdmin MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.6.0
Disambiguation3/5
Most tools are clearly separated by resource prefix and action, and the descriptions are unusually detailed about when to prefer one tool over another (e.g., ssl_reissue_domain vs ssl_admin_reissue, csf_unblock_ip vs firewall_unblock_everywhere). However, there are several near-overlapping pairs such as email_autoresponders_list vs email_vacation_list, users_search vs search_resources vs users_exists, and multiple reissue/status tools that could cause misselection without careful reading.
Naming Consistency4/5
The overwhelming majority of tools follow a predictable resource-prefix + verb pattern (users_list, ssl_reissue_domain, db_create, services_restart), which scales well across 303 tools. There are minor deviations like search_resources, policy_status, system_info, and wp_locations where the action is missing or reversed, but these do not seriously undermine the overall pattern.
Tool Count1/5
With 303 tools, this is far beyond the range where an agent can reliably select among options, and it imposes a massive context-window and prompt-selection burden. Many tools are also unnecessarily granular (system_cpu, system_memory, system_load, system_disk, system_uptime could be a single system_stats tool), so the count is not justified as a cohesive minimal surface.
Completeness4/5
The surface is exceptionally broad, covering users, resellers, domains, DNS, email, SSL, databases, files, backups, services, CloudLinux, WordPress, git, plugins, and system configuration. Gaps exist in some subdomains (e.g., no DNS zone create/delete, no git create/delete, no WordPress update), but the generic da_api and da_legacy tools provide an escape hatch, and most primary CRUD workflows are present.
Average 3.2/5 across 258 of 303 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose whether this is a read-only listing or a destructive operation. It does not; the phrase 'can remove' suggests capability but never states effects, side effects, or whether confirmation is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is very short, but this is under-specification rather than efficient conciseness. The single sentence lacks enough content to be useful, so brevity is not earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and an uninformative description, the agent cannot determine whether calling this tool is safe, whether it returns a list or performs a mutation, or how it relates to sibling CustomBuild tools. The existing output schema cannot compensate for missing semantic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameters to document. With 0 params, the baseline is 4; the description does not need to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Software CustomBuild can remove' without stating whether the tool lists removable software, performs removal, or configures removal options. The plural name 'cb_removals' hints at a list but the text does not confirm this, and it fails to distinguish the tool from siblings like cb_run, cb_kill, or cb_updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use cb_removals versus the many related cb_* tools. No context, alternatives, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says "Check a database" without stating whether this is read-only, what it verifies, what side effects may occur, or what failure behavior looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. The two lines essentially repeat the name and schema field without adding meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description fails to define what "check" means, what state or result is produced, or when this tool is the correct choice. A simple tool still needs enough behavioral context to be safely invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only "Name" for the database parameter, which barely goes beyond the schema's existing title of "Database" and provides no format, examples, or clarification of which database identifier is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Check a database" is a near-verbatim restatement of the tool name and provides no detail about what kind of check is performed. It does not distinguish db_check from db_info, db_get, db_repair, or db_server_config_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling database tools. No alternatives, conditions, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses no read-only nature, side effects, error behavior, authentication needs, or response shape. 'One database user.' says nothing about what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and has a clear Args label, but it is under-specified rather than efficiently concise. The main sentence contributes little meaning and could describe almost any database-user operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema is present, the description lacks the behavioral and usage context needed to call this tool correctly. It provides only the resource concept and one parameter, leaving the agent without enough information to understand the operation's scope or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 repeats that 'dbuser' is a DB username, which adds minimal meaning beyond the parameter name. It does not explain expected format, uniqueness, or how the value is used in the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'One database user.' is a noun phrase, not an action statement. It does not explicitly say the tool retrieves or returns a database user, so an agent must infer the verb from the tool name. It weakly distinguishes from plural database-user tools, but the purpose is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like db_users, db_get, or db_create_user. No context, prerequisites, or exclusions are provided, so the agent receives no help in selecting among the many sibling database tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it discloses almost nothing. It never states that the tool performs a read operation, what side effects it might have, or what happens when entry_id is omitted. 'One ModSecurity audit entry' reads as an object definition rather than a description of tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but brevity here is under-specification, not conciseness. 'One ModSecurity audit entry' plus an Args stub leaves out the operational meaning of the tool. While there is no fluff, the few words present do not earn their place because they add little beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with one optional parameter and an output schema, the description is incomplete for an agent trying to decide among many audit-related siblings. It omits the tool's action, the relationship of entry_id to the audit log, and the distinction from audit_search and modsecurity_audit_summary. The output schema reduces the need to explain return values, but the core usage context is still absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 schema's silence, but it barely does. 'entry_id: Optional entry identifier (query)' adds only the vague qualifier 'query' and repeats what the schema already implies via the title 'Entry Id' and the default value. It does not explain entry_id format, where it comes from, or what omission of the parameter means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'One ModSecurity audit entry,' which is essentially a restatement of the tool name and names the resource without stating an action. There is no verb such as 'gets,' 'retrieves,' or 'returns,' so an agent cannot tell whether this tool fetches, lists, or creates an entry. It also does not distinguish this tool from sibling audit tools like audit_search or modsecurity_audit_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as audit_search, audit_recent, or modsecurity_audit_summary. It does not mention prerequisites, how to obtain an entry_id, or what makes this tool the right choice. The only context is the optional entry_id parameter, but its intended use is not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not state whether the tool lists the caller's own tickets, all tickets, or requires admin privileges; whether the list is paginated; what statuses are included; or whether it mutates anything. 'Support tickets.' reveals essentially nothing beyond the resource name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity here is under-specification rather than conciseness. It is a fragment ('Support tickets.') that provides no verb, no scope, no output information, and no usage guidance. There is no structure that front-loads useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema but no parameter schema, no annotations, and no usable description. The name suggests a list operation, but the context signals include many sibling tools with similar patterns (inventory_list, users_list, packages_user_list). Without knowing what a 'ticket' is in this domain, what fields are returned, or how the list is filtered, the definition is not minimally sufficient for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so there are no parameters to document. The description could still hint at implicit filters or scoping, but with an empty schema, a baseline 4 is appropriate because no parameter semantics are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Support tickets.' is a noun phrase, not a statement of what the tool does. The name tickets_list implies a listing operation, and the description merely restates the resource. There are sibling tools like message_list and ticket_requests, suggesting different ticket-related actions, but this description fails to distinguish them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 over alternatives like message_list, ticket_requests, or audit_search. There is no mention of supported ticket states, required context, or any exclusions. An agent cannot determine the intended use case beyond guessing from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions GET, which suggests a read-only operation, but also says 'start a scan,' implying side effects. It never states whether calling this endpoint mutates state or what side effects, if any, occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but it is ambiguous rather than concise. The slash-joined 'status / start a scan' requires unpacking, and key operational details are missing. This reads as under-specification, which the calibration distinguishes from effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and return values need not be described, the central question of whether this endpoint starts a scan is left unresolved. The presence of clamav_scan and clamav_kill siblings makes this ambiguity material. An agent cannot confidently invoke this tool correctly based on the current description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline for this dimension is 4. There are no parameter semantics the description needs to add, and no ambiguity exists around argument meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads 'ClamAV status / start a scan (GET),' which combines two possible actions but never states whether this tool returns status, starts a scan, or both. 'ClamAV status' largely restates the tool name, while the slash introduces ambiguity. Since a sibling clamav_scan exists, the description does not clarify what this tool uniquely does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context or alternative routing is provided. The phrase 'start a scan' overlaps with the sibling tool clamav_scan and could mislead an agent into choosing this tool for scan-triggering behavior when another tool may be the intended one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it discloses nothing beyond a domain reference. It does not say whether the tool lists tasks, imports them, checks status, or performs another operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but this is under-specification rather than useful conciseness. The only sentence adds no operational value and does not earn its place as a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description should clarify what kind of operation this is and what the returned data represents. 'cPanel import tasks' leaves the agent unable to determine the tool's purpose or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics for the description to clarify. Per the rubric, zero parameters earn a baseline score of 4 because there is no parameter-level gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'cPanel import tasks,' which merely restates the tool name as a noun phrase. It names no action (list, create, check, run) and gives no indication of what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, what it is for, or how it relates to siblings like cpanel_import_check_remote or imapsync_import. This is a pure absence of usage context, not misleading wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says nothing about read-only status, side effects, authentication requirements, output format, or whether the tool returns a downloadable document.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short but under-specified rather than usefully concise. 'License proof document.' is a fragment that conveys no actionable content and does not front-load a verb or scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and an output schema, the definition lacks the essential action and selection context. The six-word fragment leaves the tool functionally undescribed, and an agent cannot determine what calling it accomplishes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, so there is no parameter ambiguity for the agent to resolve. The description does not need to compensate for undocumented parameters because the empty schema already provides 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase that essentially restates the tool name with 'document' added; it names no verb or action. It does not indicate whether this tool retrieves, generates, verifies, or uploads a license proof document, and it does not distinguish it from license_get or license_update_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call license_proof versus license_get or license_update_key. The description provides no context about prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It does not explicitly say this is a read-only listing, whether it has side effects, or what type of response is returned. 'Component versions' hints that it is informational, but that is not a clear 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but at the cost of informativeness. It is a fragment rather than a sentence and adds little beyond the tool name. Being short is not the same as being concisely structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema may document return values, but the description still fails to define what 'components' refers to or how this tool relates to the cb_ siblings. An agent could not confidently distinguish cb_versions from similar no-argument informational tools such as cb_updates or cb_software. The description is not complete enough for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameter semantics for the description to explain. The no-parameter baseline of 4 applies because there is nothing the description must clarify about arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only the noun phrase 'Component versions.' It names a resource but provides no verb or action, so it does not actually state what the tool does. It largely restates the tool name cb_versions without adding clarifying meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use cb_versions versus the many sibling tools in the cb_ family, such as cb_updates, cb_state, or cb_software. No conditions, exclusions, or alternatives are mentioned. An agent gets no help choosing among these related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'settings,' which does not reveal whether the operation reads, writes, or affects anything. There is no mention of side effects, permissions, or whether this is a safe read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but it is under-specified rather than concise. It omits the essential action or behavior, so brevity is achieved at the cost of usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, zero-parameter, and has an output schema, the description still fails to state what the tool does. An agent cannot confidently choose between this and email_outbound_filter_update, making the definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so the schema has no parameter burden to carry. Baseline 4 is appropriate; the description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Outbound email filter settings,' is a noun phrase that essentially restates the tool name and provides no verb or action. It identifies the resource but does not say whether this tool gets, lists, or updates those settings, so it fails to distinguish itself even from the nearby email_outbound_filter_update sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to call this tool, when not to call it, or how it relates to email_outbound_filter_update or other email configuration tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It states no side effects, read-only nature, return format, or error behavior. 'One git application' is a static phrase, not a behavioral statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short with no fluff, but it is under-specified. 'One git application' is not a complete sentence and omits the operation. The Args block is structured clearly, but the overall lack of content makes this under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks basic purpose and usage context. It does not explain what a 'git application' is, how this lookup differs from git_list, or what an agent should do with the result. For a simple get-by-uuid tool, the description is not complete enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the uuid parameter, so the description must compensate. It only adds 'Application uuid,' offering minimal clarification that the uuid refers to an application, but no format, example, or indication of how to discover the value. This barely adds meaning beyond the schema title 'Uuid.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'One git application' is a noun phrase that hints at the resource but lacks an explicit operation verb like 'get' or 'retrieve.' It is not a pure tautology since it names the resource type, but it does not distinguish itself from sibling tools like git_list or git_deploy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use git_get versus alternatives such as git_list, git_fetch, or git_webhook. An agent must guess the intended selection criteria and workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'IMAP migration tasks' does not state whether this is a list, create, delete, or status operation, nor does it mention side effects, permissions, or scope. This is essentially missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified rather than concise. It is a fragment that restates the tool name and does not provide enough structure to help an agent invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description fails to clarify the core action of the tool. The presence of multiple imapsync sibling tools makes the missing verb and scope particularly harmful, so the definition is not complete enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 the schema fully communicates that no arguments are accepted. With zero parameters, the baseline is 4, and the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'IMAP migration tasks' is essentially a noun-phrase restatement of the tool name and lacks a specific verb or operation. It does not distinguish this tool from the closely related sibling tools imapsync_import, imapsync_export, or imapsync_cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the alternative imapsync_* tools. The description provides no context about what scenario calls for 'tasks' versus import, export, or cancel operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says nothing about side effects, read-only nature, return behavior, or error conditions. A bare noun phrase provides no behavioral transparency at all.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, so it is concise, but it is under-specified to the point of being a fragment. It is not structured with an action-first framing that would help an agent parse intent quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has an output schema and no parameters, the description fails to convey what the tool actually does. An agent cannot determine the operation, expected result, or relationship to sibling inventory tools from this text alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to disambiguate. Baseline for 0 params is 4; the description does not need to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase, not a verb statement. It identifies the DirectAdmin box but never says what action inventory_this performs. It also fails to distinguish itself from siblings like inventory_get or inventory_list because it lacks an action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling inventory tools. The phrase 'this MCP process is wired to' implies a specific server, but no explicit context, exclusions, or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral disclosure. It states no side effects, read-only nature, permissions, or invocation behavior. The description provides essentially no behavioral information beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified rather than concise. It is a fragment that adds little actionable information and does not earn its place as a definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there are no parameters and an output schema exists, the missing action verb leaves the tool's purpose ambiguous. The description also fails to differentiate this tool from the many related ModSecurity sibling tools, so an agent cannot confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline of 4 applies. There is no parameter-level meaning for the description to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Global ModSecurity configuration.' is a noun phrase, not an action. It essentially restates the tool name and does not specify whether the tool retrieves, updates, enables, or disables the configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus closely related siblings such as modsecurity_global_update, modsecurity_all_configs, modsecurity_user_configs, or modsecurity_host_config. An agent cannot determine the appropriate selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior itself, but it says only 'ModSecurity config for one hostname.' It does not state whether the operation is read-only or mutating, whether it requires the hostname to exist, or what side effects may occur. This leaves the tool's behavioral profile essentially undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is very short and avoids fluff, and the argument note is front-loaded after the main phrase. However, the brevity comes at the expense of a missing verb and behavioral context, so it is under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, output schema present) yet the description omits the core operation (read vs. write) and any usage context. With no annotations, an agent would not know what invoking it accomplishes or how it relates to the ModSecurity sibling tools. The description is not complete enough for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the type and title 'Hostname' with no description, so coverage is 0%. The description adds a small amount of meaning by equating hostname with 'vhost name,' but does not explain the expected format or provide examples. It partially compensates for the missing schema description but is thin for a single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a noun phrase that restates the tool name ('ModSecurity config for one hostname') and does not specify whether the tool retrieves or modifies the configuration. It identifies the resource and hostname scope, but the missing verb leaves the operation ambiguous. This is closer to a tautology than a clear definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings such as modsecurity_global, modsecurity_all_configs, or modsecurity_user_configs. There is no mention of prerequisites, exclusions, or alternative tools. An agent has to infer the appropriate context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. 'Session UI state' does not state whether this is a read-only operation, whether it has side effects, or what it returns. There is no useful 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words and contains no filler, but this is under-specification rather than effective conciseness. It does not earn its place because it adds almost no operational meaning beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though there are no parameters and an output schema exists, the description is too vague for an agent to decide when to invoke this tool among numerous session-related siblings. It lacks enough context to be considered minimally viable for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is no parameter semantic burden for the description to carry. The baseline of 4 applies because no parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Session UI state' is essentially a rewording of the tool name and lacks an action verb. It tells the agent the broad domain (session UI) but not whether this tool retrieves, sets, or clears that state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use session_state versus the many session-related siblings such as session_get, session_user_config, or session_switch_domain. The description provides no context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely names a 'queue' and says nothing about whether the operation is read-only, what effects it has, what the queue represents, or what response behavior to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than effective conciseness. It omits essential operation and context information while providing only a fragment of a description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with no parameters and an output schema present, the description is incomplete: it does not say what action the tool performs, what the queue contains, or how it differs from nearby tools. An agent cannot reliably select or invoke this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 for the description to clarify. The baseline for a zero-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase ('Ticket requests queue') rather than a statement of what the tool does. It identifies a resource but not an operation, leaving the agent to guess whether this lists, retrieves, or manages ticket requests. It also does not distinguish itself from the sibling tool tickets_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus related siblings such as tickets_list or messages_list. There are no conditions, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Dashboard widgets' says nothing about side effects, read-only status, pagination, permissions, or response behavior, leaving the agent without any behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in length, but this is under-specification rather than effective conciseness. It is a fragment with no verb and no substantive guidance, so it does not earn its place as a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool takes no parameters and has an output schema, 'Dashboard widgets' still omits the operation, the scope of widgets, and any applicable context. An agent can infer some meaning from the name, but the description itself is barely more than a title and is not a complete callable definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so the baseline of 4 applies. The description adds no parameter-level meaning, but none is required because there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Dashboard widgets' is a noun phrase that essentially restates the resource named in the tool. It does not state the action (list/retrieve) and provides no differentiation from other list-style sibling tools such as inventory_list or users_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus any alternative. There are no exclusions, no context about dashboard widget management, and no hint about whether this is the only widget-related tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it fails to provide meaningful detail. It does not state whether repair is destructive or irreversible, what the confirm flag controls, or what happens to the database during repair. The 'confirm: Required' line is misleading because the schema marks confirm as optional with default false, so the description actively misinforms about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the brevity is under-specification rather than disciplined conciseness. The Args block mostly duplicates the schema and includes a false 'Required' flag. Every line should add value, and two of the three lines fail to do so reliably.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a maintenance and potentially destructive operation with no annotations, this description is incomplete. It does not explain the effect of the confirm flag's default false, when repair should be run, or what the output means. The presence of an output schema does not compensate for the missing safety and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 adds almost nothing beyond the schema's titles. 'database: Name' just restates the parameter name, and 'confirm: Required' contradicts the schema, which shows confirm is not required and has a default of false. It never explains what a true confirm value does or what the database name should reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Repair a database.' It conveys the operation's intent and is distinguishable at a high level from read-only database tools like db_info or db_list. However, it doesn't explain how repair differs from sibling maintenance tools like db_check or db_optimize, so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use db_repair versus db_check, db_optimize, or other database maintenance tools. It does not state prerequisites, recommended conditions, or when repair should be avoided. No explicit or even clearly implied usage context is provided beyond the verb 'repair'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it reveals nothing about side effects, read-only vs. write behavior, or system impact. The agent cannot tell if this is a safe getter or a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and easy to scan, but it sacrifices essential content for brevity. It is concise in form yet under-specified in meaning, making it borderline between acceptable brevity and insufficient specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the output schema exists and there are no parameters, the description still fails to state the operation or what the configuration represents. Without knowing whether this returns current settings or modifies them, the description is incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 effectively complete, so the baseline for parameter semantics is 4. The description adds no parameter detail, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase, 'Global email / exim configuration,' which largely restates the tool name without a verb. It does not specify whether the tool reads, writes, or applies configuration, leaving the primary action ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as email_server_config_update or email_outbound_filter. The description provides no context for selecting among the many email-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. 'Reseller configuration.' does not indicate whether the call is read-only, requires special permissions, or has side effects. It provides no behavioral disclosure beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and structurally clean, but the first line 'Reseller configuration.' mostly restates the tool name and does not earn its place. The Args block is the only substantive content, making this under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required string parameter and an output schema, the tool is simple, but the description still lacks enough context for an agent to confidently route to it among many sibling tools. It does not explain what configuration data is returned, whether the operation is safe, or how it differs from related getter tools. This is below minimum viable completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args line adds meaning by clarifying that `username` is 'Reseller name', which is a useful semantic over the schema's generic 'Username' title. However, it stops there: no format, example, or validity constraint is provided, so it only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads 'Reseller configuration.' which identifies the resource but does not state an action like 'get', 'retrieve', or 'list'. The verb only appears in the tool name itself, leaving the actual purpose vague and indistinguishable from sibling tools such as users_get_config or resellers_get_usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention selecting this over users_get_config, resellers_list, or resellers_get_usage, nor does it state any prerequisites or context. The only added content is a parameter note, not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a database user' and lists arguments; it does not disclose permissions required, side effects, whether confirmation gates the action, or any failure modes. The claim that 'confirm: Required' also conflicts with the schema, where confirm is not required and has a default of false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than efficient conciseness. It lacks necessary parameter details and provides no actionable context. The argument list is minimal and one entry is inaccurate relative to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations, vague parameters, and no usage guidance, the description is incomplete. An agent cannot determine what a valid payload looks like, what 'confirm' controls, or how this differs from db_create_with_user. Even with an output schema present, the input semantics remain critically under-defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 barely does. 'payload: User body' is vague and unhelpful, especially since payload is an open-ended object with additionalProperties true. 'confirm: Required' is misleading because the schema marks only payload as required and gives confirm a default. No parameter structure, meaning, or allowed values are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a database user.' This distinguishes it from related siblings like db_create (create a database) and db_delete_user (delete a user), though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as db_create_with_user, db_create, or db_user_get. The 'confirm' argument is mentioned but not explained as a usage condition, and no prerequisites or context are described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry side-effect and safety disclosure. It only says 'Update' and mentions confirm, without explaining whether changes are destructive, irreversible, instant, or require a restart. It also does not clarify what confirm actually does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and front-loaded, but the Args block adds little value and one line actively conflicts with the schema. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The agent cannot construct a correct call: the values object is unrestricted and undocumented, confirm's role is ambiguous, and no valid settings or required fields are described. The existence of an output schema does not compensate for the missing input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 compensate, but 'values: Config object' merely restates the schema's object type. 'confirm: Required' is misleading because the schema lists only values as required and gives confirm a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and target: 'Update SQL server settings.' This makes the tool's purpose identifiable and distinct from related read/test tools such as db_server_config and db_server_config_test, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. There are no prerequisites, no scenario hints, and no contrast with db_server_config or db_server_config_test. The only extra line is about confirm, which reads as a parameter note rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description needs to disclose the tool's behavior, but 'Email log summary' only hints that it produces a summary. It does not state whether it is read-only, what time range or scope it covers, whether authentication is required, or what the output contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-pecified rather than effectively concise. It is a noun phrase with no actionable structure and does not front-load any information beyond what the tool name already conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with zero parameters and an output schema present, an agent selecting among many email-related tools needs more than a tautological fragment. The definition fails to explain what kind of summary is provided or how it differs from email_logs and email_logs_user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and an empty input schema, so there are no parameter semantics for the description to clarify. The zero-parameter baseline of 4 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Email log summary' essentially restates the tool name with underscores removed. It lacks a clear verb or resource-action structure, so an agent cannot tell what kind of summary is produced or what data it covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of siblings such as email_logs or email_logs_user. The agent is left to infer that this is for summaries rather than raw log retrieval, but the description never says so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects, but it only says 'Update,' which is already in the tool name. It does not explain what changes are applied, whether confirmation is needed to commit the update, what happens to existing filter settings, or whether the operation is reversible. The 'confirm: Required' line hints at confirmation but contradicts the schema and lacks context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, but brevity here is under-specification rather than conciseness. The argument lines add little information, and 'confirm: Required' is potentially misleading. Not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, incomplete schema descriptions, and no behavioral detail, the description is far from sufficient. An agent cannot know what fields the filter object should contain, what 'confirm' controls, or what the response indicates. The existence of an output schema does not compensate for these missing operational semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the schema permits any object for 'values', so the description must compensate. It only says 'values: Filter object,' which is essentially the same as the schema's object type and provides no meaningful structure or valid keys. The 'confirm: Required' line is factually inconsistent with the schema, where 'confirm' is optional with a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Update outbound email filter.' This is specific enough for an agent to know the general operation. However, it adds no differentiation from the sibling tool 'email_outbound_filter', aside from the verb already visible in 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.
Usage Guidelines2/5
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 instead of alternatives. There is no mention of the sibling 'email_outbound_filter' for reading the current filter, no exclusions, and no prerequisite or confirmation semantics beyond the misleading 'confirm: Required.' The usage context must be inferred entirely 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Create a login URL' and gives no side effects, security implications, permissions, or confirmation semantics. The 'confirm' parameter is mentioned but its behavioral effect is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but its argument stubs do not earn their place. 'Create body' and 'Required' are under-specifications rather than helpful conciseness, making the structure present but uninformative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested, unconstrained payload object, no annotations, and an output schema, this description is grossly insufficient. An agent cannot determine the required payload shape, the meaning of confirm, the return value, or the behavioral side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 'payload: Create body' is empty filler and 'confirm: Required' actually contradicts the input schema, where confirm is not required and has a default of false. No meaning is added to either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a login URL.' This clearly identifies the operation among siblings like login_urls_list and login_urls_delete. It does not explicitly distinguish itself from login_url_one_shot, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 login_url_one_shot or login_urls_list. The description merely states the action and provides weak argument stubs, leaving the 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It never states whether the fix is destructive, reversible, requires elevated permissions, or what side effects may occur. The presence of a confirm argument hints at a high-impact action, but the description does not confirm or explain this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the action statement, but it is under-specified rather than efficiently concise. The argument section adds almost no useful information and one line is factually misleading about confirm being required.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an action tool with no annotations and a misleading parameter note. An agent cannot determine when to apply a maintenance fix, what the fix does, what confirm means, or what risks are involved. Even with an output schema present, the description leaves critical decision-making context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 schema's silence. It adds minimal meaning for 'task' by calling it a Task id, but it says 'confirm: Required' while the schema marks only task as required and gives confirm a default value. This is misleading and fails to explain what confirm is for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action verb and resource: 'Apply a maintenance fix.' This distinguishes it as an action tool from nearby read-only siblings like maintenance_list and maintenance_check. However, it never explains what a 'maintenance fix' actually does, so it is not fully self-contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, when not to use it, or which sibling alternatives might be relevant first. The description only lists arguments and gives no context about prerequisites or workflow relationships.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It does not state whether this is a read-only operation, whether it returns a list or a single package, or what side effects, if any, it has. Mentioning the endpoint path adds some context, but not enough behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and has no wasted words, but the main sentence is an incomplete noun phrase rather than a clear directive. The Args block is compact and helpful, but the lack of a clear verb hurts overall structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one optional parameter and an output schema present, the complexity is low, but the description still omits essential context. It does not state the default behavior when package is absent, nor does it indicate how this tool relates to packages_reseller_list. A complete definition would say 'List reseller packages; optionally filter by package name.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to the parameter. It does clarify that 'package' is an optional name used in the URL path /api/reseller-packages/{package}, which is useful. However, it does not explain what happens when package is omitted, such as whether all reseller packages are returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Reseller packages via the New API' but uses no verb, so the operation is implied rather than stated. It also does not differentiate from the sibling packages_reseller_list, which likely targets the same resource. The endpoint path is the only concrete clue, but the agent must infer that this fetches reseller packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. In particular, packages_reseller_list is a close sibling, but the description never explains when one should be chosen over the other. The optional package argument hints at singular vs collective behavior, but this is not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing that this is a disruptive operation, but it only says 'Disable Redis.' It does not state potential impact, reversibility, or whether confirmation is actually enforced. Worse, the description says confirm is required while the schema marks it optional with a default of false, making the behavior less transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no filler text. However, the brevity veers into under-specification, and the 'Args' section adds a misleading detail rather than earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and minimal schema detail, the description omits critical context: what exactly gets disabled, whether the action can be reversed, what confirmation means, and how this relates to redis_status or redis_enable. The existence of an output schema does not compensate for this missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% coverage for parameter semantics, so the description needed to explain what confirm means and what values are accepted. It only says 'confirm: Required,' which adds little meaning and actively contradicts the schema's optional default. This is insufficient compensation for the missing schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
'Disable Redis' clearly names a verb and resource, and given sibling tools like redis_enable and redis_status, an agent can infer this turns off the Redis service. It stops short of a 5 because it does not explicitly contrast with siblings or state what scope 'disable' covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus redis_enable or redis_status, nor are there any prerequisites or consequences described. The only usage hint is the misplaced note that confirm is required, which is not a sufficient usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. 'Memory information' implies a non-mutating read operation, but it does not disclose output format, units, snapshot vs historical data, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is brief, but brevity here is under-specification, not effective conciseness. Two words do not provide enough substance to earn their place when selection depends on the missing functional detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Zero parameters reduce invocation complexity and an output schema exists, but the description still fails to differentiate this tool from the many system_* siblings or to indicate what memory information is returned. An agent cannot confidently select this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero parameters and has 100% coverage, so there are no parameter semantics the description must clarify; the baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('memory') but provides no verb or explicit action. It is essentially a noun phrase that restates the tool name and does not say whether it returns current usage, statistics, or configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of related siblings such as system_resource_usage_latest, system_info, or system_load. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'WordPress instance details' and never states that the tool is read-only, what it returns, what happens if the location does not exist, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with a meaningful phrase, but the 'Args:' block redundantly repeats the schema. It is not bloated, but it is under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description still lacks essential context: how to identify a valid location_id, whether wp_get is the right tool compared to wp_locations or wp_install, and what behavior to expect. It is minimally usable but not sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely restates 'location_id: Location id', which adds no meaning beyond the schema's own title. It does not explain what a location_id is, how to obtain one, or what format it should take.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'WordPress instance details' identifies the resource and implies a retrieval operation, matching the wp_get name. It does not explicitly say 'get' or contrast itself with sibling tools, but 'details' clearly distinguishes it from wp_install and wp_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that location_id likely comes from wp_locations, nor does it explain any prerequisite or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a safe read operation, whether it returns parsed configuration, or whether it has side effects. The only behavioral clue is the reference to options.conf, which is not enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the resource name, but it is an under-specified fragment rather than a complete statement of purpose. Conciseness is fine; the issue is that it omits the verb and any meaningful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has no parameters and an output schema exists, the description still fails to explain the core operation. With many CustomBuild-related siblings present, the agent cannot reliably distinguish whether this tool fetches options, edits them, or reports their state. The missing action is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics. The baseline for zero-parameter tools is 4, and the description does not need to add parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'CustomBuild options (options.conf)' largely restates the tool name without stating an action. It identifies the resource but does not say whether the tool reads, writes, validates, or edits those options. The filename in parentheses adds mild context but does not clarify the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 cb_options_update, cb_state, or cb_run. The description does not mention read-only use, configuration changes, or any exclusion criteria, leaving the agent to infer intent 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies that default directadmin.conf values are somehow exposed, but it does not state whether this is a read-only lookup, what format is returned, or whether any state is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief with no wasted words, but it is a fragment rather than a complete, self-contained instruction. It is concise in length but lacks a verb, making the structure less helpful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description does not need to be long. However, it still fails to state the action and does not differentiate this endpoint from closely related config tools, leaving an agent without enough context to select it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema properties object is empty, so there is no parameter semantics burden. The baseline of 4 applies because there are simply no parameters for the description to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Default directadmin.conf values.' is a noun phrase that essentially restates the tool name da_config_default. It identifies the resource (directadmin.conf default values) but never states the operation, so an agent cannot tell whether this tool returns, lists, applies, or validates those values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 its siblings such as da_config_active, da_config_local, or da_config_local_update. The description gives an agent no criteria for choosing this endpoint over the other config-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it only states a noun phrase. It does not state whether the operation is read-only, whether it returns a merged view, or whether it has side effects, leaving behavior entirely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and has no wasted words, but it is under-specified rather than concise. A single noun phrase does not earn its place because it does not communicate the tool's action or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and an output schema, the description is incomplete because it does not state what the tool does. The missing operation is fundamental enough that an agent cannot reliably decide to invoke this tool over da_config_active, da_config_default, or da_config_local_update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there are no parameter semantics for the description to document. The baseline of 4 applies because the description does not need to compensate for any parameter coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource—local overrides in directadmin.conf—but lacks any verb, so it is not clear whether this tool reads, applies, or validates those overrides. It hints at the 'local' distinction from da_config_active and da_config_default, but does not explicitly differentiate among the config-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided, and no alternatives or exclusions are mentioned. An agent must infer from the tool name and sibling cluster that this is likely the reader for local overrides, which is not enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a mutation and mentions confirm, but it does not explain what happens to existing settings, whether values merge or replace, permission requirements, impact, or reversibility. The note 'confirm: Required' also conflicts with the schema, where confirm is optional with default false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is concise and front-loaded, and the Args block is tidy. However, the arg documentation is extremely sparse, and the inaccurate 'confirm: Required' undercuts the structure's usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating, server-wide configuration operation with no annotations and an open-ended values object, too much critical context is missing: valid configuration fields, confirmation semantics, permission needs, and effect on existing configuration. The presence of an output schema does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 compensate. 'values: Config object' only restates the schema's object type and provides no hints about accepted keys or structure, especially since the schema allows additionalProperties. 'confirm: Required' adds no semantic value and is contradicted by the schema's required list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Update global email configuration.' This is specific enough to distinguish it from read-only config tools, but it does not explicitly differentiate among sibling update tools like email_outbound_filter_update or db_server_config_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusions. The usage is only implied by the tool name and the one-line purpose; an agent must infer when this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only describes the result as 'one vacation message' and does not state that this is a read-only lookup, what happens when no vacation message exists, or any prerequisites such as domain/user validity. The read-only nature is only implied by the 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is very short and has a clean Args structure with no filler. However, it is terse to the point of under-specification, so it is not a model of concise completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter with an output schema, the core call shape is present. Still, the lack of any usage guidance, behavioral context, or annotation support leaves the definition only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. 'user: Local part' is somewhat useful because it clarifies that the user should be provided without the domain, but 'domain: Domain' merely restates the parameter name. No format, combination, or validation details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says only 'One vacation message,' which identifies the resource and unit but lacks an explicit verb. The action must be inferred from the tool name 'get,' and it does not clearly distinguish itself from siblings like email_vacation_list, email_vacation_set, or email_vacation_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of alternatives. Sibling tools for listing, setting, and deleting vacation messages exist, but the description never mentions them or explains when this getter is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only says 'Disk usage for a path' and does not disclose whether the result is recursive, file-level or directory-level, how units are represented, or whether paths must be directories. This is a minimal read-style tool, but the description still leaves key behavior unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is concise and front-loaded. However, the 'Args: path: Path' section is redundant with the input schema and adds no value, making the structure slightly wasteful for an already trivial description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter and an output schema, so the bar for completeness is lower. Even so, the description does not explain the purpose relative to the many sibling file-manager and system tools, nor does it clarify what kind of path is expected or what kind of 'disk usage' is reported. An agent could probably invoke it, but with limited confidence about the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 underdocumented parameter. It only repeats 'path: Path', adding no meaning beyond the schema's own 'path' string property. There is no clarification about absolute/relative paths, file versus directory, or the meaning of the default '/'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear operation ('disk usage') and a specific resource ('a path'), so an agent can understand the basic function. However, it does not differentiate this from related siblings like system_disk or fm_tree, 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.
Usage Guidelines2/5
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 system_disk, fm_list, or fm_tree. No context, prerequisites, or exclusions are provided, leaving the agent to 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavior: it does not state whether this is a read-only enumeration, what side effects it may have, what the output contains beyond 'commands', or any authentication requirements. The description is essentially a label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than appropriately concise. It is a noun phrase with no action verb, so it does not fully function as a tool description. A sentence like 'List the commands a login key can be restricted to' would be both concise and complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simple zero-parameter endpoint with an output schema, the description fails to explicitly state the operation or connect to related login-key tools where the returned commands would be used. The fragment leaves too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 are no parameter details the description must add. Per the no-parameters baseline, this dimension is adequately handled by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase identifies the subject matter—commands usable as login-key restrictions—and the name distinguishes it from sibling login-key tools. However, it lacks an action verb and reads as a noun phrase rather than a statement of what the tool does, such as 'List' or 'Return'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this endpoint or how it relates to login_keys_create, login_keys_update, or login_keys_list. An agent must infer its purpose and placement in a workflow from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It only says 'Update a login key' and gives argument labels; there is no mention of side effects, whether the update is immediate, reversibility, required permissions, or what the payload may meaningfully contain. This is a sparse mutation description with no safety-related disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and cleanly formatted, but being concise is not the same as being complete. Every line is stubby, and the confirm note is misleading. It earns a middle score because it is readable and front-loaded, yet it sacrifices necessary substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and low schema detail, the description is far too thin. It does not explain what a valid payload looks like, what 'confirm' actually does, whether the operation is destrictive, or what success/failure looks like. The presence of an output schema reduces the need to document return values, but the missing preconditions and behavioral context remain critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 compensate for the vague schema fields. Instead it merely restates 'Key id' and 'Patch body', which adds almost no meaning. Worse, it states 'confirm: Required' while the schema shows confirm as optional with a default of false, creating a factual conflict that could mislead an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Update a login key.' This modestly distinguishes it from the sibling login_keys_create, login_keys_delete, and login_keys_get operations. It does not elaborate on which fields are updatable, but the core purpose is not ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 login_keys_create, login_keys_delete, or login_keys_get. It does not state any prerequisites such as the key already existing, and it never mentions when a caller should choose update over recreate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Deactivate a plugin' and labels confirm as required. It does not explain side effects, reversibility, or downstream impact, and the 'confirm: Required' note conflicts with the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and easy to parse, and the action is front-loaded. However, the Args section largely duplicates schema titles and contributes little meaningful information, so the compactness does not make up for the lack of substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing operation with no annotations, the description is missing essential context: what deactivation means, what confirm actually does, and when this tool should be chosen over siblings. The output schema may cover return values, but it cannot compensate for absent invocation guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 restates 'plugin_id: Plugin id' and says 'confirm: Required.' The schema marks confirm as optional with a default of false, making the description actively misleading about what confirm does and whether it must be supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deactivate') and the resource ('a plugin'), so an agent can tell this is the opposite of plugins_activate. However, it does not explicitly differentiate deactivation from related operations like plugins_delete or plugins_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 plugins_delete, plugins_update, or plugins_manager_list. No prerequisites, context, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of explaining behavior. It only restates that the tool reloads a service and does not disclose effects, permissions needed, or whether the service is briefly interrupted. The 'confirm: Required' claim also adds confusion rather than clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with a clear first sentence. However, the args block is under-specified and includes a misleading 'confirm: Required' line, so the brevity sacrifices correctness and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a state-changing tool with no annotations and no meaningful parameter descriptions. It needs to explain side effects, prerequisites, and when reload is appropriate instead of restart, but none of that is present. The output schema exists, so return values don't need to be described, but operational context is still largely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should define both parameters. It only gives 'service: Service name,' which is redundant with the schema title, and 'confirm: Required,' which contradicts the schema where confirm has a default value and is not required. The purpose of confirm is never explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Reload a service configuration.' It clearly says what the tool does, but it does not differentiate it from sibling tools like services_restart, services_start, or services_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use reload versus restart, start, or stop. The sibling list includes services_restart and other lifecycle tools, but the description never mentions the conditions under which reload is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining side effects. It only says 'Restart a service,' and the 'confirm: Required' hint implies a safety gate, but the description does not disclose that restarting likely interrupts the service, requires administrative permission, or could fail if the service is not running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded with the action, and contains no fluff. The Args block is compact, though the confirm entry is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a potentially disruptive service-restart operation with no annotations, the definition is incomplete: it omits when to use this tool, what happens when invoked, and the semantics of the required confirmation. The presence of an output schema covers return values, but not the behavioral and usage context an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explain the parameters. It adds only 'service: Service name' and 'confirm: Required'; the meaning of confirm, such as what is being confirmed and why it is needed, is not explained. Calling confirm 'Required' is also misleading because the schema lists only service as required and gives confirm a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action and object ('Restart a service'), so an agent can understand the core purpose. However, it is essentially a restatement of the tool name and gives no scope, such as which service lifecycle stage this covers or how it differs from services_start and services_reload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use services_restart versus the sibling lifecycle tools such as services_start, services_stop, services_reload, or services_watchdog. The confirm argument hints at a required gate, but no scenarios, prerequisites, or exclusions are described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and 'Current account user.conf.' discloses no behavior at all. There is no mention of side effects, read-only guarantees, authentication requirements, or error behavior, leaving the agent to guess what invoking this tool actually does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and free of filler, so it is concise. However, it is under-specified rather than usefully concise because the missing verb forces the agent to infer the core operation from the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with an output schema, some return-shape burden is handled elsewhere, but the description still fails to state what operation is performed or how this relates to sibling config tools. An agent cannot confidently select or invoke it based on this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 are no parameter semantics that the description needs to add. The baseline of 4 is appropriate because there is nothing missing for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('Current account user.conf') and a scope, but it lacks a verb: the agent cannot tell whether the tool gets, sets, validates, or lists this configuration. It also does not distinguish itself from siblings like session_reseller_config or users_get_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 session_reseller_config, da_config_active, or users_get_config. The description is not misleading, but it gives the agent no context for choosing this tool over its many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It only identifies the subject as CPU information, without stating whether this is a read-only query, what metrics are included, whether it samples current state, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no filler, but it is also under-informative and largely restates the tool name. Brevity is achieved at the expense of useful content, making it too sparse to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and return values need not be fully described, the description still fails to give enough context to select this tool over similar system_* tools. The agent cannot tell what makes system_cpu different from system_load or system_info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 no parameter documentation is required. The description adds no parameter details, but none are needed; the baseline for a zero-parameter tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'CPU information.' is essentially a restatement of the tool name, with no verb or detail about what aspect of the CPU is returned. It does not distinguish system_cpu from closely related siblings like system_load, system_info, or system_uptime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many other system_* tools. No alternatives, exclusions, or context are provided, so the agent must infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names a topic and provides no information about auth requirements, time range, aggregation, read-only behavior, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and free of redundancy, which supports conciseness. However, it is under-specified as a noun phrase and lacks the structure of a complete tool description with a verb and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has no parameters and an output schema exists, the description leaves important ambiguity about what 'system resource usage' means versus system_global_usage_history and what period 'history' covers. An agent cannot fully understand the tool's purpose from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to explain. Per the rubric, zero parameters warrant a baseline of 4; the description does not need to add parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Historical resource usage' conveys the general domain and temporal aspect, but it is a noun phrase rather than a clear verb+resource statement. It can be partially distinguished from 'latest' siblings by the word 'Historical,' but it does not specify which resource or scope is covered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 system_resource_usage_latest or system_global_usage_history. The description provides no context, exclusions, or comparisons, so an agent cannot determine which sibling is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state the toggle nature and mentions DirectAdmin, but it does not disclose that suspending an account is disruptive, what 'confirm' controls, whether the operation requires special permissions, or what side effects occur. The behavior is roughly stated but materially under-described for a state-changing account operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main sentence is concise and front-loaded. However, the 'Args' block duplicates and misstates schema information, and 'confirm: Required' is inaccurate. The compactness is good, but one of its few sentences actively misleads the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a suspension-related tool with no annotations, the description is incomplete. It omits the semantics of confirm, the relationship to users_unsuspend, the effect of repeated calls, and permission requirements. The presence of an output schema helps with return values, but the operation's preconditions and consequences remain unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 fails. 'username: Account' adds little meaning. Worse, 'confirm: Required' directly contradicts the input schema, which lists username as the only required property and gives confirm a default of false. The meaning of confirm is never explained, leaving the most ambiguous parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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: 'Toggle suspend/unsuspend for an account.' This clarifies that the tool is not a one-way suspend operation, which is useful given the sibling tool users_unsuspend. However, it does not explicitly distinguish itself from users_unsuspend or explain when one should be used instead of the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the closely related users_unsuspend sibling. The description does not mention prerequisites, target user types, admin/reseller scope, or any exclusions. The single line 'DirectAdmin toggle' implies usage but provides no actionable decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure, yet it only says 'Unsuspend an account' and that the endpoint is shared with users_suspend. It does not explain permissions, side effects, idempotency, or what happens if the account is already active, leaving significant 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, which is good for conciseness, but the Args section is misleading and the overall structure omits critical clarifying details. It earns no wasted words, yet inaccuracy in one line prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple two-parameter tool, the description is not complete enough for correct invocation. The confirm parameter's purpose and requirements are misrepresented, and with no annotations, important context about the operation's effects and prerequisites is missing. The output schema covers return values, but the calling context remains under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 labels username as 'Account', which adds a small amount of meaning, but 'confirm: Required' is factually wrong because the schema lists confirm as optional with a default value and only username is required. This active misinformation makes the parameter guidance harmful rather than helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Unsuspend an account', a specific verb and resource that clearly conveys the tool's purpose. Mentioning 'same toggle endpoint as users_suspend' helps relate this tool to a sibling, though it does not fully distinguish it beyond the action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like users_suspend. The phrase 'same toggle endpoint' implies a relationship but does not state that users_unsuspend is the appropriate choice for reversing a suspension, nor are conditions or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so this description carries the full burden of behavioral disclosure. It only restates that the tool provides a summary, without disclosing whether it is read-only, what time range or scope it covers, how the data is aggregated, or what limitations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no filler, but it is an incomplete noun phrase rather than a full statement of behavior. It is under-specified rather than elegantly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and zero parameters reduce complexity, but the description does not convey what the summary contains, whether it is system-wide or per-domain, or how it relates to other audit/modsecurity tools. It is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing the description needs to explain about parameter meaning. The baseline for a zero-parameter tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ModSecurity audit log summary' is essentially a spaced-out restatement of the tool name with the word 'log' inserted. It offers no verb or action, so it does not clearly explain what the tool does or what kind of summary it produces, and it does not differentiate it from siblings like modsecurity_audit_entry or audit_searh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related audit/modsecurity tools such as audit_recent, audit_searh, modsecurity_audit_entry, or modsecurity_all_configs. No use cases, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Patch,' indicating mutation, but does not explain what happens to existing options, whether changes are reversible, what the confirm flag actually does, or what side effects may occur. The line 'confirm: Required' adds ambiguity because the schema marks confirm as optional with a default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the main action is front-loaded, which is good. However, it is more under-specified than concise: the Args section is sparse and does not meaningfully elaborate on the parameters or behavior, so it does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with no annotations and a nested object parameter that is completely undocumented. The description lacks enough information for an agent to know what options can be patched, whether confirmation is truly required, or what the outcome will be. The presence of an output schema helps return-value expectations, but the input side remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mostly repeats parameter names. 'values: Options object' does not explain the structure or accepted keys of the options object, and 'confirm: Required' conflicts with the schema, which lists values as the only required parameter and gives confirm a default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Patch CustomBuild options.' This clearly signals an update/modify operation on a distinct resource, and it is reasonably distinguishable from sibling tools like cb_options (read) or cb_run (execute). However, it does not explicitly differentiate itself from related cb_* tools that might also modify CustomBuild state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 cb_options, cb_updates, or cb_run. The verb 'Patch' implies modifying options, but there is no context on prerequisites, typical use cases, or 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.
Behavior2/5
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 this is a mutation ('Change'), but does not mention side effects, permission requirements, reversibility, or impact on active database sessions. The 'confirm: Required.' line hints at a confirmation behavior but is ambiguous and conflicts with the schema's optional confirm parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, which is good. However, the Args list is extremely sparse and the 'confirm: Required.' line is ambiguous and potentially misleading, so not every part earns its place. It is concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no usable schema descriptions, this is incomplete. The agent cannot reliably know what confirm does, whether it must be set to true, which database user context applies, or what side effects to expect. An output schema exists but does not compensate for the missing behavioral and prerequisite detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 parameters. It gives minimal meanings: 'dbuser: Name', 'password: New password', and 'confirm: Required.' The password meaning is clear, but dbuser is vague and confirm is not explained as a boolean flag or as the confirmation mechanism. Worse, 'confirm: Required' contradicts the input schema where confirm is not in required and has a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Change a database user password.' This clearly identifies the operation and helps distinguish it from sibling tools like users_change_password because it targets a database user rather than an account user. However, it does not explicitly name any sibling or state the scope boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of alternatives such as users_change_password, db_create_user, or db_user_get. It only implies use for changing a database user password, without prerequisites, exclusions, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose safety and effects. 'Drop a database' signals destruction and 'confirm: Required' hints at a confirmation safeguard, but it does not state irreversibility, impact on associated users/data, or what a successful response looks like. It also fails to reconcile 'confirm: Required' with the schema, which marks confirm optional with default false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and free of filler, which is appropriate for a simple operation. However, the Args section is so minimal that it borders on under-specification rather than disciplined conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no meaningful parameter documentation, and 0% schema description coverage, the tool's destructive semantics and confirmation contract are under-explained. For a two-parameter operation that deletes a database, an agent still lacks enough context to invoke it safely and correctly. The output schema helps but does not cover the missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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, but it only restates the property titles: 'Name' for database and 'Required' for confirm. It does not explain that confirm should be true, what database name format is expected, or that the schema considers confirm optional. This adds minimal meaning beyond the structural schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb ('Drop') and resource ('a database'), which clearly identifies the operation. It is distinguishable from sibling 'db_delete_user' even though no sibling is named, because the target is the database itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use db_delete versus related database tools, prerequisites, or alternatives. The only contextual note, 'confirm: Required,' functions as a parameter instruction rather than usage guidance and conflicts with the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. It conveys a destructive action but does not mention irreversibility, impact on active queries or connections, permissions required, or why confirmation is necessary. The claim that 'confirm: Required' conflicts with the schema, which marks it optional, further reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is concise and front-loaded, but the subsequent Args block does not earn its place. 'process_id: Process id' is a tautology, and 'confirm: Required' is inaccurate, so the brevity comes at the cost of useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description leaves gaps around how the process ID is obtained, what confirmation actually does, and what the consequences of the kill are. For a destructive tool with no annotations, a one-line command plus a misleading argument list is not enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 define the parameters, but it only restates the parameter name: 'process_id: Process id.' The confirm note says 'Required,' which contradicts the schema's default false and non-required status. This adds no useful meaning and is actively misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Kill a database process.' This immediately differentiates it from sibling tools like db_processes (list) and db_info (get), making the operation recognizable without needing the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any mention of prerequisites like obtaining a process ID from db_processes. The description only lists arguments and does not explain the context in which killing a database process is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it does not state whether the operation locks tables, causes downtime, changes data, or is reversible. The line 'confirm: Required' hints at a confirmation guard but is ambiguous and does not clarify the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no filler or unnecessary prose. It is concise to the point of under-specification, but as a structural matter it is easy to scan and immediately identifies the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations and a vague description, the agent lacks enough context to safely call this tool: no operational impact, no usage conditions, and no relationship to database siblings are described. The output schema reduces the need to document return values, but the missing behavioral and selection context remains significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 adds almost no real meaning: 'database: Name' is nearly redundant, and 'confirm: Required' is misleading because the schema marks confirm as optional with a default of false. The agent receives no information about acceptable values, formats, or the meaning of the confirmation flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Optimize a database.' This is not a tautology and gives the agent a basic sense of operation. However, it does not explain what optimization entails or distinguish it from related database maintenance siblings like db_repair or db_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, what prerequisites exist, or when a sibling like db_repair or db_check would be more appropriate. Among many database-related sibling tools, this absence leaves the agent to guess at the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It only says 'Copy files' and gives a vague 'confirm: Required' note, without disclosing overwrite behavior, whether confirmation is user-facing or API-level, or whether the operation can be destructive. The claim that confirm is required also conflicts with the schema, where confirm is optional with a default of false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core purpose, which is good. However, the argument section is sparse and includes an inaccurate 'Required' label for confirm, so conciseness is achieved at the cost of correctness and usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, but this is still inadequate for a file-mutation tool. Missing context includes path semantics, whether existing files are overwritten, what confirmation gates the operation, and how this relates to fm_move. An agent cannot safely invoke this tool based on the current description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only a minimal hint that payload is a 'Source/destination body', but does not explain the expected structure, required fields within the payload, or what confirm actually does. The false 'Required' label for confirm actively misleads the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Copy files.' This is clear and unambiguous, and it is naturally distinguished from sibling operations like fm_move, fm_remove, and fm_mkdir. However, it does not explicitly differentiate itself from fm_move or describe scope, so it stops short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as fm_move, backups_create, or fm_trash. The description does not mention prerequisites, source/destination conventions, or any context that would help an agent decide between copy and move operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Usage history' weakly implies a read-only retrieval operation, but it does not explain what the history contains, whether it is paginated, whether any filtering or time range applies, or whether any side effects or special permissions are involved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is concise and front-loaded, but the Args block is redundant with the input schema and adds no information. The description is short enough, but not every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is minimally sufficient: it names the resource and the required key_id. However, it lacks sibling differentiation and behavioral detail, and with no annotations the overall context is thinner than it should be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description's 'Args: key_id: Key id' simply repeats the schema's title 'Key Id' without adding meaning. The only parameter is self-explanatory, but the description provides no additional semantic value beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Usage history for a login key' clearly identifies the resource (a login key) and the kind of information returned (usage history). It is not as explicit as a verb like 'retrieve' or 'list', and it does not explicitly differentiate from siblings like login_history or users_login_history, but the intent is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as login_history, users_login_history, or login_keys_get. The description only restates that it provides usage history, leaving an agent to infer selection criteria without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Read' implies a non-destructive operation, but the description does not mention permissions, error behavior, or whether reading affectes message state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with a clear one-sentence function statement and a simple args section. It contains no filler, though it is arguably under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has only one parameter and an output schema, the description lacks important context such as how message_id is obtained, what the returned message contains, and how this differs from messages_list. It is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only repeats 'message_id: Message id.' This adds no meaning beyond the schema's property title and type, failing to explain where the ID comes from or any format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Read one message.' The singular construction distinguishes it from the sibling messages_list, even though it does not explicitly name the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related tools like messages_list or tickets_list. There is no mention of prerequisites, exclusions, or context in which the tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Update' and mentions that confirm is 'Required.' It does not explain whether the update overwrites existing settings, what permissions are needed, whether the change is reversible, or what the confirm parameter actually controls. The confirm note also conflicts with the schema, where confirm is optional and defaults to false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action, avoiding unnecessary filler. However, the Args section is under-specified, and the 'confirm: Required' line is inaccurate against the schema, so the brevity reflects under-specification more than well-crafted conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a global mutation tool with an open-ended values object, no annotations, and no schema parameter descriptions, this description is inadequate. The presence of an output schema reduces the need to document return values, but the agent still lacks essential understanding of what values may contain and what confirm means in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 labels 'values' as a 'Config object' and mentions 'confirm,' but it does not define the accepted keys or structure of the config object, nor confirm's expected value. The statement that confirm is 'Required' is misleading because the schema lists only 'values' as required and gives confirm a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and a clear resource ('global ModSecurity configuration'), so an agent can tell this is a mutation of the global config. It differentiates from the likely getter sibling 'modsecurity_global', though it does not explicitly distinguish itself from other ModSecurity config tools like 'modsecurity_all_configs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings such as 'modsecurity_global', 'modsecurity_all_configs', or 'modsecurity_user_configs'. No context is given about prerequisites, scope, or when another ModSecurity tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only states 'Search panel resources', which implies a read-only lookup, but it does not reveal query matching behavior, result scope, pagination, or any side-effect profile. The operation is fundamentally a search, but the description adds little beyond the action name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main descriptive sentence is short, front-loaded, and free of fluff. However, the 'Args: q: Query' section is redundant with the input schema and adds no value, so it does not fully meet the every-sentence-earns-its-place standard.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has only one parameter and an output schema, the description is too thin for the broad scope implied by 'panel resources (domains, dbs, emails, …)'. It does not clarify what resource types are actually searchable, how the query is interpreted, or how this tool relates to the many specialized search and listing siblings. An agent would likely need to infer critical usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 does not: 'Args: q: Query' merely restates the parameter name and type without explaining query syntax, matching rules, wildcard support, or what kind of query is expected. No meaningful semantic information is added beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a clear action ('Search') and a resource category ('panel resources') with concrete examples (domains, dbs, emails). It is understandable, but it does not explicitly distinguish itself from several similar sibling tools such as users_search, audit_search, or fm_search_files, so the differentiation is limited.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling search/list tools. It does not state whether it should be preferred over users_search, audit_search, fm_search_files, or the many inventory/list tools, nor does it provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'status,' which weakly implies a read-only operation, but it does not explain whether this validates the file, parses its contents, checks for presence, or reports compliance issues. For a tool with no annotation coverage, some behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than efficient conciseness. A three-word fragment does not convey enough substance to earn its place as a complete description; it is a label rather than a useful definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and there are no parameters, so return-value documentation is not required. However, the description is still too sparse: it does not clarify what 'status' means, what state is being checked, or what an agent should do with the result. For a simple tool this may be minimally workable, but it leaves the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so parameter semantics are trivially satisfied. The baseline of 4 applies because there is nothing to document and the description imposes no additional requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (security.txt) and the nature of the operation (status), so it is not a pure tautology. However, it is a fragment that never states the verb explicitly (get/check) or what aspect of security.txt is reported, leaving the action to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus any alternative, and no context is provided on which situations warrant checking security.txt status. With 0 parameters, the lack of guidance is less harmful, but the description still provides no situational context whatsoever.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden of explaining behavior, but it only discloses that a service is started. It does not mention side effects, permissions, whether the service must already exist, or what kind of response to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is also under-specified. Most of the argument list merely repeats schema titles, and the inaccurate 'Required' note for confirm means that sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating operation with no annotations and no usage guidance, this description is not complete. It lacks information about prerequisites, effects, acceptable service names, or any disambiguation from the surrounding service-management sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a small amount of meaning for 'service' by calling it a service name, but it incorrectly labels 'confirm' as 'Required' while the schema marks it as optional with a default of false. This is misleading and provides no real value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core action clearly with a specific verb and resource: 'Start a service.' This is enough to distinguish it from obvious siblings like services_stop, services_restart, and services_reload, though it does not name those alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many related service tools such as services_list, services_stop, or services_reload. The description only says what it does, not when an agent should choose it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It conveys that an installation happens, which implies mutation, but it does not disclose side effects, whether existing installations are overwritten, what the 'confirm' flag controls, or what resources are created or modified. The 'confirm: Required' note adds confusion instead of clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, which supports conciseness. However, the 'confirm: Required' line is misleading and the argument notes add little meaningful information, so not every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating installation tool with an opaque nested payload and no annotations, this description is too incomplete to call safely. It does not explain the payload contract, the role of confirm, or how this relates to wp_install. The presence of an output schema reduces the need for return-value details, but the input side remains severely underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 labels payload as 'Quick-install body' and confirm as 'Required.' This is too vague to determine what fields the payload should contain or what confirm actually does. It also contradicts the schema: confirm is described as required but the schema lists only payload as required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action and resource: 'Quick WordPress install.' It clearly identifies the tool as an installer for WordPress, and the 'quick' qualifier hints at a distinct variant from the sibling wp_install. However, it does not explain what makes this install quick or how it differs from the regular install.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 wp_install or any other alternative. There is no mention of preconditions, exclusions, or situations where a different install flow should be chosen. The word 'quick' only weakly implies a use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It only says to initiate a backup and that confirm is required, without explaining side effects, whether the operation runs synchronously, permissions needed, or what 'now'/immediate means. This is too thin for a mutating admin action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the purpose, and the Args block is easy to scan. It contains no filler, though it could trade a little brevity for more useful parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating admin-trigger action with no annotations and weak parameter documentation, this is under-specified. An agent does not learn valid 'where' values, what confirm actually requires, or the operational consequences of firing an admin backup. The output schema reduces the need to describe return values, but it does not fill these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description is the only source of parameter meaning. It usefully defines 'who' as 'all' or a username, but 'where' is only described as 'Destination the panel understands,' which is vague. It also conflicts with the schema: 'confirm' is called Required while the schema shows no required parameters and a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a concrete action ('Kick ... backup now') on a clear resource ('admin-level backup'), so an agent can tell this triggers an on-demand admin backup. However, it does not explicitly contrast with siblings like backups_admin_list or backups_create, and 'Kick' is informal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance. The description never names alternatives or conditions, such as using backups_admin_list to inspect backups or backups_create for user-level backups. The intended use is only weakly implied by the word 'now.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only notes that confirm is required, hinting at a guarded operation, but it does not explain side effects, whether the run blocks or runs async, whether it mutates system state, or what happens after the run begins.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, and the Args section is compact with no filler. It is appropriately concise, though the terseness contributes to the lack of behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating run-type tool with zero annotations and a free-form payload, the description is too incomplete. It does not mention when to call it, what actions are valid, whether it is destructive, whether it is asynchronous, or what the output represents. The presence of an output schema helps somewhat, but the description alone is not enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 some meaning by calling payload 'Run arguments (action, software, …)' and saying confirm is required, but it does not define the payload structure, enumerate valid action values, or clarify what 'confirm' actually confirms. The 'confirm: Required' wording also conflicts with the schema's default false and absence from required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 CustomBuild run' with example modes build/update/rewrite, making the core action clear. It is not explicitly differentiated from sibling cb_* tools like cb_actions or cb_software, but the 'Start a run' wording distinguishes execution from inspection well enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 cb_actions, cb_updates, or cb_software. The description implies usage from the name and first sentence but provides no 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior itself. It does not state that this operation is read-only, what it returns, whether it queries live data or cached data, or any side effects or access requirements. It only labels the result set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is an incomplete noun phrase rather than a full instruction like 'Lists available CustomBuild updates'. It is concise, yet it sacrifices the structural clarity that would help an agent understand the intended action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values do not need explanation, and there are no parameters. However, the description is too terse to fully support tool selection among a very large sibling set that includes similar CustomBuild and system-update tools. It lacks enough context about what distinguishes this update listing from cb_versions or system_packages_updates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty with 100% coverage, so the description does not need to explain parameter behavior. The baseline for a no-parameter tool is 4, and no parameter-related gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('CustomBuild updates') and implies an availability query, but it is only a noun phrase with no explicit verb such as 'list' or 'get'. It does not clearly distinguish itself from related tools like cb_versions, cb_software, or system_packages_updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The phrase 'Available CustomBuild updates' implies a read-only listing, but there are no explicit usage contexts, exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It reveals the immediate state change but leaves out permissions, reversibility, effects on running sessions, and what the confirm flag actually does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and front-loaded, but the Args section duplicates schema information and the misleading 'Required' note undermines the value of that brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating two-parameter tool with no annotations and 0% schema description coverage, the description is incomplete: the confirm flag is ambiguous and the schema conflict must be resolved before an agent can call the tool confidently. The output schema covers return values, but not the invocation contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter notes add almost no value: 'username: Account' barely restates the schema title, and 'confirm: Required' directly conflicts with the schema where confirm is optional and defaults to false. Neither parameter's real semantics are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Disable'), a clear resource ('CageFS'), and a scope ('one user'). It is immediately distinguishable from the enable sibling, and the added effect ('account leaves the cage') removes any ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 as opposed to cl_cagefs_enable, no prerequisites, and no mention of cases where disabling should be avoided. The intended use can only be inferred from the verb 'Disable'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only restates the action and notes the confirm argument; it does not mention side effects of enabling the firewall, reversibility, permission requirements, or consequences of not confirming. This is a security-sensitive mutating action, so the gap is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded: 'Enable CSF (csf -e)' immediately tells the agent the tool's purpose, and the Args line isolates parameter information. It is concise without wasted words, though it is thin on substantive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although this is a simple one-parameter tool with an output schema, enabling a firewall is security-sensitive and demands more context. The description does not explain what enabling CSF entails, the prerequisite firewall state, how it differs from csf_restart or csf_disable, or what confirmation actually does. The agent cannot reason about side effects or the confirmation contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explain the confirm parameter. It only says 'Required,' which adds a usage instruction but contradicts the schema where confirm has a default of false and is not listed as required. The value type and behavioral effect of confirm are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'Enable CSF' and includes the underlying command 'csf -e'. This naturally distinguishes it from siblings like csf_disable and csf_restart, though it does not explicitly name or contrast those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus csf_disable, csf_restart, or csf_status. With many related firewall tools in the sibling list, the agent is given no selection criteria, preconditions, or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure, but it only restates the basic operation. It does not explain consequences, irreversibility, permission requirements, or failure behavior. Worse, it states 'confirm: Required' while the schema marks confirm as optional with a default of false, creating misleading guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, and the Args section provides structure. However, the 'confirm: Required.' line is misleading and confusing, so not every sentence earns its place. The terseness is closer to under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating firewall tool with no annotations, no usage guidance, and an incomplete param explanation. The presence of an output schema helps slightly, but the agent still lacks key context about side effects, prerequisites, or the confirm parameter's actual role. The description is not sufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 a minimal gloss for ip ('Address to remove'), which is helpful, but the confirm parameter is described only as 'Required,' which is ambiguous and contradicts the schema's default false and non-required status. The description fails to explain what confirm means or how it should be supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: removing an IP from the CSF allow list, and even names the underlying command csf -ar. This distinguishes it from related sibling tools like csf_allow_ip, csf_deny_ip, and csf_ignore_ip by specifying the exact list being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as csf_unblock_ip or csf_deny_ip. It does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the basic restart action and the optional LFD behavior, but it does not disclose that restarting a firewall can drop connections, disrupt services, or require elevated privileges. The 'confirm' flag hints at a destructive operation but its exact role is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The args list is compact and easy to scan. It loses a point because the confirm line is too terse to be genuinely useful on its own.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating restart operation with no annotations, the description is incomplete. It lacks side-effect warnings, confirmation semantics, and guidance on what happens when also_lfd is false. The presence of an output schema does not compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 both parameters. It explains also_lfd with a useful mapping to 'csf -ra', but confirm is only labeled 'Required' without explaining what value it should take or why it matters. This conflicts with the schema, which lists confirm as not required and defaulting to false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Restart CSF, and optionally LFD.' This is specific and unambiguous within the csf_* sibling group. It does not explicitly distinguish itself from csf_enable, csf_disable, or csf_status, but the action 'restart' makes the purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 csf_status, csf_enable, services_restart, or system_restart_directadmin. The only usage-related note is the optional LFD parameter and the required confirm flag, but there is no context about prerequisites, safety checks, or when a restart is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It reveals that the tool patches/modifies config keys and that a confirm argument is needed, but it does not state side effects, whether the change is reversible, whether the service is reloaded, or what partial patch semantics mean for existing keys. This is a meaningful but incomplete 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and front-loaded: one operation sentence followed by a two-line argument list. There is no filler, though the argument list does not add enough detail to fully justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and an open-ended nested values param, the description leaves important gaps: no guidance on how to construct the partial config, no confirm semantics, no difference from da_config_local_update, and no effect/restart info. The existing output schema lessens the need for return-value details, not the need for operation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 gives brief definitions ('values: Partial local config', 'confirm: Required'), which add some meaning over the bare schema, but 'confirm: Required' contradicts the schema, where confirm is optional with a default of false and is not in required. The values object is untyped and open-ended, so an agent still lacks key shape or value constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence uses a specific verb ('Patch') and resource ('selected directadmin.conf keys'), so an agent can tell this is a partial modification of the local configuration. However, it does not explain how 'patch' differs from sibling da_config_local_update, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, when not to use it, or which alternative to choose. The sibling list includes da_config_local_update, da_config_active, and da_config_default, but the description gives no routing criteria. The only usage hint is 'confirm: Required,' which is a call requirement, not a situational guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and only says 'Create a database.' It does not disclose whether confirmation is required despite claiming confirm is Required, what the operation does if the database already exists, or what side effects occur. The 'confirm: Required' line is also contradicted by the schema making payload required and confirm optional with a default of false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, followed by an Args section. There is no filler, though the terseness leaves important details out.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, the description is incomplete: it omits required payload structure, confirm semantics, failure behavior, and how this differs from db_create_with_user. The existence of an output schema helps return-value understanding, but the calling context is still under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 'name, charset, …' for payload, which is helpful but vague. For confirm it only says 'Required,' which is misleading because the schema marks it optional with default false and does not explain what it confirms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a database.' This clearly identifies the operation. However, it does not differentiate from nearby sibling tools such as db_create_with_user or db_create_user, so it loses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use db_create versus db_create_with_user or other creation tools. It provides no context, prerequisites, or exclusions, leaving the agent to infer applicability from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Database server info' weakly implies read-only retrieval, but it does not explicitly state side effects, whether data is cached, what the response contains, or any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with no wasted words. However, 'Database server info.' is a terse fragment that under-specifies the tool's behavior, so brevity comes at the cost of useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal to be complete. It does not explain what 'info' means, how it relates to db_server_config, or whether it is a simple status/version read or something more. The presence of an output schema helps with return values, but the description still lacks operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter documentation is required. The description adds no parameter semantics, but nothing is needed; this is the standard baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (database server) and the general intent (info), but it is a noun phrase rather than a verb-led statement and gives no indication of what specific information is returned. It does not distinguish itself from sibling tools like db_server_config, db_server_config_test, or system_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With a large sibling list containing db_list, db_get, db_server_config, and db_server_config_test, the description provides no decision support or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only hints at confirmation via 'confirm: Required.' It does not state that deletion is irreversible, what side effects occur, or what prerequisites must be met. The wording is also ambiguous because the schema marks confirm as optional with default false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the action, and the parameter list is easy to scan. It is concise, though some entries are so terse that they add little beyond the schema field names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive 5-parameter operation with no annotations, the description omits key context: how confirm should be set, what name/value formats identify a record, and what happens after deletion. The output schema covers return values, but the input semantics and side effects remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args block is the only parameter documentation. However, it mostly restates the schema titles: domain: Zone, record_type: Type, name: Name. The only genuinely extra insight is that value is required by most DA versions, while the 'confirm: Required' note conflicts with the schema's non-required/default-false declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a DNS record'), so an agent can immediately tell what the tool does. It is implicitly distinguishable from the DNS add/query siblings, though it does not explicitly differentiate itself from dns_record_add or dns_zone_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as dns_record_add or dns_zone_get. The only usage cue is the verb 'Delete', leaving the agent to infer the appropriate context without any supporting direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It confirms the operation is a deletion and mentions that confirm is required, but it does not state whether the deletion is irreversible, cascades to associated DNS/email/subdomains, or requires specific permissions. An agent cannot predict the destructive scope beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and contains no filler. The single-sentence purpose followed by a compact Args block is easy to scan. However, the terseness omits important behavioral and semantic details, so the structure is good but not excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations and minimal schema descriptions, so the description must cover consequences and prerequisites. It mentions impersonation and confirmation, but it does not explain what happens to the domain or associated resources, nor does it clarify the required confirm value. The existence of an output schema does not compensate for missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds one useful piece of meaning ('impersonate: Owning user'), but 'domain' and 'confirm' mostly restate their titles. More seriously, 'confirm: Required' conflicts with the schema, which lists only domain as required and gives confirm a default of false; this makes it unclear whether a truthy confirm value must be sent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a domain from an account.' This is clear and distinguishes the tool at the domain level from subdomain or domain-pointer deletion tools. It does not explicitly differentiate itself from siblings, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like domains_create, subdomains_delete, or domain_pointers_delete. The description only restates the action and lists arguments; it gives no 'when to use' or 'when not to use' context. The mention of confirm and impersonate is operational, not usage-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Delete a mailbox' and lists arguments; it does not disclose that deletion is permanent, that confirm is required for the deletion to proceed, or any side effects or permission requirements. The 'confirm: Required' note is present but terse and conflicts with the schema's default, leaving behavioral expectations unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-line purpose followed by a compact argument list. There is no filler, and the purpose is front-loaded. It loses a point for the terse argument list omitting useful structural detail, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, this description is incomplete. It does not explain what happens when a mailbox is deleted, whether confirm must be set to true, what the output contains, or how this tool relates to other email deletion tools. The existence of an output schema does not cover these gaps because the description fails to give usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 does list all four parameters with brief glosses ('Domain', 'Local part', 'Owning user', 'Required'), which adds some meaning beyond bare titles. However, 'confirm: Required' is misleading because the schema shows confirm as optional with default false, and no value or format guidance is given for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a mailbox.' This clearly indicates a delete operation and, combined with the tool name email_pop_delete, distinguishes it from email_pop_list/create/modify siblings. However, it does not explicitly say 'POP account' or explain what 'mailbox' means, so it lacks explicit sibling differentiation in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when a different delete tool (e.g., email_forwarders_delete) would be appropriate. The description only states the action with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Change permissions' names the operation but does not disclose whether changes are recursive, whether they could lock out access, or what the confirm parameter actually controls. The claim that confirm is 'Required' also conflicts with the input schema, which lists only payload as required and gives confirm a default of false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded, and contains no filler. Every sentence contributes either the operation or argument context. The under-specification is counted in other dimensions, but as structure and conciseness, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested payload object, no schema descriptions, and no annotations, the description is not complete enough. It omits critical details about the payload structure, mode syntax, whether recursion is supported, and how confirm affects execution. An agent would likely need to guess or look elsewhere to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 provides minimal labels: 'payload: Paths + mode' and 'confirm: Required.' It does not explain the expected structure of paths, the mode format (octal vs symbolic), or the meaning of confirm. The statement 'confirm: Required' is actually misleading because the schema marks it optional with a default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Change permissions.' In the context of sibling file-management tools like fm_mkdir, fm_remove, and fm_move, this clearly identifies the intended operation. However, it does not mention whether it applies to files, directories, or both, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusions. The only implied usage is 'when you need to change permissions,' but the description does not provide explicit decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of describing the operation's impact. It only says 'Create a directory' and provides no information about whether the operation is destructive, what confirmation is needed, what path scope applies, or what happens on failure. It also conflicts with the schema by implying confirm is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the main action is front-loaded, but the Args section mostly duplicates schema titles and contains an inaccurate statement about confirm. It is concise in size but not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-creation tool with no annotations, the description is under-specified. It does not explain confirm's role, whether parents directories are created, how paths are scoped, or any operation-specific behavior. The presence of an output schema helps but does not compensate for the missing input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 both parameters. It merely restates 'path' as 'New directory path' and inaccurately marks confirm as 'Required' when the schema says it has a default of false and is not in the required list. It does not explain what confirm means, its type, or its accepted values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a directory,' which is a specific verb and resource. It clearly distinguishes this tool from sibling file-manager operations like fm_remove, fm_copy, fm_chmod, and fm_trash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisite context, and no mention of path scope or how the directory path should be specified. The only usage note, 'confirm: Required,' is misleading because the schema does not list confirm as required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses only the operation and a 'confirm' claim, but does not mention side effects, overwrite behavior, cross-directory semantics, or that moving is destructive to the source path. The statement 'confirm: Required' also conflicts with the schema, where confirm is optional with a default of false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core verb. It wastes no words, though the brevity contributes to under-specification rather than being balanced with necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating file operation with no annotations and a loosely-typed payload, the description omits key details such as payload field names, confirm semantics, and interaction with sibling file commands. It is not complete enough for an agent to confidently construct a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds only 'payload: Source/destination body' and 'confirm: Required.' The payload hint is vague, and confirm is misstated as required when the schema marks it optional. With additionalProperties true, an agent still does not know the required body structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Move files' names a concrete operation and resource, and the fm_ prefix makes it clear this belongs to the file-manager tool family. It does not explicitly distinguish itself from siblings like fm_copy or fm_remove, but 'move' is a distinct file operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose fm_move over fm_copy, fm_remove, or fm_trash. The description states what it does but not when it should be used or what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, and it only discloses that the operation may trash or delete depending on settings. It does not explain whether deletion is permanent, what confirm actually does, or what happens when confirm is false; the 'confirm: Required' statement also conflicts with the schema where confirm is not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the primary behavior, and uses a clear Args block. Every sentence is relevant, though the 'confirm: Required' line is misleading given the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive/mutating file operation with no annotations and minimal schema info, the description is under-specified. It omits important context such as confirmation behavior, path interpretation, error cases, and conditions under which delete replaces trash; output schema exists, so the return format is less of a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only repeats parameter names ('paths', 'confirm') with minimal meaning. It fails to describe path format/scope or the role of confirm beyond 'Required', which is contradicted by the schema default false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Move paths to trash') on paths and notes that deletion may occur depending on panel settings. It does not explicitly differentiate itself from sibling tools like fm_trash or fm_move, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use fm_remove rather than fm_trash, fm_move, or other file operations. The only usage-related instruction is 'confirm: Required', which is not a when-to-use or alternative-condition statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Search file contents' and gives param labels, with no mention of whether searches are recursive, case-sensitive, regex-based, or limited to certain file types. There is no contradiction with annotations because none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact and front-loaded, with the core purpose in the first sentence. Each parameter receives a short clarifying phrase and there is no filler, though it is terse to the point of under-specifying important behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-search tool with no annotations, important operation context is missing: whether paths are absolute or relative, whether traversal is recursive, how matches are returned, and what happens with directories or binary files. An output schema exists, but the description alone does not give an agent enough to call the tool confidently beyond the two parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 bare schema. It adds modest meaning by labeling query as 'Text' and path as 'Root to search,' but it does not explain query syntax, matching behavior, or path interpretation beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Search file contents.' This differentiates from sibling fm_search_files by indicating contents rather than filenames, but it does not explicitly contrast itself with that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 fm_search_files or fm_list. It does not mention recursion, scope, or typical use cases, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'Assign an IP' and adds 'confirm: Required,' but it does not explain consequences such as whether an existing assignment is overwritten, whether the IP must be free, or what happens on failure. The 'confirm' parameter is mentioned but its role is not actually explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action, followed by a compact argument list. It wastes little space, though the misleading 'confirm: Required' note could have been replaced with a more useful clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating operation with no annotations, an output schema, and only 0% schema description coverage. The description does not explain prerequisites, side effects, or how confirm affects execution. An agent would not know whether this reassigns an IP already in use or only assigns an unassigned one, making the definition incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 provides minimal labels: 'ip: Address' is largely tautological, 'username: Destination account' is mildly helpful, and 'confirm: Required' is confusing because the schema marks confirm as optional with a default of false. It does not clarify what value confirm should take or why it is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Assign an IP') and the target ('to a reseller/user'), so an agent can tell this is an assignment operation rather than a lookup or removal. It is clear but does not explicitly differentiate from sibling tools like ips_add or ips_remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 ips_add or ips_remove. There are no stated prerequisites, exclusions, or context such as 'use this when the IP is already allocated to the server but not yet assigned to an account.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It only says 'Delete' and does not disclose irreversibility, permissions, or what confirmation actually requires. The statement 'confirm: Required' conflicts with the input schema where confirm is optional with a default of false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is appropriately concise and front-loaded. However, the Args section contains redundant and even contradictory text, so not every line earns its place. It is compact but not especially well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, the description omits important context like whether deletion is permanent, what the confirm parameter controls, and any required value for confirm. An output schema exists, so return values are less critical, but the operation's behavior remains under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 does not: 'key_id: Key id.' merely restates the schema title, and 'confirm: Required.' contradicts the schema, which does not list confirm as required. The description adds no useful meaning and provides misleading information about a parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a login key.' It is unambiguous and naturally distinguishes this tool from siblings like login_keys_create, login_keys_update, and login_keys_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, nor are prerequisites or destructive-action caveats mentioned. The only hint, 'confirm: Required,' is not a usage guideline and conflicts with the schema, leaving the agent without clear decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It conveys that the tool creates a one-shot URL and passes an optional payload, but it doesn't disclose authentication needs, expiry, side effects, or whether the URL is immediately consumed. The endpoint hint adds some context, but the behavioral burden is largely unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the core purpose and endpoint. The 'Args' line is minimal and does not waste words, though the extreme brevity contributes to under-specification elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, a single undocumented generic parameter, and many related login/session tools in the sibling list, the description leaves important gaps: how to choose this tool, what payload content is expected, and what happens as a result beyond creating the URL. The existence of an output schema helps with return values, but not with usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for the generic 'payload' object. It only says 'Optional body the panel expects,' which confirms optionality but gives no structure, examples, or hints about what keys the panel may require. This is insufficient for an agent to construct a meaningful payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('one-shot panel login URL'), and the HTTP endpoint. It doesn't explicitly distinguish itself from sibling tools like login_urls_create, but the 'one-shot' qualifier and endpoint give enough specificity for basic identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 login_urls_create, login_urls_list, or session_login_as. The description only states what the tool does, not the conditions under which an agent should prefer it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It signals deletion but does not disclose permanence, confirm mechanics, permission requirements, idempotency, or side effects. It does not contradict annotations, so it avoids a 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the action, and structured into an args list with no filler. However, the confirm line is misleading, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive two-parameter tool with no annotations, the description is incomplete: it does not explain when confirm must be true, where url_id comes from, or what happens on deletion. Even though an output schema exists, the behavioral context needed to call it safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It only restates url_id as 'URL id' and says confirm is 'Required,' which contradicts the schema where confirm is optional with a default of false. No type, role, or allowed values for confirm are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
'Delete a login URL.' states a clear verb and resource. It distinguishes itself from the login_urls_create/list/one_shot siblings through the delete action, but provides no scope or object-selection detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus login_urls_create or login_urls_list, no mention of how to obtain url_id, and no prerequisites or exclusions. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the operation is a patch but does not describe merge behavior, validation, permission requirements, side effects, or the shape of the response. This leaves important behavioral expectations undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no wasted words. The single-sentence purpose followed by an args line is easy to parse. However, brevity comes at the cost of missing parameter details, so it is not a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool is incomplete for correct invocation because the values object is entirely unspecified. There are no annotations and no description of which settings can be patched. An agent cannot reliably determine what to pass without external documentation or inspection of sibling/related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the sole parameter 'values' is a free-form object with additionalProperties true. The description only says 'Partial settings object,' which adds the notion of partial updates but does not enumerate or explain any actual settings keys, types, or allowed values. This is insufficient for an agent to construct valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Patch profile settings.' It clearly indicates the action and target. However, it does not explicitly explain which profile's settings are affected (e.g., the current user), which limits differentiation from the sibling profile_settings tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. There is no mention of prerequisites, ownership scope, or a comparison with the closely named profile_settings sibling. The agent is left to infer context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that 'confirm' is required, which is potentially important safety information, but this conflicts with the input schema where confirm is optional and defaults to false. It does not describe side effects, whether the stoppage is reversible, or what confirmation actually does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no unnecessary prose. However, the parameter section is sparse and the inaccurate 'confirm: Required' note prevents it from being an ideal concise definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating service-control tool with no annotations, the description is under-specified. It should clarify confirmation semantics, side effects, and when to stop instead of restart or reload. An output schema exists, so return-value details are not required, but operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 'Service name' for the service parameter, which is minimal, and 'confirm: Required,' which is misleading because the schema marks confirm as optional with a default. It does not explain what confirm means or what values it accepts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Stop') and the resource ('a service') clearly, and the action verb distinguishes it from sibling tools like services_start, services_restart, and services_reload. It is slightly generic because it does not specify what kind of service or scope is involved, 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.
Usage Guidelines2/5
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 services_restart, services_reload, or services_get. The description implies usage through the verb 'Stop,' but it does not state prerequisites, exclusions, or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It only says 'Toggle' and describes the enabled flag; it does not explain what confirmation is for, whether the change is reversible, whether the service must exist, or what side effects occur. For a no-annotation mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded, and scannable thanks to the Args bullet list. However, the 'confirm: Required.' line is inaccurate relative to the schema and should be corrected, preventing a full score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Mechanically, the fields service and enabled are understandable enough to attempt a call. But the description lacks a definition of the watchdog, an explanation of confirm's role, and any routing guidance among the many service-related siblings. The existence of an output schema does not compensate for this missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for service and enabled ('True to watch, False to stop watching'), but confirm is only described as 'Required,' which contradicts the schema's optional/default-false status and does not explain what confirmation actually confirms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Toggle') and resource ('the service watchdog'), and the Args clarify the enabled semantics: true to watch, false to stop watching. It is not a 5 because the concept of 'watchdog' is not explicitly defined and no distinction is made from sibling service-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance or comparison with alternatives such as services_start, services_stop, services_restart, or system_services_overview. The intended usage is only implied by 'True to watch, False to stop watching'; no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Current account usage' implies a read-only status check but gives no detail about what usage data is included, whether it reflects the current session, or how it behaves across user/reseller/admin contexts. It is not contradictory, but it is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than efficiently complete. It is a sentence fragment with no verb or structural context, so it does not earn its place as a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: no parameters and an output schema is present. However, the description leaves ambiguity around whose usage is returned and gives no hint about session semantics, so an agent may not confidently select it among many similar usage-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and empty schema properties, so there is no parameter documentation burden. The description correctly implies no arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a resource ('current account usage') but uses no explicit verb and leaves scope ambiguous—'account' could mean user, reseller, or admin. The tool name session_user_usage clarifies it somewhat, but the description alone does not distinguish it from siblings like users_get_usage, resellers_get_usage, or admin_usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of related usage or session tools. The description does not mention session context, exclusions, or alternatives, so an agent must infer suitability 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, but 'Filesystem usage' reveals very little. It does not state whether the operation is read-only, what units or scope are involved, whether multiple filesystems/mount points are returned, or what output can be expected beyond what an output schema might provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, the description is undeniably concise and free of fluff. However, it is under-specified rather than efficiently structured; a short phrase that omits the action and important context is not the same as a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero parameters and an output schema, the description is too minimal to be contextually complete. It fails to explain what 'filesystem usage' means in this system context, when to prefer this tool over similar siblings, or what the output represents. An agent would have to guess whether this reports total disk capacity, per-mount usage, or available space.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the parameter semantics baseline is 4. The description does not need to explain parameters because there are none; the schema is already complete in that regard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Filesystem usage' identifies the resource being reported but lacks a verb, so it does not explicitly state that the tool retrieves or displays this information. It is somewhat distinguishable from siblings like system_cpu and system_memory, but it does not differentiate itself from fm_disk_usage, which also concerns filesystem usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 system_info, system_resource_usage_latest, or fm_disk_usage. The description gives no context, exclusions, or selection criteria, leaving the agent to infer suitability 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.
Behavior2/5
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 only the basic action and mentions a 'confirm' argument, but does not explain effects, reversibility, side effects, or what confirming actually does. This is thin for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loaded with the core purpose. The args section is compact, though 'confirm: Required' is too terse to be fully clear. Overall it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and only 0% schema coverage, the description is incomplete. It lacks usage context, behavioral disclosure, and clear confirmation semantics. The presence of an output schema helps with return values, but not with the key ambiguity around the confirm parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 does define 'timezone' usefully as an IANA name with an example, but 'confirm: Required' is ambiguous and contradicts the input schema, which lists only 'timezone' as required and gives 'confirm' a default of false. The description does not explain what value confirm should take.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Set server timezone.' This distinguishes it from sibling read-only tools like timezone_current and timezone_list, though it does not explicitly reference them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, no exclusions or prerequisites are mentioned, and the sibling timezone tools are not referenced. The intended use is implied by the verb 'Set' but not explicitly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain that deletion is destructive, irreversible, or what downstream effects may occur. The 'confirm: Required' note hints at a safeguard, but its meaning is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded, and has no filler. The Args list is compact. It sacrifices semantic richness but remains easy to scan and well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with four parameters and no annotations or schema descriptions, this is insufficient. It omits how confirm should be provided, whether impersonate is optional, what deletion affects, and what the response indicates. The output schema exists but does not cover usage behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The provided glosses ('Domain', 'Application names', 'Owning user') mostly restate the parameter names and lack type/format/value detail. 'confirm: Required' conflicts with the schema, where confirm is not required and has a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete one or more Nginx Unit applications.' This clearly identifies the operation and distinguishes it from sibling tools like unit_create and unit_list, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of alternatives, nor any prerequisites or conditions. The only usage signal is implied by the verb 'Delete' and the resource name, which is weak.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing behavior. It reveals that this is a mutating 'move' operation, but does not mention permissions, irreversibility, side effects on the user, or failure states. The 'confirm: Required' note also misleads about the actual requirement, since the schema does not mark confirm as required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action, followed by a compact parameter list. The Args section is arguably redundant with the schema, but it doesn't waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing operation with no annotations, this definition lacks enough context: it doesn't specify prerequisites, consequences, or correct confirm usage. The contradiction between the confirm note and the schema leaves an agent with ambiguous invocation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should carry parameter meaning. It does add useful semantics for username and new_creator, but confirm only says 'Required,' which is tautological and contradicts the schema — the schema lists confirm as optional with default false. This can cause incorrect invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation — 'Move a user to a different reseller/creator' — with a clear verb and target resource. It is unambiguous enough to separate it from most siblings, but it doesn't explicitly distinguish itself from broader tools like users_modify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when this tool should be used versus alternatives such as users_modify or users_convert_to_reseller. The description only states the action, so an agent has no context for choosing it over similar user-management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must declare behavioral traits itself. It indicates deletion but doesn't explain whether the removal is permanent, what side effects occur on the WordPress installation, or any required permissions. The 'confirm: Required' note hints at a safety mechanism but isn't elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the action in the first sentence and listing arguments without filler. The brevity is effective but omits important behavioral and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool, the description is too minimal. It fails to define what a 'WordPress location' is, leaves the confirm parameter's semantics ambiguous, and doesn't mention effects or return values. The presence of an output schema doesn't make up for missing safety and usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 restates location_id as 'Location id' and says confirm is required, but doesn't clarify what confirm does or how to set it. Furthermore, the schema marks confirm as optional with a default, so the description's claim that it is required creates potential confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Remove a WordPress location from the manager.' This is clear and unambiguous, though it doesn't explicitly distinguish itself from sibling tools by naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It simply says what it does, with no mention of wp_install, wp_get, or other related tools that might be confused with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that this is a mutating install operation, but it does not explain what 'confirm' actually does, whether installation can overwrite existing content, what prerequisites exist, or what side effects may occur. The claim that confirm is 'Required' also conflicts with the schema default of false, adding confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded with the core action, and free of filler. It could be better structured with clearer parameter explanations, but as written it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with a nested payload object, no annotations, and a sibling quick-install variant, this description is under-specified. It lacks any distinction from wp_install_quick, explanation of confirm's role, prerequisites, or effects. The presence of an output schema covers return values, but not the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The payload parameter gains some meaning from 'domain, path, title, admin user, …', which is helpful given the schema's 0% coverage. However, 'confirm' is only labeled 'Required,' which contradicts the schema where it is not required and defaults to false. The description does not explain what confirmation is being requested.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Install WordPress.' This unambiguously identifies the main action. However, it does not differentiate wp_install from the sibling wp_install_quick, 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.
Usage Guidelines2/5
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 wp_install_quick or other WordPress-related tools. No prerequisites, context, or exclusions are provided. The description only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. 'Installed / available software' only indicates subject matter; it does not explicitly state that this is a read-only listing, what kind of data is returned, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with no filler, but it is a fragment rather than a clear instruction. A sentence such as 'List installed/available software' would be equally concise and more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the bar is relatively low, and the description does convey the software domain. However, it omits the action and usage context, so an agent cannot be fully certain whether this returns a list, current status, or some other representation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, so the baseline is 4 and the description does not need to document argument semantics. There is no parameter confusion or undocumented required input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('software') and some scope ('Installed / available'), but it is a noun phrase without a verb, so the agent must infer that the tool lists or reports software. It also does not differentiate itself from sibling tools like cb_versions or cb_updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Nothing explains which question it answers or when a sibling tool such as cb_state, cb_options, or cb_versions would be a better choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does convey that this is a flushing/mutation operation, but it does not explain that temporary allow/deny rules will be removed, what the security impact is, whether the action is reversible, or whether a confirm value of true is needed to execute.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire useful content is front-loaded in a single clear sentence, followed by a minimal args note. There is no filler, repetition, or unnecessary elaboration. Every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that flushes all temporary rules and requires a confirmation argument, the description is incomplete. It lacks usage context, a clear description of the confirm parameter's expected value, and any warning about the effect of removing temporary allow/deny rules. The presence of an output schema reduces the need to document return values, but the described behavior and parameter semantics remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 `confirm` parameter. It only says 'confirm: Required,' which adds requiredness but not meaning: the schema lists `default: false` and no required constraint, so the agent cannot tell whether to pass `true`, `false`, or simply the parameter itself. This mismatch is confusing and risky for a destructive operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Flush all CSF temporary allow/deny rules') on a specific resource and includes the underlying command `csf -tf`. However, it does not explicitly contrast itself with the many related CSF sibling tools such as csf_remove_allow or csf_unblock_ip, so it only partially benefits from sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like csf_remove_allow, csf_unblock_ip, or csf_restart. The description implies usage only through its imperative phrasing, but gives no context about when flushing temporary rules is appropriate or when one of the more targeted CSF tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'Trigger a git deploy' and notes that confirm is required, without disclosing side effects, irreversibility, permissions, or what the deploy affects. The confirm hint suggests a gated action but is underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written and front-loaded: one clear action sentence plus a compact args list. There is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deployment mutation with no annotations, this is incomplete. It lacks when to use it, what actually happens during deployment, prerequisites, and the exact meaning of confirm. The output schema helps with return values but does not cover operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds 'Application uuid' and 'confirm: Required,' but the schema marks confirm as optional with a default of false. With 0% schema description coverage, the description should compensate more clearly and accurately; the confirm guidance is ambiguous and potentially misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair, 'Trigger a git deploy,' which is reasonably distinguishable from sibling tools like git_fetch, git_webhook, git_list, and git_get. It doesn't elaborate on what a deploy entails, but the core action is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as git_fetch or git_webhook. No prerequisites, exclusions, or decision criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full behavioral burden. It does not explain side effects, whether confirmation prevents partial changes, or what happens after export. Additionally, the line 'confirm: Required' conflicts with the schema, which lists confirm as optional with a default of false, creating ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with a clear one-sentence purpose. However, the Args section is too thin to be useful, and the misleading 'confirm: Required' line detracts from the value of the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an action that triggers an export with a confirmation parameter and a free-form payload, this description is incomplete. The output schema exists, so return values need not be described, but the tool still lacks essential context about what the payload should contain and what confirmation does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and payload is an open object with additionalProperties true, so the description must explain the parameter structure. It only says 'payload: Panel imapsync export body,' which gives no field-level meaning, and 'confirm: Required' is inconsistent with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Export mail from this box to a remote IMAP server.' This distinguishes it from the closely named sibling imapsync_import, though it does not explicitly call out the sibling. A clear, non-tautological purpose is present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action of exporting to a remote IMAP server implies when this tool would be used, especially alongside imapsync_import and imapsync_cancel. However, it provides no explicit guidance on prerequisites, when not to use it, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, but it only names the subject ('license details') and reveals no behavioral traits such as read-only nature, permissions, latency, or failure modes. The get-prefix in the name implies read-only, but the description does not state it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and free of filler, but it is under-specified: it reads as a label rather than an instruction and omits the verb and usage context. This is brevity at the expense of useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with an output schema, the description correctly identifies the resource and the schema covers the return shape. However, it still lacks a verb and any connection to license_proof or license_update_key, so the overall context is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object, so there are no parameters for the description to clarify. With zero params, the baseline is 4 and no additional parameter detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'DirectAdmin license details' identifies the resource but lacks an explicit verb, so an agent must infer that this is a retrieval operation from the tool name. It does not distinguish license_get from nearby license_proof or license_update_key, both of which also concern licenses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool instead of the license-related siblings; there are no exclusions or context cues. An agent cannot tell whether it should prefer license_proof or license_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only says 'Get one login key,' which implies a read operation, but it does not disclose what is returned, whether the key secret is exposed, error behavior, or any authentication or permission requirements. For a security-related tool, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no filler words. The Args block is redundant with the schema but not bloated. It is concise to the point of being sparse, but for a simple one-parameter getter this is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple get operation with one required parameter and an output schema, so the description does not need to explain return values. However, it lacks sibling differentiation and enough parameter context to be fully self-sufficient for an agent navigating a large toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description's 'key_id: Key id' essentially repeats the schema property title without adding format, source, or example information. The agent cannot learn how to find or format the key ID beyond the raw property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get one login key.' The word 'one' signals this is a fetch-by-ID operation, distinguishing it from login_keys_list, which presumably returns multiple keys. It is clear, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings such as login_keys_list, login_keys_history, or login_keys_commands. The description only says what it does, not when it should be selected or what prerequisite information (like where to obtain key_id) is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It only repeats that the tool activates a plugin, without disclosing side effects, reversibility, permissions, or what the confirm argument actually controls. This is a state-changing operation with minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with an Args block. No filler or unnecessary verbiage. However, the terseness contributes to the lack of useful parameter semantics, so it is not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing plugin tool with no annotations and a misleading parameter description, the context is incomplete. It does not explain what activation does, why the confirm flag exists, or how this differs from installing or enabling a plugin. The presence of an output schema is not enough to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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. 'plugin_id: Plugin id' is tautological, and 'confirm: Required' is misleading because the schema marks plugin_id as the only required parameter and gives confirm a default of false. The description adds almost no real meaning and actively contradicts the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Activate') and resource ('a plugin'), clearly distinguishing it from sibling tools like plugins_deactivate, plugins_update, and plugins_delete by verb alone. No ambiguity about what operation is being performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as plugins_install_url, plugins_deactivate, or plugins_update. 'Activate a plugin' implies the plugin is already installed, but this precondition is never stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for disclosing behavior. It only labels the data as 'history' and does not state whether it returns a time series, what resource metrics are included, what time range is covered, or what permissions are required. The description is a noun phrase rather than an explicit behavioral statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence plus an Args line with no filler, and the core scope is front-loaded. It is appropriately concise for a one-parameter tool, though the terseness contributes to under-specification in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the return structure does not need to be explained in the description. However, the description leaves unclear what 'global resource usage' includes, the time range or interval of history, and how this tool differs from sibling history/latest tools, making the context only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 parameter documentation. It adds only 'Username' to the schema's existing 'User' title, providing minimal clarification about the expected value but no format, example, or additional constraints. It does not meaningfully improve an agent's ability to supply the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool provides global resource usage history for one user, adding the key user-scope detail to the tool name. It is clear enough for an agent to understand the core purpose, though it lacks an explicit action verb and does not distinguish itself from nearby sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 system_global_usage_latest, system_resource_usage_history, users_get_usage, or admin_usage. The phrase 'for one user' implies scope, but no alternatives, exclusions, or selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It says the service will be restarted but does not explain potential downtime, whether a config check is performed first, what confirmation actually controls, or whether this is a safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded, and contains no filler. However, the Args line mostly repeats schema information and is under-specified, so it is concise but not a model of helpful structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-impact service restart with no annotations and almost no behavioral context, the description is incomplete. An agent cannot safely determine consequences, the confirmation contract, or when this tool should be preferred over the closely related services_restart tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 confirm parameter, but it only labels it 'Required.' This is misleading because the input schema shows default false and no required parameters. It also does not state what value confirm should receive or what effect it has.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Restart the DirectAdmin service.' This distinguishes it from related siblings like services_restart or system_update_directadmin and is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as services_restart, csf_restart, or system_update_directadmin. The description does not mention triggers, prerequisites, or conditions that should make an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Live usage + limits' gives some sense of freshness and scope, but nothing about side effects, authentication needs, error behavior, or response handling is disclosed. For a read-only getter this is minimal but not wholly absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the core purpose stated in the first sentence. It is appropriately sized for a simple one-parameter tool, though the parameter line adds little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return-value documentation is not required. The tool is simple with one required parameter, but the description lacks guidance on how it relates to sibling usage tools and does not clarify semantics beyond 'account name.' It is minimally sufficient but leaves selection context to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 says 'username: Account name,' which adds only a synonym for the schema title 'Username' and provides no useful format, constraints, or relationship to the returned data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get live usage + limits for a user.' This distinguishes it from configuration tools like users_get_config and other scope-specific tools like resellers_get_usage and admin_usage, though it does not explicitly name any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools such as resellers_get_usage, admin_usage, users_get_config, or users_list_all. The description only states what it does, not when to choose it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'Add' and repeats the confirm parameter. It does not disclose side effects such as whether a currently blocked IP is also unblocked, whether the skip is persistent, or what permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, followed by a compact Args list. It wastes no words, though the Args block could be integrated more naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating firewall-related tool with zero annotations and 0% schema coverage, the description is too sparse: it lacks side effects, usage context, and any clarifications about scope or confirmation behavior. The presence of an output schema reduces the need to document return values, but not the need for operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 ip as 'Address to skip' and says confirm is required, but it omits IP format/range syntax and does not explain what confirm's value should be despite the schema defaulting it to false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Add an IP') and a specific resource ('the BFM skip / never-block list'), which clearly distinguishes it from siblings like bfm_unblock_ip. Even without naming alternatives, the target list is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over related tools such as bfm_unblock_ip, csf_ignore_ip, or firewall_unblock_everywhere. The only usage hint is the confirm marker, which is a parameter note, not a selection criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. 'CustomBuild log names' gives no indication of return behavior, permissions, side effects, or whether the operation is read-only. This leaves key behavior ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and free of filler, earning its place with no repetition of schema content. It could be improved with an action verb, but it is structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the required contextual surface is small, and the description does identify the relevant domain. However, it lacks a clear operation, return semantics, or relationship to sibling CustomBuild commands, leaving an agent to guess what the tool actually does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is nothing for the description to clarify. With zero parameters, the baseline is 4 and no additional param detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies 'CustomBuild log names' as the subject, which is more specific than the tool name alone and separates it from siblings like cb_state and cb_options. However, it lacks a verb, so it never explicitly states whether the tool lists, returns, or otherwise manipulates those log names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call cb_logs, what information it provides, or how it differs from nearby CustomBuild tools such as cb_updates or cb_actions. An agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. 'Current state' weakly implies a non-mutating read, but there is no explicit statement that the call is safe, read-only, or that it discloses what information is returned or how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and direct, with no filler words or redundant restatement. It is efficient for a zero-parameter resource, though its brevity doubles as under-specification in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter state getter with an output schema, a minimal description can be acceptable. However, the meaning of 'current state' is ambiguous in a tool family with many CustomBuild inspection commands, so the description alone is not fully sufficient for an agent to confidently select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 meanings that the description needs to clarify. The baseline for a no-parameter tool applies, and the description suffers no parameter-semantics gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('CustomBuild') and the data area ('current state'), but it is a noun phrase with no verb and no detail about what 'state' includes. It does not clearly distinguish itself from nearby siblings like cb_versions, cb_options, or cb_software, which also expose current CustomBuild information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to call this tool versus alternatives such as cb_versions, cb_options, or cb_logs. The description implies it is a status/state read, but nothing states when it should be preferred or avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'Enable' and thus implies mutation, but does not disclose consequences for the user, whether confirmation gates the action, or whether enabling CageFS affects existing processes or settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, so there is no wasted prose, but it is under-specified rather than efficiently complete. The Args block adds minimal value over the schema and does not make the definition more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, the description should explain the confirmation gating, effects, and prerequisites. The output schema reduces the need to describe return values, but essential decision context is still absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must define both parameters. It only glosses username as 'Account', and the confirm entry 'Required' both omits meaning and conflicts with the schema, where confirm is optional with default false. A caller cannot know what value to pass or what the flag controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence uses a specific verb and resource ('Enable CageFS for one user') and is instantly distinguishable from the sibling cl_cagefs_disable by the enable/disable contrast. 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to call this tool, what state the user should be in, or why one would choose it over related tools. It does not mention that cl_cagefs_disable is the counterpart for reverting the action, and gives no scenario context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'check' and gives no detail about whether this is read-only, what credentials are validated, what connectivity is tested, or what side effects (if any) may occur. This is too thin for a credential-handling operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded, and free of filler. The first sentence states the purpose and the Args line adds a minimal parameter hint. However, the brevity is closer to under-specification than to deliberate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that takes credentials and a host, with no annotations and a schema that documents nothing about the payload, the description is incomplete. It does not explain what the check verifies, what inputs are required, what failure responses look like, or how this step relates to the import process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 0% coverage: payload is an opaque object with additionalProperties true. The description adds only 'Host / credentials body', which hints at content but does not specify required keys, expected structure, or credential format, leaving the agent unable to confidently construct a valid payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and identifies the resource as a remote cPanel server, with the temporal context 'before import'. This conveys the core purpose and roughly distinguishes it from the actual import flow, though it does not describe what specifically is checked.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before import' gives clear contextual timing for use, but the description does not name alternatives or state when not to use this tool. It also does not relate itself to the nearby sibling cpanel_import_tasks, so the agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Create a cron job' and adds a command safety note about shell metacharacters. It does not disclose side effects such as persistent scheduling, immediate deployment, privilege/ownership requirements, or what happens when creation succeeds or fails. The 'confirm: Required' claim is also inconsistent with the schema, which marks confirm as optional with a default of false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with a clear one-line purpose, followed by a tidy parameter list. Every comment is short, and there is no filler. It loses some points because several parameter comments simply restate the parameter names rather than adding meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a server-mutating tool with no annotations, the description is incomplete. It lacks usage context, prerequisites, side effects, clear cron field formats, and a coherent confirmation contract. Although an output schema exists, it cannot compensate for missing behavioral and usage guidance. The misleading 'confirm: Required' note further weakens an agent's ability to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must provide meaning for each parameter. It does add a little value: minute has valid range '0-59 or *', command has a security caveat, impersonate is described as 'Owning user', and confirm is flagged. However, most cron fields are only restated tautologically ('hour: Cron hour', 'month: Month'), leaving standard cron format and allowed values unspecified, and the confirm note contradicts the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action and resource: 'Create a cron job.' This clearly distinguishes it from siblings like cron_list and cron_delete, which are respectively for listing and removing cron jobs. The purpose is immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, nor any prerequisites such as permissions, ownership requirements, or whether a cron job must already exist. The name and lead sentence imply creation, but the description does not help an agent choose among cron-related tools or understand preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It says 'Drop,' which implies destruction, but it does not state irreversibility, permission requirements, or effects on associated databases/privileges. The 'confirm: Required' hint is misleading because the schema marks confirm as optional with a default of false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it is under-specified rather than appropriately concise. The 'Args' section is minimal and introduces a schema inconsistency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, the description is incomplete. It does not explain the confirmation semantics, what happens to the user's databases, or whether the action is reversible. The output schema exists, so return-value details are not required, but the missing behavioral and parameter context is significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 'dbuser: Name' and 'confirm: Required,' adding minimal meaning beyond the schema titles. It does not specify the expected type of confirm or clarify that it must be true to proceed, and it contradicts the schema's required/default configuration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Drop a database user.' This clearly distinguishes it from siblings like db_delete (likely dropping a database) and db_create_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 db_delete or db_user_get. The only usage-like hint is 'confirm: Required,' but it does not explain when confirmation is needed or what happens without it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of explaining behavior. It implies a read-only lookup but doesn't explicitly state side-effect-freedom, permissions, error behavior, or what 'details' contains beyond relying on the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no filler. Every sentence earns its place for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return-value gap is covered, and the tool is simple enough that this minimal description is close to adequate. However, it lacks context for choosing among similarly named db_* tools and gives no usage or behavioral prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 restates 'database: Database name,' which adds little beyond the schema's existing 'Database' title and string type. No examples, format, or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('one database') and indicates the tool returns details for it. It is understandable and distinguishes from list-style siblings by the singular scope, though it doesn't explicitly name or contrast any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 rather than the many related db_* siblings such as db_info, db_list, or db_user_get. The description leaves selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of behavioral disclosure. It does clarify the alias-versus-pointer behavior with 'True = alias (same site), False = pointer (redirect),' which is useful. However, 'confirm: Required.' is ambiguous and conflicts with the schema, where confirm is not in the required list and defaults to false. Side effects, reversibility, and confirmation semantics are left unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loaded with the core action, followed by a compact argument list. There is no filler or repetition of the schema, and each line earns its place. The main weakness is the terse 'confirm: Required.' entry, but overall the structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing operation with no annotations, the description is incomplete. It explains what the parameters mean but not when to use the tool, what prerequisites exist, or what the confirm parameter actually requires to execute the operation. Since an output schema exists, return values are not a gap, but the missing confirmation semantics and usage context are significant for an agent invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining most parameters: domain as the parent, from_domain as the new hostname, alias semantics, and impersonate as the owning user. The confirm entry, however, only says 'Required,' which adds little and actually contradicts the schema's optional-with-default-false definition. More precise value guidance would be needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Add a domain pointer / alias,' which clearly states the verb and resource. The distinction between alias and pointer in the args further clarifies what the tool does. It does not explicitly name sibling alternatives, but the resource is specific enough to stand apart from related tools like domain_pointers_delete or redirects_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as domains_create, subdomains_create, or redirects_create. The description provides a one-line action and an argument list, but no prerequisites, exclusions, or contextual hints about when this is the right operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It only reveals that this is a create operation and mentions 'confirm: Required,' but does not disclose side effects, permission needs, idempotency, or what happens to an existing forwarder. The confirm statement also conflicts with the schema, where confirm is optional and defaults to false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one clear purpose sentence followed by a terse argument list. It contains no filler, though the argument explanations are minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 5-parameter creation tool with an output schema, the description is borderline adequate. It lacks key context such as what an email forwarder does, when confirmation is required, and any preconditions, but the core parameters are at least named.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate, and it does explain most parameters: 'user: Local part (source)', 'destination: Destination address or comma-separated list', and 'impersonate: Owning user' add real meaning. However, 'domain: Domain' adds little, 'confirm: Required' contradicts the schema, and no formats or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create an email forwarder,' which identifies the exact verb and resource. It does not distinguish itself from sibling tools like email_forwarders_list or email_forwarder_delete, but the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no mention of when creation is appropriate. The description simply states the operation without contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description alone must disclose that this is a destructive operation. It says 'Delete' but gives no information about irreversibility, impact on mail routing, or whether confirmation prevents actual deletion. The 'confirm: Required' hint is present but its behavioral meaning is not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action. The Args list is minimal and adds useful glosses without fluff. It is appropriately sized for a simple delete operation, though it could have included more behavioral context without becoming inflated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and four parameters, this description is too thin. It does not explain when to use it, how confirmation works, side effects on email delivery, or what happens after deletion. The presence of an output schema reduces the need to describe return values, but critical operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds 'Local part' for user, 'Owning user' for impersonate, and 'Required' for confirm, which is valuable beyond the raw schema. However, it remains terse and does not clarify the confirm parameter's type, default false value, or behavior relative to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a forwarder.' This clearly identifies the operation as a deletion of a forwarder, and the sibling tools email_forwarder_create and email_forwarders_list make the contrast obvious. However, it does not explicitly differentiate itself from those siblings in the text, 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.
Usage Guidelines2/5
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 instead of email_forwarder_create or email_forwarders_list. The description simply says 'Delete a forwarder.' There is no mention of prerequisites, warnings, or conditions under which deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must carry the behavioral disclosure burden. It states that the action deletes a vacation message, which implies destructive behavior, but it does not explain consequences, reversibility, permission requirements, or the role of the confirm parameter. This is too thin for a deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core action, followed by an Args list. There is no filler or unnecessary detail. However, it is so minimal that some necessary semantics are missing, though that is more a completeness issue than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and 0% schema description coverage, this description is not complete enough. It fails to explain the confirm flag's purpose, whether deletion is permanent, or how domain and user combine to identify the target vacation message. An agent would likely need to inspect external documentation or guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 lack of parameter documentation. It labels domain as 'Domain' and user as 'Local part,' adding a little clarity about the email address structure, but the confirm parameter is only described as 'Required' while the schema marks it optional with a default of false. The description does not explain what confirm actually does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Delete a vacation message.' It distinguishes this tool from its email_vacation siblings by the delete action, so an agent can understand what it does. Even though the description is brief, 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.
Usage Guidelines2/5
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 email_vacation_set or email_vacation_get. No context, prerequisites, or exclusions are provided, leaving the agent to infer usage solely from the operation name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states what the tool lists; it adds no behavioral context such as read-onlyness, output shape, or whether the domain must pre-exist. The verb 'list' implies no mutation, but the description does not explicitly disclose safety or side-effect details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two lines with a clear front-loaded purpose; no filler. The 'Args:' section is redundant with the schema but harmless and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool with an output schema, the core inputs and purpose are present. However, absent annotations and any sibling differentiation, an agent cannot tell whether `email_autoresponders_list` is an alternative or whether `domain` must be a fully qualified domain name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 schema's lack of parameter docs. It merely repeats `domain: Domain`, which adds nothing beyond the schema's existing property name and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource (vacation/autoresponder) and action (list) with a domain scope. It is understandable in isolation, but it does not differentiate from sibling `email_autoresponders_list` or clarify whether 'vacation' and 'autoresponder' are the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a domain' gives clear context that this is the domain-scoped list operation, but there is no explicit when-to-use or exclusion, and no mention of when `email_vacation_get` or `email_autoresponders_list` would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It hints at a confirmation requirement and impersonation, but 'confirm: Required' is vague and arguably conflicts with the schema, and there is no statement about irreversibility, permissions, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action before the arg list. Each line is brief, though the misleading 'confirm: Required' line keeps it from being excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with no annotations, the description omits how confirmation should be expressed, whether deletion is permanent, and what ownership or impersonation requirements mean in practice. The output schema may cover return values, but the operational context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds small clarifications like 'FTP username' and 'Owning user,' but 'domain: Domain' is tautological and 'confirm: Required' is unclear and contradicts the schema's non-required status for confirm.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete an FTP account,' a specific verb and resource that clearly distinguishes it from siblings like ftp_create and ftp_list. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 ftp_list or ftp_create, nor any prerequisites, exclusions, or conditions. The intended usage must be inferred entirely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It identifies the operation as 'fetch', but does not state whether this is read-only, whether it contacts remote servers, whether existing git remotes are required, or whether any side effects occur. The description adds little beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse and front-loaded, with no filler or unnecessary caveats. The parameter block is cleanly structured. It earns high marks for concision, though a single additional sentence about behavior or usage could increase usefulness without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, this is minimally viable: an agent can determine the action and the uuid argument. But with no annotations, no stated prerequisites, and no guidance on how this relates to sibling git tools, the definition leaves too much implicit for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the parameter line must compensate. 'uuid: Application uuid' clarifies that the bare schema property Uuid refers to an application identifier, which is useful. However, it provides no format, provenance, or constraints beyond what the schema's type and required flags already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete operation and resource: 'Fetch remotes for a git application.' It clearly identifies what the tool does and requires an application uuid. It does not explicitly distinguish itself from sibling tools like git_get or git_deploy, but the 'remotes' scope provides meaningful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related git tools such as git_list, git_get, or git_deploy. No prerequisites, exclusions, or alternative conditions are mentioned. The only usage hint is 'for a git application,' which is implied context rather than explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It does state that 'confirm: Required', which is behaviorally relevant, but this conflicts with the input schema where confirm is optional with a default of false. The description does not disclose admin permissions, side effects, or irreversibility of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and wastes no words. The one-line purpose is front-loaded and the Args section is readable. The only structural issue is that 'confirm: Required' is presented as a parameter description rather than a clear usage requirement, and it conflicts with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a state-changing administrative tool with no annotations and no usage guidance. The description lacks context around when to use this versus ips_assign, whether the IP must be unused, confirmation requirements, or any consequences of the operation. An output schema exists, but it does not compensate for missing tool-selection and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 some meaning: netmask is clarified as 'IPv4 or prefix hint', and confirm is described as required. However, ip is merely restated as 'Address to add', and confirm's 'required' status contradicts the schema, making the parameter guidance partial and somewhat inconsistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Add an IP to the admin IP manager.' This clearly identifies what the tool does. However, it does not distinguish itself from the sibling ips_assign, which could also involve adding or associating IPs, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of related tools such as ips_assign, ips_remove, or csf_allow_ip. The description only outlines the operation and parameters, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only mentions that confirm is required, but not what confirmation entails, whether removal is reversible, or what systems are affected. For a destructive action, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, direct, and front-loaded with the main purpose. There is no unnecessary verbosity, though the Args section is too thin and the confirm note is misleading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive removal operation with no annotations, the description is incomplete. It omits usage context, side effects, confirmation semantics, and any distinction from related IP/firewall tools. The presence of an output schema does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only 'Address to remove' for ip and 'Required' for confirm. It does not explain confirm's meaning or type, and it contradicts the schema, which lists confirm as optional with a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove') and a specific resource ('an IP from the admin IP manager'). It is clearly distinguishable from sibling tools like ips_add, ips_assign, and firewall-level unblock tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus related tools such as csf_unblock_ip, firewall_unblock_everywhere, or ips_assign. There are no context clues, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It reveals this is a mutating operation but does not explain whether it overwrites the existing license, requires special permissions, or has irreversible effects. The 'confirm: Required' note hints at a safety mechanism but remains unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action. The Args section is minimal and easy to scan, though some of that brevity sacrifices needed behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although this is a simple 2-parameter tool with an output schema, the absence of annotations and usage context leaves significant gaps: an agent cannot tell when to invoke it, what the confirmation parameter actually does, or that it may overwrite an active license. More behavioral and contextual detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 restates the parameter names: 'key: License key' and 'confirm: Required.' Worse, 'confirm: Required' conflicts with the schema, where only key is required and confirm has a default of false, adding confusion instead of clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Install a new license key.' It clearly differentiates this tool from the related siblings license_get and license_proof, which imply reading/validating rather than changing the license.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 license_get or license_proof, nor any mention of prerequisites or consequences such as replacing an existing key. The intended use is only implicit from the verb 'Install.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that this is a read-only listing, whether it returns statuses, or whether there are side effects; 'exposes' only weakly implies a safe listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it is a fragment using a slash. Adding an action verb like 'Lists available...' would improve clarity without adding meaningful length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return shape and the absence of parameters simplifies invocation, but with no annotations and no mention of read-only behavior or relation to maintenance_check/maintenance_fix, the description is only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters to document. With 0 parameters, the baseline is 4, and the description does not need to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('Maintenance tasks / health checks the panel exposes') but uses no action verb, so it reads as a noun phrase rather than a clear statement that this tool lists those items. It does not explicitly distinguish itself from maintenance_check or maintenance_fix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or how it relates to alternatives like maintenance_check and maintenance_fix. The agent must infer from the name that this is the enumeration entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. Saying 'Message center list' conveys little beyond the operation name; it does not state whether the call is read-only, what scope of messages is returned, or whether any state is affected. The read-only nature is implied by 'list' but never made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but it is closer to under-specification than useful conciseness. It is a fragment rather than a complete operational description, and it provides no structural detail such as inputs, scope, or exclusions. Being short is not valuable when so little information is conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because the tool has zero parameters and an output schema is present, the minimal description is enough to guess a basic invocation. However, the description lacks context about what 'message center' means, how this list behaves, and how it differs from nearby messaging siblings, leaving the agent to rely on inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters and schema description coverage is 100%, so there are no parameter semantics to explain. Per the rubric, this yields a baseline of 4, and the description does not need to elaborate on parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Message center list" clearly indicates this tool returns a listing of message-center items, and the name messages_list reinforces the resource. It does not explicitly differentiate itself from the sibling messages_get, but list versus get is a recognizable distinction. The main gap is the absence of any detail about what messages are included or excluded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over messages_get, tickets_list, or any other messaging-related sibling. It neither states an intended use case nor rules out alternatives, so an agent must infer the usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It notes that payload usually includes the current password/OTP and that confirm is required, but it does not disclose side effects, whether MFA removal is reversible, or whether re-authentication is needed. The statement that confirm is 'Required' also conflicts with the input schema, which lists no required parameters and gives confirm a default of false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core action. The Args section adds meaningful parameter context without unnecessary elaboration, though the 'Required' note for confirm is inaccurate relative to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security-sensitive MFA-disabling operation with no annotations and minimal parameter details, the description is incomplete. It does not explain the consequences, prerequisites, or differences from related MFA tools, and the schema contradiction about confirm creates further ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 schema's silence. It adds some meaning by explaining that payload usually contains the current password/OTP and labeling confirm as required, but 'confirm' is not explained beyond that, and the schema's default/required status is not reconciled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Disable MFA.' This is specific and unambiguous. However, it does not distinguish itself from related sibling tools like mfa_enable or mfa_recovery_codes beyond the obvious opposition to enable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mfa_enable or mfa_generate_secret. The description simply states the action and parameters, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but not side effects, prerequisites, whether existing MFA is replaced, consequences of a bad OTP, or confirmation semantics. The 'confirm: Required' claim also conflicts with the schema, which lists no required parameters, further reducing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the main purpose in the first sentence. The Args block is compact, though the 'confirm: Required' line is misleading and slightly wasteful; otherwise, it is efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security-sensitive, two-parameter tool with no annotations and a 0% schema coverage, this description is incomplete. It lacks usage context, parameter semantics, effect on the account, and relationships to the MFA sibling tools. The presence of an output schema does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 some meaning by explaining that 'payload' is panel-specific and may contain OTP/password, but it is vague and does not describe structure, defaults, or the actual type/meaning of 'confirm'. The 'Required' label for confirm is misleading because the schema marks it as optional with a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Enable') and resource ('multi-factor authentication') with a clear scope ('on the current account'). This clearly distinguishes it from sibling tools like mfa_disable and mfa_recovery_codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mfa_generate_secret, mfa_recovery_codes, or mfa_disable. The agent is left to infer context from the name alone; there is no mention of prerequisites, sequencing, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that the operation is destructive ('Delete') but does not explain consequences such as whether users assigned to the package are affected, whether the operation is reversible, or what happens when the package is in use. It also states 'confirm: Required,' which contradicts the schema's default-false optional confirm field, adding confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loaded, with the action stated first and arguments listed compactly. For a two-parameter tool, this size is reasonable. The only structural flaw is that the 'confirm: Required' note is inaccurate and misleading, slightly reducing the value of the concise format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a destructive mutation tool with no annotations, the description should provide more context about preconditions, side effects, and confirmation semantics. It does not explain whether the operation requires the package to be empty, whether it cascades to dependent resources, or what the confirmation flag actually does. The presence of an output schema covers return values, but the missing operational context is significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 by defining parameters. It names 'package' as a package name and mentions 'confirm,' but the confirm description is misleading: it says 'Required' while the schema marks confirm as optional with a default of false. The description does not clarify what value confirm should take, what types are expected, or what the boolean meaning is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a user package.' This clearly distinguishes the tool from sibling delete operations like users_delete (deleting a user) and from package management tools like packages_user_save and packages_user_list. The resource type is named enough to avoid ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as packages_user_save or packages_user_list. The description simply states the action with no context about prerequisites, conditions, or exclusions. An agent must infer usage entirely 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral disclosure burden. It implies a destructive action but does not state that uninstalling may be irreversible, what happens to plugin data, or whether dependencies are affected. The 'confirm: Required' line adds ambiguity and conflicts with the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with its purpose, but the Args section mostly duplicates schema titles. 'plugin_id: Plugin id.' adds no value, and the structure is minimal rather than helpfully organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive plugin-management action with no annotations, more context is needed: irreversible consequences, whether confirm must be true, any prerequisites, and how it differs from deactivation. The output schema does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 restates 'plugin_id: Plugin id.' redundantly and says 'confirm: Required,' but does not explain what confirm does, what type it should be, or why it is needed. This actively contradicts the schema, which lists only plugin_id as required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the operation: 'Uninstall a plugin.' The verb 'Uninstall' plus the resource 'plugin' distinguishes it from related sibling tools like plugins_activate, plugins_deactivate, and plugins_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as using plugins_deactivate for temporary disabling or plugins_update for updates. The description gives no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Update a plugin' and mentions 'confirm: Required,' which hints at a confirmation requirement but does not explain side effects, whether the update is destructive, permission needs, or what happens to the existing plugin. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no filler or repetition. Its brevity is a strength, but it trades away needed explanatory content, especially around the confirm parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and only minimal schema descriptions, the description is incomplete. It does not explain the confirmation mechanism, the update source behavior, potential consequences, or when this tool should be chosen over related plugin tools. An output schema exists, but it does not compensate for missing behavioral and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 schema's lack of parameter details. It lists plugin_id and confirm, but adds little beyond the schema's existing titles. The statement 'confirm: Required' conflicts with the input schema, which lists only plugin_id as required and gives confirm a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update a plugin from its update_url.' This clearly identifies the action and the source, and is distinguishable from sibling tools like plugins_install_url or plugins_delete by the operation itself. However, it does not explicitly differentiate itself from any sibling by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for updating a plugin from its update_url, but it provides no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as plugins_install_url or plugins_activate. Usage context is only weakly implied by the tool name and one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does flag that confirmation is needed, but it does not explain what confirm actually does, whether the demotion is destructive/reversible, what happens to the reseller's existing accounts or resources, or what permissions are needed. The phrase 'confirm: Required' is also ambiguous and conflicts with the schema's optional default-false confirm field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, and the Args section is cleanly separated. It loses a point because the 'confirm: Required' line is misleading and does not meaningfully explain the parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a privilege-demotion operation with no annotations, the description is incomplete. It lacks side-effect disclosure, alternative routing, and confirmation semantics. While an output schema exists, the core operational context an agent needs to safely invoke this confirmed, destructive-style action is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 defines 'username: Reseller to demote' clearly, which adds value, but 'confirm: Required' is not a semantic explanation and even contradicts the input schema where confirm is optional with a default of false. The description should clarify that confirm must be set true to proceed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Demote') and resource ('a reseller') plus the resulting state ('to a regular user'). This clearly distinguishes it from the sibling users_convert_to_reseller, which performs the reverse operation, so an agent can tell which tool is which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives, no prerequisites, and no mention of related operations. The description only states the action itself, leaving the agent to infer usage context without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only repeats the destructive nature already implied by the tool name and provides no context about irreversibility, permissions, or what happens to the affected session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, which is good. However, the line 'confirm: Required.' is misleading and does not earn its place, and the description is too terse to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive session tool with no annotations, the description lacks essential context such as how confirm should be set, whether the action is reversible, and what the result will be. The output schema helps with return format, but the description is still incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds almost no semantic value. It calls confirm 'Required,' which contradicts the input schema where only public_id is required, and it does not explain what confirm means or what value should be passed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Destroy one other session.' It clearly distinguishes this tool from siblings like sessions_list and sessions_destroy_all_other by limiting scope to a single other session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the wording 'one other session' — it should be used when targeting a single session rather than all sessions. However, it does not explicitly state when to prefer this over sessions_destroy_all_other or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavioral traits. It identifies the operation as creating a CSR, but does not disclose side effects, whether an existing slot is required, idempotency, permissions, or downstream consequences. The commercial CA flow note adds context but not behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by a brief argument list. The arg list is justified because the schema has no descriptions. No filler or redundant prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation with no annotations and 0% schema coverage, the description is thin. It does not explain where this step fits in the commercial CA flow, what prerequisites are needed, or how it relates to SSL siblings. The presence of an output schema reduces the need to document return values, but other contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameter meaning. It provides terse but useful semantics: common_name defaults to the domain, and impersonate identifies the owning user. There are no formats, constraints, or examples, but the essential meaning of each parameter is present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Create a CSR for a domain certificate slot'. The parenthetical 'commercial CA flow' adds useful context that distinguishes it from self-signed or ACME flows. It does not explicitly name sibling tools, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over related siblings like ssl_reissue_domain, ssl_install_self_signed, or ssl_upload_cert_files. The phrase 'commercial CA flow' hints at a use case but does not state conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. The word 'snapshot' weakly implies a read-only point-in-time view, but the description does not explain what 'occupancy' covers, what system data is inspected, or any caveats or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a disambiguating parenthetical and no filler words. It is appropriately brief for a zero-parameter tool, though the brevity contributes to the ambiguity of the term 'occupancy'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The empty input schema and presence of an output schema lower the burden, and the basic call is simple. Still, the unexplained 'occupancy snapshot' concept and weak differentiation from the many sibling service tools leave a meaningful gap for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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-meaning gap for the description to fill. The baseline of 4 applies because nothing about parameter semantics needs to be documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a resource ('services occupancy') and an action ('snapshot'), and the parenthetical distinguishes it from 'the systemd list'. However, 'occupancy' is never defined, so an agent cannot tell exactly what data the tool returns; the phrase points more at what the tool is not than at what it is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is the negative statement 'not the systemd list', which does not tell an agent when to use this tool or which alternative to choose instead. No explicit conditions, exclusions, or sibling references such as services_list are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It only reveals that extended switches to /api/search/users-extended, but does not disclose what extended changes, how results behave, or whether any side effects or permissions are involved. The read-only nature is implied by the name but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a brief parameter breakdown. It is appropriately sized for a two-parameter search tool, though the extended parameter explanation is terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough to call the tool with q and extended, and an output schema exists so return values need not be documented. However, it lacks guidance on when extended should be used and how this search differs from sibling listing/existence tools, leaving a moderate completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 useful semantics for q by specifying accepted query forms (username/domain/email fragment). For extended, it only mentions the endpoint switch, not the behavioral difference, which leaves a partial semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as searching users via the New API, which is a specific verb and resource. It does not explicitly differentiate from sibling tools like users_list or users_exists, but the action 'Search users' is distinct enough for basic identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 users_list, users_list_all, or users_exists. The q argument hints at use cases (searching by username/domain/email fragment), but there is no explicit contextual or alternative-based guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states that actions are available; it does not explicitly say the call is read-only, what the response represents, or whether any state changes occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no wasted words. However, it is under-specified: a few more words like 'Lists the' would make the purpose explicit while preserving conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, a brief description is acceptable, but the tool is still incomplete contextually: it never states the relationship to cb_run or that this is the inventory of actions for CustomBuild operations. An agent must infer the intended use from the name and sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 detail for the description to add. The schema already covers 100% of the parameter surface, and the description adds the only relevant context: the result is about available CustomBuild actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (CustomBuild actions) and indicates the tool exposes available actions, which is clearly a listing operation despite lacking an explicit verb. It is clear but does not explicitly differentiate it from sibling tools like cb_run or cb_options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to call this tool or when to prefer an alternative. It does not mention that cb_run consumes these actions or that related CustomBuild configuration is handled by cb_options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is read-only, what it returns, whether it can fail, or whether it reflects live or saved settings. Identifying the resource without describing behavior is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short declarative sentence with no filler or redundancy. It is concise and front-loaded with the core subject.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description still leaves the operation ambiguous and does not differentiate it from db_server_config_update or db_server_config_test. An agent could reasonably call it and be uncertain whether it returns current settings, default settings, or performs some action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 nothing for the description to clarify. The baseline for parameterless tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('SQL server connection settings') and adds context ('used by the panel'), but it lacks an operational verb such as 'get' or 'retrieve'. The tool's purpose as a read operation is only implied by its name and the presence of sibling update/test tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 db_server_config_update for modifications or db_server_config_test for connectivity testing, leaving the agent to infer the correct context from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden, and it only names the output artifact. It does not say whether the call is read-only, whether it generates or downloads the file, whether it modifies account settings, or what side effects (if any) occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded phrase with no filler, so it is easy to parse. However, it is under-specified as a bare noun phrase and could add a verb or a safety note without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the mechanical invocation is simple and the return value may be documented elsewhere. Still, the absence of any action verb or behavioral notes means the description is not fully complete on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and an empty input schema, so there is no parameter documentation needed. The 'current email account' phrase provides the relevant session-based context, which is sufficient for a no-argument call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a concrete artifact ('Apple mobileconfig') and a scope ('current email account'), which implies a retrieval/generation purpose, but it never states an explicit verb or action. his is clearer than a bare tautology but still leaves whether it creates, returns, or manages the profile to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: a caller would use this when an Apple mobileconfig for the current email account is needed. It does not explicitly state when to choose it over related email or config tools, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only implies a read operation by naming the output type. It does not disclose recursion behavior, hidden-file/symlink handling, or whether the operation is safe/read-only, which is a substantial gap given zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two short lines, the description is efficiently front-loaded with the core concept and the parameter explanation. No filler or repetition exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, and the path parameter is covered. However, with no annotations and no usage context or behavioral detail, the description is only minimally viable for an agent deciding when and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explicitly defines path as 'Starting path,' adding meaning beyond the schema's bare title and default. For a single-parameter tool this is adequate, though it doesn't specify path format or accepted files/directories.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says only 'Directory tree,' identifying the resource but not stating an explicit verb such as 'list' or 'show.' It does not differentiate from sibling tools like fm_list or fm_disk_usage, leaving the agent to infer that this tool returns a hierarchical directory view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use fm_tree versus fm_list, fm_search_files, or other file-manager siblings. No exclusions, prerequisites, or context are provided; the description is limited to an arg definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Current profile settings', which implies a read-only snapshot but never explicitly states safety, side-effect profile, or any operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, which is appropriate for a zero-parameter getter. However, it is closer to under-specification than to concise completeness because it omits an explicit verb and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and there are no parameters, so invocation is trivial. Still, the description does not explicitly state that this retrieves or reads settings, nor does it distinguish itself from profile_settings_update, leaving some ambiguity for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and schema coverage is 100%, so the baseline of 4 applies. There is nothing for the description to document regarding parameter meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear resource, 'profile settings', and the qualifier 'Current' implies a read/retrieval operation. It is distinguishable from the sibling profile_settings_update tool by this current-state framing, though it lacks an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 profile_settings_update. The word 'Current' hints at a read operation, but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Search' implies a read-only operation, but the description does not disclose search semantics, what 'available' means, whether an active login-as session is required, or any pagination/result behavior. This is a significant gap for a tool with no annotation safety signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main purpose, and contains no filler. The Args block is clearly structured. Overall it is appropriately brief, though a few of the lines are near-tautological.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: two optional parameters, no enums, and an output schema exists to describe return values. The description gives the core purpose but lacks context about when to invoke it relative to siblings like session_login_as and users_search, and it does not clarify the intended workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 compensate. It only adds 'q: Query' and 'limit: Max rows,' which provide minimal meaning beyond the schema and do not clarify what q searches against, matching rules, or how limit behaves. The description adds little value for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'Search users available for login-as.' This distinguishes it from generic users_search and from the action-oriented session_login_as sibling. However, it does not explicitly describe its role as a helper step before session_login_as.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'available for login-as' implies the tool is used when an agent needs to find candidate users to impersonate, which gives useful context. But it never explicitly says when to prefer this over users_search or other user-list alternatives, and it provides no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It only names the returned data and implies a read operation, but does not state whether this is a live or cached snapshot, whether admin privileges are required, or what side effects, if any, exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and wastes no words, but it is a noun-phrase fragment rather than a complete action statement. It is concise, yet under-specified enough that the structure does not add much beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the basic invocation is clear and return values can be learned from the schema. However, with many similar system_* siblings and no annotations, the description lacks enough context to reliably route an agent to this tool over the closely related resource usage variants.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 documentation burden on the description. The empty input schema fully covers the invocation surface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('global resource usage') and a temporal scope ('latest'), so an agent can tell this returns a current system-wide usage snapshot. It lacks an explicit verb and does not differentiate from the closely named system_resource_usage_latest, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus system_resource_usage_latest, system_global_usage_history, or other system monitoring siblings. The description provides no selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It signals mutation with 'Set' and mentions confirm, but does not explain what confirm does, whether the change is reversible, what side effects may occur, or if special permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with a clean Args block. It earns its space, though the misleading 'confirm: Required' line prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and incomplete parameter semantics, this description leaves too much unsaid: what happens after the version is set, whether confirm affects execution, and when the user should prefer this over cl_php_selector_get. It is minimally functional but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It usefully defines username and provides concrete version examples like 8.2 and native. However, it states 'confirm: Required' while the schema marks confirm as optional with a default of false, creating a contradiction that undercuts reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Set CloudLinux PHP Selector version for a user.' This precisely distinguishes the tool as a mutating counterpart to cl_php_selector_get, leaving no ambiguity about 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as cl_php_selector_get or other CloudLinux tools. The context is implied by the 'Set' action, but there are no exclusions, prerequisites, or explicit routing cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get records for a zone' and does not explain what kind of records are returned, whether all zones/domains are covered, error behavior, authentication needs, or any other behavioral detail. It is accurate but extremely thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 purpose and then defines the only parameter. Every word earns its place for a single-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and an output schema exists, so the description is nearly sufficient to make a correct call. Still, there is no usage context, no clarification of scope, and no mention of how this relates to other DNS tools, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the meaning 'Zone name' to the 'domain' parameter, which is slightly more specific than the schema's bare 'Domain' title. However, it provides no format, example, or qualification such as whether a trailing dot is expected, so the compensation is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: 'Get records for a zone.' This makes the tool's purpose immediately understandable and distinct from mutation tools like dns_record_add and dns_record_delete. It does not explicitly differentiate from sibling read/DNS tools such as dns_admin_list, 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.
Usage Guidelines2/5
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. The description does not mention related DNS tools, prerequisites, or exclusions, so an agent receives no help deciding between this and other DNS endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does add one genuinely valuable disclosure: 'Passwords in the payload are redacted in logs,' plus the confirmation requirement. However, it never discloses that this is a state-mutating import, whether the operation runs synchronously (relevant given imapsync_migrations exists), or how existing mailbox contents are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one action sentence followed by a terse args list with no wasted words. The only structural flaw is the ambiguous and potentially misleading 'confirm: Required' statement, which undercuts the otherwise clean format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating, cross-system operation with zero annotations and a fully opaque payload object (additionalProperties: true), the description leaves too much unstated: the meaning of 'dest,' whether the operation is asynchronous and tracked via imapsync_migrations, and what happens to pre-existing mail. The redaction note is a good start, but an agent still lacks enough to safely invoke and monitor this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 — and it partially does by expanding payload to '(host, user, password, dest)' and flagging confirm, adding real meaning to otherwise opaque structured fields. But the claim 'confirm: Required' conflicts with the schema, which lists only payload as required, and no format or validation details for the payload fields are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action — 'Import mail from a remote IMAP server into this box' — naming the verb, source, and destination in one clear sentence. This makes the tool's basic function unambiguous, and the import direction inherently distinguishes it from siblings like imapsync_export. However, it never explicitly names its sibling alternatives, so differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to choose this tool over imapsync_export, imapsync_cancel, or imapsync_migrations, and no prerequisites (e.g., remote server reachability) or decision rules are given. The 'confirm' mention is a parameter note, not a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. It only states the operation is an admin-level list and names the API call; it does not disclose read-only status, required permissions, pagination, error behavior, or any side effects. 'List' implies read-only, but that remains an inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, and the parenthetical API reference adds useful context for agents familiar with DirectAdmin. The key operation and scope are front-loaded. However, brevity edges toward under-specification rather than deliberate completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists to document return values, and zero parameters reduce invocation complexity. Still, with no annotations the description should clarify read-only behavior and how this tool differs from the closely related ips_list tool. It provides only a minimal label and leaves behavioral context to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema coverage is effectively 100% because the properties object is empty. There is no parameter semantics for the description to add, so the baseline for a no-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (IP addresses), the action (list), and the scope (admin-level), and references the underlying DirectAdmin API endpoint (CMD_API_IP_MANAGER). This distinguishes it from user-level IP listing tools like ips_list, though 'list' is used as a noun phrase rather than an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as ips_list or ips_get. The 'admin-level' qualifier implies it is for administrative IP operations, but no exclusions, prerequisites, or selection criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'List MFA recovery codes.' It conveys a non-destructive read action through 'List,' but does not disclose whether the codes are single-use, whether listing them regenerates or invalidates existing codes, or whether authentication is required. For a security-sensitive resource like recovery codes, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('List') and the object ('MFA recovery codes'). It contains no filler, repetition, or tangential information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple in terms of parameters and has an output schema, but the description supplies no usage context or security caveats for MFA recovery codes. An agent cannot determine from the description alone when to choose this over mfa_generate_secret, nor whether calling it has side effects. The lack of any guidance around the operation makes it incomplete for a sensitive security context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameter semantics to clarify or misunderstand. The baseline for a zero-parameter tool is 4, and the description does not introduce any parameter-related confusion. Nothing more is needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' plus the resource 'MFA recovery codes,' clearly indicating a read-only retrieval operation. It is distinguishable from sibling tools like mfa_generate_secret or mfa_enable because 'list' implies returning existing codes rather than creating or enabling them. However, it does not explicitly name or contrast those siblings, so it stops short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as mfa_generate_secret or mfa_enable. There is no mention of prerequisites, such as MFA being enabled, nor any indication of when another MFA-related tool should be chosen instead. This is effectively a flat listing with no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It says 'Apply' and mentions 'confirm: Required', but never states what the operation does to existing nginx configuration, whether it is reversible, what side effects occur, or why confirmation is needed. This is a mutating tool whose consequences are left mostly to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose, followed by a clean argument list. The format is efficient, though 'Required.' and the trailing ellipsis are slightly underinformative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotation coverage and no schema parameter descriptions, this is incomplete. Missing are preconditions, the effect on existing templates, confirm semantics, and what happens after application. The output schema exists, so return value details are less critical, but the operational context is still too thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It does add useful values for 'template' and clarifies 'impersonate' as 'Owning user'. However, 'domain: Domain' is near-tautological, and 'confirm: Required' is ambiguous—and appears to conflict with the schema where confirm is optional with a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Apply'), a specific resource ('Pro Pack Nginx CMS template'), and gives concrete examples. It is clearly distinct from the surrounding sibling tools, none of which are about setting nginx templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance about when to use this tool vs alternatives, no preconditions, and no exclusions. The sibling list is large, but the description provides no routing context such as 'use this after creating a domain' or 'use wp_install to actually install WordPress'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates an admin-scoped inventory, implying a read-only listing and an authorization requirement, but it does not explicitly confirm that no changes are made or describe any behavioral caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with no filler words, and the admin qualification is useful. It is a fragment rather than a complete sentence, but it is still an efficient, front-loaded phrase for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument tool with an output schema, this is close to sufficient: it names the resource and admin context. However, it is ambiguous against nearby plugin tools and provides no direction on when to select it, so an agent may still under- or over-select it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 the baseline is 4. The description adds the admin scope but no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Plugin manager inventory' identifies a resource and admin scope, but it is a noun fragment with no explicit verb; it relies on the tool name for the 'list' action. It also does not differentiate itself from the sibling plugins_list, which could be the non-admin equivalent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to call this tool versus siblings such as plugins_list or inventory_get. The '(admin)' marker hints at privilege level but does not state conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says the active domain is switched. It does not explain side effects on subsequent session calls, whether the domain must already exist, reversibility, or what happens to the previous active domain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the core behavior. The Args line is minimal and directly tied to the single parameter, with no wasted words or repetitive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has only one parameter and an output schema, the description lacks important context about session state semantics. It does not say how the active domain affects subsequent calls, which sibling tools provide domain options, or whether the switch is scoped to a single request or persists across the session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 the Args section only says 'domain: Domain to select.' This adds little beyond the parameter name and type, and does not clarify expected format, valid values, or relationship to domains available in the session.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource combination — 'Switch the active domain in the session' — clearly identifying both the action and the object. It distinguishes itself from session and domain siblings by scoping to the active session domain, which no other tool description matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives, nor any exclusions or prerequisites. It merely states what the tool does, leaving the agent to infer when a domain switch is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. 'History' implies a read-only listing, but the description does not clarify scope (system-wide vs per-user), what data points are returned, retention limits, or whether only completed or also failed tasks are included. It adds minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with no filler words, making it efficient. However, it is a noun fragment rather than an explicit instruction, and it omits useful context such as scope or related tools. It is concise but slightly too sparse to be considered excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description may be enough for an agent to make a basic call and interpret the return schema. Still, it leaves contextual gaps around when to use it relative to update/run tools and what 'history' encompasses, which are not covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty with 100% coverage. Per the rubric, a 0-parameter tool receives a baseline of 4, and the description adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource—'OS package upgrade tasks'—and implies the operation is retrieving a history. It is not a tautology and can be semantically distinguished from related tools like system_packages_updates or system_packages_update_run. However, it lacks an explicit verb and does not name any siblings to aid differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of related package tools such as system_packages_update_run, system_packages_update_test, or system_packages_updates. No conditions, prerequisites, exclusions, or alternative tools are mentioned, leaving the agent to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It implies a read-only listing but does not explicitly state that no changes are made, nor does it mention whether the check is live/cached, requires authentication, or has side effects such as refreshing package metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant words, making it easy to parse. It is appropriately concise for a zero-parameter tool, though it could be slightly more informative without much added length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is mostly sufficient: it indicates the result is a list of available OS package upgrades. However, in the context of many sibling update-related tools, it does not clarify when to choose this tool over update_test/run/history or what the output contains beyond 'available upgrades'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 are no parameter semantics to document. The description adds useful context by clarifying the tool reports available upgrades rather than performing them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Available OS package upgrades' indicates the tool retrieves the list of upgrades available for the operating system packages. It is distinguishable from siblings like system_packages_update_run and system_packages_update_test because it points to a listing rather than an action, though it lacks an explicit verb such as 'list' or 'check'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to call this tool versus system_packages_update_test, system_packages_update_run, or system_packages_history. The description only states what is available, leaving the agent to infer the appropriate context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, but it only notes the notify side effect and marks confirm as required. It does not explain that creating an admin is a privileged, persistent mutation, whether it is reversible, or what confirmation is actually needed. The 'confirm' statement is also ambiguous relative to the schema's required list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is compact, front-loads the purpose in the first sentence, and uses a plain Args list without filler. Each line adds information, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values and the arg list covers parameters, so the definition is minimally viable. However, it lacks usage routing among account-creation siblings, permission expectations, and a clear explanation of the confirm field, leaving important context missing for a mutating admin tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by glossing username, email, password, and notify with actual meaning. The confirm parameter is only labeled 'Required' without explaining its role or value, which is a notable gap, but most parameters gain useful context beyond their titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Create another admin account.' This clearly identifies the tool's operation and distinguishes it from listing tools such as admins_list. It does not explicitly differentiate from sibling creation tools like users_create or resellers_create, so it stops short of full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the sibling creation tools such as users_create or resellers_create. No prerequisites, permission requirements, or exclusions are stated, leaving the agent to infer usage only from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'resource usage,' with no mention of whether this is a live snapshot, a cached total, or what side effects or permissions are involved. It does not contradict any annotation, but it provides very little 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, using only four words to convey the essential subject and scope. There is no repetition, filler, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description is minimally viable for a simple read-only usage lookup. However, it leaves ambiguity around what 'resource usage' means and how this relates to similar usage tools, so an agent may still be uncertain about the exact data it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 semantics burden on the description. The baseline of 4 applies because no parameter clarification is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: the current admin's resource usage, which distinguishes it from user- or reseller-level usage tools in the sibling list. However, it is a noun phrase rather than an explicit verb+resource statement, and it does not spell out which resource metrics are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over similar siblings such as users_get_usage, resellers_get_usage, session_user_usage, or system_resource_usage_latest. The phrase 'current admin' implies a narrow scope, but there is no explicit when-to-use or when-not-to-use instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It fails to warn that restoring will likely overwrite or replace the target user's current data, nor does it mention required privileges or irreversibility. The 'confirm: Required' line hints at a safety step but does not explain the actual consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the purpose, and contains no filler. The Args block is minimal and each line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists so return values are covered, this is a destructive restore operation with no annotations. The description lacks any warning about overwriting target data, necessary permissions, or confirmation semantics, making it incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 useful meaning for username ('Account to restore into') and file ('Backup filename as listed by the panel'). However, the confirm parameter is only described as 'Required', which is vague and also conflicts with the schema where confirm is optional with a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Restore') and a specific resource ('a user from a local backup file'). This clearly distinguishes it from sibling backup tools such as backups_create or backups_admin_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusions. The description simply restates the action and its arguments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. 'Kill' signals a destructive action and 'confirm: Required' suggests a safety gate, but the description is contradicted by the input schema, which shows confirm has a default of false and is not required. This leaves the agent uncertain about actual safeguards and consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded, with no filler. The main purpose is stated in the first sentence. However, the inaccurate 'confirm: Required' line weakens the value of the otherwise concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, the description is too thin. It lacks context about what happens to the job after killing, whether the operation is reversible, what the output schema represents, and how to properly set the confirm parameter. The schema contradiction makes the tool unsafe to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 says 'confirm: Required', adding a claim that directly conflicts with the schema's 'default: false' and the zero required parameters. It does not explain what confirm should be set to, what it means, or why it is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Kill') and the resource ('a running CustomBuild job'), making the tool's intent unambiguous. This also distinguishes it from sibling tools like cb_run, cb_updates, and cb_state, where 'kill' is unique to this operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when a CustomBuild job is running and needs to be terminated. However, it provides no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as cb_run or cb_actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that confirm is 'Required', but it does not say whether the scan blocks, how long it runs, what is scanned by default, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core action, followed by a minimal argument list and no filler. It earns a 4 rather than 5 because the argument explanations are too under-specified to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no parameter schema descriptions, an agent still cannot construct a valid payload or understand what confirmation really means semantically. The output schema may document results, but the input side and operational workflow are under-explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description must compensate but only says payload is 'scan options as the panel expects' – an opaque reference to the UI. It also labels confirm 'Required', which conflicts with the schema's optional default of false and lack of a required list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Start') and a concrete resource ('ClamAV scan'), so an agent can immediately identify this as the initiation tool. It also distinguishes itself naturally from sibling tools like clamav_status and clamav_kill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Start' and the confirmation argument imply this is the tool to use when initiating a scan. However, it never explicitly names alternatives or says when not to use this tool, leaving the agent to infer boundaries from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral disclosure burden. It only says 'create' and lists arguments; it does not explain that this is a mutating operation, what confirmation means, whether resources are immediately created, side effects, or permission requirements. The terse 'confirm: Required' hint is not enough to disclose the operation's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loaded: the core purpose appears in the first sentence, and the Args section is minimal. The main issue is ambiguity rather than verbosity or poor structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a compound creation tool with a nested free-form payload, no annotations, and zero schema documentation, the description is insufficient. An agent cannot reliably form the payload, interpret what 'confirm: Required' actually means, or understand the operation's effects. The existence of an output schema does not compensate for these invocation-level gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 minimal meaning by labeling payload as 'Combined create body' and confirm as 'Required,' but payload remains an unspecified free-form object under additionalProperties: true, and 'confirm: Required' conflicts with the schema, where confirm is optional with a default of false. The description does not adequately explain the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the action and resource: 'Create a database and a user in one call.' This is specific and immediately distinguishes the tool from sibling tools like db_create and db_create_user by emphasizing the combined operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are provided. The phrase 'in one call' implies the agent should use this when both a database and user need to be created together, but there is no direct statement about when not to use it or how it relates to db_create and db_create_user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'List' clearly signals a read-only operation, which is useful behavioral context. However, with no annotations provided, the description carries the full burden and does not disclose whether any special permissions are required, how impersonation affects results, or whether there are any domain ownership constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the main purpose in a single sentence, and keeps argument explanations compact. It avoids fluff, though the argument block is largely redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list operation, the description is minimally adequate: it names the operation and both parameters, and the output schema covers return values. It lacks usage guidance, alternative routing, and deeper behavioral context, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains 'domain' and clarifies that 'impersonate' means the owning user, which adds some meaning beyond the schema's bare titles, but the explanations are minimal and partly tautological ('domain: Domain').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a concrete resource ('autoresponders on a domain'), making the primary purpose clear. It does not, however, differentiate itself from sibling tools like email_vacation_list or email_forwarders_list, which could be confused with autoresponder-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no mention of prerequisites, and no exclusions or preferred conditions. The description only restates the operation without explaining the context in which an agent should select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it searches file names; it does not disclose recursion behavior, case sensitivity, hidden-file handling, or whether the operation is strictly read-only. 'Search' implies non-mutating behavior but does not state it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: a one-sentence purpose followed by a two-line argument explanation. There is no filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for invoking the tool: an agent knows to supply a filename fragment and an optional root path. However, key operational details such as whether the search is recursive, whether hidden files are included, and how this differs from fm_search_text are missing, leaving gaps for a no-annotation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by defining both parameters: 'query: Filename fragment' and 'path: Root to search'. This adds real meaning beyond the bare schema titles, though it could specify matching semantics or path format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search file names' names a specific verb and resource, and the phrase 'file names' helps distinguish it from content-search siblings like fm_search_text. It is clear, though it does not explicitly name the alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that fm_search_text is for content search or fm_list for directory listing, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral transparency burden. It does convey that this is a read-only listing operation ('List'), but it does not disclose any constraints such as required domain format, authentication needs, or behavior when no git applications exist. The output schema covers return values, but other behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and easy to parse: it opens with the action and then lists the sole argument. However, the 'Args' section is redundant with the schema and adds no unique value, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although this is a simple tool with one required parameter and an output schema, the description remains incomplete for practical use. It does not explain what constitutes a 'git application,' how the domain should be formatted, or what occurs on invalid input or empty results. The output schema covers return values, but input semantics and edge cases are left open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the Args section only says 'domain: Domain,' which is a pure restatement of the schema title. No additional meaning is added—no format, example, validation rules, or allowed values—so the parameter semantics are essentially undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'List git applications on a domain.' The verb 'list' clearly differentiates it from sibling tools like git_get (which retrieves a single app) and git_deploy/git_fetch/git_webhook (which act on apps), so an agent can immediately tell this tool is for enumerating apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the action—use this when you need an overview of git applications for a domain—but the description never names alternatives or gives exclusions. For example, it does not say 'use git_get for a single application' or 'use git_deploy to trigger a deployment,' leaving the choice partially to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of explaining behavior. It clearly indicates a mutating cancel action but does not disclose side effects, irreversibility, or what happens to partial migration data. The 'confirm: Required' note is ambiguous and does not clarify what confirmation value is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the main purpose in the first sentence and arguments listed compactly. The only structural issue is the misleading 'confirm: Required' fragment, but overall the format is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema presumably describes return shape, so that gap is covered. For a cancel tool with no annotations and no schema parameter documentation, the description should clarify the confirm flag and the consequences of cancellation. It does not, and the contradiction between 'confirm: Required' and the schema's required/default leaves the agent without enough context to call the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must document both parameters. It usefully explains migration_id comes from imapsync_migrations, but confirm is only said to be 'Required' without saying what value or meaning, and the schema marks confirm optional with default false, creating confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action ('Cancel') and the target resource ('running IMAP migration'), which clearly distinguishes it from sibling tools like imapsync_migrations, imapsync_import, and imapsync_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by restricting cancellation to running migrations and points the agent to imapsync_migrations as the source for migration_id. However, it does not explicitly compare alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Run a maintenance check' and does not disclose whether the check is read-only, what it inspects, whether it can trigger repairs, or what failure modes exist. 'Check' weakly implies non-destructive behavior, but that 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded: one action sentence followed by the argument note. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The complexity is low and an output schema exists, so return-value documentation is not needed. However, with no annotations and no side-effect disclosure, the agent still lacks enough behavioral context to decide confidently between this and maintenance_fix. It is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides 'task' as a string, with 0% description coverage. The description adds meaningful provenance: the task id must come from maintenance_list. For the sole required parameter, this is sufficient guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Run a maintenance check') and identifies the resource type. It is distinguishable from the maintenance_fix sibling by the word 'check', but it does not explicitly contrast the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is that 'task' should be a Task id from maintenance_list, which implies a prerequisite but does not explain when to use this tool versus maintenance_fix or when a maintenance check is appropriate. No alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List' and 'legacy', which implies a read operation, but it does not disclose output details, error behavior, permissions, or limitations. Minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded. Every sentence serves a purpose: the core action is stated immediately, and the parameter explanation follows directly without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has one optional parameter, and an output schema, so the description covers the essentials. However, it lacks guidance about when to use this legacy endpoint instead of the newer reseller package API, leaving an important decision to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by explaining the only parameter: 'package' is an optional package name. This directly clarifies what the parameter represents and that it is not required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb and resource: list reseller packages, with the optional ability to list a single package by name. The '(legacy)' marker helps distinguish it from newer API-style siblings, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the newer packages_reseller_new_api or the related packages_user_list. The word 'legacy' implies it is older, but the description does not state whether it should be preferred, avoided, or only used for compatibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says a session is created; it does not mention side effects, session lifetime, access scope, permissions, or whether creating a session causes existing sessions to be invalidated. Some context is present via 'database-scoped SSO', but this is too thin for a session-creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded, and contains no filler. The main action appears first, followed by a single parameter explanation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter tool with an output schema, the description is minimally adequate: it names the action and explains the one parameter. But it leaves gaps around default behavior, when database-scoped SSO is needed, and any side effects. The output schema likely covers return values, so the main missing pieces are usage and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 does add meaning beyond the raw schema: 'Optional database name for database-scoped SSO' clarifies that the parameter is optional and scopes the session to a specific database. This is useful though it stops short of explaining what happens when the parameter is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a phpMyAdmin SSO session.' It is clear what the tool does and it is distinct from the related session_* and db_* siblings. However, it does not explicitly contrast itself with any sibling tool, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention any prerequisites or scenarios where database-scoped versus global SSO is appropriate. The only usage hint is that 'database' is optional, which is implied by the parameter itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only says 'Install a plugin from a URL.' It does not disclose side effects, whether an existing plugin is overwritten, whether a restart is needed, what confirmation actually gates, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, and the Args list is compact. However, the 'confirm: Required.' line is ambiguous and potentially contradictory, which slightly undermines its value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating install operation with no annotations, the description is too thin. It omits what installation does to the system, what 'confirm' means, whether the operation is idempotent, and how it relates to existing plugin versions. The output schema may cover return values, but behavioral and safety context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 does add useful meaning for url ('https URL to a .tar.gz plugin'), but the confirm parameter is only described as 'Required,' which contradicts the input schema where confirm is optional with a default of false. This is misleading and incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Install a plugin from a URL.' This clearly distinguishes it from sibling plugin tools like plugins_list, plugins_activate, and plugins_delete, especially since the sibling list contains no other install-by-URL tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: use this when installing a plugin from a URL. There is no explicit guidance about when to prefer this over related plugin operations, no prerequisites, and no alternative tool mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'enable Redis.' It does not explain side effects, whether the action is idempotent, what happens if Redis is already enabled, or what the response indicates. The mention of a required confirm parameter hints at a consequential action but gives no detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the purpose immediately. The Args line is minimal and could be considered slightly misleading, but overall there is no unnecessary wording or clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutating action with a confirm flag and no annotations, the description is too thin for an agent to safely invoke it. It omits the meaning of confirm, the effect of the operation, and any relationship to related Redis tools. The presence of an output schema does not compensate for the missing behavioral and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 compensate, but it only says 'confirm: Required.' This actually contradicts the schema, which lists no required parameters and gives confirm a default of false. The description does not explain what value to pass or what confirming means, so it adds little useful meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Enable Redis for the current/impersonated user.' It also includes scope, which distinguishes it from sibling tools like redis_disable and redis_status. This is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you want to enable Redis, but it provides no explicit guidance about when to use it versus checking status with redis_status or disabling with redis_disable. No alternatives or exclusions are mentioned, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'notify: Send welcome email' and 'confirm: Required,' but it does not disclose side effects, reversibility, permission requirements, or failure behavior for this mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and uses a clear Args block that maps directly to the schema parameters. Every line earns its place without redundant prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The parameter list is fully covered and an output schema exists, so return values are handled. But with no annotations and no usage context, the description lacks guidance on prerequisites, side effects, and the meaning of the 'confirm' flag, leaving the agent with only partial information for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It adds useful semantics for all eight parameters, including clarifying 'ip' values, 'notify' behavior, and 'confirm' as required. However, some entries are thin ('package: Reseller package name') and 'confirm: Required' conflicts with the schema's default false and non-required status, creating ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Create a reseller from a reseller package.' It clearly identifies the action and object, and the reseller focus distinguishes it from user/admin creation tools. However, it does not explicitly differentiate itself from closely related siblings like users_create or admins_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, and there are no exclusions or prerequisite conditions beyond the phrase 'from a reseller package.' The description implies the core use case but leaves the agent to infer when this is the right choice among the many creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of conveying behavior. It signals a read-only operation via "Read" and reveals pagination behavior through "cursor from a previous response," which adds useful context. However, it does not explain how pagination is initiated, whether output is truncated, or any access/permission expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one clear purpose sentence followed by a terse args block. Every line adds some information, and there is no filler or redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the lack of return-value documentation is acceptable. However, the description does not state how to obtain a cursor initially, how log levels are formatted, or how to discover valid service names, which an agent may need for correct invocation. It is minimally adequate but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 must compensate. It gives brief but understandable meanings for all four parameters, especially "cursor: Pagination cursor from a previous response" and "level: Optional log level filter." Still, it leaves details open, such as accepted log level values and any limits on the limit parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with "Read a service log," a specific verb plus resource, and the required service parameter clearly identifies which log is being read. It does not explicitly contrast with siblings like services_get or services_list, but the log-reading 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.
Usage Guidelines2/5
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 such as services_get, services_list, or other diagnostic tools. The description does not mention prerequisites, such as knowing valid service names, nor when reading logs would be preferable to checking service status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does explicitly state the destructive outcome: destroying all other sessions and force-logging out everywhere else. However, it does not mention irreversibility, required permissions, or the fate of the current session beyond the word 'other'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with the core action in the first line and no filler text. The Args block is minimal but useful in signaling a required parameter, even though it is underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive logout-all operation with no annotations, the description leaves out critical safety and invocation details: the meaning and required value of confirm, irreversibility, and clear differentiation from sessions_destroy. The output schema covers return shape, but it cannot compensate for missing behavioral and parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, confirm, has 0% schema description coverage, so the description needed to explain it. Saying 'confirm: Required' adds some meaning, but it does not say what value must be passed or what confirm actually confirms. This is especially confusing because the schema marks confirm as optional with default false, creating a direct contradiction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Destroy') and resource ('every other session'), and the parenthetical 'force logout everywhere else' makes the effect unmistakable. It is clearly distinct from the sibling sessions_destroy because 'every other' and 'everywhere else' signal the all-sessions-except-current scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sessions_destroy or other session management tools. There are no conditions, prerequisities, or explicit alternatives, so an agent 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool lists active sessions for the account, but it does not mention whether this is a read-only operation, what 'active' means, whether results can be paginated or filtered, or how this relates to session lifecycle or destruction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. It front-loads the action and resource immediately, and every word earns its place for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description is minimally sufficient: the agent knows what will happen, needs no arguments, and can rely on the output schema for return values. However, with no annotations and no mention of usage boundaries or behavioral details, the description is not fully complete for an unfamiliar agent navigating many session-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the input schema is fully documented, so there is no missing parameter meaning for the description to compensate for. The baseline for zero-parameter tools is 4, and nothing here lowers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('active sessions') with an account scope, so the agent knows what the tool does. It doesn't explicitly contrast itself with siblings like session_get, sessions_destroy, or login_history, but the wording is specific enough to avoid major ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 session_get, sessions_destroy, login_history, or session_state. The description only names the operation and provides no exclusions, alternatives, or context indicating the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only states that the update happens and that confirm is required, without disclosing that this is a potentially disruptive mutation, whether services may restart, or what happens if confirm is false. This is a significant gap for a system-level update tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and free of fluff. The Args line adds a relevant instruction, and for a one-parameter tool this level of brevity is mostly appropriate, though the missing detail keeps it from being excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-impact mutation tool with no annotations, the description is incomplete. It does not mention prerequisites, side effects, or how this tool relates to system_set_update_channel and system_packages_update_run. The output schema may cover return values, but operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 repeats the parameter name and says 'Required.' It does not explain what confirm means, what value should be passed, or why it is required. This also conflicts with the schema, where confirm has a default of false and is not listed as required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Update DirectAdmin itself to the latest build on the current channel.' The word 'itself' clearly distinguishes this from package updates and other system operations, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'DirectAdmin itself' implies a contrast with sibling tools like system_packages_update_run, but no alternative is named and no when-to-use or when-not-to-use guidance is provided. It also references the current channel without explaining the need to check or set it first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, but 'Host uptime' only names the subject. It does not state that the operation is read-only, whether authentication is needed, or what form the returned uptime takes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
'Host uptime' is extremely short, contains no filler, and is appropriately sized for a zero-parameter read. It is more of a fragment than a structured sentence, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial inputless status read with an output schema present, 'Host uptime' conveys the core purpose sufficiently. It leaves slight ambiguity about what exactly 'Host' means and does not orient the agent to sibling tools, but no invocation detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters and schema description coverage is effectively complete, so there is no parameter meaning for the description to add. The baseline for a no-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
'Host uptime' clearly identifies a specific metric and resource, and it is distinguishable from sibling system_* tools that report info, CPU, memory, load, or disk. It lacks an explicit verb such as 'Returns' or 'Gets', so it is clear but not fully specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of system_info, system_cpu, system_memory, or other status tools. There are no exclusions, alternatives, or context prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'Available timezones' only names the resource; it does not disclose that this is a read-only lookup, what determines availability, possible failure modes, or what the response will contain. This is minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short with no filler, and the key fact 'available' is front-loaded. It is efficient for a simple zero-argument tool, though it is sparse enough that it does not contribute much beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument enumeration tool with an output schema, 'Available timezones' is largely sufficient for an agent to understand and invoke the call. The missing behavioral and usage context is already penalized in other dimensions, but the simple footprint makes the definition minimally usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with 100% coverage, so the baseline for zero-parameter tools applies. The description adds no parameter information, but none is needed since the tool takes no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Available timezones' is a noun phrase rather than an explicit verb+resource, but combined with the tool name timezone_list it clearly identifies an enumeration operation over timezone values. It does not explicitly contrast with timezone_current or timezone_set, though 'available' conveys the intent of returning a list of valid values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus timezone_current or timezone_set. The description does not mention siblings or state that this tool should be used to discover valid values before setting a timezone. Usage is only weakly implied by the name and noun phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a write operation that creates a stub, but it does not disclose side effects, overwrite behavior, permission requirements, or whether the operation is reversible. The 'confirm' mention hints at confirmation but is too ambiguous to count as clear behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in a single sentence and the args are listed compactly. There is minimal wasted text, though 'domain: Domain' adds little and 'confirm: Required' is ambiguous. Overall it is well-structured and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with four parameters, no schema descriptions, and no annotations, the description is not complete enough. It omits prerequisites, confirmation semantics, parameter formats, and clear routing to sibling tools. The output schema exists but does not compensate for the missing behavioral and parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must document parameters itself. 'domain: Domain' is tautological, 'name' adds the useful 'saved as domain_name' detail, and 'impersonate: Owning user' gives some meaning. However, 'confirm: Required' conflicts with the schema, which lists confirm as optional with a default of false, and no format or constraint details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('empty Nginx Unit application stub'), and narrows the scope by noting the JSON will be edited later in the panel. This distinguishes it from sibling tools like unit_list and unit_delete, which are the read and delete counterparts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Create an empty Nginx Unit application stub' implies this is for initial creation, and '(then edit JSON in the panel)' suggests follow-up configuration happens manually. However, it never explicitly names alternatives or states when not to use this tool, leaving the decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of disclosing behavior. It implies a read-only lookup by its wording, but it does not state whether this is non-mutating, what time range is covered, how results are ordered, or whether any special permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core purpose. The Args block is necessary and directly tied to the single parameter. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-style tool with an output schema present, the description is minimally workable. However, it lacks context about how this differs from the similarly named login_history sibling and does not clarify the scope of 'history', so an agent might still be uncertain when selecting it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides the parameter name 'username', while the description adds 'Account name', which clarifies what value should be supplied. With only one parameter and no schema-level description, this is a meaningful addition, though it is still somewhat terse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Login history for a specific user' clearly identifies the resource and scope, and the required username parameter reinforces that this is per-user rather than system-wide. However, it lacks an explicit verb like 'retrieve' or 'list', and it does not directly name the sibling login_history tool to distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 login_history, audit_search, or sessions_list. The only hint is the word 'specific user', but there is no explicit when-to-use, when-not-to-use, or alternative recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'List' and does not state whether this is a read-only operation, whether it returns a live snapshot, or what side effects or expectations exist beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. The parenthetical reference to LVE Manager `action=users` adds useful grounding without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with an output schema present, the description conveys the essential scope. It loses a point because, with no annotations, it leaves behavioral expectations such as read-only safety and live-snapshot semantics to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already covers all inputs and the baseline for no parameters is 4. The description needs to add no parameter-level detail, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List') and a resource ('LVE users / current limits'), and grounds it in the LVE Manager `action=users` operation. It is clear but does not explicitly differentiate itself from nearby siblings like cl_lve_get or cl_lve_set, so it falls just 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to prefer this tool over alternatives, no exclusions, and no mention of related siblings such as cl_lve_get or cl_lve_set. Any usage context is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It does reveal that the operation is a replacement requiring a full config object and that confirm is required, which warns of destructive intent. However, it does not explain consequences of omitted values, reversibility, required permissions, or what confirmation actually does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loads the core operation in the first sentence. The Args block is scannable, and there is no filler or repetition; the only shortcoming is that some important information is omitted entirely rather than written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive config-replacing tool with no annotations and a 0% schema description coverage on a nested values object, the description is too thin to fully guide an agent. It gives no usage context, no confirmation semantics, and no guidance on how to construct the full local config object, leaving high-risk calling decisions to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions for its two parameters, and the description partially compensates by explaining that values must be a 'Full local config object' and that confirm is 'Required.' It adds meaning beyond the raw schema, though it does not define the structure of the nested values or the confirm type/effect, and the 'required' claim conflicts with the schema marking only values as required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Replace') and names the exact resource ('local directadmin.conf overrides'), and labels the HTTP method (PUT), which differentiates it from read-only config tools and the likely partial-update sibling da_config_local_patch. This is unambiguous even without a title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool instead of da_config_local_patch or other config endpoints. The word 'Replace' implies full overwrite, but the description never states the condition that should route an agent to this tool versus a partial patch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It adds no information beyond the action conveyed by the tool name itself, such as that listing is read-only, whether hidden/system forwarders are included, pagination behavior, or any authentication/impersonation implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loaded with the core verb and resource. The Args block is somewhat redundant with the schema, but the overall length is acceptable and no significant clutter is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list operation, the description provides the essential 'what' and 'scope', and an output schema exists for return values. However, it leaves the impersonation parameter's behavioral impact unclear and does not tie the tool into the surrounding email tool family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 merely repeats the parameter titles, with 'domain: Domain' adding no meaning and 'impersonate: Owning user' adding only a slight clarification. It does not explain acceptable formats, default behavior when impersonate is omitted, or how impersonation affects the list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('forwarders') scoped to 'a domain'. This clearly distinguishes it from sibling tools like email_forwarder_create and email_forwarder_delete, which perform different operations on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever a user needs to see the forwarders configured on a given domain. However, it does not explicitly mention when not to use it or name alternatives such as email_forwarder_create/delete for management actions, leaving the routing mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears the full burden of behavioral disclosure, yet it only names the resource. It does not state that the operation is read-only, describe the log content or format, or mention pagination, filtering, session, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loads the key scoping information with no filler. It is arguably under-specified for full understanding, but as a concise definition it uses every word effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, output-schema-backed read tool, the description is minimally viable: it identifies the resource and the scope. However, it leaves the meaning of 'impersonated' and the relationship to email_logs/email_logs_summary implicit, so an agent has only partial context for confident selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is vacuously 100%, so there is no parameter burden for the description to carry. The 'current/impersonated user' wording usefully clarifies the implicit scope that substitutes for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase identifies the resource (email logs) and a specific scope (current/impersonated user), which distinguishes it from sibling tools like email_logs and email_logs_summary. It lacks an explicit verb such as 'retrieve' or 'list', so it stops short of a fully explicit statement of action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope 'current/impersonated user' implies this tool is for session-scoped email logs, but the description does not explicitly say when to prefer it over email_logs or email_logs_summary. It provides no exclusions, alternatives, or context about when this variant should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a resource but does not explicitly say the tool reads/returns data, whether it has side effects, or what kind of output to expect beyond the presence of an output schema. The noun-phrase form leaves the actual behavior implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no filler or repetition. The key scoping detail, 'current user's', is front-loaded. It is concise, though slightly under-specified because it lacks an action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is minimally viable: it names the resource and scope. However, it does not clarify how this relates to the many ModSecurity sibling tools, nor does it state the type of data returned. Given the number of related tools, more context would help an agent select it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to clarify. Per the baseline for zero-parameter tools, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('current user's ModSecurity configs') and scope, so an agent can tell it returns user-level configuration data. It lacks an explicit verb like 'get' or 'list', and it does not explicitly distinguish itself from sibling tools such as modsecurity_all_configs or modsecurity_host_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current user's' implies this tool is appropriate when retrieving the caller's own ModSecurity configuration. However, it gives no explicit guidance about when to choose this over related tools like modsecurity_all_configs or modsecurity_host_config, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden for behavioral disclosure. It mentions only the endpoint and a high-level intent, without stating that it is read-only, what kind of data it returns, whether authentication is needed, or whether there are any side effects. 'Info' weakly implies a safe read, but that 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It provides the key scope ('high-level panel info') and the endpoint, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter informational tool with an output schema, the description is largely sufficient. It could be more explicit about how it relates to the many system_* siblings, but an agent can likely invoke it correctly based on the endpoint and 'high-level panel info' alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is already complete and parameter documentation is not needed. The description's endpoint reference adds minor context, but the baseline for a no-parameter tool is appropriately high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('panel info') and gives the endpoint, clearly indicating this is a general system information read. It is somewhat vague with 'high-level' and does not explicitly state how it differs from siblings like system_version or system_cpu, but it is enough to understand the basic function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling system_* tools. 'High-level panel info' only implies it might be an overview rather than a specific metric, but no alternatives, exclusions, or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. 'Check whether' implies a read-only existence check, and '(admin)' discloses a privilege requirement. However, it does not explicitly state that the operation has no side effects or what happens when the account does not exist; the output schema may cover 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the core purpose, and contains no redundancy. Every word contributes meaning, and the parameter note is clearly separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter existence check with an output schema, the core information is present. However, it lacks sibling differentiation and explicit usage context, which is notable given the large list of related user-management tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameter. It describes username as 'Candidate username', which adds the notion that this is the proposed name to test. This is minimal but sufficient for a single string parameter, though it lacks format or case-sensitivity details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Check whether an account name already exists'. The '(admin)' suffix adds an audience hint. It does not explicitly differentiate from sibling tools like users_search or users_list_all, but the existence-check semantic is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives such as users_search or users_list_all. The '(admin)' marker implies an admin-only context, but there are no conditions, exclusions, or reasons for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Get' and the mention of the suspended flag imply a read-only status inspection with no side effects, which is the main behavioral trait of this tool. However, with no annotations, the description does not disclose authentication expectations, whether the username must be a regular user vs reseller, or how absent/missing configs are represented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, then the argument. Every line carries necessary information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation with an output schema, the essential invocation details are mostly present. But with no annotations and no usage guidance, the description leaves gaps about authorization and how this config call relates to sibling config/usage tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a one-line meaning for the sole parameter ('username: Account name'), which is helpful because the schema has zero description coverage. But it offers no format, ownership, or scope detail, so it only barely clears the minimum bar.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation and resource: getting user.conf-style configuration, and enumerates the config areas (limits, domains, suspended flag). This clearly distinguishes it from usage or search tools, though it doesn't explicitly name a sibling for contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to prefer this tool over related tools such as resellers_get_config or users_get_usage, and no exclusions or context about the required calling context (e.g., admin vs reseller). The agent must infer applicability 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. The word 'list' implies a read-only enumeration, but the description does not explicitly state that it has no side effects, what scope it covers, or whether special authentication is required. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no filler words, and places the resource type up front. It is slightly terse and uses a noun phrase rather than a clear imperative, but for a no-parameter list tool this is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description does not necessarily need to explain return values. However, it lacks usage context and explicit behavioral detail such as scope or read-only guarantees, making it only minimally complete for an agent deciding whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so no parameter documentation is needed. The description adds no param-level detail, but that is acceptable because there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (directory password-protection) and implies a list/read operation, which is clearly tied to the tool name. It distinguishes the tool from most siblings because no other sibling covers this resource, though it does not explicitly state an imperative verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or when to prefer an alternative. There is no mention of scope, prerequisites, or relationship to other tools, so the agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states a read-style operation but does not mention what information is returned, any scope considerations, or performance implications. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with every word earning its place. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with an output schema, the short description is largely sufficient to allow a correct call. A brief mention of scope (e.g., all installations on the server) would improve completeness, but the lack of parameters and presence of output schema reduce the need for extensive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 add parameter detail. The baseline of 4 applies because there is nothing to explain beyond the schema already showing an empty properties object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List WordPress installations.' It clearly identifies the operation. It does not explicitly contrast with sibling tools like wp_get, but 'list' versus 'get' implies a meaningful distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool instead of alternatives such as wp_get. The context signals and sibling list suggest wp_locations is for enumerating installations, but the description does not state this or exclude other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only names the data. It does not explicitly state that this is a read-only retrieval or what happens for an invalid/nonexistent username.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact lines with no filler, and the core purpose is stated first. The Args block is minimal and directly supplements the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with an output schema, the description covers the essential resource, scope, and parameter meaning. It lacks explicit routing to sibling tools, but nothing required to invoke the call correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for username, and the description adds 'DirectAdmin account,' which clarifies the identifier's domain. It still omits format, case sensitivity, or whether the account must already exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a concrete resource, LVE limits, and scopes it to a single user, which distinguishes it from plural/list operations like cl_lve_users. It lacks an explicit verb such as 'retrieves' or 'returns', but the resource and scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'For one user' provides implicit guidance that this is a per-account lookup rather than a list-all operation. However, it never names cl_lve_users or cl_lve_set as alternatives, so when to choose this tool over those siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It only says the operation adds an IP to csf.ignore; it does not explain persistence, whether a restart is needed, required permissions, or failure behavior. More importantly, it states 'confirm: Required' while the schema marks confirm as optional with a default of false, creating ambiguity about whether the call will succeed without explicit confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a clear purpose statement followed by a concise parameter list. Every sentence earns its place, and there is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating firewall tool with no annotations and incomplete schema descriptions, this description is not sufficient. The confirm parameter ambiguity is critical, and there is no guidance about privileges, idempotency, or when to use this versus related csf tools. The agent could easily invoke it incorrectly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does add some value: it clarifies that ip accepts IPv4, IPv6, or CIDR, and that comment is a note. However, it does not explain the semantic purpose of confirm beyond 'Required,' and that claim conflicts with the schema's default false, leaving the agent uncertain about required input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Add an IP to csf.ignore so LFD never blocks it.' This clearly identifies the tool's function and distinguishes it from siblings like csf_allow_ip, csf_deny_ip, and csf_unblock_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this when an IP should never be blocked by LFD. However, the description does not explicitly explain when to choose this over csf_allow_ip or other firewall tools, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry safety information. The verb 'Show' does imply a read-only listing, and '(admin)' signals privileged scope, which is useful. However, it does not specify whether these are database processes, what data is returned, or any side-effect-free guarantee beyond the word 'Show'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four words with no filler and the key verb is front-loaded. It states the action, resource, and scope in a tightly packed way appropriate for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there are no parameters and an output schema exists, the description does not need to document return values. However, it never explicitly says these are database processes rather than general server processes, and it offers no sibling or alternative context, leaving some room for an agent to misidentify the tool's exact domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters and an empty input schema, so the description has nothing extra to explain. The 0-parameter baseline applies and no semantic information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Show' and identifies the resource as the process list, with an admin scope. It also reads as a non-mutating operation, distinguishing it from db_kill_process, though the database context depends on the tool name rather than the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of nearby db_* tools or how it relates to process termination. The parenthetical 'admin' hints at permission needs, but no conditions, alternatives, or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Remove' and 'confirm: Required,' hinting at a destructive action that needs confirmation, but it does not state irreversibility, side effects on the domain, or permission requirements. The phrase 'confirm: Required' is also ambiguous because the schema marks confirm as optional with a default of false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the core purpose, followed by a compact argument list. There is no fluff or redundant content; every line adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema likely covers return values, but this is a destructive operation with no annotations and sparse behavioral context. The description omits impact details, irreversibility, and unambiguous confirmation semantics, making it only minimally adequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 and does provide brief labels for all four parameters: domain, pointer, impersonate, and confirm. However, these are minimal glosses and do not explain acceptable values, the need for confirm to be true, or the relationship between domain and pointer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('a domain pointer'), making it easy to distinguish from sibling tools like domain_pointers_list and domain_pointers_create. It is specific and unambiguous within the delete family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: call this tool when a domain pointer needs to be deleted. However, the description does not explicitly state when to use it versus alternatives, nor does it mention any preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does state that the tool mutates state ('Set'), identifies impersonation as owning user, and marks confirm as required. However, it does not explain side effects, permission requirements, reversibility, or what happens to the existing PHP configuration, which a fully transparent mutation description would include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well structured: one clear purpose sentence followed by a concise argument list. Every line contributes information, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with an output schema, the parameter explanations are adequate. However, the absence of usage guidance, alternative differentiation, and side-effect disclosure leaves meaningful gaps that annotations would normally cover. It is a minimum-viable description rather than a fully complete one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description accounts for all four parameters and adds real meaning beyond their titles. It explains that php1_select is a panel selector index mapping to PHP versions and that impersonate is the owning user. The only weakness is the ambiguous 'confirm: Required' note, which conflicts slightly with the schema's non-required status and default false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific action and target: 'Set the PHP version selector for a domain.' This is clear enough to identify what the tool does and distinguishes it from generic domain operations. It does not explicitly differentiate itself from cl_php_selector_set, so it falls just 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as cl_php_selector_set, domains_create, or other domain configuration tools. There are no stated prerequisites, exclusions, or explicit when-to-use instructions, leaving the agent to infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Create/update' and repeats 'confirm: Required'; it does not explain what confirm does, whether an existing message is overwritten, what permissions are needed, or what the response looks like. This is a mutation tool whose side effects are largely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the main purpose, and uses a simple argument list. However, the terse one-line parameter notes, especially 'confirm: Required,' are not fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested object parameters and no annotations, the description leaves important input semantics undefined: the shape of 'values', the meaning of 'confirm', and the behavior when a vacation message already exists. Even though an output schema exists, the missing input behavior makes this definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 bare input schema. It adds minor value ('Local part', 'Vacation body'), but 'values' is an arbitrary object and the description does not specify its required fields, and 'confirm: Required' misleadingly implies confirm is mandatory when the schema marks it optional with a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'Create/update a vacation message' names a specific action and resource, clearly distinguishing it from sibling email_vacation_list/get/delete operations. An agent can infer when to call this tool 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Create/update' phrasing makes the intended use clear: it is the tool to set or modify a vacation message, as opposed to listing, retrieving, or deleting one. It does not explicitly name alternatives or exclusions, but the context is sufficient for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the transparency burden. It does add a useful behavioral constraint: path must be an absolute path inside the account home. 'List' also implies a read-only operation, but the description does not clarify hidden files, sorting, error behavior, or whether the listing is recursive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded: 'List a directory.' followed by a single parameter explanation. There is no filler or redundant content; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, which reduces the need to describe return values. However, the description gives no help distinguishing fm_list from the many related fm_* siblings, and it lacks usage context such as whether this lists only immediate children. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives only the parameter name, type, and default, with 0% description coverage. The description compensates by explaining that path is an absolute path inside the account home, which clarifies that the default '/' means the account home root. Slightly more detail about boundary restrictions would push this to 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action and resource: 'List a directory.' This is specific and understandable. However, it does not explicitly differentiate fm_list from related siblings like fm_tree, fm_search_files, or fm_disk_usage, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use fm_list versus related file-management tools. The description does not mention alternatives, exclusions, or conditions such as 'use fm_tree for recursive listings.' This is essentially no usage guidance beyond the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose side effects and behavioral traits. It only says 'Create' and lists arguments; it does not mention that this changes server state, whether it is reversible, what protection/confirmation flow exists, or what errors/preconditions apply. The 'confirm: Required' note is ambiguous and conflicts with the schema's default false and non-required status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: one clear purpose sentence followed by a compact Args list. Every line contributes information, and there is no filler or repetition of schema titles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the output schema covers return values and parameters are individually explained, the tool has no annotations and is a mutating server operation. The description omits prerequisites, side effects, permission needs, and the practical meaning of the confirm requirement, leaving the agent with an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 parameter-documentation burden. It adds real meaning: it identifies the local part of the FTP username, lists path_type allowed values, clarifies custom_path is conditionally required, and explains impersonate and confirm. However, 'confirm: Required' appears to contradict the schema's required list and default, which prevents a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Create an FTP account.' This unambiguously identifies the action and resource, and distinguishes it from sibling tools like ftp_delete and ftp_list without needing to inspect them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any preconditions such as domain existence, permissions, or whether the user must already exist. The only usage cue is the verb 'Create,' which is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects and operational risk. It only says 'Change the server hostname' and hints at SSL reissue, but it does not explain reversibility, permissions, service impact, or whether the change is destructive. This is insufficient for a server-level mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and free of filler. The Args block is compact and the follow-up instruction is useful, though the confirm wording is ambiguous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values do not need explanation. However, a hostname change is a significant server-wide operation, and the description lacks side-effect warnings, permission requirements, and a clear contract for the confirm parameter. This is not enough for an agent to safely and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must define parameters. It does clarify that hostname is a 'New FQDN', which is helpful. However, the confirm description says 'Required', contradicting the schema's required list of only hostname and its default of false; it also omits the expected value/type for confirm.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Change the server hostname.', which is a clear, specific verb-plus-resource statement. It unambiguously identifies the operation and is not easily confused with any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides actionable guidance: it marks confirm as required and explicitly instructs the agent to reissue the hostname SSL afterwards with ssl_reissue_server. It does not list exclusions or alternative conditions, but for this unique system operation 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does add useful context by framing the tool as a catalog and explicitly stating 'no secrets', which signals data safety. However, it does not mention side effects, permissions, pagination, or return behavior beyond what the output schema may cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and contains no filler. The catalog scope is front-loaded, and the focused content about CloudLinux profiles earns its place. This is an appropriately sized description for a zero-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The zero-argument schema and presence of an output schema reduce the burden, and the description gives a useful snapshot of what the catalog contains. However, it leaves sibling differentiation ambiguous and introduces the phrase 'hops host' without explanation, which could cause an agent to select the wrong tool in the large sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 applies because parameter documentation is not needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description conveys a specific list operation over a fleet catalog on the hops host, with a clear focus on CloudLinux assignments and profiles. It does not explicitly differentiate from inventory_get or inventory_this, but the name and content make the core purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus siblings like inventory_get, inventory_this, or propack_inventory. The description implies a read-only inventory listing, but it does not state exclusions or selection conditions, leaving an agent to guess among several related inventory tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Details for one IP' reasonably implies a read-only retrieval operation with no side effects, but it does not mention error behavior, authorization requirements, or edge cases like invalid or nonexistent IPs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the purpose, and contains no filler. The Args line is minimal but earns its place for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with an output schema and no nested objects, this description is nearly sufficient. It covers the core calling scenario, though it lacks explicit routing guidance relative to list-style sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 sparse schema. It only adds 'Address' for the ip parameter, which is barely more informative than the schema's existing property name and type. It does not specify expected format, examples, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource ('one IP') and the intent ('Details'), distinguishing it from sibling tools like ips_list by emphasizing a single IP. It is concise and understandable, though it lacks an explicit verb like 'retrieve' or 'get details for'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one IP' implies this tool is for looking up details about a specific IP address, whereas siblings like ips_list and ips_admin_list likely handle listing. However, it does not explicitly state when to use this tool over alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not describe side effects, whether the secret is shown only once, permission requirements, or reversibility. The security preference and 'confirm: Required' hint at caution, but they do not explain the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the purpose comes first, followed by the security preference and argument notes. Every sentence adds information, and there is no filler or redundant restating of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested free-form payload, no annotations, and no parameter descriptions in the schema, so the description needs to be more self-sufficient. It relies on an external API documentation reference, omits confirm semantics, and does not clarify required payload fields or the implications of creating a login key. This leaves important context unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 lists example payload fields (name, expires, ips, commands) and says confirm is required, which adds some meaning beyond the bare schema. However, it does not explain what confirm actually confirms, and the schema marks only payload as required, creating a mild conflict.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a login key.' This clearly distinguishes it from siblings like login_keys_list, login_keys_get, login_keys_update, and login_keys_delete. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Prefer IP-restricted, command-restricted keys' provides useful security guidance for how to create keys, but it does not explicitly say when to use this tool versus alternatives like login_keys_update. Usage is implied by the tool name and the 'Create' verb, but no exclusions or alternative routing are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. The noun phrase 'All ModSecurity per-host configs' implies a read/list operation with no obvious mutation, but it never explicitly states read-only behavior or any edge cases. This is adequate for a getter 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four words, no filler, and the key resource and scope are front-loaded. For a zero-parameter tool this is appropriately minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, a one-line description is nearly enough. It falls short by not distinguishing 'all per-host configs' from the singular modsecurity_host_config or from modsecurity_user_configs, and it does not clarify whether 'configs' means files, settings, or entries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so there is no parameter burden and the baseline is 4. The description's use of 'all' and 'per-host' reinforces why no filtering parameter is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('ModSecurity per-host configs') and the scope ('all'), making it clear this is an enumeration/retrieval operation. It lacks an explicit verb such as 'list' or 'get', so it is clear but not maximally explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like modsecurity_host_config, modsecurity_user_configs, or modsecurity_global. The intended use is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses only that the result is 'combined' reseller-plus-owned-users usage, but does not mention read-only nature, permission requirements, aggregation details, or how the result is structured. The tool name implies a get operation, but the description itself is too thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loads the core meaning, and contains no filler. The one-line summary plus the single argument explanation is the minimum efficient expression of the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and an output schema present, the basic invocation is documented well enough. However, the lack of usage guidance, behavioral transparency, and any caveats about reseller-specific requirements leaves the description only minimally complete for an agent operating among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'username' as a generic string, while the description clarifies that it must be a reseller name. This is an essential and non-obvious semantic addition that helps the agent pass the correct value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Combined reseller + owned-users usage' defines a specific resource and scope, distinguishing it from related usage tools like users_get_usage and admin_usage. It relies on the tool name for the verb, but the intended operation is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving usage across a reseller and its owned users, which gives some usage context. However, it does not explicitly state when to prefer this over users_get_usage or admin_usage, nor does it mention any alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does state that the tool force-obtains/reissues a certificate via POST, but it omits important effects such as replacing the existing cert, service impact, irreversibility, or confirmation requirements beyond a vague 'confirm: Required'. This is insufficient for a mutating server-level operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, action-first, and includes the endpoint and a clear use-case in compact form. However, the Args section is under-specified and the 'confirm: Required' claim conflicts with the schema, which slightly weakens the structural quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating server certificate operation with three parameters and no annotations, the description is incomplete. It does not explain two of the three parameters, does not warn about consequences of reissuing the hostname cert, and does not clearly contrast with the many sibling cert tools. The presence of an output schema helps but does not cover these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 parameters, but it only mentions 'confirm: Required' and ignores reason and idempotency_key. It also contradicts the schema: the schema shows confirm as optional with a default of false, while the description calls it required. This makes the parameter guidance confusing rather than helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Force-obtain / reissue') and the resource ('DirectAdmin hostname TLS certificate'), and confirms it with the specific endpoint 'POST /api/server-tls/obtain'. This distinguishes it from sibling tools like ssl_reissue_domain, which target domain certs rather than the hostname cert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions for use: 'Use this when the panel hostname cert is expired or the hostname changed.' It does not explicitly state when not to use it or name alternatives, so it stops short of a full decision guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does disclose key behavioral details: the operation replaces the certificate, 'confirm' is required, and 'force' permits an invalid certificate. However, with no annotations provided, the description carries the full burden and still omits side effects such as service impact, reversibility, or key-mismatch behavior for a sensitive mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a single purpose sentence followed by a focused parameter list. There is no filler, and each line carries meaningful information for invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and parameter meanings, and an output schema exists so return values need not be explained. However, it lacks usage context, side-effect disclosure, and a clear definition of what 'confirm' should be set to, leaving an agent with ambiguity for a risky certificate-replacement operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining each parameter: certificate is a PEM cert with optional chain, key is a PEM private key, force allows an invalid cert, and confirm is required. It could be stronger by specifying the expected value/type for 'confirm', especially since the schema gives it a default of false but the description marks it as required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific action ('Replace'), a resource ('hostname certificate'), and an input format ('uploaded PEM files'), making the core purpose immediately clear. It does not explicitly distinguish this from sibling tools like ssl_upload_cert_files or ssl_server_certificate, but the 'hostname certificate' wording adds enough specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many SSL-related siblings, nor does it state prerequisites or exclusions. An agent must infer from the name and brief phrase that this is for hostname certificate replacement, and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the metric but does not disclose whether this is a current snapshot, whether it represents a read-only operation, what the output structure looks like, or any caveats. For a simple read tool this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no waste. It is front-loaded with the metric being reported and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a zero-parameter read tool, the description is adequate, but with no annotations and no details about the return format beyond the existence of an output schema, the agent is left to infer some behavior. The presence of an output schema reduces the burden, but the description is still minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100% by definition. The description adds meaning about what the returned data represents. With no parameters to document, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '1/5/10 minute load averages' clearly identifies the resource (system load) and the specific metric (1/5/10 minute load averages). It distinguishes this from other system_* tools like system_cpu, system_memory, system_disk. It doesn't explicitly differentiate from siblings, but the resource and metric are specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to check system load averages, and the meaning is clear. However, it does not explicitly state when to use it versus alternatives like system_cpu or system_resource_usage_latest, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does reveal this is a mutating operation and that confirm is required, which is important. However, it does not mention potential system impact, reversibility, restart effects, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded, and free of filler. The Args block efficiently documents both parameters in a readable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the core call semantics are present. However, it does not link to the similarly named update_test/updates siblings, describe consequences or rollback, or resolve the discrepancy between 'confirm: Required' and the schema's default false.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains that packages is optional and that an empty list means all pending upgrades. It also clarifies that confirm is required despite the schema default of false, though it does not explain what 'confirm' actually does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Apply OS package upgrades') with a clear resource. It does not explicitly distinguish itself from siblings like system_packages_update_test or system_packages_updates, but the verb 'Apply' makes the execution role reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the similar sibling tools, nor any exclusions or alternatives. The only usage hint is parameter-level ('Empty = all pending'), not tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. The passive phrasing implies a read-only query and names the two data points returned, so it is not misleading. However, it never explicitly states that no state is modified, how the version is resolved, or whether any authentication is implied — minimal but adequate for a zero-parameter getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single fragment with no filler — every word contributes information and the two data points are front-loaded. It is slightly terse without a verb, but appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completeness is proportionate to the tool's shape: zero parameters, no annotations, and an output schema that presumably documents the returned fields. The description conveys what the tool returns; the main missing element is sibling differentiation, which is already penalized under usage_guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is trivially 100% via an empty schema, so the baseline 4 applies. There is nothing for the description to add, and it correctly says nothing about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource clearly — DirectAdmin version and update channel — so an agent can tell what data the tool exposes. However, it lacks an explicit verb (e.g., 'Get' or 'Returns'), and it doesn't explicitly differentiate itself from closely related siblings like system_info or system_set_update_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The sibling list contains system_set_update_channel, system_update_directadmin, and system_info, but the description never hints that this is the read-only counterpart to system_set_update_channel or that system_info offers broader server data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. It dos not explain that this is a state-chang ing administrative operation, whether it is reversible, what permissions are needed, or what the confirmation flag protects against. 'confirm: Required' hints at a guided action but dos not disclose consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and free of unnecessary prose. The Args block is compact, but 'confirm: Required' is questionable in accuracy and prevents full marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema may cover return values, but the description still omits prerequisites, the account-level effects, and the real semantics of the confirm flag. For a state-changing reseller operation with a safeguard parameter, this is not complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The username gloss ('User to promote') is useful and maps to the schema. However, 'confirm: Required' is ambiguous and conflicts with the schema, where confirm is not in required and defaults to false. With 0% schema description coverage, the description should compensate but leaves the confirmation field underspecified and misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the exact operation ('Promote a user account to reseller') with a specific verb and resource. The direction from user to reseller distinguishes it from the sibling tool resellers_convert_to_user without requiring additional explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: use this when an existing user account should become a reseller. It does not name exclusions or point to alternatives like resellers_create, but the intended condition is still explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does state 'permanently delete', which conveys the critical destructive and irreversible nature, and it flags confirm as required. However, it does not explain cascading effects on the account's data, domains, email, or reseller sub-accounts, nor what permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus a compact args list, with the core purpose front-loaded. There is no filler or repetition of schema metadata, and the structure makes the destructive action immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter destructive tool, the description covers the essential action and argument names, and an output schema exists so return values need not be documented. Still, an agent is left to guess the exact confirmation payload and the scope of deletion, which is risky for an irreversible operation without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 'username: Account to delete' and identifies confirm as required, but it does not specify that confirm must be set to true or describe its type. This is further muddled by the schema, where confirm is optional with default false, directly conflicting with the description's 'Required'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Permanently delete a user/reseller/admin account', stating the exact verb, resource, and irreversibility. This clearly separates it from nearby siblings like users_suspend or users_modify, which imply temporary or partial changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives such as users_suspend, users_unsuspend, or users_modify. The description never mentions exclusions, prerequisites, or that this should be reserved for accounts that must be removed permanently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It does note that confirm is required and that where must be a recognized destination, but it does not explain side effects, permissions, reversibility, duration, or what happens on failure. This is minimal disclosure for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the one-line purpose is followed by a clean argument list. Every sentence earns its place, and there is no repetition of schema information beyond what is needed for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with an output schema, the description covers the basics needed to invoke it: what it does, which user, where, and the confirmation requirement. However, it omits when to use it relative to backup-related siblings and any operational context such as prerequisites or expected behavior after submission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the parameter explanations are essential. The description adds meaningful semantics for all three parameters: username is the account to back up, where is a panel-recognized destination with examples, and confirm is flagged as required. This meaningfully exceeds the bare schema, though the 'Required' wording is slightly ambiguous against the schema's default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action verb ('Create') and the exact resource scope ('a backup for one user'), which clearly distinguishes it from sibling tools like backups_restore or backups_admin_now. This is immediately actionable and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives, nor does it mention any exclusions or prerequisites. It does not reference backups_restore, backups_admin_now, or backups_admin_list, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry behavioral disclosure. It does disclose that the result is 'best-effort' and may be 'HTML or structured', which are meaningful caveats. However, it does not state whether it is read-only, what happens if the CSF plugin is not installed, or any potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key resource 'CSF' and immediately states the purpose. There is no filler, and the 'best-effort' and output-format details are packed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with an output schema, the description is nearly complete. It notes that output may be HTML or structured and warns that the result is best-effort. It lacks clear sibling differentiation, but that is more a usage-guideline deficiency than a completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to document or clarify. With no parameters, parameter semantics are effectively trivial and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing a CSF plugin landing/status page, which implies retrieving status information for the CSF resource. It names the specific resource, but does not explicitly differentiate it from other status-type siblings such as policy_status or clamav_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative CSF tools like csf_search_ip, csf_restart, csf_enable, or other *_status endpoints. The description relies entirely on the tool name to imply purpose, which is insufficient 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It adds useful context that the config is current and merged, but it does not indicate whether the operation is read-only, whether permissions are needed, or what happens if the config is unavailable. A single noun phrase is not enough for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words and every word carries meaning. It is front-loaded and free of filler, appropriate for a zero-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters and an output schema exists, the description is sufficient for correct invocation of a simple config-read endpoint. It leaves some broader context about how it relates to default and local config variants unspecified, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty with 100% coverage, so the baseline of 4 applies. There are no parameter semantics for the description to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Identifies the specific resource (directadmin.conf) and the merged/current variant, which distinguishes it from da_config_default and da_config_local siblings. The description lacks an explicit verb like 'get' or 'read,' but the tool name and phrase 'Currently applied' make the intent clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to choose this tool versus da_config_default or da_config_local. However, 'Currently applied' and '(merged)' imply this shows the effective configuration, so usage is conveyed indirectly rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only action through the verb 'List' and hints at permission scope with '(admin)', but it does not explicitly confirm the operation is non-mutating, describe any side effects, or note response shape beyond what the output schema already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence communicates the essence without wasted words. The description is appropriately minimal for a zero-parameter list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple admin list operation with no parameters and an existing output schema, the description is nearly complete. It could add a note about whether this lists all zones or only some subset, but the admin qualifier and output schema cover most of the practical need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 there is nothing for the description to add. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('DNS zones') with an admin scope qualifier. It is clear and distinguishes itself from dns_zone_get by being a plural list operation, though it does not explicitly name any sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or what distinguishes it from user-level DNS listing. The '(admin)' qualifier implies elevated privileges but does not explain when this should be chosen over other DNS-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. The verb 'List' implies a read-only operation, and the description names the relevant domain and impersonation context. However, it does not disclose any additional behavior such as whether results are paginated, whether all aliases are returned at once, or whether any permissions are needed beyond what the impersonate parameter suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the primary purpose in the first sentence and relevant parameter details in a clean Args block. There is no filler or redundant restating of the tool name, and every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and an output schema, the description covers the essential invocation details. It lacks usage guidance and deeper behavioral notes, but the low complexity and presence of an output schema make the definition reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning, and it does. It explains that 'domain' is the parent domain and 'impersonate' is the owning user. This goes beyond the bare schema titles of 'Domain' and 'Impersonate' and gives an agent enough context to populate the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List domain pointers (aliases) for a domain.' This clearly identifies the operation and object. It does not explicitly contrast with sibling tools like domain_pointers_create or domain_pointers_delete, but the action verb and tool name make the core purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool rather than related domain pointer tools or other listing tools. It does not state whether it should be used to check existing aliases before creating or deleting one, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It does add useful context by specifying admin scope and global visibility, and 'logs' implies a read-only operation. However, it does not explicitly state that it has no side effects, mention any limitations, or clarify what exactly the returned logs cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loads the key scope word 'Global', with no filler or repetition. It is appropriately sized for such a simple zero-parameter tool, though it is terse enough that some useful context, such as relationship to sibling tools, is omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, this is nearly sufficient for invocation: the agent knows it targets global email logs and requires admin access. However, it does not clarify how this tool relates to email_logs_user or email_logs_summary, and it leaves the read-only nature implicit rather than explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and there are no parameters to document, so the description does not need to add parameter-level detail. The zero-parameter baseline applies here, and the schema coverage is effectively complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('email logs') and the scope ('Global', 'admin'), which helps distinguish it from sibling tools like email_logs_user and email_logs_summary. However, it is a noun phrase without an explicit verb such as 'list' or 'get', so the action is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Global email logs (admin)' implies this tool is for admin-level, all-user log retrieval, but it does not explicitly state when to use it over email_logs_user or email_logs_summary. No exclusions or alternative routing are provided, so usage guidance is mostly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'List trash.' It does not clarify what 'trash' refers to, whether the operation is read-only, what scope is covered, or any side effects. The verb 'list' implies reading, but that is inference, not disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words with zero waste, and the key action and resource are front-loaded. For a zero-parameter tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is simple and the output schema covers return structure, so the description need not detail results. However, 'trash' is ambiguous without context, and there is no indication of what this trash consists of or when to use this tool. It is minimally viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 the baseline is 4. The description adds nothing about parameters because there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('trash'), and the resource is unique among siblings, distinguishing it from other file-management tools like fm_list and fm_tree. Even though it is terse, it clearly identifies the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no exclusions, and no mention of prerequisites or context. The description is not misleading, but it provides no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only listing action, which implies no mutation, but it does not disclose permission requirements, impersonation semantics, or any side effects. With no annotations present, the description carries the full burden and provides only minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The Args section is somewhat redundant with the schema but still compact and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are presumably covered. However, the description leaves ambiguity about the expected domain format and the meaning of impersonate in practice, especially for an admin versus reseller context. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 schema's lack of parameter details. The Args section merely repeats the parameter names with terse definitions ('Domain.', 'Owning user.'), adding little beyond the existing titles. It does not explain formats, constraints, or the optionality/behavior of impersonate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'List FTP accounts for a domain.' This is a specific verb plus resource, and it naturally distinguishes from sibling mutations like ftp_create and ftp_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb 'List' and the domain scope, but there is no explicit guidance about when to choose this over other tools or any exclusions. For a simple list operation, this implied guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It implies a read-only history lookup and scopes the data to the current account, but it does not disclose any caveats, such as what events are included, whether it reflects the current session only, or any authentication context. For a zero-parameter read tool this is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no redundancy or filler. Every word contributes meaning, which is appropriate for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no input parameters and an output schema exists, the description is nearly complete for basic invocation. It could still clarify the distinction between 'current account' and user-scoped login history, but the core context needed to call the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description does not need to explain parameter meaning because there is nothing for the agent to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: login history for the current account. It is not a tautology because it adds 'current account' scope, but it lacks an explicit verb like 'retrieve' or 'list' and does not differentiate itself from sibling tools such as users_login_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like users_login_history and login_keys_history, the agent is left to infer which one is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of behavioral disclosure. It only states that the tool lists URLs; it does not mention whether the operation is read-only, whether one-time URLs are consumed or invalidated by listing, or any other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single five-word sentence with no filler. It front-loads the verb and object, and the brevity is appropriate for a zero-parameter list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description does not need to document arguments or return values. The main gap is the absent usage routing, but for a simple list operation this definition is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 there is nothing for the description to add about arguments. Per the rubric, zero-parameter tools receive a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 specific resource ('one-time / login-as URLs'), making the operation clear. It does not explicitly contrast with sibling tools such as login_urls_create or login_urls_delete, but the verb strongly implies a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are named. The verb 'List' makes the general scenario inferable, but the description leaves it to the agent to determine when this tool is preferred over related login_urls tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Details for one service' implies a read-only single-item lookup and gives no hint of destructive behavior. It does not disclose permission needs or error behavior, but the output schema covers return shape, so this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loaded: it states the purpose in the first line, then provides focused parameter examples. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with an output schema, the description and parameter examples are largely sufficient. The main gap is the lack of usage guidance distinguishing this tool from list, overview, and log siblings, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines service as a string, while the description adds concrete examples such as httpd, exim, dovecot, named, and proftpd. This meaningfully expands on the bare schema and helps an agent choose valid values. It stops short of listing all valid services, but is strong for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb and resource: 'Details for one service.' This clearly distinguishes it from list-oriented siblings like services_list by emphasizing the singular scope. A stronger definition would explicitly name an alternative, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use services_get versus services_list, services_logs, system_services_overview, or services_watchdog. The singular scope is implied by the description, but there is no explicit context, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It implicitly presents the tool as a read-only getter, but it does not explicitly state that nothing is modified, whether an active session is required, or how failures are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a helpful parenthetical enumerating the returned attributes. Every word earns its place and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with an output schema, the description supplies the essential purpose and payload. It is slightly incomplete only in its silence about how this tool relates to the many sibling session_* tools, which is more of a usage-guidance gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, so the baseline is 4. The description adds relevant context about the information payload, and there are no parameter semantics to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('current session') and specifies the exact information returned ('who am I, level, selected domain'). It is clear and distinct from obvious write-tools, though it does not explicitly contrast with sibling session_* tools like session_state or session_user_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With several sibling session_* tools present, an agent receives no explicit routing cues and must infer from the name and parenthetical alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only says 'List' (a mild read-only signal) but does not disclose what set of certificates is returned (active only, all history, Let's Encrypt vs self-signed), whether the domain must already have certificates, or any admin-privilege effects. The impersonate parameter hints at admin login-as but its behavioral implications are not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a single front-loaded purpose sentence followed by a clean Args block. Every line earns its place, with no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered elsewhere. The description adequately documents both parameters and the core purpose for a simple 2-parameter tool, but it leaves behavioral context (what certificates are included, side effects of impersonation) and sibling-selection guidance unaddressed. Adequate for invocation, incomplete for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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, and it largely does. It adds real meaning beyond the schema: 'domain' is defined as a fully-qualified domain with an example format, and 'impersonate' is explained as an optional admin login-as actor. Both parameters receive semantic context that the bare schema (type/title/default) lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List TLS certificates') with a clear scope ('installed on a user domain'). The 'user domain' qualifier distinguishes this from the many server-level SSL siblings (ssl_server_*, ssl_admin_list), and the verb 'List' separates it from mutation tools like ssl_reissue_domain and ssl_delete_domain_cert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the numerous SSL siblings. There is no mention of when to prefer ssl_get_cert_files, ssl_admin_list, or how this differs from server-scoped certificate tools. With roughly 30 SSL-related siblings, an agent gets no explicit routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. The word 'Read' clearly signals a read-only, non-mutating operation, which is useful. However, it adds no further behavioral context such as scoping caveats, permission needs, or operational details beyond what the output schema may cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with the action and resource front-loaded. There is no filler, redundant phrasing, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema present, the description covers the essential invocation context. The only real gap is the lack of explicit differentiation from closely named SSL siblings, but the tool's low complexity does not demand lengthy elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 information missing. The phrase 'current hostname' gives a small implicit-scope hint, but no parameter documentation is needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Read') and resource ('current hostname certificate metadata'), which clearly identifies the tool's purpose. It does not explicitly distinguish itself from closely named siblings like ssl_server_status or ssl_get_cert_files, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many SSL-related sibling tools. No conditions, prerequisites, alternatives, or exclusions are given, so the agent must infer selection purely from the name and one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal useful behavior through the 'force' argument ('Force the switch even if a cert looks incomplete') and notes that 'confirm' is required, but it omits side effects like service restarts, downtime, or config changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, followed by a compact Args section. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-boolean mutation tool with an output schema, the description is roughly adequate, but it leaves ambiguity around whether 'confirm' must be explicitly true, what side effects occur, and when to prefer this over sibling SSL server tools. It would benefit from a brief note on prerequisites or consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 defines 'force' clearly and marks 'confirm' as required, but 'confirm: Required' is ambiguous and conflicts with the schema, which lists no required parameters and has a default of false. The description adds some meaning but not enough to fully resolve invocation behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Enable TLS on the DirectAdmin service itself.' This distinguishes it from domain-level SSL tools, though it does not explicitly name or contrast a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'on the DirectAdmin service itself' implies this is for server-level TLS rather than domain-level, but there is no explicit guidance on when to use this tool versus alternatives, nor any 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavior. It usefully flags that the key is a secret, which is a meaningful sensitivity cue, and 'download' implies a read-only retrieval. However, it does not mention any permission requirements, response behavior, or whether the files are returned inline or as attachments.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One succinct sentence with the verb and object front-loaded. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter download operation with an output schema present, the description is largely sufficient. The main missing piece is an explicit distinction from similarly named SSL file/certificate tools, which would reduce selection risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 the description has nothing to add. Per rubric, a zero-parameter tool receives a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Download') and a clear resource ('he hostname certificate and key'), and notes that the key is secret. It is clear about what the tool does, but it does not explicitly distinguish itself from similar siblings such as ssl_server_certificate or ssl_get_cert_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the many related SSL sibling tools, and no exclusion criteria are provided. An agent is left to infer the seleression context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does not disclose whether this is a read-only status check, what specific TLS status it reports, whether it inspects the certificate, or what side effects might occur. The word 'status' weakly implies a read operation, but that is not enough for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the target resource and the key exclusion. It is front-loaded and contains no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument tool with an output schema available, this description is mostly sufficient: an agent knows the target is server-level TLS status, not a user domain. However, it does not explain what kind of status information is returned or when this status check is appropriate, leaving some context gaps despite the simple signature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and parameter explanation is unnecessary. The description adds no parameter details, but none are needed for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the hostname/DirectAdmin service TLS status and explicitly scopes it away from user domains, which helps distinguish it from domain-level SSL tools. However, it lacks a specific verb like 'get' or 'retrieve,' so it reads as a noun phrase rather than a clear action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'not a user domain' provides a useful exclusion, implying this is for server-level TLS checks rather than user domain certificates. But it does not explicitly say when to use this tool versus alternatives like ssl_server_certificate or ssl_server_files, and no alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description identifies the operation as a list/read, which implies no side effects, but it does not state permission requirements, impersonation behavior, pagination, or failure modes. With no annotations, the description carries the disclosure burden and provides only the bare verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the core purpose front-loaded in the first sentence and a compact Args block. There is no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, but the description lacks usage guidance, exclusions, and explanation of impersonation behavior. It is minimally adequate yet leaves important selection and permission questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by glossing both parameters: 'domain: Parent domain' and 'impersonate: Owning user'. This adds some meaning beyond the schema property names, but the impersonate semantics remain ambiguous, especially regarding the effect of an empty default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'subdomains of a domain', making the core operation unambiguous. It is clearly distinct from sibling tools like subdomains_create and subdomains_delete, and no other sibling performs this exact read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention related tools, admin versus user context, or situations where another endpoint would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. Calling it a 'snapshot' implies a read-only, point-in-time view, but it does not disclose whether the data covers all users or only the current user, whether administrative privileges are needed, or what the returned snapshot contains beyond being 'per-user resource usage'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the key differentiators ('latest', 'per-user', 'resource usage'). Every word earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter read-style tool, and a one-line snapshot description covers the core semantics. The presence of an output schema relieves the description of explaining return values, though the ambiguity about which users are included remains a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so there is no parameter semantics gap for the description to fill. The baseline for 0-parameter tools is 4, and the description does not introduce misleading parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Latest per-user resource usage snapshot' clearly identifies the resource (per-user resource usage) and the temporal scope (latest), distinguishing it from history and global siblings. It lacks an explicit verb like 'Get' or 'Retrieve', but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'latest' suggests immediate current data versus history tools, and 'per-user' contrasts with global usage tools. However, the description does not explicitly state when to use this tool over system_resource_usage_history, system_global_usage_latest, or users_get_usage, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly implies a read-only state query and no side effects, but it does not explicitly state that nothing is modified or describe the nature of the returned value; the output schema presumably covers the return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words long with no filler and is fully front-loaded. For a parameterless current-timezone getter, this level of brevity is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument read-only query with an output schema, 'Current server timezone.' is nearly sufficient. It could be slightly stronger by explicitly naming the sibling timezone_set to clarify what this tool is not, but nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to document. The schema coverage is trivially complete, and the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('server timezone') and the specific scope ('current'), which distinguishes it from siblings like timezone_set and timezone_list. However, it uses a noun phrase rather than an explicit verb such as 'Get', so it stops short of a fully specific action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus alternatives like timezone_set or timezone_list. The word 'current' implies a read-only status query, but no explicit conditions, exclusions, or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that confirm is required and restricts accepted value forms, which is useful. However, it does not explain what happens to unspecified limits, whether existing settings are overwritten, or what permissions are needed, leaving meaningful behavioral gaps for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by a concise constraint sentence and a tight parameter list. Every part earns its place, and the format makes it easy for an agent to scan the action, constraints, and arguments quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters are covered and an output schema exists, so return-value details are not needed. The main gaps are lack of guidance about omitting fields, unclear units for 'io', and the ambiguous confirm requirement, which an agent would need to invoke the tool correctly in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description's Args section adds essential meaning by naming and explaining all eight parameters with examples. The 'confirm: Required' phrasing is slightly confusing given the schema shows confirm has a default of false, but overall it compensates well for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence clearly states the action ('Set'), the resource ('LVE limits'), and the scope ('for one user'), and lists the affected dimensions. It does not explicitly differentiate from sibling tools like cl_lve_get or cl_lve_users, so it misses the extra point for explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage through the verb 'Set' and the CloudLinux/cgroups context, but it never explicitly says when to use this tool versus cl_lve_get or cl_lve_users. The value-format constraint ('Only numeric values, percents, or unlimited') gives some usage guidance, but alternatives and when-not conditions are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral disclosure burden. It reveals that the tool performs a network request to '/api/version' and is a connectivity check, implying a read-only, non-destructive operation. However, it does not explicitly confirm lack of side effects, error behavior, or response characteristics beyond the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using a single sentence to convey purpose and the exact endpoint. Every word contributes; there is no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, zero parameters, and the presence of an output schema, the description covers everything needed to invoke it correctly. The endpoint reference and connectivity-check purpose are sufficient for a no-argument tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so there is no parameter behavior to explain. The description correctly omits any parameter guidance, and the baseline for a no-parameter tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose ('Connectivity check') and the exact resource it acts on ('/api/version'). It is easily distinguishable from sibling tools by its explicit endpoint reference, though it does not name any sibling or explicitly contrast itself with similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any conditions or exclusions. It simply states what the tool does without explaining scenarios where it is the appropriate choice among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly signals a mutating operation ('Add') and mentions that 'confirm' is required, which hints at a safety gate. However, it does not explicitly state that confirm must be set to true, what the API returns on success, whether duplicate records are rejected, or how conflicts 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and scannable: one summary line followed by a flat Args block. Every line carries useful parameter information with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough detail to make basic record additions for A, AAAA, CNAME, and TXT records. However, it under-specifies value formats for MX, SRV, and CAA records, where priority, weight, port, or flags may need to be encoded in the value string. The confirmation behavior is also ambiguous. The presence of an output schema reduces the need to document return values, but these input-format gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 does add meaning for all six parameters: domain as zone, record_type with an enumerated set of allowed types, name with apex syntax, value, ttl in seconds, and confirm as required. The 'confirm: Required' wording is slightly ambiguous because the schema marks it optional with a default of false, but it still provides information the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'Add a DNS record.' It unambiguously identifies the action and resource. It does not explicitly distinguish itself from related DNS tools such as dns_record_delete or dns_zone_get, but the verb 'add' makes the primary purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Add a DNS record' implies the tool should be used when creating a record in a DNS zone. However, there is no explicit guidance about prerequisites, such as the zone needing to exist, or when to prefer this tool over alternative DNS management tools. No exclusions or when-not-to-use context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds useful operational context such as 'quota_mb: 0 = unlimited', 'impersonate: Owning user', and 'confirm: Required', but it does not disclose duplicate-mailbox behavior, permissions, or side effects. The 'confirm: Required' note is also ambiguous and appears to conflict with the schema's optional confirm field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-line purpose followed by a compact argument list. No sentences are wasted, though a couple of arg lines such as 'domain: Domain' add little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema is present, so return values are covered. The description touches all parameters, but for a mutation tool with no annotations it still lacks duplicate-handling behavior, prerequisites, and unambiguous confirmation semantics. This makes the definition adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 does for most parameters: 'user: Local part only (before @)', 'quota_mb: 0 = unlimited', 'impersonate: Owning user', and 'confirm: Required' add real meaning. However, 'domain: Domain' is tautological and 'confirm: Required' is ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a mailbox (user@domain)', including the address format. This clearly distinguishes it from email_pop_delete, email_pop_modify, and users_create without needing to inspect siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are no prerequisites, exclusions, or mention of related tools like email_pop_modify or email_pop_delete; only 'Create a mailbox' is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Update' and lists arguments; it does not explain side effects, whether the live hostname certificate is reissued, what 'confirm' actually does, or what permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose followed by a clean Args list. Every parameter earns its place, and there is no filler or redundant repetition of schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a safety-sensitive mutation with no annotations, the description is incomplete: it omits when to use the tool, what confirm actually prevents/enables, and whether updating ACME settings triggers certificate reissuance or other side effects. The output schema covers return values, but operational context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by defining every parameter, including value domains for provider and key_type, semantic roles for additional_domains and dns_environment, and the critical requirement that confirm is required. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Update') and a specific resource ('ACME settings for the DirectAdmin hostname certificate'). The use of 'hostname certificate' differentiates this from domain-level ACME tools such as ssl_set_domain_acme_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no guidance on when to use it versus alternatives like ssl_set_domain_acme_config or ssl_reissue_server. There are no exclusions, prerequisites, or contextual use cases beyond the basic resource scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does provide useful context: the contents flag deletes files under the document root, impersonate identifies the owning user, and confirm is marked as required. However, it does not disclose whether deletion is permanent, whether DNS or other linked resources are affected, or what permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The argument list is neatly structured, and every line adds relevant information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and all parameters are briefly explained, the description is incomplete for a destructive operation. It lacks guidance on confirming the deletion, prerequisites, irreversibility, and cascading effects, and the confirm semantics conflict with the schema's optional/default-false definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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, and it does: each of the five parameters gets a meaningful one-line explanation beyond its title. The only weakness is that 'confirm: Required' is ambiguous about whether the value must be true, especially since the schema gives it a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Delete a subdomain.' This clearly distinguishes it from sibling tools like subdomains_list and subdomains_create, and the intended operation 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, what prerequisites exist, or what happens if the subdomain is still in use. The agent must infer usage entirely from the tool name and one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'List' conveys a read-only operation with no mutation, and 'admin-level' hints at required privileges. It does not disclose additional behavioral details such as sensitivity of settings or whether the call is safe to run repeatedly, but for a no-parameter list tool this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single compact phrase with no filler or redundant wording. The action ('List') and scope ('admin-level backups / backup settings') are front-loaded and immediately usable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list operation with an output schema, the description is nearly sufficient. The only weakness is the slight ambiguity of 'backups / backup settings' (whether one or both are returned), and no explicit routing versus sibling backup tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 schema coverage is complete at 100%. The description adds no parameter semantics, but none are needed; the baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('admin-level backups / backup settings'), making the core purpose clear. It is distinguishable from sibling tools like backups_create, backups_restore, and backups_admin_now by the listing action and admin scope, though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by 'admin-level' and 'List': an agent can infer it is for inspecting admin-level backup data rather than creating or restoring backups. However, there is no explicit when-to-use guidance, exclusions, or pointer to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It communicates a read-only search behavior via 'Search' and 'Shows', and identifies the exact underlying command 'csf -g'. It could disclose more about not-found behavior or output shape, but the output schema exists to cover return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the tool's purpose and command, and every sentence adds value. The Args line is slightly redundant with the schema but useful because the schema lacks semantic detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup tool with an output schema, the description is mostly complete: it names the target scope, the command, and the purpose. The main gap is the absence of when-to-use-vs-alternative guidance among the many related csf_* siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 does: 'ip: IPv4 or IPv6 address' adds format meaning beyond the schema's bare string type. The parameter is simple, so this is adequate, though it does not mention edge cases like CIDR notation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search'), the resource ('CSF/iptables/LFD'), the target (an IP), and the underlying command ('csf -g'). It also explains the point ('Shows why it is blocked'). It does not explicitly differentiate from the sibling csf_ip_reason, which may overlap in purpose, so it loses one point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives. The description implies it is for checking why an IP is blocked, but it never mentions sibling tools like csf_ip_reason or contrasts them with this search-based approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'List' and 'from official swagger' reasonably indicate a read-only introspection operation with no side effects, but the description does not explicitly confirm read-only behavior, auth requirements, or pagination/response shape beyond what the output schema likely provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one clear purpose sentence followed by a terse parameter breakdown. Every sentence contributes useful information, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple endpoint-listing tool with only two optional parameters and an output schema, this is nearly complete. It lacks only explicit guidance about when to choose a sibling discovery tool, but an agent can invoke it correctly based on the provided description and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds meaningful detail beyond the bare schema: prefix is explained as a path prefix filter with concrete examples, and method is labeled as an optional HTTP method filter. This compensates well for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 clear resource ('New API operations bundled with this server'), sourced from the official swagger. It is distinguishable from a tool like da_describe_endpoint, which would describe a single operation, though it does not explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this to discover available API operations from the server's swagger definitions. However, there is no explicit guidance about when to prefer this over related discovery tools such as da_describe_endpoint or search_resources, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It adds useful behavioral detail: the `full` flag switches to `action=full_list` and includes quota + usage, and `impersonate` scopes the call to the owning user. It does not explicitly confirm read-only status or permissions, but the 'List' wording supplies partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the purpose in the first sentence, with a compact Args block. The only minor redundancy is `domain: Domain`, but it does not bloat the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return details are covered. The three parameters are simple, and the description explains the non-obvious ones (`full`, `impersonate`) along with the required `domain`. Missing explicit usage guidance versus alternatives keeps it from being fully complete, but it is mostly sufficient for a low-complexity list call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the Args block is the only semantic source. It clarifies `full` as quota+usage behavior and `impersonate` as the owning user, but `domain: Domain` only restates the parameter name. This partial compensation is helpful but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('POP/IMAP accounts') scoped to 'a domain', clearly distinguishing it from email_pop_create/delete/modify and other email-related list tools. While it doesn't name a sibling explicitly, the resource+verb is sufficiently specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb and resource—call when you need to enumerate POP/IMAP accounts for a domain. However, it doesn't explicitly state when not to use it or point to alternatives such as email_forwarders_list or email_autoresponders_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden. It does disclose the need for confirmation ('confirm: Required') and the no-op sentinels (empty password and -1 quota leave values unchanged), but it does not describe side effects such as invalidating existing mail sessions or authorization requirements beyond the terse 'impersonate: Owning user.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-line purpose is front-loaded, and the argument list is compact with each parameter earning its place. There is no filler or redundant restatement of schema titles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with an output schema, the description provides enough to invoke it: all parameters are semantically explained and confirmation is flagged. It falls short only in not giving usage context or behavioral consequences, which are already penalized in other dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining every parameter, including crucial sentinel values for password ('empty = leave unchanged') and quota_mb ('-1 = leave unchanged, 0 = unlimited'). It also flags confirm as required, adding meaning absent from the schema's bare defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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: 'Change mailbox password and/or quota.' This clearly identifies the operation and distinguishes it from sibling tools like email_pop_create and email_pop_delete, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or alternatives are provided. The agent must infer that this tool is for modifying an existing POP mailbox, and no exclusions are given relative to similar tools such as email_pop_create or users_change_password.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that webhook URLs are secrets and that confirm is required, which is useful behavioral context. However, it does not describe the side effects of rotation, such as whether the old webhook is invalidated, nor does it mention permissions or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a front-loaded purpose sentence followed by a compact args list. Every line adds necessary information, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with an output schema, the core invocation is covered. However, because there are no annotations, more context would be valuable regarding what happens during rotation, whether the operation is destructive, and any required prerequisites. The description 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by defining all three parameters: username as the owning user, uuid as the application uuid, and confirm as required due to secrets. This adds meaning beyond the schema's bare property names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair: 'Create or rotate the deploy webhook for a git application.' This clearly identifies the operation and target, and distinguishes it from sibling git tools like git_get, git_deploy, and git_fetch, which involve different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. It does not mention prerequisites, when rotation is appropriate, or why a user would choose this over other git-related tools. The only implicit hint is that confirmation is required due to webhook URLs being secrets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the desciption carries the full burden. It does disclose a meaningful behavioral binding: results are limited to IPs visible to the current reseller/admin, which adds context beyond the mere name. It does not discuss pagination, authentication, filtering behavior, or side effects, but 'List' reasonably implies read-only behavior and an output schema is present to describe the return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action, target, and scope immediately, making it easy for an agen to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool with an output schema, this description is largely sufficient: it names the action, resource, and visibility scope. It is slightly less than fully complete because it does not clarify how it relates to ipely named siblings such as ips_admin_list or ips_get, but the tool's low complexity limits the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the description does not need to document parameter semantics. Baseline for no-parameter tools is 4, and nothing in the schema or desciption creates confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('IPs') and adds a scope qualifier ('visible to this reseller/admin'), so its purpose is immediately understandable. It is not just a restating of the tool name, but it does not explicitly differentiate from nearby siblings like ips_admin_list or ips_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'visible to this reseller/admin' implies when the tool should be used: when an IP listing scoped to the current reseller/admin is needed. However, it provides no explicit guidance about when not to use it or which of the many sibling IP-related tools (ips_get, ips_admin_list, csf_searc_ip) to choose instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It states the operation (listing) and the scope (user-facing), which implies a read-only action, but it does not explicitly state side-effect safety, permission requirements, or filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four words and every word contributes: 'installed' specifies the resource state, 'plugins' the domain, and 'user-facing' distinguishes the list scope. There is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with an output schema, the description is nearly complete: it identifies resource and scope. The only notable gap is that it does not explicitly route the agent to plugins_manager_list for administrative views.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is complete and there is nothing for the description to add. With 0 params, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('installed plugins') and the scope ('user-facing list'), which distinguishes it from the sibling plugins_manager_list. It is a noun-phrase label rather than a full action sentence, but the tool name supplies the 'list' verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'user-facing' qualifier implies this is the appropriate tool for listing plugins visible to the current user, but it does not explicitly say when to prefer it over plugins_manager_list or mention any alternatives. Usage context is implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It does add useful context by marking confirm as required and describing impersonate as the owning user, hinting at a mutating operation with an ownership dimension. However, it does not disclose side effects, overwrite behavior, or whether the operation is reversible, which are significant for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A one-sentence purpose is followed by a terse, alphabetized Args list covering all six parameters. Every line adds information and there is no filler, making the definition easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All six parameters are documented and an output schema covers return values, which is good, but the description remains thin for a no-annotation mutation tool. It omits exactly what confirm must be set to, possible side effects on existing redirects, and any usage context, leaving an agent to infer or inspect further. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args block is the only source of parameter meaning, and it supplies useful semantics: path gets an example, destination is called a target URL, redirect_type lists the allowed values, and impersonate is explained as the owning user. It loses a point because domain is left as a bare 'Domain' and confirm only says 'Required' without stating the required value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Create a site redirect' names a specific action and resource, unambiguously distinguishing this tool from its only redirect-related sibling, redirects_list, which lists redirects. The resource type is clear enough that an agent can select it for creation operations 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, exclusions, or alternative routing is provided. The verb 'Create' and the sibling name redirects_list imply the division of labor, but the description itself does not state when this tool should be chosen over alternatives or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. The verb 'List' does convey a read-only operation, and the args clarify that domain is the scope and impersonate is the owning user. It does not describe additional behavior such as auth requirements, ordering, or whether hidden/system redirects are included, but for a simple list tool the basic behavior is sufficiently clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core action in the first sentence, followed by a compact Args block. It is not bloated, though the 'domain: Domain.' line is somewhat redundant and could have been enriched without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with only two parameters and an output schema, the description gives the essential information: what is listed and which arguments control the request. It leaves out explicit usage boundaries and behavioral detail, but the output schema covers return values and the operation is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names both parameters and adds a clarifying gloss for impersonate ('Owning user'), which is more than the bare schema provides. The domain parameter description is tautological ('Domain'), so the added value is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 site redirects for a domain.' This distinguishes it from the nearby sibling redirects_create and no other sibling lists redirects, so an agent can identify the right tool immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the purpose sentence: call it when you need the site redirects belonging to a domain. However, there is no explicit guidance about when not to use it or any mention of alternatives such as redirects_create, so the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Status' implicitly conveys a read-only, non-mutating operation and 'per-user' scopes the call, but it does not disclose behavior when Redis is disabled or whether any special permission is needed. For a simple status endpoint this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no filler, and it immediately communicates the resource and scope. For a zero-parameter status tool, this brevity is appropriate and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values and there are no parameters, so the main missing elements are explicit read-only confirmation and usage differentiation from redis_enable/redis_disable. These are partially inferable from 'status', making the definition adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 add beyond the schema. The baseline for zero-parameter tools is 4, and the per-user context note is helpful even though it is not a parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (Redis) and scope (per-user), and 'status' indicates a read-only query. It lacks an explicit verb like 'get' or 'check', but it is still distinguishable from sibling tools like redis_enable and redis_disable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking a user's Redis status, but it gives no explicit when-to-use guidance. It also does not mention that redis_enable/redis_disable are the mutating alternatives, which would help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds an important security-relevant behavioral note: 'The private key is returned by DirectAdmin — treat the response as secret.' This goes beyond the schema and helps the agent handle the response safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, followed by a critical security warning. The Args list is somewhat redundant with the schema but is compact and does not add meaningful bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough to understand the basic operation and secret-handling requirement, and an output schema exists to cover return structure. However, it lacks usage guidance, a pointer to how cert_id should be obtained, and more substantive parameter semantics, leaving noticeable gaps for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. However, the Args section mostly restates the schema titles: 'domain: Domain' and 'cert_id: Certificate id' add no real meaning. Only 'impersonate: Owning user' adds a small clarification. No format, source, or relationship between domain and cert_id is explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Download certificate + chain + key files for a domain cert id.' This clearly distinguishes the tool from siblings like ssl_list_domain_certs (listing), ssl_upload_cert_files (uploading), and ssl_server_files (server-level files), even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Download... for a domain cert id' implies this tool is for retrieving cert files, but there is no explicit guidance about when to prefer it over related SSL tools or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the operation is a read and mentions the optional impersonate behavior, which is useful. However, it does not describe what the returned configuration contains, whether any side effects occur, or what permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a concise Args list. There is no filler or repetition of schema information beyond what is needed for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and an output schema exists, so the description is minimally adequate. However, it does not explain what fields the ACME configuration contains, how it differs from the server-level ACME config, or when impersonation should be used. An agent could still select it correctly but may lack nuance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 'domain' is a fully-qualified domain and that 'impersonate' is an optional user to act as. This adds meaning beyond the bare schema, though it remains fairly shallow and could specify formats or defaults more precisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a clear resource ('ACME configuration for a domain'), and names relevant providers (Let's Encrypt / ZeroSSL). This clearly distinguishes it from mutation siblings like ssl_set_domain_acme_config and from server-level tools like ssl_server_acme_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by saying it reads domain-level ACME configuration, but it does not explicitly state when this should be used over related tools such as ssl_list_domain_certs or ssl_server_acme_config. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that channel options are panel-dependent and that confirm is required, which is useful behavioral context. But it does not explain the effect of the change, whether it triggers an update, reversibility, permissions, or what happens without confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one clear purpose sentence followed by a terse argument list. It avoids fluff and every line adds information that the sparse schema lacks (channel values, confirmation requirement).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential call inputs for a simple setter, and an output schema exists so return details are not required. It is incomplete, though, on the operational context: no mention of preconditions, side effects, or the meaning of confirm beyond 'required', and no annotation safety profile to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Because schema coverage is 0%, the description usefully lists the allowed channel values and flags confirm as required. However, 'confirm: Required' conflicts with the schema, where confirm is optional with a default of false and channel is the only required parameter, making the instruction ambiguous and potentially misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb ('Change') and resource ('DirectAdmin update channel'), making the tool's purpose unmistakable. It also enumerates the valid channel values (current/stable/beta/alpha), which distinguishes it from sibling system/update tools like system_update_directadmin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: call when the DirectAdmin update channel needs to be changed, and the confirm argument is highlighted. However, it does not explicitly state when not to use it or name alternatives among the many system/update siblings, so the routing guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries more responsibility, and it does disclose an auth requirement (admin) and a special behavior for empty/current usernames. However, it does not explain consequences such as session invalidation, and the 'confirm: Required' note conflicts with the schema's default false, making the behavioral picture partially unreliable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the core purpose, and uses a compact Args list. The one-word confirm description is slightly misleading, but the overall structure is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a sensitive admin mutation with three parameters and no annotations, this is adequate but incomplete: it covers admin restriction, target username, and new password, and an output schema exists so return values need not be described. Missing pieces include confirm's actual expected value or role, password policy constraints, and potential side effects of changing another user's password.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args section is the only source of parameter meaning. Username gets useful guidance about target account and empty/current-user behavior, and new_password is identified, but confirm is described only as 'Required,' which contradicts the schema where confirm is optional with a false default and its actual role is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action — 'Change another account's password' — and adds the admin scope, making the tool's purpose immediately clear. The username parameter and 'account' wording distinguish it from database-user password tools like db_change_user_password 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit routing condition: an empty/current username should use /api/change-password instead, and the operation is labeled as admin-only. It does not name sibling MCP tools as alternatives, but the main ambiguous case is handled clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds useful context: confirm is required, notify emails the welcome message, and password is meant to be temporary. However, it does not disclose permissions, failure behavior, idempotency, or side effects beyond the creation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single purpose sentence followed by a compact argument list with zero filler. Each line provides a distinct semantic for one parameter, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no annotations and no schema descriptions, the description covers parameter semantics thoroughly and adds legacy API context. An output schema exists, so return-value details are not needed. It is slightly incomplete on preconditions like package existence and required admin permissions, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args list fully compensates. Every parameter has meaningful semantic detail, including username length/alphanumeric constraints, IP allowed values, package being an existing package name, and confirm being required. It even highlights that confirm is required despite the schema omitting it from the required list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Create a user from a package' and identifies the legacy API as CMD_API_ACCOUNT_USER. It is clear enough to distinguish from reseller/admin creation, though it does not explicitly name sibling tools for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, and no alternatives are mentioned. The phrase 'from a package' implies the intended scenario, but the description does not explain when an agent should prefer this over related tools like resellers_create or packages_user_new_api.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. The verb 'List' implies a read-only, non-destructive operation, but the description does not disclose permission requirements, output size, ordering, or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. 'List all admin accounts' is immediately understandable and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with an output schema, the description is nearly complete. It could mention that results include all admin accounts and no filtering applies, but the core calling contract is sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to clarify. The baseline for a parameterless tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('all admin accounts'). This distinguishes it from related tools like admins_create, users_list, resellers_list, and ssl_admin_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as users_list, resellers_list, or ssl_admin_list. There are no conditions, exclusions, or context to help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It does state that the tool kills a scan and that confirmation is required, which is a useful safety signal. However, it does not describe side effects such as whether results are discarded, whether the kill is irReversible, or what happens if the pid is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, action-first, and has no wasted words. The arg formatting is clear and quickly scannable, and every sentence adds directly to the caller's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter kill tool, the description covers the core action, the origin of the pid, and the need for confirmation. It is weakened by the inaccurate confirm requirement and by the lack of any note about consequences or error conditions, though the presence of an output schema reduces the need to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 usefully explains that pid comes from clamav_status, but the confirm description is both minimal and contradictory: the description says Required while the schema lists only pid as required and gives confirm a default of false. This can mislead an agent into sending a confirm value that is not actually mandatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action verb (Kill) and a specific esource (a running ClamAV scan), which clearly distinguishes it from sibling tools like clamav_scan and clamav_status. It immediately identifies what the tool does with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a running ClamAV scan' implies the intended use is to stop a scan that is already in progress, and the note that pid comes from clamav_status gives clear procedural context. It does not explicitly mention when not to use it or name alternatives, but the intended workflow is fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses account-scoped visibility ('visible to the current/impersonated account'), which is a useful behavioral trait beyond a plain 'list databases' phrasing. However, it does not explicitly state read-only intent, mention any prerequisites or side effects, or describe edge cases such as whether system databases are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the verb and resource, then adds the scope qualifier. Every word earns its place with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter listing tool with an output schema, the description is almost fully complete. It clearly names the action, the resource, and the auth scope. It could be more complete by noting when to prefer this over sibling db_* tools, but that gap is already captured under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is no parameter meaning for the description to add. Per the zero-parameter baseline, the description adequately covers semantics by simply not introducing any parameter-related ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('databases'), and a clear scope ('visible to the current/impersonated account'). This distinguishes it from sibling tools like db_info, db_get, and db_users, which could otherwise be conflated with a generic listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 db_info, db_get, or db_users. With a large family of db_* siblings, an agent would need to infer the intended use solely from the tool name, as no when/when-not conditions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does disclose a key non-effect ('does not disable the firewall') and explains the temporary nature of also_allow ('temporary CSF allow (1 hour)'). However, it does not describe side effects on existing allow/deny/ignore entries, permission requirements, reversibility, or the actual effect of the confirm parameter, leaving meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a clear action sentence, a memorable use-case line, a helpful boundary statement, and a short Args list. Every sentence adds value and the structure makes the key facts easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema removes the need to describe return values, and the core purpose is clear. Still, for a mutation tool with five parameters and no annotations, the description leaves out behavior around optional parameters and the exact confirmation mechanism, and it does not position the tool relative to its direct siblings. It is usable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 useful semantics for ip ('IPv4 or IPv6') and also_allow ('temporary CSF allow (1 hour)'), but it omits reason and idempotency_key entirely. Moreover, 'confirm: Required' conflicts with the schema, which lists only ip as required and gives confirm a default of false; this is a meaningful ambiguity for an agent deciding what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Unblock an IP in CSF *and* DirectAdmin Brute Force Monitor.' This clearly distinguishes it from sibling tools like csf_unblock_ip and bfm_unblick_ip because it addresses both systems at once. The metaphor 'customer is locked out' button reinforces the intended use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it: 'This is the customer is locked out button.' It also gives a boundary by stating 'It does not disable the firewall.' However, it does not explicitly mention sibling alternatives such as csf_unblock_ip or bfm_unblock_ip or explain when those narrower tools should be preferred, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavior disclosure. It only says a new secret is generated; it does not explain whether this replaces an existing secret, whether the secret is returned to the caller, or whether enrollment must be completed by a subsequent call to mfa_enable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that immediately conveys the operation and its enrolment context. There is no redundant wording or unhelpful filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 plus the presence of an output schema is largely sufficient for an agent to invoke it correctly. The main gap is behavioral caveats about existing MFA state, but that is already factored into the behavioral transparency score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 nothing about parameters needs to be added. The description correctly implies no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Generate a new TOTP secret'. The parenthetical '(enrolment)' clarifies the stage of the MFA lifecycle and distinguishes this from sibling tools like mfa_enable, mfa_disable, and mfa_recovery_codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'enrolment' implies this is used when setting up TOTP, but there is no explicit guidance on when to use this versus mfa_enable or how it fits into the MFA flow. Usage context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does provide some behavioral context: 'confirm: Required' signals a confirmation guard, and impersonate identifies ownership. Still, it does not disclose side effects, failure behavior if the subdomain exists, permission requirements, or whether changes are reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a concise parameter list. Every line adds useful information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters and gives a clear example for the subdomain format, and an output schema exists so return values need not be explained. However, it omits important operational context such as whether the parent domain must already exist, what confirm is confirming, and expected behavior if the subdomain already exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining all parameters: domain is the parent, subdomain is left-most label only with an example, impersonate is the owning user, and confirm is required. This adds essential meaning the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a subdomain' with a specific verb and resource, distinguishing it from subdomains_list and subdomains_delete. It does not explicitly differentiate from domains_create, but the arg list makes the subdomain-specific intent clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'create' implies use when adding a new subdomain to an existing parent domain. However, the description never explicitly states when to use this tool versus alternatives like domains_create or subdomains_list, and it offers no exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden, and it does disclose the key behavior: events are returned newest first and come from the same audit log as audit_search. For a simple, one-parameter read-only tool, this is adequate, though it does not mention maximum limits or output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 behavior and adds only the useful cross-reference to audit_search, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, this description conveys what is returned, how many, in what order, and from which log source. It is reasonably complete; the only notable omission is explicit guidance on when to prefer audit_search, but that is more of a usage-guidelines concern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'limit,' with no description, so the description needs to clarify it. 'Last N' directly maps N to the limit parameter and explains that it controls how many events are returned, adding meaning beyond the raw schema. It does not specify bounds or behavior when omitted, but the schema already supplies the default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as audit events, limits them to the last N, and specifies newest-first ordering. It does not use an explicit imperative verb like 'List' or 'Get,' but the intended operation is unmistakable, and the reference to audit_search helps distinguish it from the search sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Same log as audit_search' implies that audit_recent is the simple recent-events counterpart to a searchable audit API. However, it does not explicitly state when to choose audit_recent over audit_search or mention any exclusions, leaving the usage guidance implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds meaningful behavioral context by mentioning the structured audit log, redacted JSON lines, and specific event types like tool_denied and tool_window_denied. Still, it does not clearly state whether the operation is read-only, whether special permissions are needed, or how results are ordered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, uses concrete answerable questions to establish scope, and then presents a tight, scannable argument list. Every line earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All seven optional parameters are explained, the output schema covers return values, and examples make invocation straightforward. The main gaps are lack of sibling differentiation from audit_recent and no mention of default behavior when no filters are supplied, but overall this is sufficient for correct calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by documenting all seven parameters with useful semantics: tool name/prefix examples, agent ID source, event types, substring query behavior, inclusive ISO timestamps, and the 1–200 limit range. This is far beyond what the bare input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the structured MCP audit log and lists concrete questions it answers, such as which agent restarted which service or whether a call was denied by policy. It does not explicitly contrast itself with the similar sibling tool audit_recent, so it slightly misses the sibling-differentiation bar for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Answers: ...' list implies when this tool is useful, such as investigating who triggered an update or why a call was denied. However, there is no explicit guidance about when to choose audit_search over audit_recent or other auditing tools, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It states the mutation ('Remove'), flags that confirm is required, and clarifies that the operation is scoped to BFM rather than CSF. However, it does not explain idempotency, failure behavior, or what the confirm flag actually controls beyond being required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose, a short usage note, and a minimal args list. Every sentence contributes, and the most important scoping detail is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are not needed, and the description covers the main action and the related CSF tool. Still, with no annotations and four parameters, the description leaves reason and idempotency_key unexplained and does not fully guide selection among nearby alternatives like firewall_unblock_everywhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 for ip ('IPv4 or IPv6 to unblock') and confirms that confirm is required despite the schema defaulting to false. However, reason and idempotency_key are left completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Remove an IP from DirectAdmin Brute Force Monitor blocks.' It clearly distinguishes this from the related csf_unblock_ip tool by explicitly calling out that IPs are often listed in both BFM and CSF.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives actionable context: 'Use together with csf_unblock_ip — an IP is often listed in BOTH places.' This tells the agent when another tool is also needed. It does not enumerate exclusions or alternatives like bfm_skip_ip, but the core usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose that this is a mutating deny operation, that temporary=true switches to a TTL-based deny, and that confirm is required — a meaningful guardrail signal given the schema defaults confirm to false. It stops short of richer consequences: no mention of firewall reload behavior, reversibility via csf_unblock_ip, or the self-lockout risk of blocking one's own IP.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly packaged: one headline sentence establishes the action and the underlying CSF command, followed by a five-line argument block where every line adds meaning. There is no filler, and the most decision-critical distinction (temporary vs permanent) appears in both the headline and the args.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations and 0% schema description coverage, the description covers the core operation and all parameters, and an output schema exists so return values need no prose. It lacks a warning about consequences (permanent firewall change, reversibility path, self-lockout) and any note on CSF state prerequisites, which matters for a security-sensitive write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Arg block is the only documentation and it glosses all five parameters, including ip's accepted forms (IPv4, IPv6, CIDR) and that confirm is required. Gaps remain: ttl_seconds units are not stated, and confirm's underlying purpose as a safety gate is not explained beyond 'Required'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'Block an IP in CSF', and anchors it to the underlying command (csf -d / temporary deny), which unambiguously identifies this as the deny operation among firewall siblings like csf_allow_ip, csf_ignore_ip, and csf_unblock_ip. It also discloses that the same tool handles both permanent and temporary denies, giving the agent the full scope of the tool up front.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the verb 'Block' and the sibling names (csf_allow_ip, csf_unblock_ip) let an agent infer when this tool is appropriate. However, there is no explicit when-to-use or when-not-to-use guidance, no mention of prerequisites such as CSF being enabled, and no guidance on choosing permanent vs temporary beyond the parameter semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The word 'List' implies a read-only operation with no side effects, which is the key behavioral trait. However, it does not disclose scope, ordering, or any edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single three-word sentence is maximally concise and front-loaded. It contains no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple listing operation with an output schema present, the description is sufficient. An agent can correctly infer what this tool does without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline for this dimension is 4. The description does not need to explain parameter semantics because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 specific resource, 'database users.' This clearly distinguishes it from singular operations like db_user_get and from database-level operations like db_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to prefer this tool over the many sibling tools, such as db_user_get, db_list, or users_search. There is no mention of scope, exclusions, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. The verb 'List' reasonably implies a read-only operation, and 'on the current account' adds scope. However, it does not disclose any additional behavioral details such as whether all keys are returned at once, whether any permissions are required, or whether the list is filtered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that immediately conveys the operation and scope. There is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with an output schema available, this minimal description is complete. The agent knows exactly what action to take and what scope applies, with no further behavioral caveats needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 description has no parameter meanings to add. Per the calibration baseline for parameterless tools, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List') and resource ('login keys') with a clear scope ('current account'). It is instantly distinguishable from sibling tools like login_keys_get, login_keys_create, and login_keys_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 login_keys_get or login_keys_history. For an agent navigating a large family of login-key tools, the absence of any routing or exclusion language is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one behavioral trait: Web Terminal is intentionally not wrapped. However, it does not state whether this is a read-only reference operation, whether the mapping is fetched live or static, or what kind of output is returned beyond an implicit mapping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the core purpose front-loaded and the scope exclusion in the second sentence. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with a rich sibling list and an output schema, the description covers purpose, licensing relevance, and a notable omission. It is complete enough, though a sentence describing the expected output shape would remove residual ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter burden for the description to carry; the nominal 100% schema coverage makes this a baseline-4 case. The description adds no parameter semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Map'), a clear resource ('every Pro Pack feature'), and the destination ('the curated tool that covers it'), so an agent can tell this is a feature-to-tool reference rather than a generic inventory operation. It draws a boundary by explicitly excluding Web Terminal, but it does not explicitly contrast with sibling inventory tools such as inventory_list or inventory_this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The licensing note ('Modern licenses include Pro Pack') gives context for when the mapping is relevant, and the Web Terminal exclusion tells users not to expect a wrapper for that feature. It does not name alternatives or state 'use this when...' directly, but for a zero-parameter reference tool the usage situation is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It communicates the auth context and implies a read-only config lookup via 'Current', but does not explicitly state that it has no side effects, what happens when an admin uses it, or any other behavioral constraints. The output schema covers return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with a parenthetical qualifier. Every word earns its place: it states the resource, the access condition, and implies retrieval without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with an output schema, the description is largely complete: it names the resource and the required role. It could add a little more nuance about admin behavior or confirm that it returns the current context's reseller configuration, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 no parameter information for the description to add. The description appropriately focuses on purpose and access context rather than repeating an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('reseller config') and the access context ('when logged in as reseller/admin'), and the word 'Current' implies retrieval. It distinguishes itself from the sibling session_user_config by specifying the reseller/admin scope, though it lacks an explicit verb like 'get' or 'return'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'when logged in as reseller/admin' gives clear context for when this tool is appropriate. It does not explicitly state when not to use it or point to session_user_config as an alternative, but the access-role condition is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Dry-run' clearly indicates that the operation is non-mutating, and 'Empty = all pending' explains the scope behavior. It doesn't mention return format or edge cases, but the output schema covers 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one effective line plus a focused parameter note. It is front-loaded, contains no filler, and every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter dry-run tool with an output schema, the description is nearly complete. It explains the operation and the parameter behavior, but it could be stronger with an explicit pointer to system_packages_update_run for the actual upgrade.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. It does so meaningfully: 'Optional package name list. Empty = all pending' clarifies both the semantic type and the default behavior for an empty list. It is slightly ambiguous about whether null is treated the same as empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Dry-run OS package upgrade.' This clearly conveys what the tool does and, via the term 'dry-run,' implicitly differentiates it from the sibling system_packages_update_run. However, it doesn't explicitly name that sibling or spell out that no changes are applied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Dry-run' wording implies this is for previewing upgrades without applying them, which provides some usage context. But there is no explicit statement of when to prefer this over system_packages_update_run or system_packages_updates, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It clearly states the read-only intent ('List') and the default/override behavior of the reseller argument. However, it does not mention authorization requirements, pagination, or how results are returned, which would add useful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The main behavior is stated in the first sentence, and the Args section is minimal. No wasted words or redundant explanatory filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter list tool with an output schema, the description covers the key behavior and parameter semantics. It is mostly complete for correct invocation, though it could mention which sibling to use when listing all users is intended.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining the reseller parameter as an optional username and relating it to the behavior: if given, users of that reseller are listed; otherwise, the current reseller is used. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'List users owned by the current reseller, or by reseller if given.' This clearly conveys the tool's scope and distinguishes it from broader tools like users_list_all, though it does not explicitly name any sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need users belonging to the current reseller or a specified reseller. It provides clear context through the owner scoping, but it does not explicitly state when not to use it or mention alternative tools such as users_search or users_list_all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it does so well: it discloses the exact commands run (csf -dr, csf -tr, drop states), the optional qrm call, and the temporary-allow behavior that prevents re-banning. It does not mention permissions or reversibility, but the command-level detail is strong and goes well beyond a generic 'unblocks an IP.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a one-line summary, a numbered behavioral breakdown, an alternative-tool hint, and an Args list. It is slightly longer than strictly necessary, but every section earns its place. The most important information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior, the optional temporary allow, and the BFM pairing, and an output schema exists so return-value documentation is not required. But the tool has 7 parameters and no annotations, and two parameters are unexplained. It also lacks explicit guidance around sibling tools like csf_remove_allow or firewall_unblock_everywhere, making it good but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 documents ip, also_allow, allow_ttl_seconds, comment, and confirm, including the important 'confirm: Required' semantic. However, it omits two schema parameters entirely: reason and idempotency_key. The agent would not know what those do, which is a meaningful gap given no schema descriptions exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Unblock an IP in CSF/LFD (permanent deny + temporary ban).' It also identifies itself as 'the primary unlock from firewall action,' which clearly distinguishes it from the sibling bfm_unblock_ip and other firewall management tools. The numbered command-level steps reinforce exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context by calling itself the primary firewall-unblock action and explicitly instructs agents to 'Pair with bfm_unblock_ip if DirectAdmin Brute Force Monitor also listed the IP.' However, it does not explicitly state when to prefer this over related siblings like csf_remove_allow or firewall_unblock_everywhere, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does add useful context: json=yes is appended automatically, confirm is required for POST, and only certain command prefixes are accepted. It does not, however, disclose that this can execute arbitrary read/write server commands or describe the associated safety implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose and primary constraint, and organizes parameter guidance into a clean Args list. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Core invocation details are covered: accepted command formats, method, data handling, impersonation, and confirm requirement. The output schema covers return shape, and the remaining gap is minor—there is no guidance on discovering valid command names or when to prefer typed siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well by explaining every parameter: command with examples, method values, data as form fields, impersonate as optional user, and confirm as required for POST. It adds meaning beyond the bare schema, though method and data formats could be slightly more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Call') and a precise resource class ('legacy CMD_API_* / CMD_* endpoint'), and reinforces it with concrete examples. The prefix restriction clearly separates this from higher-level API tools such as da_api.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Only commands that start with CMD_API_ or CMD_' and the word 'legacy' imply this is for raw DirectAdmin command calls. However, the description does not explicitly say when to prefer this over modern typed siblings or da_api, nor does it warn against using it when a dedicated tool exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. 'Test' signals a diagnostic, non-mutating operation, but the description does not detail what a live test involves, what happens on failure, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and the key verb and object are front-loaded. It is appropriately sized for a simple, parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the one-line description covers the essential action. It could be slightly more explicit that this tests the connection established by db_server_config, but sibling context makes that clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so there is nothing for the description to add. The parameterless baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('test') and a specific resource ('configured SQL connection'). It clearly distinguishes this operation from the config-reading and config-updating siblings like db_server_config and db_server_config_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need to verify the configured SQL connection. However, it gives no explicit when/when-not guidance and does not mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses that impersonation is possible and that confirm is required, which is useful, but it does not explain side effects, permission prerequisites, failure behavior, or what confirm must be set to. For a mutating create operation, this is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in one clear sentence, followed by a dense parameter list covering all eight arguments. There is no redundant prose, and every line contributes actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers parameters and the core action, and because an output schema exists, return values do not need to be described. However, it omits operational context such as when adding a domain is appropriate, what conditions must be satisfied, and what confirmation value the API expects, which is notable given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining every parameter: 'FQDN to add', MB/'unlimited' for bandwidth and quota, enabling semantics for the boolean toggles, owning-user meaning for impersonate, and the required confirm flag. This adds meaningful value beyond the raw schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a precise resource ('additional domain'), and the operating scope ('current (or impersonated) user'). This clearly differentiates it from sibling domain tools such as domains_delete, domains_list_user, and domains_set_php.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case—adding a domain for an existing user—and the impersonate/confirm arguments hint at administrative context. However, it does not explicitly say when to use this tool versus alternatives, nor does it provide any when-not-to-use guidance or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It adds useful behavior beyond the name: the username is optional, empty means the current session, and the underlying API call is CMD_API_SHOW_DOMAINS. It does not disclose permission requirements or error behavior, but 'List' signals a read-only operation and the output schema covers the return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences. No filler; the purpose line is immediately followed by the only parameter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter list tool with an output schema, the description is nearly complete. The ambiguous '(admin)' placement is the main weakness—it could be read as describing a user who is an admin rather than the admin-only ability to pass a username. This keeps it from being fully self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the username parameter. It does: optional account, empty default maps to current session, and underlying API call. It could add that specifying a username is an admin capability, but for a single optional parameter this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('List') and resource ('domains'), and scopes it to a specific account or the current one. This distinguishes it from sibling domain tools like domains_create, domains_delete, subdomains_list, and domain_pointers_list. The parenthetical '(admin)' clarifies the two operating modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an implicit use case: use it to list domains for the current session, or for a named user when operating as an admin. It does not explicitly name alternatives or state when not to use it, leaving routing largely to the tool name and sibling set. Score 3 reflects implied but not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key conditional behavior (list all vs. show one), but does not explicitly state read-only status, required permissions, or behavior for unknown package names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action. The 'Args' note is minimal and earns its place because the schema has no property descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema present, the description covers both invocation modes. It does not address auth requirements or invalid-package behavior, but those are minor for a list/detail tool and are partly shielded by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by calling the parameter 'Optional package name' and linking it to the 'show one package' mode. This adds meaningful usage context beyond the bare schema property, though it stops short of explaining valid formats or where package names come from.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List user packages, or show one package') with a clear resource ('user packages') and an optional conditional mode. This distinguishes it from sibling tools like packages_reseller_list without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the optional 'package' parameter: omit it to list all, provide it to show one. However, it does not explicitly state when to use this tool over sibling package tools or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure; it does state that the operation can overwrite an existing package and that confirm is required, which are important mutation cues. However, it omits other behavioral details such as permission requirements, whether overwrite is destructive to existing settings, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in one sentence, followed by a compact parameter list with no filler. Every sentence carries useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and all 10 parameters are explained, the core calling contract is covered. It would be slightly more complete if it clarified when overwrite occurs versus create, but the combination of description, schema, and output schema is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by defining every parameter: units (MB), allowed toggle values (ON|OFF), and the confirmation flag. The only blemish is that 'confirm: Required' conflicts with the schema, which lists only name as required and gives confirm a default of false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (create/overwrite) on a specific resource (user package), which makes the tool's function immediately clear. The user-package scope also separates it from reseller packages and other package-management siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Create or overwrite a user package' implies the usage context, but no explicit guidance is given about when to choose this tool over packages_user_list, packages_user_delete, or reseller package APIs. There are no when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. 'List' implies a read-only operation, but the description does not explicitly state that there are no side effects, nor does it disclose any permission requirements or pagination/ordering behavior. The examples do add useful context about what 'managed services' includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the action and resource, then supplements with helpful examples. Every word earns its place; there is no redundant phrasing or boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description is largely sufficient: it names the resource and gives examples. It could be more explicit about whether it returns all managed services or only a subset, and how it relates to system_services_overview, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there are no parameter semantics for the description to clarify. The baseline of 4 for a parameter-free tool applies, and no additional parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 clear resource ('managed services'), with concrete examples such as httpd, exim, dovecot, and named. This clearly distinguishes it from sibling tools like services_get, services_start, and services_stop, which operate on individual services rather than listing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when an agent needs to enumerate managed services, but it does not explicitly state when not to use it or which alternative to prefer. For example, it does not clarify how it differs from system_services_overview or when services_get would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates this is a read-only listing operation and discloses the admin authorization requirement. It does not mention edge behaviors like suspended-user inclusion or pagination, but for a simple admin list these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, with no filler or redundant content. Every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema present, this description is complete enough to invoke. It states the scope, the admin requirement, and the operation. The lack of return-format details is acceptable because an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics the description needs to add. The baseline of 4 applies because no parameter ambiguity exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('every user on the server'), and the privilege level ('admin'). It does not explicitly differentiate itself from the sibling tool 'users_list', so it misses the top score for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope phrase 'every user on the server' and the '(admin)' note give an implicit sense of when to use the tool. However, it offers no explicit guidance about choosing this over related tools like users_list, users_search, or users_exists, and it names no alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the key non-obvious caveat (LFD can still block allowed IPs), explains temporary vs permanent allow behavior, comment storage, and the required confirm flag. It could add effects like persistence or removal, but the main safety-relevant behavior is already transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and front-loaded: action, non-obvious caveat, then a compact Args list. Every sentence carries information, and there is no redundant restatement of the tool name or schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a firewall-mutation tool with no annotations and zero schema descriptions, the text covers the action, all parameters, and the important LFD limitation; an output schema is present, so return-value documentation is not required. It is slightly incomplete only because confirm's required value/type is not fully spelled out, and the ignore alternative is not named.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description defines every parameter: ip explains accepted formats (IPv4/IPv6/CIDR), comment says the note is stored, temporary contrasts TTL vs permanent, ttl_seconds is scoped to temporary=true, and confirm is flagged as required. This adds important meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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: 'Whitelist an IP in CSF', and clarifies it maps to csf -a or a temporary allow. It clearly distinguishes the action from blocking/removal by stating allowed IPs bypass closed ports, but it does not explicitly name a sibling such as csf_ignore_ip, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives useful context: allowed IPs bypass closed ports but LFD can still block them unless ignored, which implies when a stronger csf_ignore_ip action might be needed. However, it never explicitly says when to choose csf_allow_ip over csf_deny_ip or csf_ignore_ip, or when not to use it, so usage guidance remains 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose important behavior such as empty strings leaving fields unchanged, 'unlimited' or numeric values, ON/OFF toggles, and confirm being required. However, it does not mention permissions, potential side effects of changing limits, or error behavior, so the behavioral picture is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: purpose statement, one global behavior note, then a compact argument list. Every sentence adds useful information, and the most important caveat about empty strings is front-loaded. There is no filler or redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is nearly complete for a 10-parameter tool: it explains every parameter, notes the required confirm flag, and the output schema covers return-value expectations. The main gap is that the confirm parameter's accepted value format is not specified, and no permission or prerequisite information is given beyond 'existing user.' Overall it is sufficient for an agent to invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate for the schema's lack of parameter meaning. It does so by documenting all 10 parameters, including accepted value formats such as 'MB or unlimited', 'ON | OFF', and the empty-string behavior. This is exactly the kind of parameter-level guidance that the schema fails to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: customize limits on an existing user. It distinguishes this from sibling tools like users_create and users_suspend by using the phrase 'existing user' and by listing the exact limit fields being modified. The reference to CMD_API_MODIFY_USER adds endpoint-level clarity without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when modifying limits on an existing user rather than creating one. It does not explicitly name alternatives or state when to prefer other tools such as users_create, users_change_password, or users_suspend. The guidance is mostly implicit and lacks exclusionary routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly labels the operation as destructive ('Delete') and flags confirm as required, which is useful. However, it does not state whether deletion is permanent, what happens when confirm is false, or what authorization implications impersonate carries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is stated in one punchy sentence, followed by a tight Args block with no filler. Every line adds operational value, and the most important guardrail (confirm) is included without extra prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with an output schema, the essential context is present: target identification, owning user, and confirmation. It could explicitly mention irreversibility or the consequence of omitting confirm, but an agent has enough information to make a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining all three parameters: job_id comes from cron_list's select0 value, impersonate is the owning user, and confirm is required. The only ambiguity is 'confirm: Required' against the schema's default false and non-required status, but the intent is reasonably clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a decisive verb and resource: 'Delete a cron job'. It also identifies the exact identifier source ('panel id / select key') and the argument docs reference cron_list, which distinguishes it from the cron_create and cron_list siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context by saying the job_id comes from cron_list and that confirm is required. It does not explicitly compare against sibling tools, but it communicates the prerequisite and safety condition needed to invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly identifies a non-destructive listing operation and explains the impersonation behavior. It does not discuss permissions or output details, but for a simple read-only list tool the essential behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the action and resource, and contains no unnecessary words. The Args line is a minimal, useful addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter and an existing output schema, the description is mostly complete. It could mention that impersonate is optional or refer to cron_create/cron_delete, but these are minor gaps given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with no description and 0% schema description coverage, so the description must compensate. 'impersonate: Owning user' adds meaning by indicating whose cron jobs are listed. It does not explain empty/default behavior but adequately clarifies the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('cron jobs'), and the scope ('current or impersonated user'). This distinguishes it from the sibling cron_create and cron_delete tools by naming the read-only listing operation explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a listing scenario and clarifies that impersonate selects the owning user, but it does not explicitly mention alternatives such as cron_create or cron_delete, nor does it state when not to use this tool. Usage context is present but mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden, and it does so well: it warns 'Dangerous', states 'the host is unprotected until re-enabled', and discloses the environment-variable gate. It also names the exact operation 'csf -x'. It does not describe response behavior or confirm semantics, but for a single-action firewall toggle the most important behavioral traits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, high-density sentences. Every line earns its place: the operation, the danger, the gate, the alternative, and the argument note. No filler, no redundant restatement of the schema, and the risk warning is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-argument dangerous tool with no annotations and an output schema, the description is largely complete: it explains the main side effect, the guard condition, and the preferred alternative. The only real gap is the exact confirm value needed to execute (true vs false), which is partly covered by 'confirm: Required' but would benefit from being explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter, confirm, has no description and default false. The description says 'confirm: Required', which tells the agent it must be provided, but it does not explicitly say it must be set to true or describe consequence of leaving the default. This is minimal but usable guidance for a self-explanatory boolean-like parameter; however the line also conflicts with the schema's 'Required parameters: 0' and default false, creating ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Disable CSF (csf -x)'. It immediately flags the dangerous, host-wide effect, and includes an explicit alternative, 'Prefer csf_unblock_ip instead', which distinguishes it from the closely related sibling tool. This gives an agent a precise mental model of what the tool does and what it is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing guidance: 'Prefer csf_unblock_ip instead' tells the agent not to use this for unblocking a single IP. It also states an operational gate, 'Blocked unless ENABLE_CSF_DISABLE=true', so the agent knows when the call will be permitted. It does not fully spell out the converse case (e.g., 'use csf_enable to re-enable'), but the warning 'until re-enabled' implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, but the verb 'Show' accurately conveys a read-only metadata lookup and the Args clarify that no operation is executed. It does not add details like error behavior or authentication, but for an introspection tool the described behavior is transparent and unambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear leading sentence and two terse parameter lines carry exactly the needed information. There is no filler, and the most important scoping ('one New API operation') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter metadata lookup with an output schema, the definition is nearly complete. The main missing piece is pointing the agent to da_list_endpoints for discovering valid method/path combinations, but nothing else an agent needs to call it is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args lines compensate by defining method as 'HTTP method' and path as a 'Path template' with a concrete placeholder example. This is meaningful but not exhaustive: valid HTTP methods and path-source guidance are not provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Show parameters for one New API operation.' This distinguishes it from siblings like da_list_endpoints (which lists operations) and da_api/da_legacy, and the method/path args complete the contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one New API operation' implies it is for a single endpoint rather than enumeration, and the method/path inputs make that concrete. However, it does not explicitly say when to prefer this over da_list_endpoints or state exclusions, leaving usage conditions to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It states the core state transition, leaving the login-as session and returning to admin, but does not mention prerequisites (e.g., an active login-as session), behavior if called outside such a session, or whether the impersonated user's session is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no filler. The action and result are front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 nearly complete: it states the action and outcome, and an output schema exists so return-value documentation is not missing. The only gap is the implicit prerequisite of being inside an active login-as session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so description adds no parameter meaning is necessary. This matches the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Leave') and resource ('login-as session') with a clear outcome ('return to the admin'). It is immediately distinguishable from sibling session_login_as tools, which enter or manage login-as sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing clearly implies this tool is used when an admin is currently in a login-as session and wants to exit back to admin. It does not explicitly name alternatives or exclusions, but the sibling pair session_login_as / session_login_as_return makes the usage context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 correctly implies a non-destructive read operation by using 'List', and 'the panel knows about' suggests the data is locally known rather than fetched live. However, it does not disclose response characteristics such as whether the list can be empty or whether any provider-specific details are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and object, with no filler or repetition. The parenthetical example adds practical value without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter enumeration tool with an output schema present, the description gives sufficient context to invoke it correctly. It could have mentioned how the result feeds into ACME DNS-01 configuration, but that is not required to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the schema already covers everything. The description's example 'Cloudflare' is illustrative but unnecessary for parameter understanding, which is why the baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and a specific resource ('ACME DNS-01 providers the panel knows about'), plus an example ('Cloudflare'). This makes the tool easily distinguishable from the many ssl_* sibling tools 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is obvious: it enumerates the DNS-01 providers supported by the panel, which is the natural discovery step before configuring ACME DNS-01. It does not explicitly list alternatives or exclusions, but with zero parameters and a generic listing purpose the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries behavioral disclosure responsibility. It does disclose that confirmation is required, that overwrite replaces existing material, and that this is lab/placeholder only. However, it does not describe side effects such as whether the server is restarted, whether prior certificates are invalidated, or what the output response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose followed by a labeled argument list. Every line adds information, and the key safety caveats are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. It covers purpose, usage context, and parameter semantics comprehensively enough for a 7-parameter tool with no annotations. Minor gaps like cert_id provenance and server-side effects prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 parameters, and it does. It documents all seven arguments, including key_type allowed values, dns_names defaulting to [domain], overwrite meaning, impersonate owner, and confirm being required. It adds meaningful value beyond the schema, though it could clarify how cert_id is obtained or how dns_names should be formatted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Install a self-signed certificate on a domain (lab / placeholder only).' This clearly distinguishes it from SSL siblings like ssl_reissue_domain or ssl_delete_domain_cert by focusing on self-signed installation. The lab/placeholder qualifier further narrows intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(lab / placeholder only)' provides clear context about when this tool is appropriate and explicitly excludes production use. It does not name alternative tools or provide when-not-to-use guidance beyond the lab caveat, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. 'List' implies a read-only operation, and the domain/impersonate scoping adds useful context. However, it does not explicitly state that no changes are made or mention any permission requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, followed by terse parameter definitions. There is no filler, repetition of schema defaults, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with an output schema, the description adequately covers the operation and both parameters. It lacks explicit alternatives and an explicit read-only statement, but those are easily inferable from the tool name and sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description defines both parameters: domain as the owner of the Unit apps and impersonate as the owning user. This adds meaningful semantics beyond the bare schema titles, though the definitions are somewhat terse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List Nginx Unit applications and routes for a domain'. This clearly identifies the tool as a read/list operation and distinguishes it from sibling tools like unit_create and unit_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by scoping the operation to a domain and optionally an owning user. It does not explicitly name alternatives or state when not to use the tool, but the sibling names make the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It clearly says 'Read', implying a non-destructive operation, and scopes the action to a user/plugin. However, it does not mention prerequisites, error behavior, or what happens if CloudLinux is not present, though the sibling note partially covers the platform condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: one core sentence, one routing note, and a one-line argument explanation. Every part earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with an output schema, the description provides all essential context: what it reads, who it targets, and when to use a different tool. The output schema handles return-value details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the title 'Username' and type string, and schema description coverage is 0%. The description's 'username: Account' clarifies that it refers to a DirectAdmin account, which adds some semantic meaning. Still, it is minimal and does not add format, domain, or validation details beyond what the schema already implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and names the exact resource ('CloudLinux PHP Selector for a user (plugin)'). It also distinguishes itself from the related DirectAdmin PHP selector tool, so an agent can tell it apart from domains_set_php without extra investigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the condition for choosing the alternative: 'On non-CL boxes use domains_set_php (DirectAdmin PHP selector) instead.' This gives clear routing guidance and prevents misuse on non-CloudLinux systems.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, but 'List' and 'all' clearly signal a non-mutating enumeration with no hidden filtering or side effects. It does not describe pagination or access scope, yet for a zero-parameter, read-only listing with an output schema, the core behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence: 'List all reseller accounts.' The verb, object, and scope qualifier are front-loaded with no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list operation with an output schema, this description is sufficient for an agent to invoke it correctly with no arguments. The scope is clear, return values are covered by the output schema, and there are no hidden configuration requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so schema coverage is effectively complete and no parameter semantics are needed. The baseline for zero-parameter tools is 4, and nothing in the description lowers that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific action verb ('List') and a precise resource ('all reseller accounts'), clearly distinguishing it from sibling resources like users_list, admins_list, and resellers_get_config. The qualifier 'all' clarifies the scope as an enumeration rather than a detail/config lookup, exceeding a mere restatement of 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb and resource: call this when you need to enumerate reseller accounts. However, it does not explicitly name alternatives or exclusions, such as when to prefer resellers_get_config or users_list, so the routing 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns that 'confirm' must be true and that the operation 'writes ACME secrets,' and it notes that dns_environment tokens are redacted in logs. This is strong transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a one-sentence purpose statement and then uses a compact per-parameter list. Every line adds meaningful semantic value, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter mutation tool with no annotations, the description covers all parameter meanings, the main side effect (writing ACME secrets), and the confirm requirement. It lacks explicit sibling routing and details about overwrite/merge behavior, but an output schema exists to handle return values. Overall, it is near-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining every parameter. It adds allowed values for provider and key_type, explains wildcard and DNS-01 behavior, identifies skip_dns_names and impersonation, and clarifies the confirm flag's mandatory, write-triggering role—far beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and a clear resource ('ACME settings for a domain'), with an explicit purpose ('before issuing or reissuing a cert'). The domain scoping clearly distinguishes it from server-level or read-only ACME sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context that this is a pre-issuance/reissuance configuration step, implying when to use it. However, it does not explicitly name alternative tools such as ssl_get_domain_acme_config for reading settings or ssl_set_server_acme_config for server-level configuration, nor does it state when not to use them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It discloses a non-obvious operational detail: reads still work when the maintenance window is closed, which helps the agent understand the meaning of the status. It does not state whether the call itself is read-only or what the exact impact of an open window is, but for a zero-parameter status check the key caveat 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the core purpose and an important behavioral caveat without any filler. The information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status check with an output schema, the description is complete. It tells the agent what the tool determines and gives an operational implication of the result. It does not need to describe return values because an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already documents everything needed. No parameter explanations are required, and the description adds no unnecessary parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact operation as a question: 'Is the maintenance window open right now?' This clearly identifies the resource (maintenance window) and the temporal scope (right now), which distinguishes it from maintenance_list and maintenance_check siblings. It also adds useful context about reads still working when closed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear and the statement that reads still work when closed implies this tool is useful for determining whether maintenance-related restrictions apply. However, there is no explicit guidance on when to choose this over maintenance_list or maintenance_check, nor any mention of 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose meaningful behavior: /api/execute blocking, the swagger requirement, and the need for confirm on destructive methods/paths. However, it does not mention authentication context, error behavior, or side-effect risks beyond the confirm flag, so it is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with purpose and usage, then a clean bulleted parameter list. Every sentence contributes information; there is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic raw-API tool with 7 parameters and an output schema, the description covers the essentials: when to use it, swagger prerequisite, blocked endpoint, and parameter semantics. It could add more detail about error behavior or the exact form of confirm, but the provided guidance is enough for an agent to invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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, and it does. Every parameter gets an explanation: method lists allowed HTTP verbs, path instructs to keep {placeholders}, path_params maps placeholder values, body is for non-GET requests, impersonate is an optional user context, and confirm is tied to destructive calls. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Call') and resource ('any documented DirectAdmin New API endpoint'), and explicitly frames itself as the generic fallback for operations without a dedicated curated tool. This clearly distinguishes it from the many sibling tools that cover specific operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this tool for operations that 'do not yet have a dedicated curated tool,' telling the agent when to choose it and implicitly when not to. It also gives concrete constraints: the path must exist in swagger, and /api/execute is blocked unless ENABLE_EXECUTE=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral burden. It explicitly discloses that this tool mutates the long-lived session and requires confirm, which are the key side-effect and safety traits. It doesn't elaborate on reversibility or permissions, but the core mutation behavior is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, then usage guidance, then parameter notes. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter session tool with an output schema, the description covers what the tool does, when to prefer an alternative, and the key side effect. It could mention how to revert the session change, but the essential information for selecting and invoking the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for username ('Account to impersonate') and says confirm is required, which helps given the 0% schema description coverage. However, 'confirm: Required' is ambiguous: it doesn't explicitly say confirm must be set to true, and it seems to conflict with the schema's required list which only includes username.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Switch the session into another account (login-as).' This clearly identifies what the tool does and distinguishes it from per-call impersonation via the impersonate= argument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises preferring the impersonate= argument on individual tools because it does not mutate the long-lived session. This is an explicit when-not-to-use and alternative, making the appropriate usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that this calls POST /api/domain-tls/{domain}/provision-certs, that ACME must be enabled, that dry_run only validates and does not hit the CA, and that confirm is required unless dry_run is true. It does not cover every side effect, but the key operational behaviors are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well structured: purpose first, then endpoint, prerequisites, alternatives, and a clean arg list. No sentence is wasted, and the critical caveats are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main invocation concerns: prerequisite check, sibling routing, dry-run behavior, and the confirm requirement. The output schema exists, so return values need no explanation. The only real gap is the undocumented optional parameters reason and idempotency_key, which keeps this from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 domain, impersonate, dry_run, and confirm's conditional requirement, but it omits reason and idempotency_key entirely. The most important parameters are covered, but two optional ones remain semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Reissue / provision the ... certificate for a domain.' It also brands itself as the 'primary renew/reissue SSL action,' which distinguishes it from sibling tools like ssl_reissue_server and ssl_reissue_domain_legacy. The endpoint reference adds further precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use alternatives: use ssl_get_domain_acme_config first when ACME status is uncertain, and use ssl_reissue_server for hostname/server certs. This is concrete, actionable routing guidance rather than vague context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds useful context such as the legacy API, wildcard DNS challenge requirement, and the need for confirmation. However, it does not disclose side effects (e.g., replacement of existing certificate), auth requirements beyond impersonate, or failure behavior, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the most important instruction ('Use ssl_reissue_domain first'), and followed by a tight args list. Every sentence and bullet adds value, with no filler or repetition of schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a legacy fallback tool with 7 parameters and no annotations, the description covers the key context: purpose, alternative, legacy scope, parameter meanings, and special requirements. Since an output schema exists, return values need not be described. Minor omissions like explicit error conditions or prerequisites keep it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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, and it does. It explains every parameter concisely, adds meaningful semantics (wildcard requires DNS challenge, entries default to domain and www, keysize options, impersonate owner, confirm required). This goes well beyond the schema, though domain itself is described minimally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line identifies a specific action and resource: a fallback Let's Encrypt request through the legacy CMD_API_SSL path. It also explicitly differentiates from the sibling ssl_reissue_domain by stating which one to use first, making the tool's role clear without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct usage guidance: 'Use ssl_reissue_domain first' and clarifies that this legacy variant exists only for panels predating /api/domain-tls. This names the alternative and the condition that selects between them, which is exactly what an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, and it does meaningful work: 'force: Allow a certificate that fails validation,' 'dry_run: Validate only,' and 'confirm: Required unless dry_run' disclose validation, safe execution, and confirmation behavior. 'impersonate: Owning user' hints at authorization context. It does not fully explore irreversibility or service impact, but it discloses the most safety-relevant behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence purpose followed by a compact Args list. Every line adds information about a parameter or behavior, with no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter mutation tool with no annotations and an output schema, the description covers the essential invocation details: what the operation does, all parameters, validation behavior, dry-run mode, and confirmation requirement. It stops short of explaining post-replacement effects or error conditions, but the output schema and the existing flag descriptions make the definition sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 schema's silence. It does so by documenting all nine parameters, including valuable semantics for 'chain' as optional intermediate PEM list, 'force' as allowing failed validation, and 'dry_run' as validate-only. A few entries like 'domain: Domain' are nearly tautological, but the overall parameter guidance is solid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Replace a domain certificate with uploaded PEM files.' This clearly distinguishes the tool from siblings such as ssl_get_cert_files (reading), ssl_delete_domain_cert (deleting), and ssl_reissue_domain (ACME reissuance), and from ssl_server_upload_files, which targets server certs rather than domain certs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use: replacing an existing domain certificate with PEM data. It does not explicitly name alternatives or give when-not-to-use guidance, but the purpose statement is specific enough that an agent can understand when this tool applies versus certificate retrieval, deletion, or ACME reissuance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does reveal a non-obvious behavior: blocked_only is only a 'Hint for the client; the panel still returns the full JSON.' This tells the agent not to expect server-side filtering. It does not discuss auth, rate limits, or result shape, but the output schema covers return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, then sibling differentiation, then parameter detail. Every sentence provides value and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with an output schema, the description covers the essential facts: what the tool lists, how to get single-IP detail, and what the blocked_only parameter actually does. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 effectively explains the single boolean parameter by stating it is a client-side hint and that the full JSON is always returned, which is meaningful beyond the schema's bare 'default: true'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List Brute Force Monitor state', and clarifies the content with examples '(blocked IPs, failed logins)'. It also distinguishes itself from the sibling bfm_ip_reason by pointing to the single-IP 'why was this blocked' view, so an agent can select correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs one-IP lookups to bfm_ip_reason, which is a clear alternative and condition. It does not enumerate all other related siblings like bfm_unblock_ip or bfm_skip_ip, but for the core listing purpose it gives the necessary routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does: it states the tool reads the plugin list, pings LVE Manager, and changes nothing. That clearly conveys a read-only safety profile and the actual mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the core purpose and then add only the essential mechanism and safety note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter detection tool with an output schema present, the description is complete: it says what is checked, at a high level how, and that it is non-destructive. No critical calling context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 needs no elucidation. Per the zero-parameter baseline this is a solid 4; the description does not need to add parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation—detect CloudLinux/LVE Manager on this box—and explains the probe mechanism (plugin list + LVE Manager ping). 'Does not change anything' differentiates it from the mutating cl_* siblings such as cl_lve_set or cl_cagefs_enable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use it: when you need to check whether CloudLinux/LVE Manager is present or running. It does not explicitly name sibling alternatives or state when not to use it, so usage guidance is largely inferred rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of conveying behavior. 'Look up' clearly signals a read-only lookup with no mutation, and the scope is limited to the hops inventory. It doesn't discuss error cases or missing IDs, but for a simple getter this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loaded: one clear action sentence followed by a single parameter note. Every sentence contributes necessary information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with an output schema, the description is complete. It states what is retrieved, the target inventory, and how to source the parameter. No additional behavioral context is essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 meaningful provenance: 'id from inventory_list' tells the agent exactly how to obtain a valid server_id, going beyond the schema's bare 'Server Id' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Look up one server in the hops inventory.' It clearly identifies the tool as a singular getter, distinguishing it from inventory_list and inventory_this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by stating the server_id comes from inventory_list, implying the tool should be used when you already have an ID from that list. It doesn't explicitly name alternatives or exclusions, but the intended usage is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the safety and behavior burden. 'Show' implies a read-only operation, and the second sentence explicitly frames denied tools as flag-driven rather than bypassable, including the correct remediation. It does not describe output structure, but an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the primary purpose, followed by two high-value behavioral notes. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument status tool with an output schema, the description is complete: it states the purpose, clarifies the denied-tool semantics, and directs the agent to the correct escalation path. There is no missing information an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so there is no parameter meaning for the description to add. The baseline of 4 applies because nothing is left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb ('Show') and resource ('optional capabilities') and states the state being reported (which are on). This is distinct from all sibling tools, none of which cover policy/capability introspection, so an agent can identify what it does without needing the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use it to see which optional capabilities are enabled, and explains the meaning of denied tools in terms of ENABLE_* flags. It does not explicitly enumerate when-not-to-use alternatives, but no sibling offers the same capability, and the instruction to ask the operator rather than bypass is a practical routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden. It clearly says the operation is a read and names the exact source file. It also adds domain context about what the flags control. It does not state error behavior or permission requirements, but for a zero-parameter read tool this is a reasonable disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one sentence states the operation, and two short sentences add context and a pointer to the mutation sibling. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with an output schema, the description is complete. It identifies the source, the specific flag families, the behavior those flags control, and the tool to use for changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema coverage is effectively 100%, so the baseline of 4 applies. The description adds contextual meaning about the flags but is not required to document parameter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Read admin_ssl_* and letsencrypt_* flags from directadmin.conf.' It then explains what these flags control, which distinguishes this read-only inspection tool from the many SSL admin and da_config siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by tying the flags to the automatic Admin SSL poller and explicitly points to da_config_local_patch for changing them. It does not explicitly compare against other read-style config tools, but the purpose is clear enough that an agent can select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the underlying endpoint, legacy-API status, licensing requirement, and authorization requirement. 'List' and 'overview' imply read-only behavior, though an explicit no-side-effects statement would have made this even clearer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each earning its place: the scope statement, the endpoint context, the access requirements, and the intended workflow. The most identifying information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only overview tool with an output schema present, the description is complete. It specifies the endpoint, the required access level, the Pro Pack dependency, and the downstream use case, with no critical operational gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics for the description to add. According to the calibration baseline for zero-parameter tools, this is appropriately handled by the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 every user/domain certificate the Admin SSL page shows.' It further identifies the exact legacy endpoint (CMD_ADMIN_SSL?json=yes) and clarifies that it is not part of the New JSON API, which helps distinguish it from sibling SSL tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'Use this to see which customer domains are missing, expired, or valid before calling ssl_admin_reissue.' It also states access prerequisites (Pro Pack and a login key allowed to run CMD_ADMIN_SSL). It does not explicitly name an alternative tool or say when not to use it, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the safety burden. It discloses that ACME is queued in the background via dataskq, that no impersonation occurs, and that confirm is required. It does not list failure modes or side effects on existing certificates, but the core behavioral traits are clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, an implementation note, usage guidance, and an Args section. It is slightly longer than strictly necessary and mixes prose with formal argument documentation, which is acceptable given the complexity and the zero schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters and no annotations, but the description covers the critical aspects: what the tool does, when to prefer it, the async behavior, and the meaning of the main parameters. Missing details about reason, idempotency_key, and explicit confirmation semantics are secondary. An output schema exists, so return-value documentation is not the description's burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 domains as coming from ssl_admin_list with a max of 50, wildcard as dns-01 versus default http-01/per-host, and confirm as required. The reason and idempotency_key parameters are not explained, leaving a modest gap, but the most important semantics are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests Let's Encrypt certificates for selected customer domains, names the underlying admin action, and explicitly contrasts itself with ssl_reissue_domain. This makes its purpose and scope immediately distinguishable from nearby SSL sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('Prefer this when an operator says reissue SSL for these clients') and names the more precise alternative for single domains on modern panels. It also warns about asynchronous queueing behavior, which is valuable for setting expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the destructive nature of the action, the requirement to confirm, and the ACME skiplist side-effect. It does not discuss irreversibility, permissions, or impact on live services, but the confirm requirement is a meaningful behavioral disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a one-line summary followed by a compact Args list. Every line adds information, and the most important fact—delete one certificate from a domain—is front-loaded. There is no filler or redundant prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 need not be described. The description covers the parameter semantics, a key prerequisite (cert_id source), and the confirm requirement. It lacks explicit notes on permissions, reversibility, or failure behavior, and the 'confirm: Required' note slightly conflicts with the schema marking confirm as optional with a default of false.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description documents all five parameters with meaningful semantics: cert_id is sourced from ssl_list_domain_certs, update_acme_skiplist controls future ACME management, impersonate is the owning user, and confirm is required. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete one certificate from a domain.' It clearly identifies the domain-scoped nature of the operation, distinguishing it from server-level SSL tools like ssl_server_certificate and ssl_reissue_server. An agent can immediately understand 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful invocation context: cert_id should come from ssl_list_domain_certs, impersonate identifies the owning user, and update_acme_skiplist controls whether ACME manages the name again. It clearly implies the prerequisite of listing certs first. It does not explicitly discuss alternatives or when not to use this tool, but no sibling offers the same delete-domain-cert behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It clearly signals a read-only operation ('Read') and defines what resource is being read. For a zero-parameter getter, this is adequate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler. It conveys the action, resource, and scope immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool with an output schema present, the description is complete. It tells the agent exactly what resource is being accessed, and no additional usage clues are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description does not need to add anything beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and names a precise resource: the ACME configuration for the server hostname certificate. This clearly distinguishes the tool from domain-focused siblings like ssl_get_domain_acme_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope is clearly stated as the server hostname certificate, which implies this is for server-level ACME config rather than domain-level. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It explains the implementation ('Parses csf -g via the plugin'), shows a typical output comment, and notes that the output is safe to show an operator. It doesn't explicitly state it is read-only, but the purpose and parse wording make that clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. Every sentence adds value: the purpose, the safety note, the parsing method, the output example, and the sibling guidance. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup tool, this is complete. It states what the tool returns, gives a representative comment, references the output schema implicitly, and directs the agent to alternatives when broader context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 does by documenting 'ip: IPv4 or IPv6', adding format and version constraints that the schema lacks. This is sufficient for the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific question and resource: 'Why CSF/LFD listed this IP'. It distinguishes itself from csf_search_ip by focusing on the reason/comment, and from bfm_ip_reason by clarifying it covers CSF/LFD. The example comment makes the output concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to pair with bfm_ip_reason or use ip_block_reason when both CSF/LFD and BFM reasons plus customer text are needed. This gives an agent a clear decision rule between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 declares read-only behavior, specifies the returned fields (operator_reason, customer_message en/bg, no host paths), and discloses the honesty fallback when no reason is recorded. This exceeds typical lookup-tool disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core answer, then gives the trigger, safety, return summary, and fallback. It uses bullet points to make return fields scannable and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, an existing output schema, and a read-only lookup, the description covers trigger, inputs, outputs, and no-result behavior. No critical call information is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add parameter meaning. The Args section defines ip as IPv4 or IPv6, which supplies format beyond the bare string in the schema. It could add an example or state exact-match requirements, but this is sufficient for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool explains why an IP is blocked by combining CSF/LFD and BFM data. This is a specific resource plus intent and distinguishes it from sibling tools like csf_ip_reason and bfm_ip_reason by being the combined answer. Clear and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'This is the tool to call when the operator (or the customer) asks "защо е блокиран"'. It does not explicitly list exclusions or alternatives, but the context is clear that this tool is the combined read-only explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses what the tool returns (operator reason, customer_message in en+bg) and how the output is meant to be used (pasted to the client). It does not explicitly state that the call is read-only, but the return-focused wording and 'reason' semantics make the non-mutating behavior clear enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose, returned payload, routing note, then the argument definition. Every sentence contributes and there is 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with an existing output schema, the description covers what the tool does, what it returns, the input format, and the relevant alternative. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema only says ip is a string, but the description fully compensates by defining the parameter as 'IPv4 or IPv6 to explain'. For a single-parameter tool this is complete semantic coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the tool's exact purpose—explaining why Brute Force Monitor listed an IP—and lists the returned fields (service, user, attempts, log line). It also differentiates from sibling ip_block_reason by naming the CSF/LFD alternative, so an agent can pick the right tool without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs when to prefer ip_block_reason over this tool ('when you also need the CSF/LFD side'), which is the key routing decision among the BFM/CSF sibling tools. This gives clear context for selection rather than leaving it to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![directadmin-mcp-server MCP server](https://glama.ai/mcp/servers/OpenIaaS/directadmin-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/OpenIaaS/directadmin-mcp-server)

Score Badge

Copy to your README.md:

[![directadmin-mcp-server MCP server](https://glama.ai/mcp/servers/OpenIaaS/directadmin-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/OpenIaaS/directadmin-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OpenIaaS/directadmin-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server