Create Web Page

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

Annotations already show readOnlyHint=true and destructiveHint=false. The description adds behavioral context by stating no editToken is required, which is useful beyond annotations. No contradictions.

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 concise sentences, front-loaded with the core action and usage context. No unnecessary 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?

Given the tool is simple (one required parameter, output schema exists), the description sufficiently covers when and how to use it, and the annotations cover safety. No 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 sole parameter pageId is described in the schema as 'The claimed pageId to manage.' The description does not add extra meaning beyond the schema, and schema coverage is 100%, so baseline score of 3 is 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?

The description clearly states 'Read a claimed account page' indicating a specific verb and resource. It distinguishes from siblings like page.get and page.claim by noting it does not require an editToken and is for managing a durable website.

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 a clear usage context: after OAuth when the user wants to manage a durable website. It implies the tool is for read-only management, but does not explicitly state when not to use or name alternative 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 and destructiveHint=false. The description adds value by specifying the OAuth requirement and the account management context, which are behavioral traits not covered by 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 concise sentences with no wasted words. The first sentence states the core purpose, and the second adds essential context. 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?

With a single optional parameter and an output schema present, the description adequately covers purpose, auth, and usage domain. No significant gaps remain for a read-only listing tool.

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% coverage and the parameter 'limit' has a clear description. The tool description adds no additional parameter information beyond what the schema provides, justifying the baseline score.

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 lists 'claimed' pages for the authenticated account, using specific verb+resource. The title and description align perfectly. With no other page listing sibling tools, there's no ambiguity.

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 mentions OAuth requirement and clarifies the tool is for account management, not first-time demo creation. While it doesn't name alternatives, the context signals and sibling names implicitly guide usage.

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 behavioral context about the return value (account context with authentication and demo info), which is valuable 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?

Two short, clear sentences. The first sentence states the action, the second explains when to use it. No unnecessary 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 tool with no parameters and an output schema, the description fully explains the purpose and usage scenario. It is complete and leaves no 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?

No parameters exist, so schema coverage is 100%. The description has no need to provide parameter details. Baseline 4 for zero parameters is 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?

The description clearly states the tool returns the current account context and specifies checking authentication or demo status. It distinguishes from sibling tools like account.page.manage by focusing on identity.

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 says to use it for checking authentication or demo status. While no when-not or alternatives are given, the context is clear and sufficient for this simple 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?

Beyond annotations (readOnlyHint false, destructiveHint false), the description adds vital behavioral detail: server generates block id, for published pages it saves only an unpublished revision, and it explicitly warns against calling page.publish/unpublish in the same turn. 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?

The description is long but well-structured: action first, then allowed types (though redundant with schema), then critical workflow instructions. It could be more concise by omitting the type list, but the information is clearly front-loaded and organized.

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 complexity (13 block types, oneOf schema, publish workflow), the description covers all essential aspects: action, constraints, server-generated id, draft behavior, workflow instructions, and nextSteps. Output schema exists, so not explaining return values is acceptable.

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 schema coverage at 33%, the description adds minimal parameter-specific meaning. It repeats that block must match one of 13 types with strict props (already in schema) but does not explain pageId, editToken, or compensate for missing schema descriptions. The block object schema itself is detailed, but the description fails to add value for the less-documented parameters.

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 'Append a new content block to a link-in-bio page.' It specifies the action (append), the resource (content block to a page), and distinguishes from siblings like block.delete, block.update, page.publish by providing explicit workflow instructions not to call publish/unpublish in the same turn.

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 tells when to use this tool (adding a block) and provides crucial guidance: for published pages it saves an unpublished revision, do not call page.publish in the same turn, and wait for user explicit request. It does not, however, compare with block.update or mention prerequisites like the page must exist.

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 destructiveHint: true, but the description adds critical behavioral context: 'For already-published pages, this saves an unpublished latest revision only.' It also warns about not publishing or unpublishing, which goes beyond 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?

The description is appropriately front-loaded with the main action and uses multiple sentences for necessary warnings. While lengthy, nearly every sentence earns its place, though some repetition could be trimmed.

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 complexity (3 params, no enums, has output schema), the description provides essential context about behavior on published pages and critical interaction rules. It is comprehensive enough for safe usage, but could elaborate on the return value or error conditions.

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 0% schema description coverage, the description partially compensates by referencing 'blockId' and implying 'pageId' via 'page.get'. However, it does not explain the 'editToken' parameter. The behavioral context adds value, but parameter semantics are incomplete.

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's purpose: 'Delete one block by stable blockId.' It uses a specific verb and resource, distinguishing it from sibling tools like block.add, block.reorder, block.update.

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 explicit guidance on when to use the tool ('Use page.get first if unsure which id to remove') and when not to use it ('Do not call page.publish in the same assistant turn... Do NOT call page.unpublish either'). It also instructs the agent to wait for user confirmation before publishing.

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 annotations (which note mutation and non-destructive), the description adds key behavior: for published pages it saves an unpublished latest revision only. It also advises on not publishing immediately, which prevents unintended live updates.

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 concise with three sentences, each adding value. The core action is front-loaded, followed by behavioral nuance and instructions. No unnecessary 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?

Output schema exists, so return values need no explanation. However, parameter semantics are missing, and edge cases (invalid blockId, pageId) are not addressed. The behavioral notes are helpful, but the tool lacks completeness in parameter documentation.

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 0% schema description coverage, the description adds no parameter details. Parameter names (pageId, blockId, toIndex) are partially self-explanatory, but editToken is ambiguous and unexplained. This is a significant gap.

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 action ('Move a block to a new zero-based index') and the resource ('page main slot'). It distinguishes from sibling tools like block.add, block.delete, and block.update by specifying reordering rather than adding, deleting, or modifying properties.

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 strong process guidance about not calling page.publish or page.unpublish in the same turn, which helps the agent manage state. However, it lacks explicit 'when to use' vs 'when not to use' compared to siblings; the context 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?

The description discloses key behaviors: it only saves an unpublished latest revision for published pages, validates props and types against strict schema, and implies a write operation (non-read-only, non-destructive). This adds context beyond the annotations (readOnlyHint=false, destructiveHint=false) and is consistent with them.

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 thorough but well-structured, front-loading the core action and then adding usage guidelines. Every sentence contributes useful information, though it could be slightly more concise without losing clarity.

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 complexity (many block types, validation, publishing workflow), the description covers essential aspects: main action, effect on published pages, validation, and workflow cautions. It does not detail each block type (handled by schema) but is sufficiently complete for agent use.

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 schema itself provides detailed descriptions for each parameter (100% coverage). The description adds value by explaining the merge behavior ('merged into existing props') and validation, which enhances the schema's meaning but is not necessary for every parameter.

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 patches a content block by stable blockId, specifying it is a partial update (props patch) and/or type change. This distinguishes it from sibling tools like block.add (add new block) and block.delete.

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 explicit when-to-use and when-not-to-use guidance: it explains that for published pages it saves an unpublished revision, instructs not to call page.publish in the same turn, and advises against calling page.unpublish. It also differentiates from page.publish and page.unpublish clearly.

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 clear. Description adds useful context that v1 only includes link_in_bio, informing the agent about the limited set of possible results. For a zero-parameter read-only tool, this is sufficient.

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 concise sentences with no wasted words. Front-loaded with clear purpose, then adds version-specific detail. Excellent structure.

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, read-only nature, and presence of an output schema, the description is complete. It clearly communicates the tool's function and limitations. No 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?

No parameters; schema coverage is 100% by default. Description adds value by stating the scope of layouts (link_in_bio only), providing context beyond the schema. Baseline for 0 parameters is 4.

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 clearly states it lists supported page layouts, with specific verb 'List' and resource 'page layouts'. It also specifies the current version scope 'v1 ships link_in_bio only', which distinguishes it from other list tools among 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?

No explicit guidance on when to use this tool versus alternatives like account.pages.list or presets.list. However, the context is clear enough for a simple listing tool with no parameters.

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=false and destructiveHint=false. The description adds context that claiming transfers ownership to the authenticated account, which is a behavioral trait beyond the annotations. It doesn't mention any edge cases like expiration, but overall it adds value.

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 two sentences: the first states the action and inputs, the second provides usage guidance. No extraneous words, perfectly front-loaded, 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 simple tool with 2 parameters, 100% schema coverage, annotations, and an output schema, the description is sufficient. It explains the purpose and when to use. It could mention the outcome of claiming (e.g., page becomes editable via other tools), but given the output schema likely covers that, it's acceptable.

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% with descriptions for both pageId and editToken. The description reinforces that these are 'returned by page.create,' which adds context but doesn't provide substantial new semantics beyond the schema. Given high coverage, a score of 4 is 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?

The description clearly states the action (claim), the resource (anonymous demo page), and the inputs (pageId and editToken from page.create). It distinguishes from sibling tools like page.create and page.get by specifying the context of 'keep or manage permanently'.

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 says 'Use this only when the user wants to keep or manage the website permanently,' providing clear when-to-use guidance. It could have elaborated on when not to use (e.g., if the page is not wanted), but the instruction is sufficient.

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 annotations (readOnlyHint=false, destructiveHint=false), the description reveals that the tool creates a draft only, does not return a publish action, and warns that anonymous demo pages expire. It also advises not to invent content, adding behavioral context.

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

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

The description is a single paragraph that packs necessary information without redundancy. It is moderately concise but could be broken into shorter sentences for easier scanning.

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 complexity (9 params, output schema exists), the description covers creation workflow, post-actions, and expiration. It is complete for an agent to select and invoke the tool 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?

With 89% schema coverage, the description adds value by explaining the 'auto' preset inference from businessType/style and the roles of title/displayName. However, it does not detail all nine parameters, but the schema already covers them well.

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 creates a 'hosted link-in-bio page draft from a style preset', specifying the action and resource. It distinguishes from siblings like 'page.publish' and 'page.create_from_brief' by focusing on draft creation from presets.

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 explicit when-to-use guidance: it warns against calling 'page.publish' in the same turn unless the user explicitly asks to publish. It also instructs to use 'block.update' for content and to show the preview URL after creation.

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?

Discloses that draft previews are customer-facing, planning fields are not rendered, and pages expire unless claimed. Aligns with annotations (readOnlyHint=false implying creation) and adds critical behavioral context.

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

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

The description is comprehensive but somewhat lengthy; however, every sentence contributes useful guidance, and it is front-loaded with the core purpose. Minor room for tightening, but overall efficient.

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 complexity (29 params, nested objects, output schema exists), the description covers creation behavior, prerequisites, output elements, and post-call steps thoroughly. No gaps left for the agent.

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 high (83%), but the description adds value by clarifying which parameters are planning-only vs public copy, and by explaining how to use fields like fallbackLeadForm and publicSections. This goes beyond schema definitions.

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 it creates a hosted landing page draft from a structured brief, listing inputs and outputs. It distinguishes from sibling tools like page.publish and page.create by emphasizing the draft-only nature.

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 not to call page.publish in the same turn and advises asking for missing CTA destinations. Provides clear guidance on handling sparse briefs and avoiding invented content.

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 mark it as read-only and non-destructive. The description adds context about reading 'latest content JSON' and the special case for anonymous demo pages with editToken. No contradictions.

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, no redundant words. Front-loaded with the core action and key special case. Every sentence 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 the tool's simplicity (2 params, read-only), the description covers essential aspects: what is read, content JSON inclusion, and demo page handling. Output schema exists, so return values are covered elsewhere.

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 description must compensate. It mentions pageId implicitly and editToken explicitly, explaining its use for anonymous demo pages. However, it does not detail format or constraints beyond 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 clearly states the tool reads a landing page draft and includes its latest content JSON, with a specific mention of anonymous demo pages requiring editToken. This distinguishes it from sibling tools like page.create or page.publish.

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 use for reading drafts but does not explicitly state when to use versus alternatives like account.pages.list for listing or page.preview for previewing. No 'when-not' or alternative tool names 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?

The description adds behavioral context beyond annotations: it explains that the tool creates an unpublished draft for already-published pages and provides workflow guardrails. There is no contradiction with the annotations (readOnlyHint=false, destructiveHint=false).

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 relatively long but every sentence adds necessary context. It is front-loaded with the action and then provides usage guidelines. Slightly verbose but justified by complexity; could be tightened very slightly.

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 complexity (6 params, output schema exists), the description covers all essential aspects: what the tool does, parameter optionality, behavioral side effects, and correct sequencing. It is complete for a mutation tool with output schema.

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 67% (4 of 6 params described). The description reiterates the purpose of the four described fields but does not add meaning for pageId or editToken. The instruction 'Use only the fields you want to change' clarifies optionality, but overall minimal additive value beyond 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 action 'Update the link-in-bio page header' and lists the specific fields (displayName, bio, verified checkmark, QR display). It clearly distinguishes from sibling tools like page.meta.update and page.publish.

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 detailed when-to-use and when-not-to-use instructions: it saves an unpublished revision for published pages, forbids calling page.publish in the same turn, and instructs the assistant to wait for explicit user confirmation before publishing or unpublishing.

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 readOnlyHint=true, destructiveHint=false. Description reinforces by stating 'Does not create a page' and discloses the return of guided questions. No contradictions. Adds 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?

Four sentences, no fluff. Front-loaded with purpose, then guidance and exclusions. 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?

Given 7 parameters fully described in schema, an existing output schema, and annotations, the description provides sufficient context. It explains the tool's role in the creation flow, its non-destructive nature, and when to use alternatives.

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% with good descriptions. Description adds value by listing key collected fields (businessName, sourceUrl, primaryGoal, locale) and providing usage constraints (e.g., 'Only include if user already provided' for businessName, caution about protected platforms for sourceUrl).

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?

Clear verb+resource: 'minimal intake for first-page creation'. Distinguishes from sibling page.onboarding.start by contrasting features. Explicitly states returns guided questions and does not create a 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?

Explicit when-to-use and when-not: 'For a richer onboarding... use page.onboarding.start'. Also gives operational guidance: 'Call once per creation request; do not repeat if the user has already provided a source URL.'

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 show readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds critical context: for published pages, it creates an unpublished draft/revision, and it explicitly instructs not to call publish/unpublish. This goes beyond annotations to disclose behavior and workflow restrictions.

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 front-loaded with the core purpose and then provides detailed behavioral instructions. It is not overly verbose; each sentence serves a purpose. Slightly longer due to necessary workflow guidance, but still well-structured.

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 complexity of publishing workflows and the presence of sibling tools like page.publish and page.unpublish, the description is remarkably complete. It explains the impact on published vs. unpublished pages, the draft revision behavior, and the recommended interaction flow. An output schema exists, so return values are not needed.

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 67% (4 of 6 parameters have descriptions). The description restates the updateable fields (title, slug, seoTitle, seoDescription) but does not add extra meaning for pageId or editToken. It does not clarify formatting or constraints 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?

The description clearly states it updates internal page title, URL slug, and SEO title/description. It differentiates from sibling tools like page.publish and page.unpublish by focusing on the 'update' action, making the tool's purpose unambiguous.

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

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

The description provides explicit instructions: for already-published pages, it only saves an unpublished latest revision. It warns not to call page.publish in the same turn, to stop and inform the user, and to wait for explicit user request to publish. It also advises against calling page.unpublish. This is exemplary 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 indicate readOnlyHint=true, destructiveHint=false, and the description reinforces this by stating the tool returns selections 'without creating a page'. It adds value beyond annotations by detailing the return types and the workflow, which is crucial for an AI agent to understand the tool's role.

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 extremely concise (two sentences) and front-loaded with the tool's purpose. Every sentence adds value, and the structure flows logically from purpose to return items to workflow steps.

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 onboarding start tool with 3 optional parameters and an output schema, the description is generally complete: it explains what the tool does, what it returns, and how to proceed. Minor omission: it does not mention that locale is optional or default behavior, but the schema handles that partially.

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 only 33% (locale has description, but originalRequest and suggestedSelection subfields are partially documented). The description does not mention any parameters or their meanings, leaving significant gaps for an agent to understand how to use the parameters correctly.

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 clearly identifies the tool as the default first tool for first-page creation, listing specific outputs (category choices, layout options, etc.) and distinguishing it from siblings by outlining the workflow to page.onboarding.update and page.create_from_brief.

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?

Description explicitly states it is the default first tool for first-page creation and outlines the subsequent steps (pass to page.onboarding.update, then createFromBriefHints with page.create_from_brief), providing clear context for use. However, it does not mention any exclusions or alternative tools for this specific onboarding step.

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 readOnlyHint=true, consistent with 'validate and return'. The description adds that it returns the next compact UI/prompt and remaining quality checklist, enriching behavioral understanding. No contradictions.

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 sentence that concisely conveys purpose and parameters, though it is somewhat dense with many listed fields. No wasted 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?

Given the complexity of 4 parameters with nested objects and no required params, the description covers the tool's role in the onboarding flow and its output (next UI + quality checklist). It omits explanation of the output schema, but an output schema exists. Adequate for effective use.

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%, but the description lists the fields the user can provide (category/subcategory, template style, palette, etc.), adding meaning beyond the schema's property names and types. For example, it explains that knownFields includes name, description, image availability, etc. However, stepId enum values are not explained.

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 validates onboarding selections and returns the next UI prompt and quality checklist. It specifies the context: use after page.onboarding.start, and lists the user choices covered (category, template style, palette, etc.). This distinguishes it from siblings like page.onboarding.start and page.create.

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 says 'Use after page.onboarding.start', providing clear when-to-use context. It does not mention alternatives or when not to use, but the sibling context makes it clear this is part of the onboarding flow.

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 it is read-only and non-destructive. The description adds no further behavioral details beyond the basic purpose, but 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?

The description is a single sentence with zero wasted words. It is appropriately front-loaded and easily parsed.

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 presence of an output schema and simple parameters, the description is adequate. It could mention that the URL may change over time, but overall it is complete for its simplicity.

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% with clear descriptions for both parameters. The tool description adds no additional meaning 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 action ('Return') and the resource ('the current preview URL for a page'), using a specific verb and resource that distinguishes it from sibling tools like page.get or page.publish.

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 does not explicitly state when to use this tool over alternatives, though its purpose is self-evident. No exclusions or context cues 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 provide mutation and non-destructive status. Description adds context about publishing revision and returning nextSteps. However, it does not detail potential side effects (e.g., notifications) implied by openWorldHint.

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-loaded with core purpose, then usage rules, special case, and output instruction. Three sentences, no 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?

Covers when to use, parameter guidance, and output handling. Lacks explanation of what 'publishing' means for page state (e.g., making it live), but sibling tools and output schema provide some 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 100%. Description adds value: clarifies editToken as required for anonymous pages and references page.create as source for both parameters.

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 action ('publish the latest page revision') and specifies when to call it (explicit user request). It distinguishes from siblings like page.create by advising against immediate automatic publishing.

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 instructions on when to call (only on explicit publish/live/share request) and when not to (not automatically after create). Also provides condition for anonymous demo pages and output handling (share nextSteps).

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?

Discloses that for published pages, it only saves an unpublished latest revision. Warns against calling page.publish or page.unpublish. Adds context beyond annotations (which only indicate non-readOnly, non-destructive).

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 moderately long but each sentence serves a purpose: core action, constraints, workflow, and warnings. Front-loaded with the main action. Could be slightly trimmed but overall well-structured.

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 complexity (nested objects, many enum fields, sibling tools), the description covers purpose, usage, behavioral traits, and links to presets. Output schema exists, so return values need no explanation. Complete for agent decision-making.

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 description states 'partial theme patch' and 'provide only fields you want to change', which adds meaning beyond the schema's per-field descriptions. Schema coverage is 33% but nested objects have inline descriptions; description compensates with usage context.

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 it applies a partial theme patch, distinguishing it from complete restyle via presets.list. The title 'Update Page Theme' and the verb 'Apply' with 'partial theme patch' gives a specific action on a resource.

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 provides when to use (partial updates) and when not to (use presets.list for full restyle). Includes workflow guidance: not to call page.publish in same turn, and to wait for user confirmation. Clearly distinguishes from siblings.

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 mark destructiveHint as true, and the description adds valuable context by noting that draft and revision history are retained, reducing the perceived destructiveness. It does not cover permissions or reversibility, but the output schema may provide return value 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?

The description is a single sentence that is concise and front-loaded with the main action. It communicates the essential function without superfluous words, though it could be slightly improved by adding brief parameter hints without sacrificing conciseness.

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 covers the primary effect (unpublishing while preserving history) but lacks details on prerequisites (e.g., page must be published), error conditions, or state changes. Given the presence of an output schema and the relative simplicity of the tool, it is minimally 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 0% parameter description coverage, and the tool description does not explain the purpose of 'pageId' or 'editToken'. The agent receives no semantic guidance for these parameters, which is a significant gap.

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 'Remove' and the resource 'published landing page', and it distinguishes from sibling tool 'page.publish' by indicating the reverse action. It also specifies what is preserved (draft and revision history), making the purpose 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?

The description explicitly tells when to use the tool (when needing to remove public availability of a published page while keeping its content). However, it does not explicitly state when not to use it or provide comparisons with alternatives like page.delete, but the context from sibling tools implies the proper usage.

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 read-only, non-destructive. Description adds that presets are curated and limited to 8, which provides useful context beyond annotations. No contradictions.

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 concise sentences, front-loaded with action, no unnecessary words. 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?

With no parameters and an output schema present, the description adequately covers purpose, scope (link-in-bio), and count. No additional context needed.

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, so baseline 4 applies. Schema coverage is 100%, description adds no param info but none needed.

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 'List' and the resource 'curated style presets', specifies count (8) and content (theme + starter blocks) for link-in-bio. Distinguishes from siblings like layouts.list.

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 says when to use: to offer user choice or confirm auto-selection. Does not list alternatives or when not to use, but context is sufficiently clear.

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 and destructiveHint, so safety is covered. The description adds important behavioral context: only public pages, no bypassing login/CAPTCHA/paywalls, and specifies return content. This goes beyond annotations to inform the agent of limitations.

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 concise sentences: main action, restrictions, returns. No redundant information, every sentence adds value. Front-loaded with the core purpose.

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 has only 2 params and an output schema (not shown), the description is complete: explains purpose, limitations, output format, and ties to a sibling tool (page.create_from_brief). No 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 covers 100% of parameters with descriptions. The description adds no additional parameter-level detail beyond the schema, but provides overall context that the tool extracts a brief. Baseline 3 is appropriate given high schema coverage.

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 fetches a public website URL and extracts a structured brief with specific fields (business name, description, contact links, suggested page blocks). It distinguishes from sibling tools by specifying it imports external data, not managing existing pages.

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 clear context: works only with public HTTP/HTTPS pages and does not bypass authentication. It implicitly guides when to use (when external source is needed) and mentions the output is for page.create_from_brief, but does not explicitly exclude other alternatives, though no direct sibling exists.

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