dochost

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

Annotations indicate destructiveHint=true and readOnlyHint=false; the description adds valuable detail: 'permanently delete', 'link stops working immediately', 'slug is freed', and 'safe no-op'. This enhances transparency beyond annotations alone.

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, front-loaded with primary action and effect, followed by a crucial safety note. No superfluous words.

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

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

For a simple tool with one parameter and an output schema (not described), the description covers core behavior, effect, and idempotency. Ownership is implied by 'your pages'. Missing explicit prerequisites or output details are mitigated by low complexity.

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

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

Schema coverage is 0%, so the description must explain the parameter. It states 'by slug', adding meaning to the slug parameter. While adequate, it could be more explicit about ownership or slug scope.

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

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

The description clearly states the tool deletes a page by slug, distinguishing it from sibling tools like get_page (read), update_page (modify), or list_my_pages (list). The action and resource are specific.

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

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

The description explains the tool's effect and idempotency but does not explicitly advise when to use it versus siblings like update_page or publish. Guidance on avoiding deletion is 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 indicate readOnlyHint true, destructiveHint false, and description confirms it's a read operation. Describes returned fields (plan, quota, flags) without contradicting 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 sentences, front-loaded with key details, every word adds value. No waste.

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 zero parameters, annotations covering safety, and an output schema (not shown), the description is complete: it tells what the tool returns and when to use 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?

No parameters, and schema coverage is 100%. The description adds value by listing the specific data returned (plan, quota, entitlement flags) beyond the empty schema.

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

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

The description explicitly states the tool retrieves account information including plan, page-quota usage, and entitlement flags. It clearly distinguishes from sibling tools which deal with pages (delete_page, get_page, list_my_pages, publish, update_page).

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 guidance to call before publishing to know limits. Does not mention when not to use or alternatives, but the context is clear given the sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds significant behavioral context beyond annotations: it never returns the page body or the password, which are crucial safety constraints for an AI agent. This explains what the tool will not do, complementing the read-only annotation.

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

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

The description is a single, well-structured sentence that front-loads the action ('Get one of your pages by slug') and efficiently lists return fields and exclusions. No unnecessary words; every part adds value.

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

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

Given that the tool has an output schema (not shown), the description correctly omits return value details. It covers all essential aspects: operation, input (slug), output content (metadata fields), and critical exclusions (body, password). For a simple one-parameter read tool with good annotations, this is 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 input schema has one parameter 'slug' with no description (0% coverage). The description explains that the slug is used to identify which page to retrieve, adding meaning to the parameter. However, it does not elaborate on slug format or constraints (maxLength 64, minLength 1), which could affect invocation. With only one parameter, the baseline is 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?

The description clearly states 'Get one of your pages by slug' and lists what it returns (title, format, status, view/like counts, expiry, password-protected flag). It distinguishes itself from sibling tools like delete_page, publish, update_page (mutations) and list_my_pages (list all pages). The exclusion of page body and password further clarifies its specific purpose.

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

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

The description explicitly states what the tool returns and what it does NOT return (body and password), giving clear usage context. It implies that if you need the page body, you should use a different tool, but does not name an alternative. The sibling tools provide context, but explicit when-not-to-use guidance would earn a 5.

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 indicate readOnlyHint=true and destructiveHint=false. The description adds value by mentioning pagination, compact records (no page bodies), and ordering. It does not contradict 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 sentences with no wasted words. Key information (listing user's pages, newest first, paginated, compact records) 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?

The description clarifies the scope ('you have published'), pagination behavior, and return format. An output schema exists to cover return structure. The sibling context is adequate. Minor lack: no mention of authentication or that it only shows the current user's pages beyond the phrase 'you have published'.

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

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

Schema coverage is 0% (no parameter descriptions). The description mentions pagination but does not explain what 'limit' and 'offset' mean. It adds minimal semantic value beyond the schema's type 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?

The description clearly states the verb 'list' and resource 'pages you have published to dochost', with ordering 'newest first'. It distinguishes from siblings like 'get_page' (single page) and 'delete_page' (delete operation).

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

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

The description implies usage for the user's own published pages via 'you have published', but does not explicitly state when to use this tool versus alternatives or mention any prerequisites. No exclusions or alternative tool recommendations are provided.

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

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

Annotations indicate write operation (readOnlyHint=false). Description adds context about plan entitlements but does not detail side effects or idempotency. No contradiction with 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 sentences, each serving a clear purpose. No fluff.

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

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

Output schema exists, so return values are covered. However, does not explicitly differentiate from update_page for creating vs updating. Still sufficient for context.

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

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

Schema coverage is 0%. Description mentions password, custom slug, and branding but does not explain all parameters like 'public' or the 'format' enum. Lacks clarity on parameter usage.

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?

Clearly states the verb 'Publish' and the resource 'dochost page', and mentions the output 'shareable URL'. Differentiates from sibling tools like delete_page, update_page, etc.

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?

Mentions plan restrictions but does not explicitly state when to use vs alternatives like update_page. No when-not 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 indicate destructiveHint=true and readOnlyHint=false, and the description adds value by specifying what stays the same (URL, counts, expiry) and what changes (body, format, title). It also clarifies that resending identical content is a no-op, which is useful behavioral context beyond 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?

The description is only three sentences, front-loaded with the core action, and every sentence adds useful information. There is no redundancy or fluff.

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

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

Given that the tool has four parameters, annotations, and an output schema, the description covers the key behavioral aspects (what changes, what stays, no-op behavior). It could mention that the page must exist (implied by 'your pages') or error conditions, but it is largely complete for the typical usage.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions that body, format, and title can change, and indirectly implies slug is required as a page identifier. However, it does not describe the constraints or meaning of each parameter beyond what the schema provides, so it adds limited but some value.

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

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

The description clearly states 'Replace the content of one of your pages in place', which uses a specific verb and resource. It also explicitly differentiates from siblings by noting that URL, view/like counts, and expiry remain unchanged, and that it alters only body, format, and title. This distinguishes it from delete, get, list, and publish tools.

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 the tool is for updating existing pages by replacing content, but it does not explicitly state when to use it versus alternatives like delete or publish. It lacks explicit 'when not to use' or comparative guidance against siblings.

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