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

Annotations already cover read-only, idempotent, and open-world behavior, and the description does not contradict them. It adds useful non-obvious context: results are ranked, bodies are omitted, and returned question_ids feed stackexchange_get_thread. It does not discuss pagination or rate limits, but those are not required for a read-only search with an output schema.

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 front-loaded sentences: core action first, then return-value scope and a key limitation, then downstream workflow. Every sentence contributes distinct information, and the prose is compact without restating the schema at length.

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 tool is well-covered by the combination of a 100%-described schema, read-only/idempotent/open-world annotations, an output schema, and a description that explains the search-to-get_thread workflow and how to discover valid sites. An agent has everything needed to decide when to call it and how to invoke it correctly; the only implicit contrast with stackexchange_get_tag_faq is not material to correct invocation.

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 100%, so the input schema already documents every parameter's meaning, defaults, and constraints. The description mentions the `site` parameter and list_sites, but that guidance duplicates the schema rather than adding new semantics. Baseline 3 is appropriate because the schema carries the load and the description adds only marginal integration 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 opens with a specific verb+resource pair ('Search questions across a Stack Exchange site') and names the exact returned fields (title, score, answer count, accepted status, tags, excerpt), explicitly noting bodies are not included. It differentiates from stackexchange_get_thread by framing search results as providers of question_id values for that sibling, so an agent can distinguish searching from fetching full threads.

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?

It embeds the tool in a workflow: search to find ranked questions, then call stackexchange_get_thread for full bodies/answers, and call stackexchange_list_sites when site values are needed. 'No bodies at this stage' acts as a when-not signal for body retrieval, and the alternatives are named explicitly. This gives an agent clear decision guidance without needing to open sibling schemas.

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