demo.st

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

No annotations provided, so description carries full burden. It explains the availability check and domain format, but omits return value structure (boolean vs object), error behaviors (invalid format handling), or idempotency guarantees expected for a read operation.

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

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

Single compact sentence with an illustrative example. No filler words. Information density is optimal—every element serves the purpose of explaining what the tool does and how the parameter is used.

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?

Appropriate for a single-parameter read operation. The description covers the essential operation, though it could briefly indicate the return value type (availability status) given the lack of output schema. Sibling tools imply the workflow context adequately.

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

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

Schema coverage is 100%, but description adds valuable semantic context with the example 'my-site' → 'my-site.demo.st', clarifying how the input name maps to the full domain beyond the schema's character constraints.

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?

Specific verb ('Check') + resource (subdomain availability) + scope (on demo.st). The example clearly illustrates the input-to-domain mapping. Distinct from sibling 'reserve_subdomain' by using 'Check' vs 'reserve', clarifying this is read-only verification.

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 implied usage through naming contrast with 'reserve_subdomain' (check before reserving), but lacks explicit guidance like 'Use this before reserve_subdomain to verify availability' or 'Do not use this to claim a subdomain'.

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

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

With no annotations provided, the description carries full burden. It discloses the destructive nature ('Remove') and persistence of subdomain reservation, but lacks details on idempotency, error conditions (e.g., if no site exists), or whether content is recoverable. Adequate but not comprehensive for a destructive operation.

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

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

Two sentences with zero waste: first states the action, second states the critical side-effect distinguishing it from siblings. Every word earns its place in the 13-word description.

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

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

Appropriate for a zero-parameter tool with no output schema. Describes the operation and final resource state completely. Would benefit from mentioning error conditions or return value, but given the simplicity and sibling context, the description is sufficiently complete.

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

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

Zero parameters present. Per scoring rules, 0 params establishes a baseline of 4. The description appropriately requires no additional parameter clarification beyond the schema.

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

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

Specific verb 'Remove' with clear resource 'deployed site content' and scope 'from your subdomain'. The second sentence explicitly distinguishes from sibling 'release_subdomain' by stating the subdomain remains reserved, clearly differentiating its function from upload_site (adds content) and release_subdomain (unreserves).

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

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

Provides clear context for when to use versus alternatives through the explicit state outcome 'Subdomain remains reserved', implying this preserves the reservation while release_subdomain does not. Lacks explicit prerequisites (e.g., 'use when a site is currently deployed') but the context is sufficient for selection.

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

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

With no annotations provided, the description carries the full burden of disclosure. It successfully reveals the destructive nature ('Deletes') and scope (affects both reservation and any deployed site), but omits details about reversibility, authentication requirements, or immediate vs. delayed effects.

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

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

Two sentences with zero waste. The first sentence front-loads the primary action ('Release'), and the second sentence efficiently details the destructive consequences. Every word earns its place.

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

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

For a zero-parameter tool without output schema, the description adequately explains the operation and its consequences. It could be improved by mentioning that the user must currently hold the reservation, but given the tool's simplicity and sibling context, it is sufficiently complete.

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

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

The tool has zero parameters (empty schema), which per the evaluation rules establishes a baseline score of 4. No parameter documentation is required or expected.

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

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

The description uses specific verbs ('Release', 'Deletes') with clear resources ('subdomain', 'reservation', 'deployed site'). It distinguishes from sibling 'reserve_subdomain' (opposite action) and 'clear_site' by explicitly mentioning deletion of the 'reservation' itself, not just the site content.

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

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

The description implies usage through the word 'Release' and mentions the consequence of deleting the reservation, but lacks explicit guidance on when to use this versus 'clear_site' (which likely preserves the reservation) or prerequisites like requiring an existing reservation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates the account-level constraint (one per account), but fails to disclose other critical behavioral traits such as failure modes (what happens if the subdomain is taken), idempotency, permanence of the reservation, or side effects.

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

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

The description consists of two highly efficient sentences with no wasted words. The primary action is front-loaded in the first sentence, while the second sentence provides a critical constraint. Every word earns its place.

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

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

Given the tool's low complexity (single parameter, simple action) and complete schema coverage, the description provides the minimum viable information to invoke the tool. However, it lacks completeness regarding workflow integration (relationship to availability checking) and behavioral edge cases, leaving meaningful gaps.

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

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

The input schema has 100% description coverage for its single parameter, establishing a baseline score of 3. The description mentions 'subdomain' but adds no additional semantic meaning, validation rules, or format guidance 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?

The description clearly states the specific action ('Reserve') and resource ('subdomain') with scope ('for the logged-in account'). The constraint 'One subdomain per account' helps distinguish it from tools allowing multiple reservations. However, it lacks explicit differentiation from the sibling 'check_subdomain_availability' tool, which could confuse the agent about which to call first.

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

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

The description provides no explicit guidance on when to use this tool versus its siblings, particularly 'check_subdomain_availability' which likely should be called first. While the 'One subdomain per account' constraint implies a limitation, it does not constitute a usage guideline or workflow recommendation.

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

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

With no annotations, the description carries full burden. It transparently explains the three input modalities and their constraints (e.g., 'when MCP runs locally'), but omits critical side effect disclosure: whether uploading overwrites existing content, size limits, or success/failure 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?

Two sentences with zero waste. Front-loaded with core purpose, followed immediately by parameter selection guidance. Every word earns its place.

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

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

Adequate for the schema richness (100% coverage) but gaps remain for a mutation tool: no mention of content overwrite behavior, idempotency, or return values (though output schema is absent). Mention of 'reserved subdomain' implies prerequisite without explicit enforcement.

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%, establishing baseline 3. The description largely echoes schema content (e.g., 'base64-encoded zip', 'local path') without adding significant semantic depth regarding parameter interactions or validation rules beyond what the schema 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?

Specific verb ('Upload') with clear resource ('.zip as site content') and scope ('for your reserved subdomain'). Clearly distinguishes from subdomain lifecycle siblings (reserve/release/clear) by focusing on content deployment.

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

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

Provides excellent guidance on selecting between the three input parameters (recommending zip_base64 as 'Easiest for agents'), but lacks explicit workflow prerequisites (e.g., 'use after reserve_subdomain') or differentiation from clear_site.

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