probe_idea_question

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

With no annotations, the description carries the full burden and does most of it: it discloses the cache-miss precondition, that the tool performs technology search internally, and that the return contains question, options, and a cache_hit marker. It omits latency/cost and whether external network calls happen implicitly, so it is short of exhaustive but well beyond minimum.

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 with the core purpose, then workflow, args, and returns in clearly headed sections; every block is scannable. The Args/Returns sections restate some schema content and could be trimmed slightly, but there is no filler prose.

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 4-parameter tool with no output schema and no annotations, the description supplies the calling prerequisites, the meaning of every argument, and the shape of the return value. The only meaningful gap is that nothing is said about failure modes or cost when the internal technology search is triggered.

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 compensate, and it documents all four parameters: idea, domain as an accuracy hint for built-in knowledge matching, search_results with a concrete example format, and max_options with a recommended 8-15 range for long multiple-choice. Only `idea` stays at a bare restatement of its name, which keeps this just under full credit.

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+resource: on a cache miss for a new idea, search related technologies and generate a long multiple-choice counter-question. That is concrete enough to separate it from siblings like find_related_technologies or probe_technology_details, though it never explicitly names them, so the differentiation is inferred rather than stated.

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?

A numbered workflow tells the agent exactly when to call this tool (cache/knowledge-base miss), when not to (cache hit), and what to pass in each case, including handing over already-performed external search results. Nothing about invocation timing is left to inference.

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