list_landing_pages

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

No annotations are provided, so the description carries the transparency burden. It discloses that name_contains matching is client-side across several pages and that results may include a note when the search is cut short, which is genuinely behavioral information. However, it does not mention auth requirements, rate limits, or clarify that this is a read-only operation, though 'list' strongly implies it.

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 compact docstring with a one-line summary, an Args block, and a one-line Returns note. Every line adds necessary information, and the structure is front-loaded with the tool's purpose. It avoids fluff while still defining defaults and formats.

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 return dict shape, filter defaults, and the edge-case note when the search is cut short. With an output schema present, it does not need to fully enumerate return fields. It is slightly short on operational details like explicit pagination behavior beyond mentioning client-side multi-page matching, but for an optional-parameter list tool this is 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?

Schema description coverage is 0%, so the description must supply parameter semantics, and it does so thoroughly. name_contains is defined as a case-insensitive substring, state has an enumerated default of ANY, language expects ISO 639-1, updated_after expects ISO 8601, and limit has a numeric range and default. This fully compensates for the empty schema descriptions.

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 opens with 'List landing pages,' a specific verb+resource statement. The resource type distinguishes it from sibling list tools like list_blogs and list_site_pages, and the filter list reinforces that this is a listing operation. No ambiguity remains about what this tool does.

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?

There is no explicit statement about when to choose this tool over list_site_pages or get_page. The description implies usage via the list verb and filter parameters, but it does not state exclusions or direct the agent to an alternative for specific scenarios. This is clear context without explicit alternatives or when-not guidance.

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