get_topic_page_content

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains that JSON output is render-ready and resolves cards by executing the swimlane widget's saved query, and mentions the hasMore flag and topicPageUrl. It lacks explicit details on read-only nature or error cases, but for a content retrieval tool this is sufficient transparency, earning a 4.

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, well-structured, and front-loaded with the primary purpose. The first sentence states what the tool does, followed by usage guidance and parameter clarification. Every sentence earns its place, and the line breaks improve readability. No unnecessary fluff.

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 no annotations and no output schema, the description provides comprehensive context: it explains the result structure (swimlanes, headings, nodeIds), the JSON output specifics, the maxPerSwimlane behavior, and how to resolve nodeIds with another tool. It also ties into the workflow with search_wlo_topic_pages, making it complete for a tool with 5 parameters and multiple output formats.

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 covers 100% of parameters, so the baseline is 3. The description adds value by explaining the relationship between variantId and collectionId, noting that variantId is faster, and explicitly stating that at least one is required (a constraint not captured in the schema). This goes beyond the individual parameter descriptions, meriting a 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?

The description clearly states the tool retrieves the content structure of a Themenseite (topic page), detailing swimlanes with headings and nodeIds. It explicitly differentiates from sibling tool search_wlo_topic_pages by noting the latter only returns a URL. This is a specific verb+resource+scope with clear distinction.

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 usage guidance: 'Use this AFTER search_wlo_topic_pages' and 'Resolve the returned nodeIds to human titles with get_nodes_details.' It also tells when to use variantId vs collectionId and that at least one is required, giving clear context for when to invoke this tool versus alternatives.

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