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

No annotations are provided, so the description carries the full burden and it only partially does so. It implies a mutation on a notebook but says nothing about permissions, duplicate handling, or processing latency; the wait/blocking behavior is documented only in the schema description, not the tool description.

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 short sentences, purpose first then the critical constraint, with zero filler. 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?

With a full schema and an output schema present, the description need not cover return values or parameter formats, and it covers the core action plus the exclusivity rule. It leaves gaps only around invocation behavior (latency, permissions) that a no-annotation mutation tool arguably warrants.

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 contributes the mutual-exclusion constraint among url/text/file_path that the schema itself does not encode. That is real added meaning beyond the per-parameter descriptions.

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 (add) and resource (source to a notebook) and enumerates the three accepted input modalities (URL, pasted text, local file). This cleanly separates it from sibling list_sources and delete_source without needing to name them.

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 instruction 'Pass exactly one of url, text, or file_path' is a genuine usage rule that is not enforced by the schema (which only sets additionalProperties: false and does not declare a oneOf), so it adds value. However, there is no guidance on when to choose this tool over siblings, nor when to prefer one input modality over another.

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 must carry the behavioral burden, and it does disclose the key mechanism: the answer is produced by Gemini reading the notebook's own sources and is returned with citations. It says nothing about latency, cost, persistence of the Q&A, or auth requirements, so it is only partially transparent for a query tool with no annotation coverage.

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 short sentences, front-loaded with the action and immediately followed by the grounding/citation guarantee and the when-to-use rule. No filler or repetition.

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 explanation is unnecessary, and the description covers the mechanism, grounding, and citations an agent needs to trust the result. Only minor gaps remain around cost/latency and whether the interaction is persisted.

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 explains notebook_id, source_ids scoping, conversation_id continuation, and the 'specific questions cite better' hint. The description adds no parameter meaning beyond that, so the baseline of 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 names a specific verb ('ask') and resource ('a notebook'), plus states the output is an answer 'grounded in its sources' with citations, which is concrete and distinguishable from sibling listing/generation tools like list_sources or generate_artifact. It stops short of naming any sibling it competes with, so the differentiation is implied rather than explicit.

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 usage condition — 'use this instead of summarizing the sources yourself when a notebook already holds the material' — which tells the agent when this beats doing the work manually. No explicit exclusions or named alternative tools are provided, so it lands at 'clear context, no exclusions' rather than full 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 does disclose meaningful behavior: it makes a real (cheap) network request and can distinguish 'no cookies stored' from 'cookies stored but expired'. It does not mention permissions, rate limits, or failure modes, but for a diagnostic probe this is substantive 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, front-loaded with the purpose before the routing advice and the behavioral caveat. Every sentence adds information; nothing is padded.

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. For a zero-parameter diagnostic tool, the description supplies everything needed to call it correctly: what it checks, when to call it, and that it costs a real request.

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 zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. The prose adds no parameter detail, but none is needed.

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: checks whether the server has a working NotebookLM session. It is unmistakably distinct from every sibling (which act on notebooks, sources, artifacts, or chat), so an agent can identify 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 an explicit trigger condition: call it first when any other tool reports an auth problem. It does not state the inverse (e.g., that it need not be called before routine operations), so it is clear context without full 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?

No annotations are provided, so the description carries the full behavioral burden, and it supplies almost nothing beyond the word "Read." It does not state read-only guarantees, auth/permission requirements, ordering behavior, or what happens when the conversation is empty.

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 with no filler; the resource and scope are stated in the first few words and nothing is wasted.

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 not be described, and both parameters are documented. The only shortfall is the absence of any safety/behavioral note, which matters more here because there are no annotations to lean on.

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%, with both notebook_id and limit fully documented in-schema (including the newest-first ordering), so the baseline is 3. The description's "current conversation" phrasing adds only marginal scope nuance over 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 pairs a specific verb ("Read") with a specific resource ("past question/answer turns") scoped to "a notebook's current conversation." That is enough to distinguish it from siblings like ask or get_notebook, though it never names a sibling 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?

Usage is only implied: the "current conversation" framing suggests using it alongside ask to recover prior turns, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer the trigger condition.

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 a non-obvious behavioral trait: the created notebook starts empty and is functionally useless for answering questions until sources are added. It omits any mention of permissions/auth or duplicate-title behavior, but the key post-condition is stated.

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 short sentences with zero filler; the operation is stated first and the follow-up prerequisite second. 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 not be explained, and the description covers the essential behavior for a simple one-parameter creation tool. The only missing pieces are permission/error context, which is minor at this complexity.

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?

There is a single parameter (title) and schema description coverage is 100%, so the schema already explains it fully. The description adds no format, length, or uniqueness constraints beyond the schema, which is the baseline-3 situation.

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 ('Create an empty notebook') and immediately qualifies the result as empty, which tells an agent what state the object will be in. It does not name a sibling to contrast with, but the purpose is unambiguous.

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 context: an empty notebook cannot answer questions, so call add_source before ask. That is real workflow guidance tying this tool to the next step. It lacks an explicit 'when not to use' clause or a comparison against list_notebooks/get_notebook, so it falls just short of 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?

With no annotations, the description carries the full burden and does well: it explicitly says the deletion is permanent, cannot be undone, and cascades to sources, chats, and generated artifacts. It omits permissions/authorization requirements and the confirmation ceremony, though the latter is covered by 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?

Two short sentences, both front-loaded, with the irreversible nature placed immediately after the core action. No filler or repetition.

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, and the destructive scope is fully described. The only gap is the absence of any authorization or prerequisite context for a permanently destructive operation.

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 both notebook_id and the confirm guard, including the instruction to ask the user. The description adds no parameter-level detail beyond what structured fields provide, 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?

Names a precise verb and resource ('delete_notebook') and specifies the blast radius ('everything in it', enumerated as sources, chats, and generated artifacts). This is enough to separate it from delete_source 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?

The description states no conditions for when to use this tool, no prerequisites, and never points to alternatives such as delete_source for removing a single source. It conveys only that the action is destructive, which is informational rather than 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?

No annotations are provided, so the description carries the full burden. It says 'Remove' but omits that citations pointing at the source are dropped and that confirmation is required; those details live only in the schema's confirm parameter.

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 with no wasted words. It is appropriately sized, though for a destructive action it is perhaps under-specified.

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 and the input schema covers the required confirm flag and its consequences, so an agent has key operational details. However, the description itself adds almost no usage or behavioral context for a destructive removal tool.

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 parameters are richly documented (including the confirm requirement and citation consequence), so the baseline is 3. The description adds no additional parameter meaning.

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 with its scope: removing a source from a notebook. This distinguishes it from the sibling add_source, though it does not explicitly name alternatives.

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 offers no when-to-use guidance or alternatives. The schema's confirm parameter says to ask the user first, but the description itself gives none of that routing context.

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 the key behavioral trait that the file is written to the server host rather than returned to the caller, but says nothing about overwrite behavior, required permissions, or error handling for incomplete artifacts.

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 with no filler; the action and destination are both established immediately.

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 parameters are fully documented. However, for a tool with no annotations that writes a file to a host, the description omits permission requirements and overwrite semantics, leaving gaps an agent would want 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%, and output_path's path-resolution rules are already documented in the schema. The description adds only the 'server host' framing, 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 (Download) and resource (Studio artifact) plus the destination (a file on the server host). It clearly separates itself from list_artifacts and generate_artifact, though it never names a sibling 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?

The word 'completed' hints that only finished artifacts are downloadable, but there is no explicit when-to-use, prerequisite, or alternative (e.g., list_artifacts to find the artifact) guidance. Usage must be inferred.

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 and does well: it discloses that generation is server-side, slow (audio can take minutes), and consumes the account's daily Studio quota. It stops short of covering auth requirements or failure behavior when the quota is exhausted.

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: purpose first, then cost/latency, then the recommended call pattern. Every sentence carries load and nothing is repeated from 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 values needn't be explained, and all 11 parameters are schema-documented; the description supplies the missing quota and latency context plus the preferred invocation pattern. Only auth/prerequisite and failure-mode details are 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 every parameter (including wait, kind, and the kind-conditional options) is already documented in the schema. The description adds meaning to wait by pairing it with the polling workflow, but adds nothing else 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 (Generate) and resource (Studio artifact) and enumerates concrete artifact types (podcast, report, quiz, mind map), which lets an agent distinguish it from sibling read tools like list_artifacts and download_artifact.

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: prefer wait=false and poll with list_artifacts rather than blocking. It names the alternative tool and the condition that selects it, but says nothing about when NOT to use this tool (e.g., versus ask).

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 behavioral burden, and it says almost nothing: no permission requirements, no error behavior for an invalid or missing notebook_id, no mention that the sources payload may be large. 'With its sources' hints at return content, but the output schema already covers that.

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 with no filler. It is efficient, though arguably under-specified rather than genuinely well-structured.

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 low-complexity read tool with a full output schema and 100%-covered parameters, the description is minimally sufficient. The missing piece is routing guidance against list_notebooks/list_sources and any note on behavior when the id is unknown.

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%: notebook_id is tied to list_notebooks output and include_summary's cost/latency tradeoff is fully documented in the schema. The description adds nothing for either parameter, 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 and resource ('Get one notebook') and adds scope detail ('with its sources') that distinguishes it from list_notebooks. It stops short of naming the sibling explicitly, but the singular 'one' makes the contrast inferable.

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?

No indication of when to use this tool versus list_notebooks, list_sources, or ask. The only implicit guidance is that a notebook_id must already be known, which is not stated in the description itself.

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 burden. It helpfully discloses that artifacts expose a status field that flips to 'completed' — a real behavioral detail beyond the schema. However, it omits any mention of pagination, ordering, or permission requirements for a list endpoint.

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 short sentences, front-loaded with the core action and followed immediately by the polling use case. Every sentence earns its place 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 a two-parameter list tool with a full output schema and 100% schema coverage, the description supplies the key missing operational context (the polling workflow). It is close to complete; only ordering/pagination expectations are unstated.

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 the kind filter's enumerated values are documented in the schema itself. The description adds nothing about parameter meaning, 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 opens with a specific verb+resource+scope: listing generated Studio artifacts within a notebook. It naturally separates itself from siblings like generate_artifact and download_artifact by virtue of the 'list' verb and the notebook scoping.

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 concrete usage scenario — polling a generation started with wait=false — and explains the readiness signal to look for. This is clear context, but it does not state when NOT to use it or point to alternatives (e.g. download_artifact once status is completed).

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 implies a read-only, account-scoped listing and previews the returned fields, but says nothing about pagination, result limits, or ordering, which matters for a list tool that may return many notebooks.

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 the core action and followed by the return summary and the key routing rule. No filler and the most decision-relevant fact (ids are mandatory elsewhere) is kept.

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 read tool with an output schema present, the description supplies everything needed to select and invoke it: what it lists, whose scope, what comes back, and why the result matters downstream.

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 schema has zero parameters, so there is no parameter semantics to clarify; the baseline for a parameterless tool applies. Nothing in the description misleads about inputs.

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 ('List the notebooks') plus scope ('reachable by the signed-in Google account'). It also implicitly separates itself from get_notebook and other id-based siblings by noting that ids are the required handle throughout the toolset.

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?

'Use the ids with every other tool' tells the agent exactly when this tool is needed as a prerequisite step. It also rules out the title-based alternative ('NotebookLM has no lookup by title'), though it doesn't give explicit when-not-to-use conditions.

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 the meaning of processing status (non-ready sources do not ground answers), but it omits permissions, ordering, and pagination details for a read operation.

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, front-loaded, with no filler. The second sentence efficiently explains the status semantics.

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 an existing output schema and a single self-evident notebook_id parameter, the description covers the tool's core purpose and status behavior sufficiently for correct invocation. The main gap is the undocumented 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?

The only parameter, notebook_id, has 0% schema description coverage, and the description merely says 'in a notebook' without defining the identifier format or where to obtain it. It adds almost no semantic meaning beyond the parameter name.

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 ('List') and resource ('sources in a notebook') plus the processing-status dimension. It does not explicitly contrast itself with siblings like list_notebooks or add_source, but the scope is distinct.

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 implies usage by explaining that non-ready sources are still being ingested and will not ground answers. However, it does not say when to prefer this over alternatives or what a caller should do with the returned statuses.

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