research_start

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the asynchronous nature (requires polling research_status), time estimates for different modes (~30s for fast, ~5min for deep), expected result volumes (~10 sources for fast, ~40 sources for deep), and source limitations (deep mode is web only). However, it doesn't mention authentication requirements, rate limits, or error handling.

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 well-structured with clear sections (purpose, usage examples, workflow, parameter explanations) and every sentence adds value. It could be slightly more concise by combining some sentences, but the information density is high with no wasted words.

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 the tool's complexity (asynchronous research initiation with multiple parameters), no annotations, and the presence of an output schema, the description provides substantial context about behavior, workflow, and parameters. It doesn't need to explain return values since an output schema exists. The main gap is lack of information about authentication or error scenarios.

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?

With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for all 5 parameters. It explains what each parameter controls (query as search terms, source as location, mode as speed/depth tradeoff, notebook_id for existing notebooks, title for new notebooks) and provides concrete examples and constraints (e.g., 'deep mode is web only').

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's purpose with specific verbs ('search web or Google Drive to FIND NEW sources') and distinguishes it from siblings by focusing on initiating research workflows. It explicitly mentions the workflow sequence (research_start → poll research_status → research_import), which differentiates it from other tools like notebook_create or source_list_drive.

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 guidance on when to use this tool with concrete examples ('deep research on X', 'find sources about Y', 'search web for Z', 'search Drive'). It also specifies the workflow context and distinguishes it from sibling tools by focusing on research initiation rather than notebook management or source listing.

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