RunCloud MCP by usefulapi

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds meaningful context beyond them: a restart briefly interrupts the service and the sites behind it, and stop is intentionally excluded. It omits any note on auth requirements or what the response returns.

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

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

The 'WRITE:' prefix front-loads the mutation nature, and each of the five short sentences carries distinct information (operations, impact, exclusion, realName source, endpoint). Zero filler.

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

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

With a fully described 3-parameter schema and no output schema, the description supplies everything an agent needs: what it does, its side effect, the excluded action, where to get the service identifier, and the target endpoint. Nothing material is missing for a mutation tool of this scope.

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

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

Schema coverage is 100% so the baseline is 3, and the description adds provenance for the required real_name (obtain it from runcloud_list_services) plus format examples, and reiterates the action enum. That provenance guidance is useful beyond the schema, though it repeats the enum and examples the schema already provides.

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

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

States a specific verb set (systemctl start/restart/reload) and resource (one service on a server), names concrete examples (nginx-rc, php81rc-fpm), and gives the underlying endpoint PATCH /servers/{id}/services. The 'WRITE:' prefix and the sibling reference to runcloud_list_services distinguish it clearly from read-oriented siblings.

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

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

It routes the agent to runcloud_list_services to supply realName, and explicitly notes that 'stop' is deliberately not offered, which is genuine when-not guidance. It does not, however, help the agent choose between start vs restart vs reload, so the action-selection logic is left implicit.

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

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description earns credit beyond that by spelling out the consequence: 'changes the live site's files' and that it pulls the branch and runs the deployment script. It stops short of noting irreversibility, auth needs, or rate limits, but the destructive impact is made concrete.

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

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

Front-loads the WRITE marker, then a single dense sentence covering action, mechanism, and side effect, followed by the retrieval prerequisite and endpoint. No filler; every clause carries information.

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

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

No output schema exists, so the description must stand alone for behavior; it covers the mutation, its side effect, and how to obtain the id. Annotations already carry the safety profile, so nothing critical is missing, though the lack of any rollback/reversibility note is a minor gap for a destructive write.

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

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

Schema description coverage is 100% and every parameter already carries its own description and cross-reference (runcloud_list_servers, runcloud_list_webapps, runcloud_get_git_deployment). The description merely restates the git_id source, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('force a Git deployment of a web application now') and immediately explains the mechanics: RunCloud pulls the configured branch and runs the deployment script. It is distinguishable from the sibling runcloud_force_deploy_atomic by naming the Git-deployment mechanism explicitly.

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

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

It gives a prerequisite ('Get git_id from runcloud_get_git_deployment') and signals immediacy ('now'), but never states when to prefer this over runcloud_force_deploy_atomic or what conditions make a force-deploy appropriate. Usage is implied rather than guided.

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

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

Annotations already carry the safety profile (destructiveHint=true, idempotentHint=false, openWorldHint=true), yet the description adds real mechanic detail: it builds a new release and switches the live symlink only on success. That 'what actually changes' context goes beyond the structured hints, though it omits auth/rate-limit behavior.

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

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

A single front-loaded sentence prefixed with 'WRITE:' plus the endpoint path; zero filler and the write nature is surfaced first. Slightly above minimal but the endpoint string is arguably redundant with the tool name.

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

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

For a destructive mutation with no output schema, the annotations cover the safety profile and the description explains the deployment mechanics, so an agent has enough to invoke it correctly. It does not describe the response or failure behavior, which is a minor gap.

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

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

Schema coverage is 100% for the single project_id parameter, and the schema itself points to runcloud_list_atomic_projects for lookup. The description only restates the {project} path segment, adding no new semantic detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('start an atomic deployment of a project') and adds the 'force'/'now' semantics, so the action is unambiguous. It does not explicitly differentiate itself from siblings like runcloud_list_atomic_deployments or runcloud_deploy_git, so it falls short of a 5.

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

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

'start ... now' implies the immediate-deployment use case, giving implied guidance. However, it names no alternatives (e.g., runcloud_deploy_git) and states no prerequisites or when-not-to-use conditions, leaving routing to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the output is DNS record guidance (A/CNAME) for pointing a domain at the server, but says nothing about format, completeness, or any rate/scope caveats.

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

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

Two short sentences, zero filler, with the resource definition front-loaded. The endpoint sentence is somewhat redundant with the title but compact.

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

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

No output schema exists, so the description carries the burden of explaining the return value; it names record types but not the shape of the response or whether it is copy-paste-ready config. Adequate for a read-only informational tool with full param coverage, but not complete.

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

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

Schema description coverage is 100% and each id is documented with a cross-reference to a list tool, so baseline is 3. The description adds the path template mapping ids to server/webapp/domain, which loosely reinforces the hierarchy but adds no format or validity detail.

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

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

The description names a specific resource and scope: the DNS records (A, CNAME) a domain needs to point at the server, with the exact REST path. It is clear what is returned, though it doesn't contrast itself against any sibling (there is no close DNS sibling, so differentiation is less critical).

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative. The agent must infer from the endpoint that this is a read used when configuring a domain's DNS.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is largely covered. The description nonetheless adds real behavioral context beyond the annotations: webhook keys are deliberately excluded from the response, and the result's id doubles as the git_id consumed by runcloud_deploy_git. That is useful disclosure for a read tool.

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

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

It is front-loaded with the returned shape, then the omission caveat, then the id linkage and endpoint. Nearly every clause earns its place, though the raw 'GET /servers/{id}/webapps/{webapp}/git' endpoint string is redundant with the tool name and schema.

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

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

With no output schema, the description correctly enumerates the return fields and marks the one excluded field, and explains the id linkage to the sibling deploy tool. An agent has enough to call it and interpret the result; only per-alternative routing guidance is absent.

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

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

Schema description coverage is 100% and both server_id and webapp_id are documented in the schema, including cross-references to runcloud_list_servers and runcloud_list_webapps. The description adds no further parameter meaning, so the baseline 3 applies.

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

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

The description names the specific resource (the Git deployment configured on a web application) and enumerates the fields returned (provider, branch, repository URL, auto-deploy flag, script, atomic flag), so the agent knows exactly what data this read returns. It does not state a standalone verb like 'Get' but the noun scope is precise enough to identify the operation. Differentiation from siblings is partial: it links to runcloud_deploy_git but does not contrast with runcloud_get_webapp or runcloud_get_webapp_settings.

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

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

There is no explicit when-to-use or when-not-to-use statement. The strongest guidance is the functional pointer 'The id of the result is the git_id for runcloud_deploy_git', which tells the agent this tool feeds the deploy tool. Usage is implied (fetch Git config) but alternatives are not addressed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered by structured data. Against that lower bar the description still adds value by enumerating the returned fields, which is meaningful because no output schema exists. It stops short of disclosing error behavior (e.g., unknown id) or permission requirements.

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

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

Two compact fragments, front-loaded with the returned field set, and nothing is padded. The trailing 'GET /servers/{id}' is largely redundant with the tool name and title, which is the only wasted token.

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

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

For a single-read tool with full schema coverage and no output schema, the field enumeration is the one piece of context an agent actually needs, and it is present. Annotations supply the safety profile. Only the absence of error/failure semantics 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.

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

Schema description coverage is 100% and the single parameter already documents that it is the RunCloud server id sourced from runcloud_list_servers. The description adds nothing parameter-specific beyond restating 'by id', so the schema is doing all the work and the baseline 3 applies.

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

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

States a specific resource and scope ('One server by id') and enumerates the exact attributes returned (provider, IP, OS, stack, online state, agent version, update settings, tags). That field list is what separates it from runcloud_list_servers and from the narrower runcloud_get_server_health / _stats / _hardware siblings, so an agent can route correctly without opening the schema.

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

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

The phrase 'by id' implies the usage condition (you already have a server id), but there is no explicit when-to-use guidance, no statement of when to prefer this over runcloud_list_servers, and no note that the id is obtainable from the list tool. That pointer exists only in the schema's parameter description, not in the tool description.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that data comes from a fixed GET /servers/{id}/hardwareinfo endpoint, but says nothing about auth requirements, rate limits, or whether values are cached/live. Adequate but not rich.

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

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

One content sentence plus an endpoint reference, with the highest-value information (returned fields) front-loaded and zero filler.

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

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

There is no output schema, so the description correctly compensates by enumerating the returned fields, and annotations carry the read-only safety profile. It is nearly complete for a single-param read tool; only the absence of usage routing against sibling health/stats tools is a real gap.

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

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

Schema coverage is 100% and the single server_id parameter is fully documented in the schema, including a pointer to runcloud_list_servers. The description adds no further parameter meaning, so the baseline 3 applies.

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

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

States a specific verb+resource (get server hardware info) and enumerates exactly what is returned: kernel version, CPU model/cores, memory and disk totals/free, load average, uptime. This field list implicitly distinguishes it from sibling tools like runcloud_get_server_health and runcloud_get_server_stats, but no sibling is named explicitly, so it stops short of a 5.

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

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

Provides no when-to-use guidance and does not contrast itself with the closely related runcloud_get_server, runcloud_get_server_health, or runcloud_get_server_stats. The agent must infer the distinction from the returned-field list alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral value beyond that: it tells the agent this returns a single 'latest' sample rather than a time series, and enumerates exactly which metrics come back — important since there is no output schema.

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

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

One tight sentence with the resource front-loaded, followed by the REST endpoint for traceability. No padding, though the field enumeration partially overlaps with what the endpoint implies.

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

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

For a single-parameter read with no output schema, the description supplies the missing return-value context by naming the metrics returned. Only the distinction from sibling health/stats tools remains unaddressed.

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

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

Schema description coverage is 100% and the single server_id parameter is documented in-schema with a pointer to runcloud_list_servers. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb+resource (fetch the latest health sample of a server) and enumerates the payload fields (memory, disk, load average), which meaningfully differentiates it from siblings like runcloud_get_server_stats or runcloud_get_server_hardware. It never names those siblings explicitly, so the differentiation is inferential 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.

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

There is no when-to-use / when-not-to-use guidance and no reference to the obvious alternative tools (runcloud_get_server_stats, runcloud_get_server_hardware). The agent must infer from field lists which health-related tool to pick.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully discloses what the response contains (four counts plus country), but adds nothing about failure modes, permissions, or freshness.

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

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

A single front-loaded sentence describing the payload, followed by the endpoint path. Tight, though the raw endpoint adds little for an agent and could be dropped.

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

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

For a one-parameter read tool with no output schema, the description fully enumerates the returned fields (web apps, databases, cron jobs, supervisor jobs, country), and annotations cover safety. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100% and server_id is documented in the schema with a pointer to runcloud_list_servers. The description adds no extra semantics for the parameter, so the schema does the heavy lifting — baseline 3.

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

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

States the exact resource being returned (counts of web apps, databases, cron jobs, supervisor jobs, plus country) and the endpoint. This clearly separates it from siblings like runcloud_get_server_hardware and runcloud_get_server_health, though it doesn't 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.

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

There is no when-to-use guidance, no mention of alternatives, and no prerequisites. The agent must infer that this is for obtaining aggregate counts rather than detailed listings or health data.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the plan-tier constraint (Advanced SSL requires Business/Enterprise), which is genuinely useful context, but says nothing about the response shape or what AutoSSL statuses can be returned. With annotations carrying much of the load, a 3 is appropriate.

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

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

Two short sentences plus a raw endpoint path. Most of it is front-loaded and useful, though the trailing 'GET /servers/{id}/webapps/{webapp}/ssl/advanced' restates information an agent does not need to invoke the tool.

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

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

With no output schema, the description carries the burden of explaining return values, and it only names two fields (SSL method, AutoSSL status) without indicating possible values or shape. It is adequate to decide when to call, but thin on what comes back.

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

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

Schema coverage is 100% and both parameters (server_id, webapp_id) are documented in the schema with pointers to helper tools. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

The description states specifically what is retrieved: whether the webapp uses basic (one certificate) or advanced (one per domain) SSL, plus its AutoSSL status. The parenthetical definitions make the distinction concrete. It does not, however, differentiate itself from siblings like runcloud_get_webapp_ssl, which could plausibly return overlapping information.

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

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

There is no guidance on when to call this versus runcloud_get_webapp_ssl, runcloud_install_letsencrypt_ssl, or runcloud_renew_ssl. The note that 'Advanced SSL is a Business/Enterprise feature' is a constraint on results, not usage direction, and no prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by disclosing the return payload shape (status values, pid, uptime) and that results are grouped by job label, which matters since no output schema exists.

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

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

Two compact fragments that front-load the returned fields and states. The trailing raw route 'GET /servers/{id}/supervisors/status' is developer-oriented rather than agent-oriented, but it costs little.

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

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

For a read-only single-parameter tool with no output schema, the description supplies what the agent cannot get elsewhere: the concrete status vocabulary, the returned fields, and the grouping dimension. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and the single server_id parameter is fully documented with a pointer to runcloud_list_servers. The description adds no parameter-level meaning; 'by job label' describes grouping of results rather than an input, and could momentarily suggest a filter parameter that does not exist.

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

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

States a precise resource and what it returns: live status (RUNNING, FATAL, BACKOFF), pid and uptime for every supervisor process. This is clearly distinct from runcloud_list_supervisors, though that sibling is never named explicitly, so the agent must infer the difference between listing supervisors and reading their live status.

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

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

Monitoring intent is implied by 'live status' and the enumerated failure states, but there is no explicit when-to-use guidance, no prerequisites, and no routing to runcloud_list_supervisors or runcloud_reload_supervisor. Usage must be inferred.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /servers/{id}/webapps/{webapp}) and the returned field list, which is modest additional context, but says nothing about failure modes when the id is unknown or whether the record is fetched live.

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

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

Two compact sentences, front-loaded with the object and its return fields. The trailing raw endpoint restates the same idea in a second notation and is close to redundant, but the overall length is tight and nothing is buried.

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

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

With no output schema, the description's field enumeration (path, PHP version, stack, type, default flag) is a valuable substitute that tells the agent what it will receive. It is close to complete for a simple read-by-id tool, though it omits any note about unknown/invalid id behavior.

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

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

Schema coverage is 100%: both server_id and webapp_id are documented with descriptions pointing at runcloud_list_servers and runcloud_list_webapps respectively. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb+resource: fetches one web application by id, and enumerates the fields returned (path, PHP version, stack, type, default flag). This distinguishes it from runcloud_list_webapps, but it never names that sibling or the related runcloud_get_webapp_settings/runcloud_get_webapp_ssl, so the differentiation is implicit rather than explicit.

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

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

There is no when-to-use guidance and no alternatives named in the description. An agent must infer from the tool name alone that this returns a single webapp versus runcloud_list_webapps (all webapps) or runcloud_get_webapp_settings/runcloud_get_webapp_ssl (adjacent data for the same object).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the endpoint path and the list of setting categories, without noting auth requirements, rate limits, or return format beyond the category hints.

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

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

A single tight sentence front-loads the resource and enumerates the key setting categories, followed by the endpoint. No filler text; the trailing endpoint is arguably redundant given annotations already carry the title.

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

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

For a read-only getter with annotations covering safety and a fully documented schema, the description is nearly complete. With no output schema, the enumeration of returned setting categories (disabled functions, timezone, limits, process manager) usefully anticipates the payload, though it stops short of describing structure or pagination.

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

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

Schema description coverage is 100% and both parameters (server_id, webapp_id) are documented in-schema with cross-references to runcloud_list_servers and runcloud_list_webapps. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb+resource (get settings of a web application) and enumerates the concrete setting categories returned (disabled functions, timezone, memory/upload limits, process manager), which distinguishes it from a plain get_webapp. It doesn't explicitly contrast with siblings like runcloud_get_webapp_ssl, but the scope is unambiguous.

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

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

Usage is only implied: an agent can infer you call this when you need PHP/FPM/Nginx configuration for a webapp, but there is no statement of when to prefer it over runcloud_get_webapp or runcloud_get_webapp_ssl, and 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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious context beyond that: private keys are never returned, and the exact GET path 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.

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

Three terse fragments, zero filler, with the resource and its scope front-loaded and the endpoint path appended last for disambiguation.

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

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

For a two-parameter read with no output schema, the description compensates by naming the fields returned and stating the negative behavior around private keys, while annotations and the schema cover safety and inputs.

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

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

Schema description coverage is 100%, and both parameters (server_id, webapp_id) are fully documented with cross-references to the listing tools. The description adds no parameter-level detail, so the baseline of 3 applies.

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

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

States a specific resource (web application SSL certificate) and enumerates the returned content (provider, validity, HTTPS settings), plus the underlying endpoint. It does not explicitly distinguish itself from the nearby runcloud_get_ssl_method sibling, so an agent must infer the boundary between them.

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

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

The parenthetical '(basic / web-app-level SSL)' implies this is the per-webapp SSL read as opposed to other SSL-related tools, but no when-to-use, when-not, or named alternative is given. Usage is inferable but not spelled out.

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

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

Annotations already declare destructive=true, non-idempotent, and openWorld, so the write semantics are covered structurally. The description adds real operational context beyond them: the web server is reloaded as a side effect, and the domain's DNS must already point at the server before issuing. It stops short of noting Let's Encrypt rate limits or re-issue behavior on an existing certificate, which are the main remaining operational risks.

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

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

Opens with a WRITE marker, then mode selection, then side effects and prerequisites, then the exclusion, then the endpoint paths. Three dense sentences with no filler; the highest-value routing information is front-loaded.

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

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

For an 8-parameter, 5-required mutation with no output schema and full schema coverage, the description supplies the mode logic, preconditions, and side effects an agent needs to call it correctly. It omits what a caller should expect on failure (e.g., DNS validation failure or rate limiting), which is the only notable gap.

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

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

Schema description coverage is 100%, so every parameter including the enums and the dns-01/external_api coupling is already documented in the schema. The description restates the domain_id/advanced-mode relationship but adds no format, syntax, or default detail the schema lacks, so the baseline 3 applies.

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

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

States a specific verb and resource ('issue and install a free Let's Encrypt certificate') and immediately splits the two operating modes (basic webapp SSL vs advanced per-domain SSL). It also distinguishes itself from sibling runcloud_get_ssl_method, which it names as a prerequisite lookup rather than a duplicate.

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

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

Explicit routing rules: basic SSL for the whole web application, advanced SSL for one domain via domain_id, and the constraint that advanced mode must already be configured (pointing to runcloud_get_ssl_method). It also names a negative case — custom certificates are not supported here — which steers the agent away from misusing this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine context beyond them: the status vocabulary (DEPLOYING, COMPLETED, FAILED) and the endpoint path, which hints at the underlying API. It does not discuss result ordering, pagination limits, or empty results.

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

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

One sentence front-loads the resource and the returned fields, and the trailing 'GET /atomic/{project}/deployments' is terse and informative about the backing endpoint. Slightly dense field enumeration, but nothing is wasted.

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

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

No output schema exists, but the description compensates by listing every returned field, including the status enum, which is exactly what an agent needs to interpret results. Pagination semantics and the project_id cross-reference live in the schema, so coverage is adequate overall.

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

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

Schema description coverage is 100%, so project_id, page and per_page are already fully documented (including 'Pass the previous reply's next_page'). The description contributes nothing about parameters, which is the expected baseline when the schema does the work.

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

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

Names the resource precisely ('deployments of an atomic project') and enumerates the returned fields, so it is clearly distinct from list-shaped siblings like runcloud_list_atomic_projects and from single-record fetches like runcloud_get_git_deployment. It does not explicitly name a sibling to route against, which keeps it short of a 5.

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

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

There is no when-to-use/when-not guidance or named alternative; the description never explains when an agent should list deployments versus checking a single deployment or project. Pagination is only implied via the schema, not stated as a usage consideration.

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

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

Annotations already cover readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is clear. The description adds useful behavioral context beyond annotations: it lists the exact fields returned and explicitly notes that webhook keys are not returned, which is security-relevant output scoping.

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

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

Extremely concise and front-loaded: the purpose and returned fields are in the first sentence, followed by two short factual sentences. No filler or redundancy.

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

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

For a simple read-only list tool with no output schema, the description adequately explains what is returned and explicitly excludes webhook keys. Pagination is fully covered by the input schema, and annotations cover safety and openness, leaving no critical gaps.

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

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

Schema description coverage is 100%, and the schema already documents both page and per_page parameters with defaults and limits. The description adds no parameter-level syntax or meaning beyond what the schema provides, so the baseline score of 3 applies.

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

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

States a specific verb and resource ('atomic Git deployment projects of the workspace') and enumerates the fields returned (name, provider, repository, branch, auto-deploy, success/failure counts, latest deployment). This distinguishes it from the sibling runcloud_list_atomic_deployments, which lists deployments rather than projects.

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

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

Provides no guidance on when to use this tool versus alternatives such as runcloud_list_atomic_deployments or runcloud_get_git_deployment. The description only states what it returns and the endpoint, leaving usage context entirely implicit.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description's real contribution is disclosing the response shape (label, coverage, storage, type, frequency, size, status) and the underlying endpoint GET /backups. That is genuinely useful given there is no output schema, though pagination behavior is left to the schema.

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

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

Three short sentences, information-dense and front-loaded: resource first, returned fields second, filters third. The opening fragment 'The backup instances of the workspace' is telegraphic but costs nothing in length.

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

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

For a read-only list tool with no output schema, the description does the minimum needed by enumerating return fields, and pagination is handled by the schema. The notable gap is that it never distinguishes this tool from runcloud_list_backup_snapshots, leaving real ambiguity in a 40-tool sibling set.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, which sets the baseline at 3. The description's filter mention (server, storage, status, name) maps onto server_id, storage, status and search but adds no syntax or format detail beyond what the schema already provides.

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

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

It names a specific verb (list) and resource (backup instances of the workspace) and even enumerates the fields returned, so an agent knows exactly what comes back. What it does not do is distinguish itself from the sibling runcloud_list_backup_snapshots, which an agent could easily confuse with this tool.

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

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

It states the available filters (server, storage, status, name), which implies the retrieval use case, but gives no when-to-use guidance, no prerequisites, and no exclusion pointing to runcloud_list_backup_snapshots as the alternative for snapshot data. Usage 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds only the returned field names; it says nothing about pagination behavior, ordering, or what an empty result means, and does not contradict the annotations.

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

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

Two compact fragments, with the resource scope front-loaded before the endpoint reference. Tight and appropriately sized, though the raw 'GET /backups/{id}/snapshots' line adds traceability rather than agent-facing meaning.

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

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

For a read-only list tool with no output schema, the description names the fields returned and the annotations cover the safety profile, with pagination handled in the schema. Only minor gaps remain (ordering, empty-result semantics).

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

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

Schema description coverage is 100%, so page, per_page and backup_id are already fully documented in the schema; the description adds no syntax, format, or default information beyond that. Baseline 3 applies.

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

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

States a specific verb+resource ('snapshots of one backup instance') and enumerates the returned fields, which separates it from runcloud_list_backups (which lists backup instances). It never names the sibling explicitly, so the differentiation is inferred 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.

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

The phrase 'of one backup instance' implies the backup_id prerequisite, and the schema points to runcloud_list_backups for obtaining it, but the description itself gives no when-to-use, when-not, or alternative-tool guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the endpoint path and the 'currently blocks' state; it discloses nothing about pagination, result volume, or auth requirements, leaving the behavioral bar minimally met.

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

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

Two short fragments with zero filler, and the resource description is front-loaded ahead of the endpoint. Every sentence earns its place.

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

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

For a single-parameter read-only list tool with annotations covering the safety profile and no output schema, the description is essentially sufficient. It could optionally describe the returned fields, but nothing required for correct invocation is missing.

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

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

Schema description coverage is 100%, so server_id is fully documented in the schema (referencing runcloud_list_servers). The description adds no parameter detail beyond the phrase 'on a server', so the baseline 3 applies.

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

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

States a specific verb (list) and resource (IPs Fail2Ban currently blocks on a server), with the underlying endpoint GET /servers/{id}/security/fail2ban/blockedip. It is clearly distinct from generic siblings like runcloud_list_firewall_rules by naming Fail2Ban, 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.

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

Usage is only implied (security inspection of blocked IPs on a server). There is no explicit when-to-use guidance and no mention of the closest sibling runcloud_list_firewall_rules, so the agent must infer the boundary between Fail2Ban blocks and firewall rules.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so the safety profile is covered. With no output schema, the description carries real weight by disclosing the returned fields (id, label, user, schedule, command, enabled) and the underlying endpoint.

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

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

Two compact sentences: the first front-loads what the tool returns, the second gives the downstream id usage and the endpoint. Every clause earns its place with no filler.

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

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

For a simple read-only list tool with full schema coverage, the description supplies the missing return-shape information that the absent output schema would otherwise provide. Pagination mechanics live in the schema, so nothing essential is missing.

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

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

Schema description coverage is 100%, with page, per_page and server_id all documented in the schema (including pagination chaining). The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource (the cron jobs of a server) and enumerates the returned fields, so the agent knows exactly what it gets back. It is clear enough to distinguish from most siblings, though it never explicitly contrasts itself with list tools like runcloud_list_servers.

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

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

The line 'The id is what runcloud_run_cronjob needs' implies the intended workflow (list first, then run), which is useful routing context. However, there is no explicit when-to-use/when-not guidance and no stated prerequisites or alternatives.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond that: the exact fields returned and the explicit 'No credentials' guarantee, plus the underlying GET endpoint. It omits pagination behavior, which the schema covers anyway.

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

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

Three telegraphic clauses with zero padding: what is returned, what is excluded, and the endpoint. Front-loaded with the resource, no sentence is wasted.

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

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

There is no output schema, so the description's field enumeration (id, name, collation) usefully compensates. Combined with schema-documented pagination and read-only annotations, an agent has what it needs; only the relationship to sibling list tools is unstated.

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

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

Schema description coverage is 100%, so all three parameters (page, per_page, server_id) are already documented in the schema, including paging semantics. 'On a server' restates the server_id requirement but adds no format or constraint detail, so the baseline of 3 applies.

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

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

The description names the resource (databases on a server) and enumerates the returned fields (id, name, collation), which combined with the title 'List databases' gives an unambiguous read-only list operation. It does not explicitly distinguish itself from the closest sibling runcloud_list_database_users, though 'No credentials' hints at the boundary.

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

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

There is no explicit when-to-use or when-not-to-use guidance, but the 'No credentials' qualifier implicitly routes an agent looking for DB usernames/passwords to runcloud_list_database_users instead. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds a valuable behavioral detail beyond that: 'Passwords are never returned,' which reassures the caller about output sensitivity.

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

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

Extremely terse, front-loaded, and free of filler; the endpoint path is included as a compact reference. It reads a bit telegraphically but wastes no words.

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

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

For a read-only list tool with no output schema and full annotation coverage, the description supplies the return fields and the notable security behavior, which is adequate. It could be slightly richer about pagination scope, but the schema handles that.

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

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

Schema description coverage is 100%, so page, per_page, and server_id are fully documented in the schema. The description adds nothing about parameter semantics, so the baseline 3 applies.

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

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

States a clear verb+resource ('list database users on a server') and even enumerates the returned fields (id, username). It implicitly distinguishes itself from runcloud_list_system_users and runcloud_list_databases, but never names those siblings as alternatives.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no prerequisites are stated. The reader must infer the 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.

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so the safety profile is covered. Since there is no output schema, the description adds real value by enumerating the exact fields the response exposes (type primary/alias, www, redirection, wildcard, DNS integration, status). It does not mention auth or pagination behavior, but pagination is handled in the schema.

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

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

Two compact sentences: the field list first, then the endpoint. Nothing is padded, and the return fields are front-loaded. It is terse to the point that the actual 'list' verb is missing, which is a minor structural weakness.

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

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

For a read-only list tool with full schema coverage and read-only/non-destructive annotations, the definition supplies what the structured fields don't: the returned field set and the resource path. No output schema exists, yet the description compensates by naming the response fields. Missing only explicit usage routing against siblings.

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

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

Schema description coverage is 100%, so both server_id/webapp_id and the page/per_page parameters are already documented in the schema. The description contributes only the path template '/servers/{id}/webapps/{webapp}/domains', which loosely signals the two required path params but adds no new semantics. Baseline 3 applies.

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

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

The description names the specific resource (domain names of a web application) and enumerates the fields returned (id, name, type, www, redirection, etc.), plus the exact endpoint GET /servers/{id}/webapps/{webapp}/domains. This makes the operation identifiable without opening the schema. It stops short of 5 because the verb 'list/get' is only implied by the endpoint, and no sibling (e.g. runcloud_get_domain_dns) is named to disambiguate.

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

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

There is no guidance on when to call this versus the similarly-named sibling runcloud_get_domain_dns, and no prerequisites or exclusions are stated. The reader must infer usage entirely from the noun phrase and endpoint path.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds the useful fact that this is a listing scoped to a single server and previews the returned fields (there is no output schema), but says nothing about pagination limits, permissions, or ordering beyond what the schema states.

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

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

Two compact fragments with zero padding: the resource/field list comes first, followed by the endpoint. It is front-loaded and easy to scan, though the raw endpoint string adds little for an agent that already has the tool binding.

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

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

For a simple 3-parameter read-only list tool with full schema coverage and no output schema, the field enumeration is the meaningful completion piece and it is present. Missing only optional depth such as pagination semantics in prose, which the schema already covers.

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

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

Schema description coverage is 100% – page, per_page (1-40) and server_id are all documented in the schema, including the next_page chaining hint. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description names a concrete resource (a server's firewall rules) and enumerates the attributes each rule carries (type global/rich, port, protocol, IP, action), so the agent knows exactly what it is fetching. It does not, however, distinguish itself from the closely related runcloud_list_blocked_ips sibling, leaving that routing decision to inference.

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

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

There is no when-to-use guidance, no prerequisites (e.g., the server must exist), and no mention of alternatives such as runcloud_list_blocked_ips for IP-level blocks. The API endpoint hint (GET /servers/{id}/security/firewalls) gives context but is not usage guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety and scope are covered. The description adds ordering ("newest first") which is useful, but omits pagination behavior, retention limits, and the fact that the schema references a next_page reply field. Beyond ordering, little behavioral value is added.

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

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

Two compact fragments, front-loaded with the resource and its scope. Efficient, though the bare endpoint string adds little for an agent that already has structured params.

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

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

For a simple paginated read tool with full schema coverage and safety annotations, the core is covered. But the lack of any sibling differentiation from runcloud_list_webapp_logs leaves a real ambiguity unresolved for an agent choosing between log sources.

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

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

Schema description coverage is 100%, so pagination params (page, per_page, server_id) are already fully documented including defaults, ranges, and cross-tool hints. The description adds nothing new; baseline 3 applies.

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

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

States a clear verb (list) and resource (server activity log), with a parenthetical clarifying exactly what the log contains. It distinguishes the resource from runcloud_list_webapp_logs implicitly, but never explicitly addresses the sibling log tool, so it falls short of a 5.

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

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

No when-to-use guidance, no conditions, and no routing to alternatives. Notably it never distinguishes itself from runcloud_list_webapp_logs, the obvious neighboring log tool. The agent must infer the server-vs-webapp split from the name alone.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds the underlying endpoint (GET /servers) and enumerates returned fields, which is useful, but says nothing about pagination behavior or result limits beyond what the schema implies.

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

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

A single front-loaded sentence with the action first and the field list after; no filler. The field enumeration is long but justified because no output schema exists to carry that information.

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

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

With no output schema, describing the returned fields is essential and done well; annotations cover the safety profile. Pagination is only implicitly covered (the schema mentions next_page), so an explicit note about paging through results would complete it.

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

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

Schema description coverage is 100% and both parameters (page, per_page) are fully documented in the schema, including the next_page handoff. The description adds no parameter-specific meaning, so the baseline 3 applies.

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

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

States a specific verb and resource ("List the servers") and scopes it to "connected to the workspace," then enumerates the returned fields. It is clearly distinguishable from read siblings like get_server_health or get_server_stats, though it never names the singular runcloud_get_server as the single-server alternative.

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

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

Usage is only implied: an agent can infer this is the enumeration entry point versus the get_* single-server tools, but no when-to-use, when-not-to-use, or explicit alternative is stated. No preconditions or filters (e.g. by provider/state) are mentioned.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value beyond annotations by disclosing the returned fields and the underlying GET endpoint, which matters since there is no output schema. It does not discuss pagination or rate limits, so not a 5.

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

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

Two tight sentences, front-loaded with the resource and its contents, then the key routing detail about realName, then the endpoint. Every clause carries information with no filler, though the trailing endpoint string is slightly redundant for an agent that only needs the tool name.

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

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

With no output schema, the description compensates by listing the returned service fields and the realName hand-off, which is the critical piece for chaining into runcloud_control_service. Combined with full annotation coverage, an agent has enough to call this correctly, missing only edge-case behavior like empty servers.

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

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

Schema description coverage is 100% and the single server_id parameter is documented in the schema as a RunCloud server id cross-referencing runcloud_list_servers. The description adds no parameter syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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

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

The description names a concrete resource and enumerates its contents (nginx, php-fpm, mariadb, redis, supervisor) plus the field shape (realName, running state, CPU, memory, version), so the agent knows exactly what comes back. It also links to the sibling runcloud_control_service via realName, aiding disambiguation. It lacks an explicit verb in the opening noun phrase, which keeps it 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.

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

It states a clear consumption path: use this to obtain realName, which runcloud_control_service requires, effectively telling the agent when this tool is the prerequisite step. There is no explicit when-not or alternative listing tool mentioned, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that this hits GET /servers/{id}/supervisors and lists the returned attributes, but says nothing about pagination behavior or freshness. With annotations carrying the safety semantics, a 3 is appropriate.

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

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

A single dense sentence that front-loads the resource and then the field list, plus a short endpoint reference. Every element earns its place, though the field enumeration could arguably be trimmed since there is no output schema to match it against.

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

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

For a read-only paginated list with full schema coverage and annotation-declared safety, the description is sufficient; it even compensates for the absent output schema by naming the returned fields. Only the lack of differentiation from the supervisor-status sibling leaves a small gap.

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

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

Schema description coverage is 100%: page, per_page and server_id all have explicit schema descriptions including the pagination chaining hint. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description names the concrete resource (supervisor/background worker jobs of a server) and enumerates the returned fields, so the agent knows exactly what it fetches. It is clearly a list operation for a given server. It doesn't explicitly contrast with the sibling runcloud_get_supervisor_status, which is the nearest alternative, so it stops short of a 5.

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

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

Usage is only implied: the resource is 'of a server' and the endpoint shows the server_id scoping, but there is no explicit when-to-use or when-not-to-use guidance. The close sibling runcloud_get_supervisor_status (status of a supervisor vs listing all supervisors) is not mentioned or differentiated.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description nonetheless adds real behavioral value by disclosing that deployment keys and passwords are never returned, which tells an agent the result set is deliberately redacted and unsuitable as a source of credentials.

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

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

Three short fragments covering contents, exclusions and endpoint; nothing is padded and the returned-fields list is front-loaded. Slightly telegraphic rather than a flowing sentence, but every clause earns its place.

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

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

For a read-only paginated list with a 100%-documented schema and annotations carrying the safety profile, the description supplies the missing pieces: the exact returned fields and the redaction guarantee. No output schema is needed since the return shape is described inline.

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

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

Schema description coverage is 100%, so page, per_page and server_id are already fully documented in the schema (including the next_page chaining hint). The description adds no parameter meaning beyond that, making the baseline 3 appropriate.

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

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

States the exact resource ('system (Linux) users on a server') and enumerates the returned fields (id, username, deletable), which distinguishes it from runcloud_list_database_users and other list siblings. The verb is only implied by the name/title rather than restated, but the scope is unambiguous.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative is named (e.g. vs runcloud_list_database_users). The only routing hint, 'see runcloud_list_servers' for server_id, lives in the schema rather than the description.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral trait beyond that — results are returned 'newest first' — but says nothing about how far back the log goes, retention, or pagination behavior beyond what the schema documents.

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

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

Two short sentences, front-loaded with what the log contains, followed by the endpoint path. Nothing is wasted, though the raw GET path is of limited use to an agent deciding whether to call the tool.

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

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

For a read-only, paginated list tool with fully documented parameters, the description covers what the resource is and the ordering of returns. The absence of an output schema means the shape of individual log entries is undocumented, but that is a minor gap for this tool class.

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

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

Schema description coverage is 100%: page, per_page, server_id and webapp_id all carry their own descriptions, including the cross-reference hints (see runcloud_list_servers / runcloud_list_webapps). The description contributes no parameter meaning beyond the path template, so the baseline 3 applies.

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

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

States a specific resource (a web application's activity log) and enumerates the event types it contains (settings changes, PHP version changes, deployments), which makes its scope concrete. It does not explicitly contrast itself with the nearest sibling, runcloud_list_server_logs, so an agent must infer the webapp-vs-server distinction from the name alone.

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

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

There is no explicit when-to-use statement, no prerequisites, and no routing to an alternative log tool. Usage is only implied by the enumerated log contents (e.g. auditing deploy or PHP version changes), which is the minimum viable level.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a genuine data-boundary disclosure ('Deployment webhook keys are not returned') and the underlying endpoint, which is useful context beyond the annotations, though it says nothing about pagination limits or rate behavior.

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

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

Three compact clauses: the action, the returned fields, and a boundary caveat, with the endpoint appended. Nothing is redundant and the purpose is front-loaded.

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

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

With no output schema, the description usefully enumerates the returned fields, which is the key information an agent would otherwise lack. Pagination and filtering are covered by the schema, so the definition is nearly complete; only the relationship to the single-app sibling is left implicit.

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

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

Schema description coverage is 100%, so page, per_page, search and server_id are already fully documented in the schema, including pagination chaining and the per_page range. The description adds nothing about parameter meaning, so the baseline of 3 applies.

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

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

The description states a specific verb and resource with scope ('List the web applications on a server') and enumerates the returned fields, so the agent knows exactly what comes back. It does not explicitly name the sibling it contrasts with (runcloud_get_webapp for a single app), so it falls just short of the top band.

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

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

Usage is implied by the purpose: use this to enumerate webapps on a server. There is no explicit when-to-use/when-not guidance and no mention of the paginated nature of the call or when to prefer a search over a full listing, so the guidance is only adequate.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds value beyond that by disclosing the expected response ('RunCloud answers with a message (\'pong\')') and the underlying endpoint (GET /ping), which is exactly the return-format context annotations don't provide.

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

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

A single tight sentence front-loads the purpose, then the return behavior and HTTP endpoint. No filler, no repetition of the title or schema.

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

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

For a zero-param health check with no output schema, the essential context is present: what it verifies and what a successful response looks like. It stops short of describing failure/error behavior, which would round it out fully.

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

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

The tool takes zero parameters and schema coverage is 100%, so the baseline is 4. There are no parameters whose semantics could be clarified, and the description correctly implies a no-argument call via the bare GET /ping reference.

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

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

States a specific verb+resource: 'Check that the API key works', which unambiguously identifies this as an auth/connectivity health-check, naturally distinct from the CRUD/listing siblings. It does not explicitly name a sibling, but the purpose is unmistakable for an agent.

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

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

Usage is implied rather than stated — the reader infers this is a preflight check before calling other tools or when auth errors occur, but there is no explicit 'use this when...' framing or condition. Adequate but leaves the when-to-invoke to inference.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false. The description adds real context beyond that: the restart effect on worker processes, the interruption of running processes, and the underlying POST endpoint, all consistent with the destructive hint.

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

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

Three tightly packed elements: a WRITE marker, one sentence covering action and impact, and the endpoint. Nothing is redundant and the impact warning is not buried.

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

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

For a two-parameter mutation with full annotation coverage and no output schema, the definition supplies the source of ids and the destructive side effect, which is most of what an agent needs. A brief note on failure/reversibility would make it fully complete.

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

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

Schema description coverage is 100%, so both server_id and supervisor_id are already documented, including their lookup tools. The description repeats the id-source hint but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (reload) and resource (one supervisor job) and clarifies the effect: worker processes restart. This clearly distinguishes it from siblings like runcloud_get_supervisor_status and runcloud_list_supervisors.

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

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

Names the prerequisite source for the required id (runcloud_list_supervisors) and warns that running processes are interrupted, which tells the agent when this is risky. It stops short of naming an explicit alternative or a when-not-to-use condition.

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

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

Beyond the annotations (destructiveHint=true, openWorldHint=true, idempotentHint=false), the description discloses concrete side effects: the cert is re-issued and the web server is reloaded, plus the prerequisite advanced SSL mode. It does not explain failure/rollback behavior, so it is strong but not exhaustive.

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

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

Front-loads the WRITE marker and core action, then conditions and endpoints. Dense but every clause carries information; the raw REST endpoint listing is slightly redundant for an agent but harmless.

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

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

For a 4-parameter mutation with no output schema, the description covers action, side effects, prerequisites, parameter routing, and the underlying endpoints. An agent has everything required to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds meaningful routing semantics by stating which parameter set applies to basic vs advanced SSL and why domain_id is conditionally needed. That is genuine value beyond the schema descriptions.

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

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

States a specific verb and resource: 'redeploy (renew) the Let's Encrypt certificate of a web application'. It clarifies the distinction from the sibling install tool by emphasizing re-issue/reload, so an agent knows this is not the initial issuance.

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

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

Explicitly branches usage: basic SSL passes ssl_id from runcloud_get_webapp_ssl, advanced per-domain SSL additionally requires domain_id and advanced SSL mode (verified via runcloud_get_ssl_method). It names the exact sibling tools that supply each input, leaving nothing to inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is largely covered. The description adds genuinely new context beyond that: the job's command executes on the server under its configured user, explaining the privilege/execution semantics and the 'WRITE' nature of the call.

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

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

Three tight sentences plus the raw endpoint, front-loaded with the 'WRITE' marker so the mutating nature is visible immediately. No filler.

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

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

For a two-parameter mutating tool with full annotation coverage and no output schema, the definition covers purpose, execution context, and id sourcing adequately. A note on what the call returns or how failures surface would close the remaining gap.

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

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

Schema description coverage is 100% with both parameters documented (server_id points to runcloud_list_servers, cronjob_id to runcloud_list_cronjobs). The description reinforces the id-sourcing but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: force-run exactly one cron job of one server, right now, outside its schedule. It also names runcloud_list_cronjobs as the source of the job id, which cleanly separates it from that read-only sibling.

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

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

The 'once, right now, outside its schedule' framing tells the agent this is an immediate manual trigger rather than a scheduling operation, and it points to runcloud_list_cronjobs for the required id. It stops short of explicit when-not guidance (e.g. don't use for scheduling or bulk runs), but context is clear.

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