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 the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the operation appends (write), saves an unpublished revision (non-destructive), and that the server generates the block id. The important behavioral rule about not publishing immediately is clearly stated, adding significant 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 slightly longer than ideal but every sentence earns its place. It is front-loaded with the main action, then covers constraints, side effects, and workflow guidance. No redundancy. A minor deduction for length, but it is 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 (13 block types, nested objects, output schema exists), the description covers key aspects: purpose, allowed types, side effect on publish state, and workflow rule. It does not explicitly mention the output schema or response format, but the schema itself provides that. Nearly complete.

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

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

Schema description coverage is only 33%, but the description itself does not elaborate on individual parameters beyond a high-level mention of 'must match one of the 13 allowed types with that type's strict props.' The schema carries the full burden for parameter details. While the description provides a useful overview, it does not compensate for the low coverage by adding significant meaning beyond what the schema already defines.

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 'append', the resource 'content block', and the scope 'link-in-bio page'. It lists the 13 allowed block types and mentions the server generates the id. This distinctly differentiates it from siblings like block.update, block.delete, and block.reorder.

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 on when to use (adding a block to a page), the side effect on published pages (saves an unpublished revision only), and crucially, what not to do: 'Do not call page.publish in the same assistant turn after this edit. Stop and tell the user... wait for a separate user message...' This is exemplary context for an AI agent.

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?

Adds important context beyond destructiveHint annotation: 'For already-published pages, this saves an unpublished latest revision only.' 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?

Concise first sentence, but the long instruction about publish workflow is slightly verbose yet necessary. Overall well-structured and 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?

Covers key behavioral aspects like using page.get first, unpublished revision behavior, and publish workflow. However, lacks parameter explanations. Output schema exists but is not referenced.

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?

Description adds no meaning to parameters. Schema coverage is 0%, but description does not explain pageId, blockId, or editToken. Requires compensation but provides none.

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 'Delete one block by stable blockId,' specifying verb, resource, and method. It distinguishes from sibling tools like block.add, block.reorder.

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: use page.get first if uncertain, warns not to call page.publish in the same turn, and instructs to wait for user's explicit request.

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 this is a mutation (readOnlyHint=false) but not destructive (destructiveHint=false). The description adds valuable context about saving an unpublished revision for published pages and warns against immediate publishing, enhancing transparency 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 concise and well-structured: it starts with the core purpose, then provides behavioral context and usage guidelines in a few sentences, with 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?

While the description covers purpose and usage well, it lacks parameter explanations (especially needed given zero schema coverage). It also does not describe the output schema or any side effects beyond the revision note. For a mutating tool with 4 parameters, more detail on inputs would improve completeness.

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%, and the description does not explain individual parameters like pageId, blockId, toIndex, or editToken. It only implicitly mentions 'zero-based index' for toIndex, leaving the agent to infer the meaning of other required fields without further elaboration.

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') and the resource ('block') with specific scope ('to a new zero-based index in the page main slot'). It effectively distinguishes from sibling tools like block.add, block.delete, and block.update by specifying the reordering 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 provides explicit guidance on when not to use this tool (avoid calling page.publish in the same turn) and what to do instead (inform user and wait for separate request). It also clarifies behavior for already-published pages, giving clear context for appropriate 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=false and destructiveHint=false, and description adds crucial behavioral context: for published pages, it saves an unpublished revision only. It also warns against immediate publishing, which is a key behavioral trait not captured by annotations. No contradiction.

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-organized paragraph of about 100 words. It front-loads the core action, then covers constraints, then provides workflow guidance. No unnecessary repetition or filler.

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

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

Given the complexity (13 block type variants), the description covers the essential behavior and workflow. However, it does not mention the editToken parameter (present in schema) or elaborate on implications of changing a block's type. Despite this, it sufficiently covers the most critical aspects.

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 detailed oneOf variants. The description adds value by summarizing the merge behavior ('merged into existing props') and validation requirement ('validated against strict per-type schema'). It also clarifies the type parameter usage: provide current type unless intentionally changing it. This goes beyond schema alone.

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 'Patch one content block by stable blockId' clearly states a specific verb (patch) and resource (content block), and distinguishes itself from siblings like block.add or block.delete. It also emphasizes the stable identifier, which is unique.

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 explains when to use (for editing blocks) and when not to (do not call page.publish immediately; wait for user request). It provides a clear workflow instruction: after editing, inform user and wait for separate publish command. This is excellent guidance.

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

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

Annotations already declare readOnlyHint=true 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?

Annotations indicate mutation, and description adds concrete draft-saving behavior for published pages. However, it does not disclose authentication requirements or rate limits.

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 front-loaded purpose and sequential guidelines. While dense, all lines add value; could be slightly more concise.

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 output schema exists and complexity (6 params), description covers essential behavior and usage. No need to detail output format, but could mention response type.

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 67% coverage; description adds partial update semantics ('use only fields you want to change') and lists key parameters, but does not explain pageId or editToken.

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 the page header with specific fields (displayName, bio, verified, QR). It differentiates from siblings like page.meta.update by focusing solely on header attributes.

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: use only fields to change, warns that for published pages it saves a draft only, and instructs not to call page.publish in the same turn, waiting for user confirmation instead.

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?

The description discloses key behavioral traits: it saves an unpublished revision for published pages, and warns against sequential calls. Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false), so the description adds value by explaining the revision behavior 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?

Two sentences: first states purpose, second provides critical usage guidance. Every sentence earns its place, no waste, and front-loaded with the core action.

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 6 parameters, no enums, and an output schema, the description covers the main behavior and usage context. It differentiates from siblings like page.publish. Could mention that the page must exist, but overall complete enough 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?

The description maps to four of six parameters (title, slug, seoTitle, seoDescription), adding context beyond the schema. Schema coverage is 67%, and the description groups fields meaningfully. However, editToken and pageId are not explained in the description, but they are less user-facing.

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 updates internal page title, URL slug, and SEO fields, distinguishing it from siblings like page.publish and page.create. It specifies that for published pages it only saves an unpublished revision, which differentiates its behavior.

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 (updating page meta) and when not to (calling page.publish in the same turn). It provides clear instructions to stop, inform the user, and wait for a separate request 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?

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 already-published pages, it saves an unpublished latest revision only. This behavioral trait is beyond annotations and crucial for understanding side effects. 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?

Three sentences, each earning its place: action, alternative, behavioral warning. Front-loaded and concise with no redundant information.

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

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

Despite complexity with many nested parameters, the description provides essential workflow context (draft-saving, publish ordering) and high-level guidance. 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 description coverage is low (33%), but the description adds little beyond schema: it mentions enum constraints already in schema. It does not explain editToken. The partial theme patch concept is clear but does not significantly augment parameter understanding.

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 and enumerates the constrained fields. It also distinguishes from presets.list for complete restyles, providing specific verb+resource differentiation.

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 presets.list instead, and gives critical workflow guidance: do not call page.publish in same turn, wait for user to ask to publish. This provides clear when-to-use and when-not-to-use context.

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.