Yeetit - POST HTML, get a URL. No account needed.

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

With no annotations provided, the description carries full behavioral disclosure burden and excels: it states immediate effects ('immediately inaccessible'), irreversibility ('deletion cannot be undone'), authentication requirements ('Requires authentication via edit_key or api_key'), and safety mechanisms ('requires confirm: true'). It fully discloses the destructive nature and safety constraints.

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

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

Four sentences with zero waste: (1) core action + permanence, (2) immediate effect + auth requirements, (3) usage context, (4) user confirmation + irreversibility warning. Information is front-loaded with the critical 'permanently delete' statement, and 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 destructive operation with 100% schema coverage and no output schema, the description is comprehensive. It covers the destructive nature, immediate consequences, authentication requirements, safety mechanisms, and human-in-the-loop prerequisites. No gaps remain that would prevent safe and correct invocation.

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

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

Schema coverage is 100%, establishing a baseline of 3. The description adds value by clarifying the relationship between edit_key and api_key as alternative authentication methods ('via edit_key or api_key') and emphasizing that confirm must be 'true' as a safety mechanism. It effectively groups the optional auth parameters as mutually exclusive requirements.

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

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

The description opens with 'Permanently delete a published website' — a specific verb + resource combination. It clearly distinguishes from siblings (get_website_status, publish_website, update_website) by emphasizing 'permanently' and 'delete' versus read, create, or update operations.

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

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

Explicitly states when to use ('when a user explicitly asks you to remove or delete a site') and provides critical prerequisites ('Always confirm with the user before calling this tool'). It effectively signals this is for explicit removal requests only, contrasting with update_website for modifications.

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 behavioral burden. It effectively discloses 'No authentication required — this is public information' and lists the specific data returned. It could improve by mentioning error behavior (e.g., what happens if the slug doesn't exist) or whether unpublished sites are accessible.

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 with zero waste. The first establishes scope and return values, the second discloses auth requirements, and the third provides usage guidance. Information is front-loaded and 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 simple single-parameter read operation with no output schema, the description adequately compensates by listing return fields and auth requirements. Minor gap: does not specify behavior for invalid/expired slugs or unpublished sites, but otherwise complete for the tool's complexity.

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

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

Schema description coverage is 100% ('The slug of the site to check (e.g. "hello-world-k3m")'), so the description appropriately does not attempt to redundanty document the parameter. The baseline score of 3 is correct when the schema fully carries the semantic load.

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

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

The description uses a specific verb ('Get') with a clear resource ('published website') and enumerates specific returned fields (title, view count, size, expiry date, claimed status). It effectively distinguishes from siblings (delete_website, publish_website, update_website) by positioning this as a read-only status check vs. mutation operations.

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 explicit use cases: 'check if a site is still live,' 'see how many views it has gotten,' and 'check when it expires.' While it doesn't explicitly contrast with sibling tools (e.g., 'use this instead of update_website when reading'), the usage context is clear and actionable.

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?

Since no annotations exist, description carries full burden and excels: discloses expiration (24 hours), auth model (none required initially, API key for subsequent updates), security-critical handling (store edit_key silently), side effects (creates public URL), and recovery procedures. Covers lifecycle from publish through expiration and ownership transfer.

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

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

Every sentence serves distinct purpose: capability, auth, output format, lifecycle constraint, trigger condition, feature support, and critical post-invocation instructions (edit_key security). Well-structured with 'IMPORTANT' flagging security-critical workflow steps. Length is justified by complexity and lack of annotations/output 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?

Comprehensive despite missing output schema and annotations. Documents all outputs (public URL, claim URL, edit_key), their semantics, and handling instructions. Explains size limits (referenced in schema but contextualized), expiration mechanics, and fallback workflows. Sufficient for correct invocation and result handling.

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

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

With 100% schema coverage, baseline is 3. Description adds value by explaining high-level patterns not explicit in schema: multi-page site architecture (/{slug}/{pagename}) and the bundling concept for assets, complementing the technical schema definitions without redundancy.

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?

Opens with specific verb+resource ('Publish HTML content to a live URL instantly') and clearly distinguishes from siblings (delete_website, update_website) by focusing on initial deployment vs. lifecycle management. Lists concrete use cases (landing page, invitation, portfolio) to disambiguate trigger conditions.

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

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

Explicitly states when to use ('when a user asks you to build, create, or deploy a website...'). Implicitly guides toward sibling tools by explaining the edit_key workflow for updates and mentioning that lost keys require claiming (via claim URL) before using API credentials, effectively routing to update_website.

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

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

No annotations provided, so description carries full burden. It excellently discloses authentication requirements (edit_key vs api_key sources), emphasizes destructive replacement semantics ('full replacement, not a patch'), and warns about mandatory auth. Missing only rate limits or error behavior details.

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?

Six sentences, zero waste. Front-loaded with core action, followed by auth requirements, critical behavioral warning (full replacement), usage context, and mandatory auth emphasis. Every sentence adds value beyond structured data.

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 mutation tool with no annotations and 100% schema coverage, description successfully covers authentication sources, replacement semantics, and usage triggers. Only lacks return value documentation, but no output schema exists to guide this.

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

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

Schema has 100% coverage (baseline 3). Description adds valuable provenance context absent from schema: edit_key comes 'from the original publish response' while api_key comes 'from the user's dashboard after claiming the site,' helping the agent select correct credentials.

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

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

Description opens with specific verb-resource pair ('Update an existing published website') and distinguishes from publish_website sibling by emphasizing 'existing' and 'previously published,' clearly signaling this is for modifications rather than initial creation.

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 explicit positive guidance ('Use this when a user asks you to modify, edit, or change a site you previously published'), implicitly distinguishing from publish_website for new sites. However, it does not explicitly name the sibling alternative or state 'do not use for new sites.'

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