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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds ordering semantics beyond that: results are newest first, but pinned answers may be hoisted to the top, which is a non-obvious behavior an agent needs when interpreting position. It also enumerates the returned fields and names the pagination handle.

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 and short, but it restates itself: 'newest first' appears twice (with the pinned caveat following each time) and the field list is duplicated across the two sentences. Tightening to one ordering clause and one field list would remove the redundancy without losing information.

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 only two optional parameters and no output schema, the description supplies what is otherwise missing: the shape of a returned item, the ordering rule including the pinned exception, and how to continue pagination. An agent can call and interpret results correctly from this. It stops short of enumerating defaults or limits, but the schema covers those.

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%, so limit and cursor are already documented, and the description adds little beyond repeating cursor semantics. Its one genuine addition is naming the response field next_cursor, which the input schema does not mention and is useful given there is no output schema. Baseline 3 applies.

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?

States a specific verb and resource ('Lists the answers on your profile') plus the scope and returned fields (question, text, URL, upvotes, views). This clearly separates it from question-oriented siblings like get_question or search_questions, though it never names an alternative explicitly.

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?

Usage is only implied by the possessive scope ('your answers', 'your profile'), which tells an agent this is self-scoped rather than a general search. There is no explicit when-to-use/when-not statement or pointer to a sibling such as search_questions for other users' content. The pagination instruction ('Pass next_cursor back as cursor') is the only concrete procedural guidance.

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