account.pages.listList 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. |
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | ||
| pages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the requirement for OAuth and clarifies the scope to 'claimed pages' for the authenticated account, which are useful behavioral details 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 two sentences, front-loaded with the primary action and resource. It avoids unnecessary detail and every word adds value, making it highly concise and 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?
For a simple list operation with one optional parameter, an output schema, and strong annotations, the description covers the necessary context: purpose, auth requirement, and a usage caveat. It lacks explicit pagination/ordering details, but the output schema and simple nature make it adequate.
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 defines the sole parameter 'limit' with constraints and a clear description, covering 100% of parameters. The tool description does not add any additional parameter semantics, so it relies on the schema, which is sufficient.
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 uses a specific verb ('list') and clearly identifies the resource ('landing pages claimed by the authenticated account'). It also distinguishes itself from demo creation by stating this is for account management, not first-time demo creation, which clarifies its role among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it requires OAuth and is intended for account management. It explicitly excludes first-time demo creation, giving a when-not-to-use signal, though it does not name specific sibling alternatives like 'page.create' or 'page.get'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target distinct resources and actions (blocks, accounts, pages), but page.create and page.create_from_brief both create pages, and page.intake.start vs page.onboarding.start/update are overlapping planning helpers. The detailed descriptions help disambiguate, though an agent might still pause on choosing between them.
All tool names follow a consistent lowercase dot-separated resource.action pattern (e.g., block.add, page.publish, account.whoami). Nested resources like page.header.update and page.onboarding.update extend the same rule without mixing conventions.
At 23 tools, the count sits in the borderline 16-25 range. Many tools are specific and justified, but the planning helpers (intake/onboarding) and multiple page creation variants add bulk that could be consolidated.
The server covers create, read, update, block management, and publish/unpublish, but misses a page.delete operation, leaving a lifecycle dead-end. Account tools are also minimal, limited to reading/listing without management capabilities.