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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that no credentials are returned, which is a security-relevant trait, but it omits whether the tool performs network requests, requires authentication, or has side effects.

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 a single, front-loaded sentence that delivers the core purpose and one key behavioral caveat without any wasted words. Perfectly sized for a simple status-check tool.

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 simplicity, a complete input schema, an output schema that covers return values, and no annotations, the description covers the essential purpose and a security note. It falls short only on usage context and deeper operational behavior, which are minor for this type of read-only query.

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%, and the schema fully documents the optional profile parameter. The description adds no additional meaning about the parameter, so baseline 3 is appropriate.

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 gives a specific verb (查询/query) and resource (本地登录与在线状态/login and online status) scoped to the NotebookLM upstream. It does not explicitly differentiate from the sibling dossier_status, so the agent must infer the distinction from the name.

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 states what the tool checks but offers no guidance on when to use it versus alternatives like dossier_status, nor any prerequisites or exclusions. Usage context is left entirely to inference.

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

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

With no annotations, the description carries the full burden and does add real behavioral context: it discloses the task is asynchronous, and enumerates enforced comparison semantics (mere non-mention ≠ opposition, conflicting conclusions require dual citations, reprints merged, reports not double-counted). It omits auth requirements and failure/error behavior, so not a 5.

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?

Purpose is front-loaded, followed by enforced rules and the parameter note. Dense but each clause adds substance; no filler sentences, though the rule block is somewhat terse in phrasing.

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?

An output schema exists, so return-value detail is unnecessary. For a 3-param async tool with no annotations, the description covers the async nature and the key validation rules; gaps remain on how to retrieve results (delegated to siblings) and on research_id/questions format.

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% across 3 parameters, so the description must compensate. It ably explains 'statements' (host AI's pre-formed comparison draft via HostStatementInput, merged and validated against NotebookLM results), but leaves 'research_id' and 'questions' undefined beyond their names.

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 (compare source viewpoints by common questions) and the concrete output (consensus/differences/gaps). The parenthetical '后台任务，返回任务号' (background task, returns task number) distinguishes it from synchronous siblings like dossier_result, so an agent can route to it correctly.

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 'background task, returns a task number' note implies the async flow (call, then poll status/result), which is useful usage context. However, no sibling is named as an alternative and there is no explicit when-to-use vs dossier_query/dossier_evidence guidance, so usage is implied rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool is asynchronous (returns a task number), runs separate sessions per source, and verifies quotes against source text. However, it omits how to poll for completion, auth/permission needs, failure behavior, and whether repeated calls create new jobs.

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?

Two dense sentences front-load the primary action and return value, then enumerate the card contents. There is no filler, though the second sentence is a long enumeration that could be slightly tighter.

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?

An output schema exists, so return-card fields need not be fully explained, and the description does note the task-number return. Still, for an asynchronous generation tool with no annotations and 0% parameter coverage, critical gaps remain around parameter meaning and how to retrieve results.

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% for three parameters. The phrase 'per source' loosely connects to source_ids, but research_id and the optional questions array receive no explanation. The description does not compensate for the complete lack of schema-level parameter documentation.

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 states a specific action (generate evidence cards per source), its scope (one session per source, source-only basis), and the immediate return (task number). It distinguishes itself from general query tools through the per-source evidence-card framing, though it does not explicitly name a sibling alternative.

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 implied by the per-source evidence-card purpose, but the description never states when to choose this tool over siblings like dossier_query or dossier_compare, nor does it mention prerequisites or exclusions. An agent can infer intent but gets no explicit routing guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose useful behavior: the export excludes Cookies, tokens, and browser Profile, and every judgment links to source/evidence IDs. However, it omits whether the tool writes files to disk, whether it overwrites existing output, what auth is required, and whether the operation is reversible.

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?

Two compact sentences with the artifact list and the privacy constraint front-loaded. No filler; the second sentence carries the meaningful caveat.

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?

An output schema exists, so return values need not be described, which the definition correctly relies on. But given zero annotation coverage and 0% parameter coverage, the description is incomplete about side effects (file writing) and the semantics of its own parameters.

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 for parameters, and it does not. None of the three parameters (research_id, angles, output_dir) are explained – in particular output_dir and angles are left entirely opaque, and the listed export contents are not the same as the parameters.

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 names a specific verb (导出/export) and resource (文章研究底稿/dossier) and enumerates the artifact types produced (manifest, 报告, sources, evidence, viewpoints, writing-brief). This makes the tool's output concrete. It stops short of explicitly contrasting itself with siblings like dossier_result or dossier_query, so the agent must infer the 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?

There is no guidance on when to use export versus the other dossier tools (result, status, query, compare). No prerequisites, no preconditions, no named alternatives. The agent gets 'what' but not 'when'.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that imports are recorded one-by-one and may yield 'uncertain results', and names the external target (NotebookLM), but says nothing about authentication needs, idempotency, side effects on the destination notebook, or what triggers the task-ID mismatch that confirm_task_id resolves.

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?

A single front-loaded sentence covering the action and its two recording obligations. There is no filler, though it is terse enough that the surrounding context that would aid selection is absent.

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?

An output schema exists so return values need no explanation, but this is a mutation tool writing to an external system with no annotations. Given the complexity signaled by the reconciliation and task-confirmation parameters, the description omits too much about preconditions and failure modes to be considered complete.

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 the schema already fully documents all five parameters including defaults and the reconciliation and confirmation semantics. The description adds no parameter-level detail beyond that, so the 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?

The description states a specific verb plus resource plus destination: it imports the selected discovery sources into NotebookLM and records the mapping. An agent can distinguish it from dossier_export and dossier_source_get by the 'import into NotebookLM' action, though no sibling is named 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as dossier_source_get for inspecting sources first or dossier_export for the inverse direction. The existence of a reconcile_only mode is only visible in the schema, not framed as usage guidance in the text.

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

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

With no annotations the description carries the full burden. It usefully discloses non-obvious traits — the source set is software-enforced, sessions default to new, and citation numbering is only valid within a single answer (with a citation_key format). It omits auth requirements, error/idempotency behavior, and confirmation that the call is read-only, leaving important gaps.

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?

Two dense sentences, with purpose front-loaded and constraints following. Parentheticals carry genuinely useful detail, so little is wasted, though the packing is on the terse side.

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?

An output schema exists, so return structure need not be re-explained, and the description adds citation-validity context. However, with 5 parameters at 0% schema coverage, no annotations, and 3 required fields, the semantics of research_id, question_id, and conversation_id remain unaddressed.

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% across 5 parameters, so the description must compensate. It clarifies source_ids (pass a single source for per-source evidence) and implies conversation_id via the 'default new session' note, but says nothing about question_id or research_id, so it only partially covers the parameter set.

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 (ask NotebookLM a question over a software-enforced source set) and hints at the per-source evidence case, which points toward the sibling dossier_evidence. It does not explicitly name or contrast with siblings, so this lands just below the sibling-differentiating top score.

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?

Gives real usage context: a new conversation is the default, and to do per-source evidence you must pass only one source. This is clear conditional guidance, though it never explicitly says when to prefer dossier_evidence or dossier_compare over this tool.

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

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

No annotations are provided, so the description carries the full burden; it discloses pagination behavior, view-specific contents such as cite_map and citation_warnings, report cursor/max_chars semantics, the digest length cap, and the deprecated include_report_text behavior. Remaining gaps include default pagination behavior and whether limit/cursor apply consistently across all views.

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 front-loaded with purpose and the view list, then adds useful view-specific details and a deprecation note. It is dense but efficient, with little wasted text.

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 output schema exists, so return values need not be fully explained, but the tool still has 6 parameters, 0% schema descriptions, no annotations, and seven view values of which four are undocumented. The description is adequate for the main views but incomplete for the full tool surface.

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. It explains view, cursor, max_chars, and include_report_text to some extent, but only details findings/report/digest; it leaves evidence, comparisons, tasks, answers, and the limit parameter without semantic guidance.

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: paginated reading of research results, with a list of supported views. The scope is clear, but it does not explicitly distinguish this tool from siblings such as dossier_evidence, dossier_compare, or dossier_query.

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?

Provides implied guidance by describing findings as the complete source, report as full-text pagination, and digest as a summary, plus a recommendation to use view='report' instead of include_report_text. However, it gives no when-to-use guidance for the other view values or for choosing this tool over sibling tools.

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

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

With no annotations, the description carries the full burden. It does add real contract value — return payload composition (version hash, acquisition time) and the rule that absent metadata stays null rather than being model-filled. However it says nothing about the effect of limit/offset on the excerpt, failure modes for an unknown source_id, or auth requirements.

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?

Two compact sentences with the core payload described first and the null-handling caveat second. Nothing is padded, though the parenthetical could be folded in more tightly.

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?

An output schema exists, so return-value detail is rightly omitted, and the null-preservation rule is a useful addition. Still, with zero annotation coverage and undocumented pagination parameters, an agent lacks enough to call this confidently against its many siblings.

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% and all four parameters (research_id, source_id, limit, offset) are bare types. The description never maps limit/offset to excerpt sizing or clarifies the identifier semantics, so it fails to compensate for the schema gap.

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 states a concrete verb (取得) and a specific resource (单个来源的元数据与索引文本摘录), enumerating the payload components (内容版本哈希、取得时间). It is clearly a single-source fetch as distinct from collection-level siblings like dossier_query or dossier_result, though it never names those siblings 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?

There is no statement of when to use this tool versus the nine siblings, nor any prerequisite (e.g. that research_id must come from dossier_start). Usage is only implied by the word 单个来源. The closing sentence is a data-fidelity rule, not usage guidance.

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

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

With no annotations, the description carries the full burden and does disclose the key traits: the call is asynchronous (returns research_id immediately rather than blocking for results), it creates a Notebook resource per topic, and duplicate request_key calls return the existing task instead of re-launching research. It omits auth requirements (a sibling dossier_auth_status hints one is needed) and any cost/rate-limit context, keeping it below 5.

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 short sentences, front-loaded with what the tool does, followed by the per-topic rule and the idempotency contract. No filler or repetition of structured fields.

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?

An output schema exists, so return fields need not be enumerated, and the description correctly covers the async launch contract, resource-creation semantics, and idempotency. The main remaining gap is that no auth prerequisite is mentioned for a tool that clearly creates server-side state.

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 a 3 is the baseline; the description earns a bump because it explains the functional effect of request_key (same key returns an existing task rather than starting duplicate research), which is more than the schema's terse 'optional idempotency key'. topic/scope/title are left to the schema, which already documents them adequately.

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: launches a NotebookLM Deep Research (web + deep) and immediately returns a research_id. It is clearly distinguished from the polling/result/export siblings by being the entry point that produces a research_id. It stops short of naming which sibling consumes that id (e.g. dossier_status), so it is clear but not fully self-locating.

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 gives two useful usage rules: one research Notebook per independent topic, and idempotent behavior via request_key. However, it never states when to call this versus its siblings (e.g. that dossier_status/dossier_result follow), nor any preconditions such as required auth. Usage is implied rather than spelled out.

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

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

No annotations, so the description carries the full burden and rises to it partly: it discloses that completion persists the full compact=False result and warns that source statistics is not the same metric as discovery/import. It omits auth requirements, error behavior, or rate limits beyond the long-poll cap already in the 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?

Four compact sentences, front-loaded with the core purpose before the completion-save and metrics caveats. Each sentence carries information, with no repetition of schema content.

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?

An output schema exists, so return values need not be explained, yet the description usefully foreshadows phase/elapsed_ms/sources_discovered and the adaptive poll hint. For a two-param status tool with full schema coverage, this is sufficient, with only permission and failure-mode context missing.

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%, including the wait_seconds long-poll semantics, so the schema does the parameter work. The description adds no parameter-level meaning beyond what the schema already provides; baseline 3 is appropriate.

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: querying research task status, plus syncing the full report and the list of discovered sources. It is clear enough to separate it from dossier_result, which returns the finished result, but the description never names the sibling, so differentiation is implied 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?

There is no explicit when-to-use or when-not-to-use guidance, nor a named alternative among the many siblings. Usage is only implied by the mention of suggested_next_poll_seconds, which signals this tool is meant for polling.

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