Create Web Page
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.
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.
Tool Definition Quality
Average 4.4/5 across 23 of 23 tools scored. Lowest: 3.7/5.
Each tool targets a distinct aspect of page creation/management (account, page, block, layout, preset, source import). No two tools have overlapping purposes; descriptions clearly differentiate them.
Tools use a dot-separated hierarchical pattern (e.g., block.add, page.publish) which is consistent within subgroups. However, minor inconsistencies exist like 'presets.list' vs 'layouts.list' (plural noun+action) and 'source.import' (verb-object order).
23 tools cover the full lifecycle of link-in-bio page creation and management. While slightly on the high side, each tool serves a specific function and the count is appropriate for the domain.
The tool set covers creation, editing, publishing, unpublishing, account management, and onboarding. Missing a direct page deletion tool, but the core workflows are well-supported.
Available Tools
23 toolsaccount.page.manageManage Claimed PageARead-onlyIdempotentInspect
Read a claimed account page without requiring an editToken. Use after OAuth when the user wants to manage a durable website.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The claimed pageId to manage. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=true and destructiveHint=false. The description adds behavioral context by stating no editToken is required, which is useful beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one required parameter, output schema exists), the description sufficiently covers when and how to use it, and the annotations cover safety. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter pageId is described in the schema as 'The claimed pageId to manage.' The description does not add extra meaning beyond the schema, and schema coverage is 100%, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a claimed account page' indicating a specific verb and resource. It distinguishes from siblings like page.get and page.claim by noting it does not require an editToken and is for managing a durable website.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: after OAuth when the user wants to manage a durable website. It implies the tool is for read-only management, but does not explicitly state when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
account.pages.listList Claimed PagesARead-onlyIdempotentInspect
List landing pages claimed by the authenticated account. This requires OAuth and is for account management, not first-time demo creation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of claimed pages to return. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| pages | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the OAuth requirement and the account management context, which are behavioral traits not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The first sentence states the core purpose, and the second adds essential context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single optional parameter and an output schema present, the description adequately covers purpose, auth, and usage domain. No significant gaps remain for a read-only listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage and the parameter 'limit' has a clear description. The tool description adds no additional parameter information beyond what the schema provides, justifying the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'claimed' pages for the authenticated account, using specific verb+resource. The title and description align perfectly. With no other page listing sibling tools, there's no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions OAuth requirement and clarifies the tool is for account management, not first-time demo creation. While it doesn't name alternatives, the context signals and sibling names implicitly guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
account.whoamiCurrent AccountARead-onlyIdempotentInspect
Return the current Create Web Page account context. Use this to check whether the user is authenticated or using an anonymous expiring demo.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| role | Yes | |
| service | Yes | |
| authMode | Yes | |
| accountId | Yes | |
| demoExpiresAt | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context about the return value (account context with authentication and demo info), which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, clear sentences. The first sentence states the action, the second explains when to use it. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema, the description fully explains the purpose and usage scenario. It is complete and leaves no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description has no need to provide parameter details. Baseline 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current account context and specifies checking authentication or demo status. It distinguishes from sibling tools like account.page.manage by focusing on identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it for checking authentication or demo status. While no when-not or alternatives are given, the context is clear and sufficient for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| block | Yes | The block to add. Must match one of the 13 allowed types with that type's strict props schema. The server generates the block id. | |
| pageId | Yes | ||
| editToken | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint false, destructiveHint false), the description adds vital behavioral detail: server generates block id, for published pages it saves only an unpublished revision, and it explicitly warns against calling page.publish/unpublish in the same turn. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: action first, then allowed types (though redundant with schema), then critical workflow instructions. It could be more concise by omitting the type list, but the information is clearly front-loaded and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 block types, oneOf schema, publish workflow), the description covers all essential aspects: action, constraints, server-generated id, draft behavior, workflow instructions, and nextSteps. Output schema exists, so not explaining return values is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 33%, the description adds minimal parameter-specific meaning. It repeats that block must match one of 13 types with strict props (already in schema) but does not explain pageId, editToken, or compensate for missing schema descriptions. The block object schema itself is detailed, but the description fails to add value for the less-documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Append a new content block to a link-in-bio page.' It specifies the action (append), the resource (content block to a page), and distinguishes from siblings like block.delete, block.update, page.publish by providing explicit workflow instructions not to call publish/unpublish in the same turn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (adding a block) and provides crucial guidance: for published pages it saves an unpublished revision, do not call page.publish in the same turn, and wait for user explicit request. It does not, however, compare with block.update or mention prerequisites like the page must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
block.deleteDelete Landing Page BlockADestructiveIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | ||
| blockId | Yes | ||
| editToken | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true, but the description adds critical behavioral context: 'For already-published pages, this saves an unpublished latest revision only.' It also warns about not publishing or unpublishing, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with the main action and uses multiple sentences for necessary warnings. While lengthy, nearly every sentence earns its place, though some repetition could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, no enums, has output schema), the description provides essential context about behavior on published pages and critical interaction rules. It is comprehensive enough for safe usage, but could elaborate on the return value or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by referencing 'blockId' and implying 'pageId' via 'page.get'. However, it does not explain the 'editToken' parameter. The behavioral context adds value, but parameter semantics are incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Delete one block by stable blockId.' It uses a specific verb and resource, distinguishing it from sibling tools like block.add, block.reorder, block.update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('Use page.get first if unsure which id to remove') and when not to use it ('Do not call page.publish in the same assistant turn... Do NOT call page.unpublish either'). It also instructs the agent to wait for user confirmation before publishing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
block.reorderReorder Landing Page BlockAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | ||
| blockId | Yes | ||
| toIndex | Yes | ||
| editToken | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which note mutation and non-destructive), the description adds key behavior: for published pages it saves an unpublished latest revision only. It also advises on not publishing immediately, which prevents unintended live updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each adding value. The core action is front-loaded, followed by behavioral nuance and instructions. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need no explanation. However, parameter semantics are missing, and edge cases (invalid blockId, pageId) are not addressed. The behavioral notes are helpful, but the tool lacks completeness in parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no parameter details. Parameter names (pageId, blockId, toIndex) are partially self-explanatory, but editToken is ambiguous and unexplained. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move a block to a new zero-based index') and the resource ('page main slot'). It distinguishes from sibling tools like block.add, block.delete, and block.update by specifying reordering rather than adding, deleting, or modifying properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong process guidance about not calling page.publish or page.unpublish in the same turn, which helps the agent manage state. However, it lacks explicit 'when to use' vs 'when not to use' compared to siblings; the context is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
block.updateUpdate Landing Page BlockAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it only saves an unpublished latest revision for published pages, validates props and types against strict schema, and implies a write operation (non-read-only, non-destructive). This adds context beyond the annotations (readOnlyHint=false, destructiveHint=false) and is consistent with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but well-structured, front-loading the core action and then adding usage guidelines. Every sentence contributes useful information, though it could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many block types, validation, publishing workflow), the description covers essential aspects: main action, effect on published pages, validation, and workflow cautions. It does not detail each block type (handled by schema) but is sufficiently complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself provides detailed descriptions for each parameter (100% coverage). The description adds value by explaining the merge behavior ('merged into existing props') and validation, which enhances the schema's meaning but is not necessary for every parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool patches a content block by stable blockId, specifying it is a partial update (props patch) and/or type change. This distinguishes it from sibling tools like block.add (add new block) and block.delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: it explains that for published pages it saves an unpublished revision, instructs not to call page.publish in the same turn, and advises against calling page.unpublish. It also differentiates from page.publish and page.unpublish clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
layouts.listList Available LayoutsARead-onlyIdempotentInspect
List supported page layouts. v1 ships link_in_bio only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. Description adds useful context that v1 only includes link_in_bio, informing the agent about the limited set of possible results. For a zero-parameter read-only tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with clear purpose, then adds version-specific detail. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, read-only nature, and presence of an output schema, the description is complete. It clearly communicates the tool's function and limitations. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% by default. Description adds value by stating the scope of layouts (link_in_bio only), providing context beyond the schema. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists supported page layouts, with specific verb 'List' and resource 'page layouts'. It also specifies the current version scope 'v1 ships link_in_bio only', which distinguishes it from other list tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like account.pages.list or presets.list. However, the context is clear enough for a simple listing tool with no parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.claimClaim Demo PageAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The pageId returned by page.create. | |
| editToken | Yes | The editToken returned by page.create for the anonymous demo page. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds context that claiming transfers ownership to the authenticated account, which is a behavioral trait beyond the annotations. It doesn't mention any edge cases like expiration, but overall it adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the action and inputs, the second provides usage guidance. No extraneous words, perfectly front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters, 100% schema coverage, annotations, and an output schema, the description is sufficient. It explains the purpose and when to use. It could mention the outcome of claiming (e.g., page becomes editable via other tools), but given the output schema likely covers that, it's acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both pageId and editToken. The description reinforces that these are 'returned by page.create,' which adds context but doesn't provide substantial new semantics beyond the schema. Given high coverage, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (claim), the resource (anonymous demo page), and the inputs (pageId and editToken from page.create). It distinguishes from sibling tools like page.create and page.get by specifying the context of 'keep or manage permanently'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this only when the user wants to keep or manage the website permanently,' providing clear when-to-use guidance. It could have elaborated on when not to use (e.g., if the page is not wanted), but the instruction is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| bio | No | Optional short bio for the header. | |
| slug | No | Preferred public URL slug. | |
| style | No | Free-form style hint used by preset:auto inference. | |
| title | Yes | Internal page title and default header display_name. | |
| layout | No | Layout id. Defaults to 'link_in_bio'. | |
| preset | Yes | Style preset id, or 'auto' to infer deterministically from businessType/style. | |
| displayName | No | Visible header display name. Defaults to title. | |
| businessType | No | Used by preset:auto inference. Examples: musician, restaurant, designer. | |
| initialPrompt | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description reveals that the tool creates a draft only, does not return a publish action, and warns that anonymous demo pages expire. It also advises not to invent content, adding behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that packs necessary information without redundancy. It is moderately concise but could be broken into shorter sentences for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, output schema exists), the description covers creation workflow, post-actions, and expiration. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 89% schema coverage, the description adds value by explaining the 'auto' preset inference from businessType/style and the roles of title/displayName. However, it does not detail all nine parameters, but the schema already covers them well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 'hosted link-in-bio page draft from a style preset', specifying the action and resource. It distinguishes from siblings like 'page.publish' and 'page.create_from_brief' by focusing on draft creation from presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it warns against calling 'page.publish' in the same turn unless the user explicitly asks to publish. It also instructs to use 'block.update' for content and to show the preview URL after creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| bio | No | Optional short bio for the header. | |
| offer | No | Planning context only. Not rendered directly as public page copy; use bio and publicSections for final-audience copy. | |
| style | No | Planning context only. Not rendered directly as public page copy. | |
| layout | No | Defaults to 'link_in_bio'. | |
| locale | No | ||
| preset | No | Style preset id, or 'auto' to infer deterministically. Defaults to 'auto'. | |
| audience | No | Planning context only. Not rendered directly as public page copy. | |
| location | No | Public business address or service area intended for map/address actions, not direct body copy and not the user's private/current location. | |
| sourceUrl | No | Provenance reference only. | |
| mustInclude | No | Planning checklist only. Do not put section names, CTA labels, owner instructions, or private notes here; not rendered directly. | |
| primaryGoal | No | Planning context only. Not rendered directly as public page copy. | |
| publicPhone | No | Public business phone number explicitly supplied by the user or a public source. Do not use the user's private/account phone. | |
| businessName | Yes | ||
| businessType | No | Planning context only. Not rendered directly as public page copy. | |
| heroImageUrl | No | Explicit user-provided image URL for featured-photo or full-image styles. | |
| sourceHandle | No | ||
| initialPrompt | No | ||
| preferredSlug | No | Desired 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. | |
| publicSections | No | Final-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. | |
| publicWhatsapp | No | Public WhatsApp phone number explicitly supplied by the user or a public source. Do not use the user's account phone or invent placeholder numbers. | |
| primaryActionId | No | ||
| fallbackLeadForm | No | Public 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. | |
| onboardingLayout | No | Layout style: background_color (minimalist), full (featured photo), or background_image (full image background). | |
| primaryActionUrl | No | Real 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. | |
| onboardingPalette | No | Palette id returned by page.onboarding.* paletteChoices, for example atom_dark_plum. | |
| primaryActionLabel | No | Public label for the primary action in the page's target language. | |
| publicBusinessEmail | No | Public business contact email explicitly supplied by the user or a public source. Do not use the user's ChatGPT/account email. | |
| onboardingSubCategory | No | Validated atom.bio subcategory id, for example health. | |
| onboardingMainCategory | No | Validated atom.bio category id from page.onboarding.*, for example physical-business or online-business. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that draft previews are customer-facing, planning fields are not rendered, and pages expire unless claimed. Aligns with annotations (readOnlyHint=false implying creation) and adds critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but somewhat lengthy; however, every sentence contributes useful guidance, and it is front-loaded with the core purpose. Minor room for tightening, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (29 params, nested objects, output schema exists), the description covers creation behavior, prerequisites, output elements, and post-call steps thoroughly. No gaps left for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), but the description adds value by clarifying which parameters are planning-only vs public copy, and by explaining how to use fields like fallbackLeadForm and publicSections. This goes beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a hosted landing page draft from a structured brief, listing inputs and outputs. It distinguishes from sibling tools like page.publish and page.create by emphasizing the draft-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to call page.publish in the same turn and advises asking for missing CTA destinations. Provides clear guidance on handling sparse briefs and avoiding invented content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.getGet Landing PageARead-onlyIdempotentInspect
Read a landing page draft, including its latest content JSON. For anonymous demo pages, include the editToken.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | ||
| editToken | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and non-destructive. The description adds context about reading 'latest content JSON' and the special case for anonymous demo pages with editToken. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant words. Front-loaded with the core action and key special case. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, read-only), the description covers essential aspects: what is read, content JSON inclusion, and demo page handling. Output schema exists, so return values are covered elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions pageId implicitly and editToken explicitly, explaining its use for anonymous demo pages. However, it does not detail format or constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a landing page draft and includes its latest content JSON, with a specific mention of anonymous demo pages requiring editToken. This distinguishes it from sibling tools like page.create or page.publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for reading drafts but does not explicitly state when to use versus alternatives like account.pages.list for listing or page.preview for previewing. No 'when-not' or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.header.updateUpdate Page HeaderAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| bio | No | Short bio under the display name. Pass null to clear it. | |
| pageId | Yes | ||
| showQr | No | Show a QR code for this page. | |
| verified | No | Show a verified checkmark next to the display name. | |
| editToken | No | ||
| displayName | No | Visible display name in the page header. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it explains that the tool creates an unpublished draft for already-published pages and provides workflow guardrails. There is no contradiction with the annotations (readOnlyHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but every sentence adds necessary context. It is front-loaded with the action and then provides usage guidelines. Slightly verbose but justified by complexity; could be tightened very slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, output schema exists), the description covers all essential aspects: what the tool does, parameter optionality, behavioral side effects, and correct sequencing. It is complete for a mutation tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (4 of 6 params described). The description reiterates the purpose of the four described fields but does not add meaning for pageId or editToken. The instruction 'Use only the fields you want to change' clarifies optionality, but overall minimal additive value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'Update the link-in-bio page header' and lists the specific fields (displayName, bio, verified checkmark, QR display). It clearly distinguishes from sibling tools like page.meta.update and page.publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed when-to-use and when-not-to-use instructions: it saves an unpublished revision for published pages, forbids calling page.publish in the same turn, and instructs the assistant to wait for explicit user confirmation before publishing or unpublishing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.intake.startStart Landing Page IntakeARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Preferred content locale if obvious from the conversation. | |
| sourceUrl | No | Public 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. | |
| primaryGoal | No | The main visitor action if known, such as book, call, WhatsApp, buy, or leave a lead. | |
| businessName | No | Only include if the user already provided the business or project name. | |
| businessType | No | Business category inferred from the user's words, such as hamburger restaurant or dental clinic. | |
| sourceHandle | No | Public social handle provided by the user. | |
| originalRequest | No | The user's original page-creation request, copied verbatim when available. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| mode | Yes | |
| title | Yes | |
| actions | Yes | |
| questions | Yes | |
| canCreateNow | Yes | |
| promptToUser | Yes | |
| missingFields | Yes | |
| sourceGuidance | Yes | |
| recommendedNextTool | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false. Description reinforces by stating 'Does not create a page' and discloses the return of guided questions. No contradictions. Adds behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no fluff. Front-loaded with purpose, then guidance and exclusions. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters fully described in schema, an existing output schema, and annotations, the description provides sufficient context. It explains the tool's role in the creation flow, its non-destructive nature, and when to use alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. Description adds value by listing key collected fields (businessName, sourceUrl, primaryGoal, locale) and providing usage constraints (e.g., 'Only include if user already provided' for businessName, caution about protected platforms for sourceUrl).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'minimal intake for first-page creation'. Distinguishes from sibling page.onboarding.start by contrasting features. Explicitly states returns guided questions and does not create a page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use and when-not: 'For a richer onboarding... use page.onboarding.start'. Also gives operational guidance: 'Call once per creation request; do not repeat if the user has already provided a source URL.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.meta.updateUpdate Page MetaAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Preferred public URL slug. | |
| title | No | Internal page title shown in editor results. | |
| pageId | Yes | ||
| seoTitle | No | SEO <title> tag value. | |
| editToken | No | ||
| seoDescription | No | SEO meta description value. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds critical context: for published pages, it creates an unpublished draft/revision, and it explicitly instructs not to call publish/unpublish. This goes beyond annotations to disclose behavior and workflow restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides detailed behavioral instructions. It is not overly verbose; each sentence serves a purpose. Slightly longer due to necessary workflow guidance, but still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of publishing workflows and the presence of sibling tools like page.publish and page.unpublish, the description is remarkably complete. It explains the impact on published vs. unpublished pages, the draft revision behavior, and the recommended interaction flow. An output schema exists, so return values are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (4 of 6 parameters have descriptions). The description restates the updateable fields (title, slug, seoTitle, seoDescription) but does not add extra meaning for pageId or editToken. It does not clarify formatting or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates internal page title, URL slug, and SEO title/description. It differentiates from sibling tools like page.publish and page.unpublish by focusing on the 'update' action, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions: for already-published pages, it only saves an unpublished latest revision. It warns not to call page.publish in the same turn, to stop and inform the user, and to wait for explicit user request to publish. It also advises against calling page.unpublish. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.onboarding.startStart Guided Page OnboardingARead-onlyIdempotentInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Preferred UI locale, such as es or en. | |
| originalRequest | No | ||
| suggestedSelection | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| mode | Yes | |
| stepId | Yes | |
| uiHtml | Yes | |
| choices | Yes | |
| selected | Yes | |
| nextPrompt | Yes | |
| canContinue | Yes | |
| profileCopy | Yes | |
| slugGuidance | Yes | |
| imageGuidance | Yes | |
| layoutChoices | Yes | |
| missingFields | Yes | |
| readyToCreate | Yes | |
| layoutGuidance | Yes | |
| paletteChoices | Yes | |
| primaryActions | Yes | |
| invalidSelection | Yes | |
| qualityChecklist | Yes | |
| recommendedLinks | Yes | |
| recommendedBlocks | Yes | |
| createFromBriefHints | Yes | |
| recommendedMissingFields | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, and the description reinforces this by stating the tool returns selections 'without creating a page'. It adds value beyond annotations by detailing the return types and the workflow, which is crucial for an AI agent to understand the tool's role.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the tool's purpose. Every sentence adds value, and the structure flows logically from purpose to return items to workflow steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only onboarding start tool with 3 optional parameters and an output schema, the description is generally complete: it explains what the tool does, what it returns, and how to proceed. Minor omission: it does not mention that locale is optional or default behavior, but the schema handles that partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (locale has description, but originalRequest and suggestedSelection subfields are partially documented). The description does not mention any parameters or their meanings, leaving significant gaps for an agent to understand how to use the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as the default first tool for first-page creation, listing specific outputs (category choices, layout options, etc.) and distinguishing it from siblings by outlining the workflow to page.onboarding.update and page.create_from_brief.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly states it is the default first tool for first-page creation and outlines the subsequent steps (pass to page.onboarding.update, then createFromBriefHints with page.create_from_brief), providing clear context for use. However, it does not mention any exclusions or alternative tools for this specific onboarding step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.onboarding.updateUpdate Guided Page OnboardingARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | ||
| stepId | No | ||
| selection | No | ||
| knownFields | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| mode | Yes | |
| stepId | Yes | |
| uiHtml | Yes | |
| choices | Yes | |
| selected | Yes | |
| nextPrompt | Yes | |
| canContinue | Yes | |
| profileCopy | Yes | |
| slugGuidance | Yes | |
| imageGuidance | Yes | |
| layoutChoices | Yes | |
| missingFields | Yes | |
| readyToCreate | Yes | |
| layoutGuidance | Yes | |
| paletteChoices | Yes | |
| primaryActions | Yes | |
| invalidSelection | Yes | |
| qualityChecklist | Yes | |
| recommendedLinks | Yes | |
| recommendedBlocks | Yes | |
| createFromBriefHints | Yes | |
| recommendedMissingFields | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with 'validate and return'. The description adds that it returns the next compact UI/prompt and remaining quality checklist, enriching behavioral understanding. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys purpose and parameters, though it is somewhat dense with many listed fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 4 parameters with nested objects and no required params, the description covers the tool's role in the onboarding flow and its output (next UI + quality checklist). It omits explanation of the output schema, but an output schema exists. Adequate for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description lists the fields the user can provide (category/subcategory, template style, palette, etc.), adding meaning beyond the schema's property names and types. For example, it explains that knownFields includes name, description, image availability, etc. However, stepId enum values are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates onboarding selections and returns the next UI prompt and quality checklist. It specifies the context: use after page.onboarding.start, and lists the user choices covered (category, template style, palette, etc.). This distinguishes it from siblings like page.onboarding.start and page.create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after page.onboarding.start', providing clear when-to-use context. It does not mention alternatives or when not to use, but the sibling context makes it clear this is part of the onboarding flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.previewPreview Landing PageARead-onlyIdempotentInspect
Return the current preview URL for a page.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The pageId returned by page.create. | |
| editToken | No | Required for anonymous demo pages. Use the editToken returned by page.create. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is read-only and non-destructive. The description adds no further behavioral details beyond the basic purpose, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It is appropriately front-loaded and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and simple parameters, the description is adequate. It could mention that the URL may change over time, but overall it is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The tool description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the resource ('the current preview URL for a page'), using a specific verb and resource that distinguishes it from sibling tools like page.get or page.publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives, though its purpose is self-evident. No exclusions or context cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.publishPublish Landing PageAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The pageId returned by page.create. | |
| editToken | No | Required for anonymous demo pages. Use the editToken returned by page.create. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide mutation and non-destructive status. Description adds context about publishing revision and returning nextSteps. However, it does not detail potential side effects (e.g., notifications) implied by openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with core purpose, then usage rules, special case, and output instruction. Three sentences, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers when to use, parameter guidance, and output handling. Lacks explanation of what 'publishing' means for page state (e.g., making it live), but sibling tools and output schema provide some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds value: clarifies editToken as required for anonymous pages and references page.create as source for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('publish the latest page revision') and specifies when to call it (explicit user request). It distinguishes from siblings like page.create by advising against immediate automatic publishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instructions on when to call (only on explicit publish/live/share request) and when not to (not automatically after create). Also provides condition for anonymous demo pages and output handling (share nextSteps).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.theme.updateUpdate Page ThemeAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | Yes | Partial theme patch. Provide only fields you want to change. | |
| pageId | Yes | ||
| editToken | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that for published pages, it only saves an unpublished latest revision. Warns against calling page.publish or page.unpublish. Adds context beyond annotations (which only indicate non-readOnly, non-destructive).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but each sentence serves a purpose: core action, constraints, workflow, and warnings. Front-loaded with the main action. Could be slightly trimmed but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, many enum fields, sibling tools), the description covers purpose, usage, behavioral traits, and links to presets. Output schema exists, so return values need no explanation. Complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description states 'partial theme patch' and 'provide only fields you want to change', which adds meaning beyond the schema's per-field descriptions. Schema coverage is 33% but nested objects have inline descriptions; description compensates with usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies a partial theme patch, distinguishing it from complete restyle via presets.list. The title 'Update Page Theme' and the verb 'Apply' with 'partial theme patch' gives a specific action on a resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (partial updates) and when not to (use presets.list for full restyle). Includes workflow guidance: not to call page.publish in same turn, and to wait for user confirmation. Clearly distinguishes from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page.unpublishUnpublish Landing PageADestructiveIdempotentInspect
Remove a published landing page from public availability while keeping its draft and revision history.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | ||
| editToken | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | Yes | |
| pageId | Yes | |
| status | Yes | |
| actions | Yes | |
| content | No | |
| claimUrl | Yes | |
| editToken | Yes | |
| expiresAt | Yes | |
| isClaimed | Yes | |
| nextSteps | No | Enrichment hints to present to the user. Address 'required' items before publishing. |
| canPublish | Yes | |
| previewUrl | Yes | |
| isPublished | Yes | |
| publishedUrl | Yes | |
| missingFields | No | |
| publishPolicy | No | For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing. |
| liveUpdateMessage | No | Plain-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. |
| liveUpdateRequired | No | True after an edit to an already-published page when the public live page still needs page.publish to reflect the latest revision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint as true, and the description adds valuable context by noting that draft and revision history are retained, reducing the perceived destructiveness. It does not cover permissions or reversibility, but the output schema may provide return value details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the main action. It communicates the essential function without superfluous words, though it could be slightly improved by adding brief parameter hints without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary effect (unpublishing while preserving history) but lacks details on prerequisites (e.g., page must be published), error conditions, or state changes. Given the presence of an output schema and the relative simplicity of the tool, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter description coverage, and the tool description does not explain the purpose of 'pageId' or 'editToken'. The agent receives no semantic guidance for these parameters, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'published landing page', and it distinguishes from sibling tool 'page.publish' by indicating the reverse action. It also specifies what is preserved (draft and revision history), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (when needing to remove public availability of a published page while keeping its content). However, it does not explicitly state when not to use it or provide comparisons with alternatives like page.delete, but the context from sibling tools implies the proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
presets.listList Style PresetsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive. Description adds that presets are curated and limited to 8, which provides useful context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action, no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description adequately covers purpose, scope (link-in-bio), and count. No additional context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4 applies. Schema coverage is 100%, description adds no param info but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'List' and the resource 'curated style presets', specifies count (8) and content (theme + starter blocks) for link-in-bio. Distinguishes from siblings like layouts.list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: to offer user choice or confirm auto-selection. Does not list alternatives or when not to use, but context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
source.importImport Public SourceARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Preferred output locale if obvious from the conversation, such as es or en. | |
| sourceUrl | Yes | Public http/https source URL to import. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| brief | Yes | |
| finalUrl | Yes | |
| warnings | Yes | |
| extracted | Yes | |
| fetchMode | Yes | |
| sourceUrl | Yes | |
| confidence | Yes | |
| suggested_blocks | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so safety is covered. The description adds important behavioral context: only public pages, no bypassing login/CAPTCHA/paywalls, and specifies return content. This goes beyond annotations to inform the agent of limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: main action, restrictions, returns. No redundant information, every sentence adds value. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 params and an output schema (not shown), the description is complete: explains purpose, limitations, output format, and ties to a sibling tool (page.create_from_brief). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds no additional parameter-level detail beyond the schema, but provides overall context that the tool extracts a brief. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a public website URL and extracts a structured brief with specific fields (business name, description, contact links, suggested page blocks). It distinguishes from sibling tools by specifying it imports external data, not managing existing pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: works only with public HTTP/HTTPS pages and does not bypass authentication. It implicitly guides when to use (when external source is needed) and mentions the output is for page.create_from_brief, but does not explicitly exclude other alternatives, though no direct sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!