Skip to main content
Glama

Server Details

Create, edit, preview, publish, and manage web pages from MCP-capable AI clients.

Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

Glama MCP Gateway

Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.

MCP client
Glama
MCP server

Full call logging

Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.

Tool access control

Enable or disable individual tools per connector, so you decide what your agents can and cannot do.

Managed credentials

Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.

Usage analytics

See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.

100% free. Your data is private.
Tool DescriptionsA

Average 4.3/5 across 23 of 23 tools scored.

Server CoherenceA
Disambiguation5/5

Each tool targets a distinct action (create, edit, publish, import, etc.) and resource (page, block, account, layout, preset). The dot-separated naming hierarchy further clarifies the domain, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tools follow a uniform dot-separated namespace convention (e.g., page.create, block.add, account.pages.list). No mixing of camelCase, snake_case, or inconsistent verb styles, ensuring predictability.

Tool Count4/5

With 23 tools, the set is on the higher end but remains well-scoped for a full-featured page builder. Each tool serves a specific purpose, covering creation, editing, publishing, and account management without redundancy.

Completeness4/5

The tool surface covers creation, editing, metadata, themes, publishing, import, and account management. Minor gaps exist: no tool to delete a page entirely (only unpublish), and the page listing is limited to authenticated accounts.

Available Tools

23 tools
account.page.manageManage Claimed PageA
Read-onlyIdempotent
Inspect

Read a claimed account page without requiring an editToken. Use after OAuth when the user wants to manage a durable website.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageIdYesThe claimed pageId to manage.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it doesn't require an editToken, which is useful but not significantly 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.

Conciseness5/5

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

Two sentences, no wasted words. First sentence defines core action, second adds usage context. Front-loaded and efficient.

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

Completeness4/5

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

Tool is simple with one parameter, output schema exists (though not detailed here), annotations cover safety. Description provides purpose and usage context adequately for this complexity.

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

Parameters3/5

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

The single parameter pageId has a description in the schema ('The claimed pageId to manage.'), so schema coverage is 100%. The description does not add further parameter meaning beyond the schema.

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

Purpose5/5

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

The description clearly states it reads a claimed account page without an editToken, distinguishing it from siblings like page.get which likely require a token. The verb 'Read' and resource 'claimed account page' are specific.

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

Usage Guidelines4/5

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

Provides a specific use case: 'Use after OAuth when the user wants to manage a durable website.' This guides when to use the tool, but no explicit alternatives or when-not-to-use are given.

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

account.pages.listList Claimed PagesA
Read-onlyIdempotent
Inspect

List landing pages claimed by the authenticated account. This requires OAuth and is for account management, not first-time demo creation.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of claimed pages to return.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
pagesYes
Behavior3/5

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds OAuth requirement and account management context, but adds little new behavioral detail.

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

Conciseness5/5

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

Two sentences, front-loaded with purpose, no redundant words.

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

Completeness5/5

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

For a simple list tool with full annotations and output schema, the description is complete enough. No missing information is critical.

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

Parameters3/5

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

Schema coverage is 100% with a single parameter 'limit' adequately described. The description does not add parameter info, but baseline is 3 due to schema richness.

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

Purpose4/5

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. It distinguishes from siblings like page.create but not explicitly from account.page.manage, but that is acceptable.

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

Usage Guidelines4/5

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

Specifies that OAuth is required and that the tool is for account management, not first-time demo creation, providing clear context on when to use.

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

account.whoamiCurrent AccountA
Read-onlyIdempotent
Inspect

Return the current Create Web Page account context. Use this to check whether the user is authenticated or using an anonymous expiring demo.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
roleYes
serviceYes
authModeYes
accountIdYes
demoExpiresAtYes
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating safe behavior. The description adds context about what the tool returns (account context and auth status), enhancing transparency without contradiction.

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

Conciseness5/5

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

Two concise sentences, front-loaded with the core action and usage guidance. No unnecessary words.

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

Completeness5/5

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

Given the tool has no parameters and an output schema exists, the description is complete for its purpose. It explains the tool's function and use case sufficiently.

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

Parameters4/5

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

The tool has no parameters, so the schema coverage is 100%. Per guidelines, baseline is 4. The description does not need to add parameter information.

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

Purpose5/5

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

The description clearly states the verb 'Return' and the resource 'current account context'. It distinguishes from sibling tools by specifying it checks authentication status.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool: to check whether the user is authenticated or using an anonymous demo. It provides clear context but does not include when-not-to-use scenarios.

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

block.addAdd Content BlockAInspect

Append a new content block to a link-in-bio page. The block must match one of the 13 allowed types (link, social_row, whatsapp, phone_call, email_contact, image, gallery, video_embed, text, map_embed, product_card, lead_form, reviews) with that type's strict props. The server generates the block id and returns it in the response. For already-published pages, this saves an unpublished latest revision only. Do not call page.publish in the same assistant turn after this edit. Stop and tell the user the draft/preview was updated, then wait for a separate user message that explicitly asks to update the live link, publish, or make the changes public before calling page.publish. Do NOT call page.unpublish either — the live page should stay public; only unpublish when the user explicitly asks to take it down. The response includes nextSteps: after adding a block, share these hints with the user so they know what else would make the page more complete.

ParametersJSON Schema
NameRequiredDescriptionDefault
blockYesThe block to add. Must match one of the 13 allowed types with that type's strict props schema. The server generates the block id.
pageIdYes
editTokenNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior4/5

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

Annotations already indicate a write operation (readOnlyHint false) and non-destructive (destructiveHint false). The description adds context: server generates block id, for published pages it saves an unpublished revision, and warns about publish/unpublish calls. This goes 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.

Conciseness3/5

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

The description is verbose with multiple sentences, including orchestration instructions. While front-loaded with purpose, it could be shorter. Every sentence provides value but the length reduces conciseness.

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

Completeness4/5

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

The description covers the core operation, allowed types, server behavior, and publish workflow. It is sufficient for an agent to correctly use the tool. An output schema exists, so return values are covered separately.

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

Parameters2/5

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

The description lists the 13 block types but does not elaborate on specific props for each type. The input schema contains oneOf variants with their own descriptions, so parameter meaning is largely derived from the schema. Given low schema description coverage (33%), the description should have compensated more.

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

Purpose5/5

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

The description clearly states the verb 'append' and the resource 'new content block to a link-in-bio page'. It lists the 13 allowed block types and distinguishes from sibling tools like block.update, block.delete, 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.

Usage Guidelines5/5

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

The description explicitly provides when-to-use (adding a block) and when-not-to-use (do not call page.publish in same turn, do not call page.unpublish). It also instructs to wait for explicit user request to publish, offering clear orchestration guidance.

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

block.deleteDelete Landing Page BlockA
DestructiveIdempotent
Inspect

Delete one block by stable blockId. Use page.get first if unsure which id to remove. For already-published pages, this saves an unpublished latest revision only. Do not call page.publish in the same assistant turn after this edit. Stop and tell the user the draft/preview was updated, then wait for a separate user message that explicitly asks to update the live link, publish, or make the changes public before calling page.publish. Do NOT call page.unpublish either — the live page should stay public; only unpublish when the user explicitly asks to take it down.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageIdYes
blockIdYes
editTokenNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior5/5

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

Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds critical context: for published pages, only an unpublished latest revision is saved. It also clarifies that the live page should remain public, and provides explicit workflow instructions 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.

Conciseness4/5

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

Description is somewhat lengthy but each sentence adds value: purpose, guidance, behavioral notes, agent instructions. It is well-structured and front-loaded with the action. Slightly verbose but justified by the need for clear warnings.

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

Completeness4/5

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

Covers key aspects: what it does, when to use, behavioral implications for published pages, and post-action instructions. Output schema exists, so return values are covered. Minor omission: error handling or behavior when block does not exist, but overall complete for the task.

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

Parameters2/5

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

Schema coverage is 0%, so description must compensate. It only mentions blockId as a stable ID, but does not explain pageId or editToken. This leaves significant gaps for parameter understanding.

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

Purpose5/5

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

Description clearly states 'Delete one block by stable blockId.' Verb 'delete' and resource 'block' are precise. It distinguishes from sibling tools like block.add, block.update, block.reorder by specifying deletion and referencing page.get for identification.

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

Usage Guidelines5/5

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

Explicitly advises to use page.get first if unsure of the ID, and provides strict instructions on what not to do after deletion: do not call page.publish or page.unpublish in the same turn, and wait for explicit user request. Also explains behavior for published pages.

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

block.reorderReorder Landing Page BlockA
Idempotent
Inspect

Move a block to a new zero-based index in the page main slot. For already-published pages, this saves an unpublished latest revision only. Do not call page.publish in the same assistant turn after this edit. Stop and tell the user the draft/preview was updated, then wait for a separate user message that explicitly asks to update the live link, publish, or make the changes public before calling page.publish. Do NOT call page.unpublish either — the live page should stay public; only unpublish when the user explicitly asks to take it down.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageIdYes
blockIdYes
toIndexYes
editTokenNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior4/5

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

Annotations already indicate idempotent and non-destructive. Description adds that for published pages it saves an unpublished revision, providing 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.

Conciseness4/5

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

Sentences are functional, front-loaded with core action. Could trim minor redundancy, but overall efficient for the behavioral warnings needed.

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

Completeness3/5

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

Covers core behavior and constraints well, but lacks parameter details despite 0% coverage and 4 parameters. Output schema exists but not visible; still incomplete for parameter semantics.

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

Parameters2/5

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

0% schema description coverage; description only mentions 'toIndex' implicitly (zero-based index) but does not explain pageId, blockId, editToken, or valid ranges. Insufficient compensation.

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

Purpose5/5

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

Specific verb 'move' and resource 'block to a new zero-based index' clearly states the action. Distinct from siblings like block.add, block.delete, block.update.

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

Usage Guidelines5/5

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

Explicitly states when to use (move block) and when not to, including warnings against calling page.publish or page.unpublish in the same turn, and instructing to wait for user request.

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

block.updateUpdate Landing Page BlockA
Idempotent
Inspect

Patch one content block by stable blockId. Provide a props patch (merged into existing props) and/or a new type. Block types and props are validated against the strict per-type schema. For already-published pages, this saves an unpublished latest revision only. Do not call page.publish in the same assistant turn after this edit. Stop and tell the user the draft/preview was updated, then wait for a separate user message that explicitly asks to update the live link, publish, or make the changes public before calling page.publish. Do NOT call page.unpublish either — the live page should stay public; only unpublish when the user explicitly asks to take it down.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior5/5

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds that for already-published pages, only an unpublished revision is saved, and it mentions validation against per-type schema. No contradictions; provides useful 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.

Conciseness4/5

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

The description is somewhat lengthy due to behavioral instructions, but it is front-loaded with the core purpose. Every sentence is justified, though some redundancy exists (e.g., repeating 'for already-published pages'). Still efficient for the complexity.

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

Completeness5/5

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

Given the complexity (many block types with oneOf), the description covers core behavior, draft/publish workflow, and validation. It references output schema (not shown) but doesn't need to explain return values. Complete for an update tool.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds that the update uses a props patch (merged into existing props) and optionally a new type, which is helpful but not extensive. Baseline 3 is appropriate as schema already does heavy lifting.

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

Purpose5/5

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. It specifies the action (patch) and resource (content block), and distinguishes from siblings like block.add and block.delete by focusing on updating existing blocks.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use the tool and critical warnings: for published pages it saves an unpublished revision, instructing not to call page.publish or page.unpublish in the same turn and to wait for user confirmation. This is excellent for correct invocation.

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

layouts.listList Available LayoutsA
Read-onlyIdempotent
Inspect

List supported page layouts. v1 ships link_in_bio only.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

Behavior3/5

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

Annotations already cover read-only and idempotent nature. Description adds version info but doesn't discuss any additional behavioral traits.

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

Conciseness5/5

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

Two sentences, front-loaded verb, no unnecessary words. Efficient and clear.

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

Completeness5/5

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

Given no parameters and an output schema, the description is complete enough—states what is listed and a version note.

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

Parameters4/5

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

No parameters exist, schema coverage is 100%, so description doesn't need to add parameter details. Baseline score of 4 applies.

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

Purpose4/5

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

Clearly states the action 'List' and resource 'page layouts', with a version-specific detail. However, no explicit differentiation from sibling tools.

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

Usage Guidelines3/5

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

No guidance on when to use or alternative tools. For a simple list, perhaps not needed, but lacking explicit context.

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

page.claimClaim Demo PageA
Idempotent
Inspect

Claim an anonymous demo page into an AUTHENTICATED account. This requires the signed-in user's OAuth — an anonymous chat/agent session cannot call it and will get an OAuth-required error. So in a normal agent conversation, do NOT call this to 'save' a demo page: instead share the claimUrl from the page.create/page.publish result with the user, who opens it, signs in, and keeps the page. Only call page.claim when the request already runs under the owner's OAuth.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageIdYesThe pageId returned by page.create.
editTokenYesThe editToken returned by page.create for the anonymous demo page.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior4/5

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

Annotations already mark idempotentHint=true and destructiveHint=false. Description adds the critical OAuth requirement and the error condition for anonymous sessions. Could mention the ownership transfer effect, but overall informative.

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

Conciseness5/5

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

Concise and front-loaded. Every sentence carries essential information with no redundancy or fluff.

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

Completeness5/5

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

Given sibling tools and annotations, the description fully explains the tool's role in the workflow, authentication constraints, and alternative usage patterns. Output schema exists so return values need not be described.

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

Parameters4/5

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

Schema already covers both parameters with descriptions (100% coverage). Description adds value by tying them to page.create results, reinforcing the workflow context.

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

Purpose5/5

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

The description clearly states the tool claims an anonymous demo page into an authenticated account. It uses specific verb 'claim' and resource 'anonymous demo page', and distinguishes from siblings like page.create 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.

Usage Guidelines5/5

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

Explicitly states when not to call (in a normal conversation to 'save' a demo page) and suggests alternative: share claimUrl. Also specifies that it only works under the owner's OAuth, providing clear usage boundaries.

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

page.createCreate Landing PageAInspect

Create a hosted link-in-bio page draft from a style preset. Provide title, displayName, and a preset (or 'auto' to infer from businessType/style). The page starts with empty placeholder blocks for you to fill in via block.update — do not invent content. This tool intentionally creates a draft only and does not return a publish action. After calling it, stop and show the preview URL. Do not call page.publish in the same turn unless the user's current message explicitly asks to publish, make the page live, or get a public share link. Anonymous demo pages expire unless claimed.

ParametersJSON Schema
NameRequiredDescriptionDefault
bioNoOptional short bio for the header.
slugNoPreferred public URL slug.
styleNoFree-form style hint used by preset:auto inference.
titleYesInternal page title and default header display_name.
layoutNoLayout id. Defaults to 'link_in_bio'.
presetYesStyle preset id, or 'auto' to infer deterministically from businessType/style.
displayNameNoVisible header display name. Defaults to title.
businessTypeNoUsed by preset:auto inference. Examples: musician, restaurant, designer.
initialPromptNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior5/5

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

Discloses beyond annotations: draft-only nature, no publish action returned, expiration of anonymous demo pages, and that the page starts with empty placeholder blocks. Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false, which are consistent. 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.

Conciseness5/5

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

Concise 5-sentence description. Front-loaded with the primary action. Every sentence adds value: what it does, how to use, what not to do, and key constraints. No fluff.

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

Completeness4/5

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 the critical workflow: creation, preview, and expiration. Since output schema exists, the description need not detail return values. It is complete enough for an agent to use correctly.

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

Parameters4/5

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

Schema coverage is 89%, so baseline is 3. Description adds meaning: explains 'auto' preset behavior, default for displayName, and context that initialPrompt is a free-form hint. It also clarifies that the page starts empty for block.update. This extra value justifies a 4.

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

Purpose5/5

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

Clearly states 'Create a hosted link-in-bio page draft from a style preset.' It distinguishes from siblings by explicitly warning not to call page.publish and to use block.update for content, and implies a different purpose than 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.

Usage Guidelines5/5

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

Provides explicit guidance: 'Do not call page.publish in the same turn unless the user's current message explicitly asks to publish...' Also instructs to stop and show preview URL, and notes that anonymous pages expire. This covers when and when not to use the tool.

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

page.create_from_briefCreate Landing Page From BriefAInspect

Create a hosted landing page draft from a structured brief. Accepts business name, category, layout, palette, primary action, explicit final-audience publicSections, and optional hero image. Planning fields such as audience, offer, primaryGoal, location, businessType, style, and mustInclude are context only and are not rendered as public body copy. Draft previews are customer-facing: do not pass owner instructions, section-planning labels, or placeholder copy as public content. Keep sparse briefs sparse: use only facts supplied by the user or imported public sources, plus light wording polish; do not invent menus, services, hours, facilities, locations, testimonials, guarantees, staff details, prices, or operational claims. Prefer one short section or no extra section when the prompt is minimal. If a requested CTA lacks its real destination, ask for it before creation or provide fallbackLeadForm with public copy. Returns a preview URL, edit token, and next-step hints. This tool intentionally creates a draft only and does not return a publish action. After calling it, stop and show the preview URL. Do not call page.publish in the same turn unless the user's current message explicitly asks to publish, make the page live, or get a public share link. Anonymous pages expire unless claimed via page.claim.

ParametersJSON Schema
NameRequiredDescriptionDefault
bioNoOptional short bio for the header.
offerNoPlanning context only. Not rendered directly as public page copy; use bio and publicSections for final-audience copy.
styleNoPlanning context only. Not rendered directly as public page copy.
layoutNoDefaults to 'link_in_bio'.
localeNo
presetNoStyle preset id, or 'auto' to infer deterministically. Defaults to 'auto'.
audienceNoPlanning context only. Not rendered directly as public page copy.
locationNoPublic business address or service area intended for map/address actions, not direct body copy and not the user's private/current location.
sourceUrlNoProvenance reference only.
mustIncludeNoPlanning checklist only. Do not put section names, CTA labels, owner instructions, or private notes here; not rendered directly.
primaryGoalNoPlanning context only. Not rendered directly as public page copy.
publicPhoneNoPublic business phone number explicitly supplied by the user or a public source. Do not use the user's private/account phone.
businessNameYes
businessTypeNoPlanning context only. Not rendered directly as public page copy.
heroImageUrlNoExplicit user-provided image URL for featured-photo or full-image styles.
sourceHandleNo
initialPromptNo
preferredSlugNoDesired URL path. Ask the user for it near the end of onboarding. Use normal letters, numbers, and hyphens; the server normalizes and makes it unique.
publicSectionsNoFinal-audience text sections to render on the public page. Write in the target language with correct spelling/accents. Only include facts the user supplied or that came from an imported public source; for sparse prompts, keep this short and avoid invented service lists, hours, benefits, testimonials, prices, or operational details.
publicWhatsappNoPublic WhatsApp phone number explicitly supplied by the user or a public source. Do not use the user's account phone or invent placeholder numbers.
primaryActionIdNo
fallbackLeadFormNoPublic fallback contact/interest form to use when the requested primary action lacks a real destination. All copy must be final-audience copy in the page's target language.
onboardingLayoutNoLayout style: background_color (minimalist), full (featured photo), or background_image (full image background).
primaryActionUrlNoReal destination URL for the primary action when explicitly supplied by the user or imported public source, such as a booking link. Do not invent booking/order URLs; if missing, ask for it or use fallbackLeadForm.
onboardingPaletteNoPalette id returned by page.onboarding.* paletteChoices, for example atom_dark_plum.
primaryActionLabelNoPublic label for the primary action in the page's target language.
publicBusinessEmailNoPublic business contact email explicitly supplied by the user or a public source. Do not use the user's ChatGPT/account email.
onboardingSubCategoryNoValidated atom.bio subcategory id, for example health.
onboardingMainCategoryNoValidated atom.bio category id from page.onboarding.*, for example physical-business or online-business.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior5/5

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

The description richly discloses behaviors: it's a draft-only tool, planning fields are not rendered, content rules (no inventing), handling of missing CTAs, fallback form usage, expiration of anonymous pages. Annotations are all false, so description carries full burden and exceeds expectations.

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

Conciseness4/5

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

The description is well-structured with clear front-loading of purpose, but it is quite long. Every sentence adds value, so it's not overly verbose, but slightly more conciseness could improve it.

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

Completeness5/5

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

Given 29 parameters, nested objects, output schema existence, and sibling tools, the description covers all essential aspects: it explains what the tool returns (preview URL, edit token, next-step hints), addresses content rules, error handling, and usage constraints. It is complete for an AI agent.

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

Parameters5/5

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

With 83% schema coverage, base is 3, but the description adds significant meaning: it explicitly marks parameters as 'planning context only' vs 'public', explains what not to put in arrays, describes how to handle fallbackLeadForm and preferredSlug. It provides actionable guidance beyond schema.

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

Purpose5/5

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 landing page draft from a structured brief. It distinguishes from siblings by explicitly saying it only drafts and does not publish, and by mentioning 'Do not call page.publish 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.

Usage Guidelines5/5

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 (for creating a draft from a brief) and what to avoid (calling page.publish immediately, passing owner instructions). It includes 'stop and show the preview URL' after calling.

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

page.getGet Landing PageA
Read-onlyIdempotent
Inspect

Read a landing page draft, including its latest content JSON. For anonymous demo pages, include the editToken.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageIdYes
editTokenNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior4/5

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

Annotations already mark the tool as read-only and idempotent. The description adds value by detailing that it returns the latest content JSON and that editToken is required for anonymous demo pages, providing 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.

Conciseness5/5

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

The description is two sentences, front-loads the main action ('Read a landing page draft'), and includes essential details without extraneous information.

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

Completeness5/5

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

Given the tool's low complexity (2 params, output schema exists), the description sufficiently covers the key aspects: what is read, what is returned, and a special case (anonymous pages). No gaps for effective use.

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

Parameters3/5

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

With 0% schema description coverage, the description must compensate. It clarifies that editToken is used for anonymous demo pages but does not describe pageId's purpose or format beyond the schema's UUID constraint. Partial compensation.

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

Purpose5/5

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 with its latest content JSON, differentiating it from sibling tools like account.pages.list (list) and page.create (create). The mention of anonymous demo pages and editToken further specifies the scope.

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

Usage Guidelines3/5

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

The description implicitly indicates use for reading page drafts but provides no explicit when-to-use or when-not-to-use guidance. It does not reference alternative tools such as account.pages.list for listing or page.publish for publishing.

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

page.header.updateUpdate Page HeaderA
Idempotent
Inspect

Update the link-in-bio page header: displayName, bio, verified checkmark, and QR display. Use only the fields you want to change. For already-published pages, this saves an unpublished latest revision only. Do not call page.publish in the same assistant turn after this edit. Stop and tell the user the draft/preview was updated, then wait for a separate user message that explicitly asks to update the live link, publish, or make the changes public before calling page.publish. Do NOT call page.unpublish either — the live page should stay public; only unpublish when the user explicitly asks to take it down.

ParametersJSON Schema
NameRequiredDescriptionDefault
bioNoShort bio under the display name. Pass null to clear it.
pageIdYes
showQrNoShow a QR code for this page.
verifiedNoShow a verified checkmark next to the display name.
editTokenNo
displayNameNoVisible display name in the page header.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior4/5

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

Adds context beyond annotations: it saves an unpublished revision for already-published pages, and advises to inform user. Annotations already provide readOnlyHint, idempotentHint, destructiveHint, but description clarifies the draft nature.

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

Conciseness4/5

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

Description is front-loaded with purpose, then guidelines and warnings. While comprehensive, it could be slightly more concise but every sentence adds value.

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

Completeness4/5

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

Covers the main workflow and constraints adequately given the presence of an output schema. Could mention prerequisites or the role of editToken, but overall sufficient for an AI agent.

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

Parameters2/5

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

Schema description coverage is 67%, but the description does not add new meaning for the documented parameters nor clarify undocumented ones (pageId, editToken). It only advises to use fields to change, which is already implied by the schema.

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

Purpose5/5

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

Clearly states the tool updates the link-in-bio page header fields (displayName, bio, verified checkmark, QR display) and distinguishes from siblings like page.publish and page.unpublish.

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

Usage Guidelines5/5

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

Provides explicit instructions on when to use (only fields to change), and strong warnings against calling page.publish or page.unpublish in the same turn, with a clear workflow to wait for user confirmation.

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

page.intake.startStart Landing Page IntakeA
Read-onlyIdempotent
Inspect

RECOMMENDED first step for building a page. Returns the few questions worth asking (business name, primary visitor action, key content, optional source link) so you can then call page.create_from_brief. This is the simplest, most reliable path — prefer it. (page.onboarding.* offers extra category/layout/palette pickers but is a stateless planning helper, not required.) Call once per creation request; skip if the user already gave you a source URL. Does not create a page.

ParametersJSON Schema
NameRequiredDescriptionDefault
localeNoPreferred content locale if obvious from the conversation.
sourceUrlNoPublic HTTP/HTTPS source URL provided by the user, such as a business website or link-in-bio page. Protected platforms (social networks, maps, paywalls) require client-side browsing or pasted details instead.
primaryGoalNoThe main visitor action if known, such as book, call, WhatsApp, buy, or leave a lead.
businessNameNoOnly include if the user already provided the business or project name.
businessTypeNoBusiness category inferred from the user's words, such as hamburger restaurant or dental clinic.
sourceHandleNoPublic social handle provided by the user.
originalRequestNoThe user's original page-creation request, copied verbatim when available.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
modeYes
titleYes
actionsYes
questionsYes
canCreateNowYes
promptToUserYes
missingFieldsYes
sourceGuidanceYes
recommendedNextToolYes
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces these by stating 'Does not create a page.' It also adds behavioral context: it returns questions for later use, and it is the simplest path. No contradictions 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.

Conciseness5/5

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

The description is concise (a few sentences), front-loaded with the most important information (recommended first step), and every sentence serves a purpose: stating action, return value, alternative, and caveats. No redundant text.

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

Completeness5/5

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

Given the 7 optional parameters, existence of output schema, and context signals, the description fully sets the tool's role: it initiates the intake for page creation, leads to page.create_from_brief, and clarifies it does not create a page. It also addresses the alternative onboarding flow, making the workflow complete.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema, only mentioning some parameters ('business name, primary visitor action, key content, optional source link') as 'the few questions worth asking'. This provides some contextualization but does not significantly enhance understanding beyond the already descriptive parameter descriptions.

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

Purpose5/5

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

The description clearly states the tool's purpose: it is the recommended first step for building a page, returns questions for intake, and distinguishes itself from sibling tools (page.onboarding.*) by emphasizing it is the simplest, most reliable path. The verb 'start' and resource 'intake' are specific.

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

Usage Guidelines5/5

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

Explicit guidance is provided: 'RECOMMENDED first step', 'prefer it', 'Call once per creation request; skip if the user already gave you a source URL.' It also mentions an alternative (page.onboarding.*) and when that might be used, giving clear when-to-use and when-to-skip instructions.

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

page.meta.updateUpdate Page MetaA
Idempotent
Inspect

Update internal page title, URL slug, and SEO title/description. For already-published pages, this saves an unpublished latest revision only. Do not call page.publish in the same assistant turn after this edit. Stop and tell the user the draft/preview was updated, then wait for a separate user message that explicitly asks to update the live link, publish, or make the changes public before calling page.publish. Do NOT call page.unpublish either — the live page should stay public; only unpublish when the user explicitly asks to take it down.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugNoPreferred public URL slug.
titleNoInternal page title shown in editor results.
pageIdYes
seoTitleNoSEO <title> tag value.
editTokenNo
seoDescriptionNoSEO meta description value.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior4/5

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

Annotations already indicate non-read-only, non-destructive, and idempotent. The description adds valuable context: the draft-only behavior for published pages and the prohibition on simultaneous publish/unpublish calls. This goes beyond annotations to clarify the tool's side effects.

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

Conciseness5/5

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

Three sentences: first sentence states purpose, second explains behavior for published pages, third gives step-by-step usage instructions. Every sentence is necessary and front-loaded. No wasted words.

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

Completeness4/5

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

Given the existence of an output schema, the tool's 6 parameters, and the nuanced interaction with publish/unpublish, the description covers key behavioral constraints. It could mention editToken briefly, but overall it provides enough context for correct agentic use.

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

Parameters4/5

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

Schema coverage is 67% with descriptions for 4 of 6 parameters. The description explains the effect of updating title, slug, seoTitle, and seoDescription but does not address editToken or pageId. However, it adds meaning by linking parameter updates to the draft/published distinction, making the schema more actionable.

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

Purpose5/5

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

The description clearly states the verb 'update' and the resource 'page meta', listing specific fields (title, slug, seo title/description). It distinguishes from sibling tools like page.publish and page.unpublish by providing explicit usage boundaries.

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

Usage Guidelines5/5

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

The description provides explicit guidance: for published pages, it saves only an unpublished revision; it instructs not to call page.publish in the same turn, to wait for user confirmation, and not to call page.unpublish unless explicitly asked. This clearly differentiates when to use this tool versus alternatives.

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

page.onboarding.startStart Guided Page OnboardingA
Read-onlyIdempotent
Inspect

Optional planning helper that returns category/layout/palette/primary-action choices and a quality checklist (it does NOT create a page). Use it only if you want those pickers; otherwise page.intake.start → page.create_from_brief is the simpler path. IMPORTANT: this flow is STATELESS — page.onboarding.update does not remember earlier calls, so each update must resend the FULL set of selections + knownFields gathered so far. As soon as you have a business name and a primary action, stop and call page.create_from_brief (you do not need to reach a 'ready' step).

ParametersJSON Schema
NameRequiredDescriptionDefault
localeNoPreferred UI locale, such as es or en.
originalRequestNo
suggestedSelectionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
modeYes
stepIdYes
uiHtmlYes
choicesYes
selectedYes
nextPromptYes
canContinueYes
profileCopyYes
slugGuidanceYes
imageGuidanceYes
layoutChoicesYes
missingFieldsYes
readyToCreateYes
layoutGuidanceYes
paletteChoicesYes
primaryActionsYes
invalidSelectionYes
qualityChecklistYes
recommendedLinksYes
recommendedBlocksYes
createFromBriefHintsYes
recommendedMissingFieldsYes
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context: the tool does not create a page, returns specific choices and a checklist, and the flow is stateless (applies to the update tool but relevant for the start tool's output). No contradictions 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.

Conciseness5/5

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

The description is a single concise paragraph with front-loaded purpose, explicit usage guidance, and an important caveat. Every sentence adds value, with no wasted words.

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

Completeness4/5

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

Given the tool has an output schema (not shown but known to exist), the description need not detail return values. It covers the tool's role in the onboarding flow, alternatives, and critical caveats. The main gap is missing parameter guidance, but the overall context is sufficient for an agent to decide when to invoke this tool.

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

Parameters2/5

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

Schema description coverage is only 33% (low). The description provides no parameter-specific information, leaving locale, originalRequest, and suggestedSelection unexplained. The description does not compensate for the low coverage, so agents must infer parameter usage from names alone.

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

Purpose5/5

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

The description clearly states it is an optional planning helper that returns category/layout/palette/primary-action choices and a quality checklist, and explicitly says it does NOT create a page. It distinguishes itself from sibling tools like page.intake.start and page.create_from_brief by describing when to use each.

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

Usage Guidelines5/5

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

Excellent guidance: tells the agent to use this tool only if it wants the pickers, otherwise recommends the simpler path (page.intake.start → page.create_from_brief). Provides a stopping condition (once business name and primary action are obtained, switch to page.create_from_brief) and warns about the stateless nature of the flow.

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

page.onboarding.updateUpdate Guided Page OnboardingA
Read-onlyIdempotent
Inspect

Validate onboarding selections and return the remaining checklist. STATELESS: it does not remember previous calls, so every call must include the FULL accumulated selection (mainCategory, subCategory, layout, palette, primaryAction) plus all knownFields (name, description, action destination, etc.) gathered so far — not just the latest answer, or earlier choices will look 'missing'. You do not need to loop to a 'ready' state: once you have a name and a primary action, call page.create_from_brief with those values.

ParametersJSON Schema
NameRequiredDescriptionDefault
localeNo
stepIdNo
selectionNo
knownFieldsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
modeYes
stepIdYes
uiHtmlYes
choicesYes
selectedYes
nextPromptYes
canContinueYes
profileCopyYes
slugGuidanceYes
imageGuidanceYes
layoutChoicesYes
missingFieldsYes
readyToCreateYes
layoutGuidanceYes
paletteChoicesYes
primaryActionsYes
invalidSelectionYes
qualityChecklistYes
recommendedLinksYes
recommendedBlocksYes
createFromBriefHintsYes
recommendedMissingFieldsYes
Behavior4/5

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds crucial stateless context, 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.

Conciseness5/5

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

Single paragraph with no redundancy; front-loaded with purpose, then critical usage notes, then exit strategy.

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

Completeness4/5

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

With an output schema present, the description adequately covers core behavior and usage. Lacks error handling details, but sufficient for correct invocation.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It explains the need to pass full selection and knownFields, but does not detail all parameters individually.

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

Purpose5/5

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

The description clearly states the tool validates selections and returns the remaining checklist, distinguishing it from sibling tools like page.onboarding.start 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.

Usage Guidelines5/5

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

Explicitly explains the stateless nature requiring full accumulated state each call, and provides a non-ambiguity condition: once name and primary action are obtained, use page.create_from_brief instead.

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

page.previewPreview Landing PageA
Read-onlyIdempotent
Inspect

Return the current preview URL for a page.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageIdYesThe pageId returned by page.create.
editTokenNoRequired for anonymous demo pages. Use the editToken returned by page.create.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns a URL, but does not disclose additional behavioral traits beyond what annotations provide. This is adequate but minimal.

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

Conciseness5/5

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

A single sentence that immediately states the action and object. No filler words, front-loaded with 'Return the current preview URL'.

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

Completeness5/5

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

Given the tool has only two parameters, 100% schema coverage, and an output schema exists, the description sufficiently covers what the agent needs to know. The annotations provide safety context.

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

Parameters3/5

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

Schema coverage is 100% and parameter descriptions are clear, so the description does not need to add extra meaning. Both pageId and editToken are well-documented in the schema.

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

Purpose5/5

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 preview URL for a page, using a specific verb and resource. It distinguishes from siblings like page.get (returns page data) 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.

Usage Guidelines3/5

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

The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., page.get, page.publish). While the purpose is clear, an agent could benefit from knowing that this is for obtaining a preview link before publishing.

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

page.publishPublish Landing PageA
Idempotent
Inspect

Publish the latest page revision. Call this only when the user's latest message explicitly asks to publish, make the page live, or get a public share link. Do not call this immediately after page.create or page.create_from_brief just because the draft is publish-ready. For anonymous demo pages, include the editToken returned by page.create. The response includes nextSteps: always share these with the user after publishing — they include the claim reminder and any remaining improvements.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageIdYesThe pageId returned by page.create.
editTokenNoRequired for anonymous demo pages. Use the editToken returned by page.create.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior5/5

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

Description adds context beyond annotations: it indicates the response includes nextSteps which must be shared with the user after publishing, and mentions the claim reminder and remaining improvements. No contradictions with annotations (idempotentHint=true, 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.

Conciseness5/5

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

Four sentences, front-loaded with purpose, then usage rules, then special case, then response handling. No wasted words, each sentence adds essential information.

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

Completeness5/5

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

Given the tool has 2 parameters, output schema exists, and annotations are provided, the description covers all necessary aspects: when to use, parameter roles, special cases, and post-processing of response. No gaps.

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

Parameters4/5

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

Input schema already has 100% description coverage, so baseline is 3. Description enhances by explaining pageId comes from page.create and editToken is required for anonymous demo pages, adding practical usage context.

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

Purpose5/5

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

The description explicitly states 'Publish the latest page revision' and distinguishes from sibling tools by specifying when to call (explicit user request) and when not to call (immediately after create). It also mentions handling anonymous demo pages with editToken, which differentiates it further.

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

Usage Guidelines5/5

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

Provides clear guidelines: call only when user explicitly asks to publish, make live, or get share link; do not call immediately after page.create or page.create_from_brief. Also specifies handling for anonymous demo pages via editToken.

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

page.theme.updateUpdate Page ThemeA
Idempotent
Inspect

Apply a partial theme patch. Theme fields are enum-constrained (button variant/radius/shadow, font family/weight, density, icon_size). Use presets.list first if the user wants a complete restyle. For already-published pages, this saves an unpublished latest revision only. Do not call page.publish in the same assistant turn after this edit. Stop and tell the user the draft/preview was updated, then wait for a separate user message that explicitly asks to update the live link, publish, or make the changes public before calling page.publish. Do NOT call page.unpublish either — the live page should stay public; only unpublish when the user explicitly asks to take it down.

ParametersJSON Schema
NameRequiredDescriptionDefault
themeYesPartial theme patch. Provide only fields you want to change.
pageIdYes
editTokenNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior4/5

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

Adds context beyond annotations: for published pages, saves an unpublished revision only; warns against concurrent publish/unpublish calls. IdempotentHint and destructiveHint from annotations are consistent.

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

Conciseness4/5

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

Front-loaded with core action, but includes several warnings that lengthen the description. All sentences are necessary for safe usage, so it remains efficient.

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

Completeness5/5

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

Given the nested schema and sibling tools, the description covers purpose, usage, behavioral constraints comprehensively. Output schema exists but is not needed in description.

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

Parameters2/5

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

Schema coverage is low (33%) with only theme having a description. Tool description does not elaborate on parameters beyond stating enum constraints, which are already in schema. No added semantics for pageId or editToken.

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

Purpose5/5

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

Clearly states it applies a partial theme patch and distinguishes from sibling tools by mentioning presets.list for complete restyle and page.publish/unpublish for publishing actions.

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

Usage Guidelines5/5

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

Explicitly provides when to use presets.list, warns against calling page.publish/unpublish in the same turn, and instructs 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.

page.unpublishUnpublish Landing PageA
DestructiveIdempotent
Inspect

Remove a published landing page from public availability while keeping its draft and revision history.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageIdYes
editTokenNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
slugYes
titleYes
pageIdYes
statusYes
actionsYes
contentNo
claimUrlYes
editTokenYes
expiresAtYes
isClaimedYes
nextStepsNoEnrichment hints to present to the user. Address 'required' items before publishing.
canPublishYes
previewUrlYes
isPublishedYes
publishedUrlYes
missingFieldsNo
publishPolicyNoFor edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
liveUpdateMessageNoPlain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
liveUpdateRequiredNoTrue after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision.
Behavior4/5

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

The description adds behavioral context beyond annotations by stating it keeps draft and revision history. Annotations already indicate destructiveHint=true and idempotentHint=true, but no contradiction. No mention of permissions or error states, but acceptable given tool simplicity.

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

Conciseness5/5

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

The description is one sentence of 14 words, front-loaded with the verb, and contains no redundant information. Every word serves a purpose.

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

Completeness4/5

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

Given the tool is simple, annotations provide destructive and idempotent hints, and an output schema exists, the description sufficiently explains the outcome (removed from public, kept history) without needing return value details.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate but does not explain what pageId or editToken mean beyond their schema types. However, the parameters are self-explanatory given the tool name.

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

Purpose5/5

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

The description uses a specific verb ('Remove') and resource ('published landing page'), clearly distinguishing it from sibling tools like 'page.publish' (which does the opposite).

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

Usage Guidelines3/5

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

The description implies usage (removing public availability while keeping history), but does not explicitly state when to use this tool over alternatives or mention any preconditions or exclusions.

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

presets.listList Style PresetsA
Read-onlyIdempotent
Inspect

List the 8 curated style presets (theme + starter blocks) for link-in-bio. Use to offer the user a choice or to confirm a preset:auto selection.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint as true/false appropriately. The description adds context about the fixed set of '8 curated style presets' and their composition ('theme + starter blocks'), which is helpful beyond the 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.

Conciseness5/5

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

Two sentences, no fluff. Front-loaded with the core action and resource. Every word contributes value.

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

Completeness5/5

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

For a simple listing tool with no parameters and an output schema, the description is complete. It states what is listed, for what context (link-in-bio), and the intended use cases. No missing information.

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

Parameters4/5

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

Tool has zero parameters. The description adds meaning by specifying the content of the list (8 curated presets, theme + starter blocks), which goes beyond the empty input schema. Since there are no parameters, the effect of the description is to clarify the return data, which is already indicated by the output schema.

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

Purpose5/5

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

Description clearly states the tool lists 'the 8 curated style presets (theme + starter blocks) for link-in-bio'. The verb 'list' and specific resource 'style presets' is unambiguous. It differentiates from sibling tools which manage pages, accounts, blocks, and layouts.

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

Usage Guidelines4/5

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

The description explicitly states when to use: 'to offer the user a choice or to confirm a preset:auto selection'. It does not discuss when not to use or alternative tools, but the narrow scope makes that clear. A slight improvement would be to explicitly exclude page or layout tools from alternatives.

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

source.importImport Public SourceA
Read-onlyIdempotent
Inspect

Fetch a public website URL and extract a structured brief with business name, description, contact links, and suggested page blocks. Only works with public HTTP/HTTPS pages. Does not bypass login, CAPTCHA, or paywalls. Returns extracted fields and suggestedBlocks for use with page.create_from_brief.

ParametersJSON Schema
NameRequiredDescriptionDefault
localeNoPreferred output locale if obvious from the conversation, such as es or en.
sourceUrlYesPublic http/https source URL to import.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
briefYes
finalUrlYes
warningsYes
extractedYes
fetchModeYes
sourceUrlYes
confidenceYes
suggested_blocksYes
Behavior4/5

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds behavioral constraints (no login bypass) and mentions return type. No contradiction with annotations; adds context beyond what annotations provide.

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

Conciseness5/5

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

Two sentences, front-loaded with purpose and output. Second sentence covers constraints and return usage. No wasted words.

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

Completeness5/5

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

Output schema exists, so no need to detail return values. Description covers what the tool does, its limitations, and how the output is used. Complete for a simple tool with 2 parameters.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. Description adds minimal value: restates 'locale' purpose and 'sourceUrl' format. Does not provide additional semantics beyond schema.

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

Purpose5/5

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

The description clearly states the verb 'Fetch' and resource 'public website URL', and specifies the output 'structured brief with business name, description, contact links, and suggested page blocks'. It distinguishes from sibling tools like page.create_from_brief by noting the extraction output.

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

Usage Guidelines4/5

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

Explicitly states conditions: 'Only works with public HTTP/HTTPS pages' and limitations: 'Does not bypass login, CAPTCHA, or paywalls'. It implies usage context and when not to use, but does not explicitly list alternative tools for non-public pages.

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

Discussions

No comments yet. Be the first to start the discussion!

Try in Browser

Your Connectors

Sign in to create a connector for this server.

Resources