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

Annotations only say readOnly=false, openWorld=true, idempotent=false, destructive=false. The description adds what actually matters for a long-running job: it consumes user quota, runs for several minutes, is gated by a confirmation flag, is asynchronous, and the result must be polled via studio_status before a download_url exists. None of that is recoverable from the annotations.

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 dense sentences, front-loaded with what the tool produces before the operational caveats. No filler, no repetition of the title, and every clause carries actionable 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?

An output schema exists so return values need no explanation, and the description still closes the loop on async completion (poll studio_status, then fetch download_url). For a 7-parameter, non-idempotent, quota-consuming generation tool, nothing an agent needs to call it correctly is 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%, so every parameter including confirm, format, source_ids, and language is already documented in the schema. The description restates the confirm contract and the provenance of source_ids and notebook_id rather than adding new syntax or constraints. 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 ('Start generating an Audio Overview') and immediately defines the artifact: 'a podcast-style conversation between two AI hosts about the notebook's sources'. That level of detail is enough to separate it from siblings like video_overview_create, infographic_create, or slide_deck_create without opening any schema.

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 the preconditions ('uses the user's NotebookLM quota and takes several minutes, so agree on the options with the user first'), the exact two-phase invocation contract (confirm=false returns pending_confirmation, confirm=true returns artifact_id), and the follow-up path ('poll studio_status until that artifact is completed'). It also implicitly routes the agent to notebook_get for source_ids and studio_status for retrieval.

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?

Annotations already cover the safety profile (idempotent, non-destructive, open-world), but the description adds real context beyond them: it reads the live page with saved cookies, its failure mode is an auth error when the Google session is signed out, and the remediation path. It stops short of describing how a stale/missing cookie differs from a signed-out state.

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-loads the action and its mechanism, then failure handling and the call-once instruction. Compact overall, though the semicolon clause carrying the remediation command is slightly awkward to parse.

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 zero-parameter session-refresh tool with an output schema already documenting return values, the description covers mechanism, failure mode, and next step. An agent has everything needed to call it correctly and react to failure.

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?

The tool takes no parameters, so the baseline is 4. The description correctly adds no parameter detail because none exists; there is nothing the schema fails to cover.

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 (re-read/refresh) and resource (CSRF token and session ID) and explains the mechanism (saved cookies). An agent can distinguish it from the auth_save_tokens sibling by the 'refresh existing session' framing.

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?

Explicitly states when to call it ('once after an auth error, then retry') and what to do on failure (direct the user to run the CLI auth command). It does not contrast with the sibling auth_save_tokens, so the save-vs-refresh choice 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.

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the overwrite behavior is partly covered; the description usefully specifies what is destroyed (the existing ~/.notebooklm-mcp/auth.json contents), that the next call consumes the new tokens, and adds a security constraint about not echoing secrets. No contradiction with annotations.

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 purpose and destination are front-loaded, and most sentences carry distinct information (destination, replacement, confirmation, alternative, constraint). It is slightly dense with five clauses, but every sentence earns its place.

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 elaboration, annotations carry the safety profile, and the schema fully documents parameters; the description covers destination, overwrite semantics, and security handling. It is nearly complete, with only the sibling auth_refresh relationship left implicit.

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 each parameter (cookies, csrf_token, session_id) is fully documented there, including the required SID/HSID/SSID/APISID fields. The description only restates that csrf_token and session_id are optional, adding no syntax or format detail beyond the schema, 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 (save) and resource (NotebookLM cookies plus optional CSRF/session IDs) and names the exact destination file (~/.notebooklm-mcp/auth.json), so the purpose is unambiguous. It does not explicitly differentiate itself from the sibling auth_refresh, which is the nearest alternative, so it stops short of a 5.

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 gives an explicit alternative ('Prefer the CLI auth command') and a precise gating condition ('Use this only when the user hands you cookies'), plus a handling constraint ('never echo them back'). It frames itself as a manual fallback, so an agent knows both when to reach for it and when not to.

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?

Adds substantial context beyond the annotations: consumes the user's NotebookLM quota, takes several minutes, confirm=false is a no-op returning pending_confirmation, confirm=true returns artifact_id, and the artifact has no downloadable file (viewed in-app). None of this is derivable from the annotation set.

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 tightly packed sentences, front-loaded with the core action and the quota/time cost, followed by the confirm-gate behavior and the polling follow-up. Every clause carries actionable 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?

For a long-running, quota-consuming async generation tool this covers cost, latency, the confirmation contract, the completion-tracking path, and the fact that no download artifact is produced. An agent has everything needed to call and follow up correctly.

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 schema already documents all four parameters including the confirm gate and difficulty. The description largely restates the confirm behavior (pending_confirmation/artifact_id) rather than adding syntax or format detail beyond the schema, so the baseline of 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: generating study flashcards from a notebook's sources. It is clearly distinguishable from sibling artifact creators (quiz_create, report_create, slide_deck_create) and names the scoping input (notebook sources).

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 a clear precondition ('agree on the options with the user first') and post-call workflow ('poll studio_status until that artifact is completed'). It stops short of explicitly contrasting with alternative artifact types (e.g. quiz_create) for the same notebook, so it is strong but not fully routing.

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?

The description adds substantial behavioral detail beyond annotations: it consumes NotebookLM quota, takes several minutes, requires a two-step confirmation flow (confirm=false returns pending_confirmation; confirm=true returns artifact_id), and requires polling studio_status until completion. This goes well beyond what the annotations disclose.

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 sentences, front-loaded with the core purpose, then usage guidance, then the two-phase workflow. No filler; every sentence contributes critical 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?

Given that an output schema exists and annotations cover safety signals, the description is complete: it explains the asynchronous generation flow, the confirmation requirement, and the polling step needed to retrieve the result. No essential invocation detail is 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%, so all seven parameters are fully documented in the schema itself. The description only reiterates the confirm behavior and does not add new meaning beyond the schema for other parameters like orientation, detail_level, or focus_prompt.

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 clear verb and resource: 'Start generating an infographic: a single image that summarises the notebook's sources visually.' It distinguishes the artifact type from other creative outputs (audio, video, slides, reports), though it does not explicitly contrast with those sibling tools.

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 provides clear usage context: agree on options first, use confirm=false for a dry run, confirm=true to start generation, then poll studio_status. It does not, however, explicitly state when to choose an infographic over a sibling tool like slide_deck_create.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false; the description reinforces the non-idempotent trait concretely ('Each call creates another notebook') and explains the return value's role ('keep its id for every later call'). It doesn't mention auth requirements, rate limits, or title uniqueness enforcement, so it stops short of fully rich disclosure.

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: identity, duplicate-avoidance prerequisite, then follow-up actions. The safety-relevant warning is front-loaded ahead of the downstream workflow, and nothing is padding.

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 an output schema present, return values need no prose explanation, and annotations cover the safety profile. The description supplies exactly the missing pieces for a non-idempotent creation tool: duplicate-check guidance and the id-retention habit.

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?

Only one parameter and schema coverage is 100%, so the schema already documents 'title' as the notebook title. The description adds no format, length, or uniqueness constraints on the title, 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?

States a specific verb and resource ('Create an empty NotebookLM notebook') plus the scope qualifier 'empty', which tells the agent this tool allocates a container rather than populating it. This distinguishes it cleanly from source_add_*, research_start, and notebook_rename among the siblings.

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?

Explicitly warns that every call creates another notebook and directs the agent to check notebook_list for an existing one with the same title first. It also prescribes the follow-up path by naming source_add_url, source_add_text, source_add_drive, and research_start as the fill options.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description still adds real value by spelling out the confirm two-phase flow (returns pending_confirmation vs performs deletion), the irreversibility ('This cannot be undone'), and an explicit approval requirement. It doesn't mention permission/scope needs, so not a full 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 tight sentences, front-loaded with the irreversible action, then the confirm mechanics, then the safety instruction. Every sentence earns its place with no restatement of the name or title.

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 destructive two-parameter tool with full schema coverage, an output schema, and annotations covering the safety hints, the description supplies the remaining needed context: irreversibility, confirm behavior, and the approval precondition. Nothing an agent needs to invoke it safely is 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%, and both parameters (notebook_id, confirm) are already documented in the schema with the same confirm semantics. The description adds no format or syntax detail beyond the schema, 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 names a specific verb and resource ('Permanently delete a notebook') and states the full scope ('everything in it'), immediately distinguishing it from siblings like notebook_rename or notebook_get. An agent can tell what this does and how destructive it is without opening the schema.

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 gives clear preconditions: name the notebook to the user and get explicit approval before invoking, and explains the confirm=true/false gate. It doesn't explicitly name alternatives (e.g., notebook_rename for non-destructive edits), so it stops short of full when/when-not routing, but the usage context is unambiguous.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description's return-field summary is useful but largely duplicates the existing output schema, adding little behavioral context beyond what annotations and schema supply.

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 sentences with the purpose front-loaded and no filler, and the return/source-type enumeration is at least informative. The field list is mildly redundant given a full output schema exists, keeping it just short of a 5.

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 an output schema present, the description need not explain return values, and it correctly focuses on purpose and downstream ID use. It is essentially complete for a simple read tool, though it omits failure behavior (invalid or missing notebook_id).

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 single notebook_id parameter is documented in the schema as coming from notebook_list or notebook_create. The description adds nothing about the parameter, so the baseline 3 for a fully covered schema 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 ('Get one notebook's details') and explicitly scopes to a single notebook, which cleanly separates it from notebook_list. It also enumerates what the response contains (title, emoji, ownership, timestamps, sources), so an agent knows exactly what it is retrieving.

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 clear usage contexts: fetching source IDs for notebook_query and the Studio tools, or verifying that a newly added source appeared. It names the downstream consumers explicitly, but never states when not to use it (e.g. use notebook_list to enumerate) or any prerequisite such as the notebook existing.

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?

The annotations already declare readOnly/idempotent/openWorld/no-destructive, so the safety profile is covered. What the description adds beyond that is genuinely useful: the scope of results (owned and shared) and, critically, the non-obvious paging behavior keyed off count vs max_results. It stops short of describing ordering or total-availability limits, 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?

Three sentences, each carrying distinct load: contents returned, routing to the sibling tool, and the paging caveat. Front-loaded with the core purpose and no filler.

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 field enumeration is technically redundant but harmless, and the description's real gaps to close — result scope and the absence of paging — are both addressed. Nothing an agent needs to call this correctly is 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 coverage is 100% and the single parameter (max_results) is documented, so the baseline is 3. The description earns extra credit by explaining the semantic consequence of max_results — the result set is truncated with no paging cursor, and count == max_results signals more data. That is meaning the schema alone does not convey.

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?

Specific verb+resource ('List the user's NotebookLM notebooks, owned and shared') and it explicitly distinguishes itself from notebook_get by stating 'Start here to find a notebook_id by title; once you have the id, notebook_get reads one notebook.' An agent can pick between the two without opening either schema.

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 explicit entry-point guidance ('Start here to find a notebook_id by title') and names the natural follow-up tool and its condition. It also covers the retry condition ('if count equals max_results, call again with a higher max_results'), leaving little 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?

Adds substantial context beyond the annotations: it discloses that the answer keeps bracketed citation numbers like [1] but loses the passage mapping, that it returns a conversation_id, and that server-side conversation memory is ephemeral ("while it keeps running"). The readOnlyHint=false is consistent with creating conversation state, so there is no contradiction.

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 dense sentences, front-loaded with the core action and scope, then return shape, then the follow-up mechanism. No filler or repetition of the schema.

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 re-explained, and the description covers the remaining gaps: source scoping, citation limitation, and conversation persistence. An agent has everything needed to invoke it correctly.

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 baseline is 3. The description still adds meaning: it clarifies the source_ids scoping behavior (all sources otherwise) and explains the follow-up role of conversation_id, going slightly beyond the per-field schema text.

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 (ask a question) and resource (NotebookLM notebook) with an explicit scope restriction: it answers only from the notebook's sources, all of them or source_ids. This distinguishes it from siblings like notebook_summarize or research_start without opening their schemas.

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 clear operational context: restrict answers to all sources or specific source_ids, and pass conversation_id back to continue a conversation. However, it never explicitly contrasts this with alternative tools (e.g., notebook_summarize), so the agent must infer when Q&A is preferred over other retrieval options.

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?

Annotations already declare readOnly=false, idempotent=true, destructive=false. The description adds real value beyond that by specifying the mutation scope (sources and chat are untouched) and the return shape (a confirmation message with the new title). It does not cover permissions or failure modes, keeping it short of 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?

Three short sentences, each earning its place, with the mutation and its non-effects front-loaded and the prerequisite last. No filler.

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 needn't be elaborated, yet the description still summarizes the confirmation message. For a two-param idempotent rename, everything an agent needs is present.

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 both params are fully documented in the schema. The description's mention of notebook_id/notebook_list marginally reinforces this but adds no syntax or format detail beyond the schema. Baseline 3 is correct.

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 ('Change a notebook's title') and immediately scopes what is NOT affected ('its sources and chat stay as they are'). This clearly distinguishes it from siblings like notebook_create, notebook_delete, or source_* tools.

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 a concrete prerequisite: 'Find the notebook_id with notebook_list first.' Clear context for invocation, but no explicit when-not-to-use or alternative-selection guidance (e.g., when to rename vs. create).

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds non-obvious behavior: the output is AI-generated, contains the notebook's coverage plus NotebookLM's suggested follow-up questions, and is a whole-notebook (not per-source) view. That is real context beyond the annotations and 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 tight sentences, front-loaded with the action, then the return content, then the routing guidance. Every sentence carries information an agent needs; nothing is decorative.

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 one-parameter, read-only tool with an output schema and full annotation coverage, the description supplies everything still needed: what it does, what it returns conceptually, and when to prefer siblings. No material gap remains.

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?

A single parameter with 100% schema description coverage, so the schema already documents notebook_id and its provenance (notebook_list / notebook_create). The description adds no syntax or format detail beyond that. Baseline 3 is correct when the schema does the heavy lifting.

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 ("AI-generated overview of the whole notebook") and explicitly scopes it to the entire notebook rather than individual sources or targeted Q&A. It distinguishes itself from notebook_query and notebook_get by name, so an agent can route without opening schemas.

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 an explicit positive trigger ("use it to get oriented in an unfamiliar notebook") and names two alternatives with their own conditions: notebook_query for specific questions, notebook_get for listing sources. Nothing 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.

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

Goes beyond annotations by disclosing quota consumption, multi-minute latency, the confirm=false no-op, the artifact_id return, the need to poll studio_status, and the absence of a downloadable file. These operational details are exactly what an agent needs for a long-running write.

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 with no filler; the purpose and the critical confirm/polling behavior are front-loaded.

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 output schema and annotations, the description covers the remaining agent-critical context: cost, latency, confirmation flow, polling handoff, and artifact access. Nothing essential is omitted.

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 documents confirm, difficulty, question_count, source_ids, and notebook_id. The description restates confirm semantics but adds no new parameter-level details beyond the schema, making the baseline 3 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 the specific action (start generating) and resource (multiple-choice quiz from notebook sources), which distinguishes it from other studio creation tools such as flashcards_create or audio_overview_create. The description is front-loaded and specific.

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 clear procedural guidance: agree on options first, use confirm=false for a no-op preview, confirm=true to start. It does not explicitly name when to choose this over sibling creation tools, so it gives clear context rather than a full alternatives map.

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?

Goes well beyond the annotations: states quota consumption, multi-minute latency, the exact no-op behavior of confirm=false (returns pending_confirmation), the artifact_id returned by confirm=true, and the non-obvious fact that this artifact has no downloadable file and must be opened in NotebookLM. That is exactly the context annotations cannot convey.

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?

Dense but front-loaded: purpose first, then cost/workflow, then return-value caveat. Only mild redundancy with the schema's confirm description, and the long single-paragraph form makes the workflow steps slightly harder to scan than they could be.

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 long-running, quota-consuming generation tool with an output schema, the description supplies everything needed to call it safely: prerequisites, side effects, confirmation semantics, follow-up polling, and where the result is consumed. Nothing material is 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 coverage is 100%, so the baseline is 3, but the description adds real value by linking report_format to the 'Create Your Own' option that requires custom_prompt, a relationship the per-field schema text does not make explicit. Minor: it does not mention language or source_ids scoping.

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?

Opens with a specific verb+resource ('Start generating a written report from the notebook's sources') and enumerates the concrete formats available. It is clearly distinguishable from the sibling studio generators (audio_overview_create, video_overview_create, quiz_create, etc.) because it names 'written report' and its formats.

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?

Explicitly instructs to 'agree on the options with the user first' because it consumes the user's quota and takes minutes, and describes the two-step workflow (confirm=false previews, confirm=true starts, then poll studio_status). It names the follow-up tool and the condition that triggers it.

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?

Annotations cover safety (readOnly=false, destructive=false, openWorld=true, idempotent=false); the description goes further by disclosing partial-success semantics ('fetches each URL and skips any it can't reach'), the return message shape, the import_failed error state, and that a retry may succeed. The one notable gap is that it never states whether re-importing the same results creates duplicate sources, which matters given idempotentHint=false.

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 tight sentences, front-loaded with the action and the importable-scope constraint before the failure/retry details. No filler and each sentence carries distinct information (scope, filtering, partial success, failure).

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 3-parameter mutating tool with full schema coverage, annotations, and an output schema, the description covers scope, filtering, partial failure, and retry well. The only meaningful omission is duplicate-import behavior on repeated calls.

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 meaning of source_indices and its omit behavior, so the baseline is 3. The description largely restates the same omit rule and adds only the Drive-skip detail, which is a modest gain rather than compensating for any missing schema information.

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 and resource ('Add results of a finished research task to the notebook as sources') and scopes it to a completed research task, which cleanly separates it from research_start and research_status in the sibling list. An agent can tell what this does without reading the schema.

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 gives a clear precondition ('a finished research task') and an explicit rule for when to pass source_indices versus omitting it, plus the constraint that only web results are importable. It stops short of naming what to do if the task is not yet finished (e.g., poll research_status) or of pointing at an alternative 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?

Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false) already signal a non-idempotent, open-world write; the description adds genuinely new behavior — that the task runs asynchronously and must be polled via research_status, and that deep mode is slower but more thorough. It does not mention rate limits or cost, keeping it below 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?

Three tight sentences, each carrying distinct information: what the tool does, the mode tradeoff, and the follow-up workflow. Nothing is redundant and the core purpose is front-loaded.

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, and the description covers what an agent still needs: the returned task_id, the required polling step, and the import step. For a 4-parameter async research tool, nothing critical is 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 coverage is 100%, so the baseline is 3, but the description adds real meaning about the mode parameter (deep is more thorough and slower than the default fast mode) rather than merely restating the enum values. The source distinction (web vs the user's Drive) and the query's role as topic/question are also clarified.

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 — 'Start a NotebookLM research task' — and names the scope (web or Google Drive sources on a topic). It is clearly distinguishable from the sibling research_status (polling) and research_import (ingest) tools, which it explicitly routes to.

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 explicit downstream routing: poll with research_status using the returned task_id, then import with research_import. It also explains the deep/fast tradeoff so the agent can pick a mode. It does not state conditions under which not to start research, or prerequisites like notebook existence, so it stops short of full when/when-not coverage.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive. Beyond that, the description discloses the state machine's terminal semantics, the 'unknown' case for unrecognised states, and the positional coupling with research_import — meaningful behavioral context not present in the annotations. No rate-limit or eventual-consistency caveats, 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?

Front-loads the purpose in the first clause and packs status values, polling guidance and the cross-tool index link into three dense sentences with little waste. Slightly run-on, but each sentence carries distinct 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?

An output schema exists, so return values need not be re-explained, yet the description still summarises the payload shape. With annotations covering the safety profile and the schema covering parameters, nothing an agent needs in order to call this correctly is 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%, so both parameters are already fully documented in the schema. The description's 'one task, or all of them' reinforces the task_id omission behavior but adds no syntax or format detail beyond that, making the baseline 3 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 ('Check research tasks in a notebook') plus the scope ('one task, or all of them'), and enumerates the exact status strings returned. The closing reference to research_import's index argument distinguishes it from research_start and research_import without needing to open either schema.

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 explicit operational guidance ('Poll until the status is no longer in_progress') and tells the agent how to use the result with research_import. It does not explicitly name research_start as the counterpart for initiating a task or state exclusions, so it stops short of full when/when-not 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?

The description adds real behavioral context beyond the annotations: it warns that generation consumes the user's NotebookLM quota and takes several minutes, and it explains the confirm=false no-op versus confirm=true commit and the required polling loop with download_url. It does not, however, state whether a started generation can be cancelled or how duplicate calls behave, so there is room beyond a 3 but it is not exhaustive.

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 a cost/latency warning and then the confirm workflow. Every sentence carries actionable information with no filler.

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 an async, quota-consuming generation tool this covers the critical path (confirm gate, artifact_id, polling via studio_status, PDF download). An output schema exists so return values need not be detailed, though cancellation/error-recovery behavior is not addressed.

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 baseline is 3. The description's confirm detail largely restates the schema ('Must be true to start generation. With false the tool only returns pending_confirmation and does nothing') and it says nothing about format, length, language, source_ids, or focus_prompt, so it adds little parameter meaning beyond the schema.

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 ('Start generating a slide deck from the notebook's sources'), and the resource is inherently distinct from the other studio artifacts (audio_overview_create, video_overview_create, infographic_create, report_create). An agent can identify exactly what this produces without opening the schema.

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 explicit pre-conditions and a workflow: agree on options with the user first, use confirm=false to preview, confirm=true to commit, then poll studio_status for completion. This is unambiguous when-to-use and what-to-do-next 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?

Annotations already declare a non-read-only, non-idempotent, open-world write. The description adds context annotations cannot: the source is a snapshot that goes stale and must be refreshed via source_sync_drive, plus the account-level permission prerequisite. It doesn't state what happens on duplicate adds, which is the main remaining gap given idempotentHint=false.

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 sentences, zero filler, front-loaded with the action and required inputs before the constraints and alternatives. Every sentence carries distinct information: action, lifecycle, and routing.

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 re-explained; the brief '(id, title, type)' mention is harmless. With prerequisites, snapshot/lifecycle behavior, and sibling routing all covered, an agent has everything needed to invoke this correctly on the first try.

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% and each parameter already carries its own description (including the '/d/' hint for file_id and the MIME-type examples). The description only restates that file ID and MIME type are needed, adding no syntax or constraint beyond the 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 ('Add a Google Drive file as a source') and pins the required identifiers (Drive file ID, MIME type). It also names the sibling it is not (source_add_url), so an agent can distinguish it without opening a schema.

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 the precondition ('the signed-in Google account must be able to open the file'), names the refresh path (source_sync_drive) for later changes, and routes public web pages to source_add_url instead. When-to-use, when-to-refresh, and the alternative are all explicit.

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?

Annotations only mark it as non-read-only, non-idempotent and open-world. The description adds non-obvious behavioral facts beyond that: the content-vs-file_path precedence rule, the security refusal for paths outside the working directory/temp dir, and the shape of the created record (id, title, type pasted_text).

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 tight sentences: what it does, the two input modes with a precedence tiebreak and a failure escape hatch, then the sibling routing. No filler and the core behavior is front-loaded.

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 an output schema present the return value need not be spelled out, and everything an agent needs to invoke correctly — input precedence, sandbox limits, and which sibling to use instead — is covered.

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 all four parameters are already documented. The description largely restates what the schema says (content takes precedence, file_path must be under the working/temp directory), adding no new syntax or format guidance, 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?

States a precise verb+resource ('Add text as a source') and immediately names the two sibling tools it is NOT for (source_add_url for web/YouTube, source_add_drive for Drive files). An agent can distinguish this from every adjacent add tool without opening a schema.

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?

Explicit routing rules are given: URL/YouTube content goes to source_add_url, Drive files to source_add_drive, and there is a concrete fallback instruction (read out-of-sandbox files yourself and pass content) for a case that would otherwise fail.

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?

Annotations cover the safety profile (readOnly=false, openWorld=true, idempotent=false, destructive=false), and the description adds genuinely new behavior: fetching is server-side, the page must be publicly reachable, the title may temporarily be the URL while processing, and the call fails outright on fetch failure. The return-value portion overlaps the output schema, so it earns slightly less credit.

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 tight sentences, front-loaded with what the tool does, then the fetch prerequisite, then the failure/retry caveat. No filler or restated title 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?

Covers the prerequisite, the async title caveat, and the failure mode, which is more than most add-style tools. The output schema already exists, so the brief return summary is redundant rather than missing, leaving little an agent needs that is absent.

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 both parameters are already documented in the schema, including that the URL must be public http(s). The description restates the public-reachability constraint but adds no syntax, format, or validation detail beyond what the schema supplies. 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 ('Add a web page or a YouTube video to a notebook by URL'), and the resource qualifier immediately separates it from sibling text/drive importers like source_add_text and source_add_drive. An agent can distinguish it without opening any schema.

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 a clear prerequisite ('must be publicly reachable') and a recovery path ('check notebook_get before retrying'), which is real when-to-use guidance. It does not explicitly name source_add_text/source_add_drive as the alternatives for non-URL content, so the routing is implied by the siblings 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds materially beyond them: the dry-run behavior of confirm=false, the returned sentinel value pending_confirmation, the irreversibility warning, and the human-approval requirement. This is exactly the extra behavioral context a destructive tool should carry.

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 sentences, zero filler: the destructive purpose leads, the confirm semantics follow, and the safety warning closes. Each sentence earns its place and the most important constraint (irreversible) is not buried.

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 three-parameter destructive tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what happens on each confirm value, the return sentinel, the irreversibility, and the approval gate. Nothing required for correct invocation is 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%, so the schema already documents notebook_id, source_id, and confirm. The description restates confirm's semantics ('with confirm=false it does nothing') but adds no syntax, format, or sourcing detail beyond what the schema provides; 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 ('Permanently remove one source from a notebook') and scopes it to a single source within a notebook, clearly distinguishing it from read siblings like source_get and source_get_content. An agent can tell immediately what this does without opening the schema.

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?

Explains the two-step confirmation flow (confirm=false returns pending_confirmation, confirm=true deletes) and adds a procedural rule: name the source to the user and get explicit approval first. There is no competing delete sibling to disambiguate against, so the absence of named alternatives is acceptable, but no explicit 'do not use for X' boundary is given.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds genuinely non-obvious behavior: what fields come back, the meaning of content_length (characters extracted by NotebookLM), and the deliberate omission of the body text. It does not discuss failure modes (e.g., unknown source_id), but for a simple read that is a minor gap.

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 tight sentences: purpose first, then the concrete return payload, then the exclusion and the redirect. Every sentence carries information and nothing is padding.

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, yet the description still summarizes the shape and explains the one surprising omission (body text). Combined with the sibling redirect, an agent has everything needed to call this correctly and to know when not to.

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% (both notebook_id and source_id are documented with where to obtain them), so the schema carries parameter meaning. The description adds nothing about parameter formats or constraints, making the baseline 3 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+resource ('Get one source's metadata') and enumerates the returned fields (id, title, type, content_length), so the agent knows exactly what it gets. It also distinguishes itself from the sibling source_get_content by name, which removes any ambiguity between the two.

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?

Explicitly routes the agent to source_get_content when the extracted text is needed, with the reason ('the text itself is left out because it can be very long'). That is a clear alternative and condition, though it does not state positive scenarios where this metadata call is the right first step (e.g., verifying source type before acting on it).

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the return shape { text }, the fact that tables are flattened to 'cell | cell' rows, and a concrete size warning (~100,000 chars for a long Wikipedia article).

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 tightly packed sentences, front-loaded with the core purpose, then output format/size, then routing guidance. No filler; every clause carries information an agent needs.

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?

Despite an output schema existing, the description still communicates the practically important return characteristics (shape, table flattening, potential length) that an agent needs for context-window planning. Combined with the routing advice, nothing material is 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%, so both notebook_id and source_id are already documented in the schema with their provenance (notebook_get, notebook_list/create). The description adds no further parameter meaning, so 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 (get) and resource (full source text extracted by NotebookLM), and immediately distinguishes itself from source_get by clarifying it returns the extracted text rather than metadata. The table-flattening detail makes the output format unmistakable.

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?

Explicitly routes the agent: prefer notebook_query for answering questions, and use this only when the user needs verbatim text. Both the when and the when-not are named with the alternative 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?

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the concrete consequence: the stored snapshot is replaced. It also discloses the two return modes (pending_confirmation vs. count of synced sources). It stops short of covering failure modes or permission 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 sentences, zero waste, front-loaded with the destructive effect and then the confirm branch. Both sentences earn their place by conveying behavior not present in 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?

For a destructive, idempotent mutation with a full schema and an output schema, the description covers the essential what, the snapshot-replacement consequence, and the confirm gating. Nothing an agent needs to invoke it correctly is 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%, so the schema already documents confirm, source_ids and notebook_id. The description restates the confirm semantics rather than adding new syntax or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Re-import Google Drive sources') and names the originating sibling (source_add_drive) plus the effect ('replacing the stored snapshot'). An agent can distinguish this from source_add_drive and other source tools without opening any schema.

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?

Clear context: use it to make the notebook use the latest version of files previously added via source_add_drive. It also routes behavior by flag ('with confirm=false it does nothing'). It does not explicitly state when NOT to use it or name a preferred alternative for other refresh cases, which keeps it below a 5.

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?

Annotations already cover the safe read-only, idempotent profile. The description adds important behavioral context beyond that: it lists the returned fields and their status values, specifies when download_url is populated, notes that older artifacts are also listed, and recommends a polling cadence after creation.

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 the core action, then adds return details and polling guidance in two compact sentences. Every sentence contributes useful information without unnecessary padding.

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 simple one-parameter list/status tool with an output schema and rich annotations, the description is complete. It covers the return shape, status lifecycle, download_url behavior, and the polling workflow after creation.

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 single notebook_id parameter is fully documented in the schema. The description adds only the implicit scoping to the notebook and does not provide meaningful new syntax or format details beyond the schema.

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 (List) and resource (Studio artifacts), scoped to the notebook. It clearly distinguishes this status-listing tool from the many sibling creation tools like audio_overview_create and video_overview_create.

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 gives clear usage context: after a *_create call, poll every 30-60 seconds and locate the artifact by artifact_id. It does not explicitly name alternatives or state when not to use the tool, but the polling instructions are actionable.

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?

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), and the description adds substantial context beyond them: it consumes the user's NotebookLM quota, takes several minutes, confirm=false is a true no-op returning pending_confirmation, and confirm=true returns an artifact_id to be polled. This is exactly the operational detail an agent needs before committing.

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 dense sentences with no filler: the outcome first, then the confirmation protocol, then the polling/download path. Every clause carries operational value and the confirm semantics are front-loaded.

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 long-running, quota-consuming generation tool, the description supplies the full lifecycle (confirm gate, artifact_id, polling, download_url) even though an output schema exists. Nothing needed to invoke it correctly is 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%, so the schema already documents all seven parameters including enums for format, visual_style, and language. The description only elaborates on confirm, which the schema already explains, so it adds little parameter meaning beyond the structured fields.

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 ('Start generating a Video Overview: a narrated video with visuals that explains the notebook's sources'), which clearly distinguishes it from audio_overview_create, slide_deck_create, and infographic_create without opening any schema.

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 explicit operating context: agree on options with the user first, use confirm=false for a dry run, and poll studio_status after confirm=true. It routes the agent to the right follow-up tool, though it never explicitly contrasts itself with the sibling overview/deck creators when choosing output medium.

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