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

With no annotations, the description carries the behavioral disclosure burden. It does disclose that delete is IRREVERSIBLE and requires confirm=True, which is valuable. However, it does not describe side effects, permissions, or behavioral nuances for the other mutating actions like create, add_source, or studio.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with a one-sentence purpose, followed by a compact bulleted list of actions. Every line earns its place, and there is no redundant 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?

The description covers the main actions and flag the critical delete confirmation requirement. However, it does not explain notebook selection semantics (all, tags, notebook_names) or how this relates to similar siblings like cross_notebook_query. The schema and output schema compensate partially, but the description alone is not fully complete for a tool with 9 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Because schema description coverage is 100%, the baseline is 3. The description adds little parameter-level meaning beyond the schema, though it does tie actions to their conceptual purposes. The schema already documents which parameters apply to which actions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs batch operations across multiple notebooks and enumerates five specific actions. It is specific enough to distinguish from single-notebook siblings, though it does not explicitly name sibling tools or contrast itself with cross_notebook_query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The action list implies when to use the tool: for batch operations on notebooks, such as querying, creating, deleting, or adding sources across multiple notebooks. However, there is no explicit guidance on when to prefer this over single-notebook tools like notebook_query or notebook_delete, nor any when-not-to-use instructions.

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 of behavioral disclosure. 'Configure notebook chat settings' only vaguely implies a mutation; it does not state whether existing settings are overwritten, whether the change is persistent, what scope it applies to, or whether any side effects occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler and front-loads the action verb. It is concise, though the brevity sacrifices useful detail; structurally it is appropriate but not exemplary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has four parameters, a conditional dependency, and a large sibling context, but the description does not explain when to use it, what behavior to expect, or how it relates to other chat tools. With no annotations, this sparse description is insufficient for an agent to invoke the tool confidently in the right context.

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 each parameter, including defaults and the conditional requirement for custom_prompt. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline score 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 uses a specific verb ('Configure') and identifies the resource ('notebook chat settings'), making the tool's broad function clear. It distinguishes itself from read-oriented siblings like chat_list and chat_get by implying a mutation or settings update, though it does not specify exactly which settings are affected.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use chat_configure versus alternatives such as chat_list, chat_get, or notebook_query. The description gives no prerequisites, such as requiring an existing notebook, nor does it explain conditional usage like needing custom_prompt when goal=custom.

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. It only states the export action and formats, without disclosing side effects, whether any auth is needed, whether the operation is read-only, or any limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple operation, though it could earn a higher score by also including brief usage or behavior context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema fully documents all parameters and an output schema exists, so the call contract is mostly covered. Missing usage guidance and behavioral transparency keep it from being fully complete, but complexity is low and structured metadata does most of the work.

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 input schema already documents all three parameters, including defaults and allowed values for format, and notebook_id/conversation_id descriptions. The description adds no parameter-specific meaning beyond what the schema provides, 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 clearly states the tool exports a chat transcript to Markdown or JSON, which is a specific verb plus resource. It distinguishes the tool from chat_get/chat_list by emphasizing export/output-file intent, though it does not explicitly name a sibling alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use chat_export versus alternatives like chat_get or export_artifact. The export verb and formats imply a file-download use case, but no context, prerequisites, or exclusions are provided.

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 behavioral burden. It does convey that the tool returns a full transcript of a specific session and implies a read-only retrieval. However, it does not mention potential large payloads, behavior when conversation_id is omitted (though the schema notes the default), or any failure/edge-case behavior.

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 one clear, front-loaded sentence with no filler or redundant wording. It communicates the core purpose efficiently.

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 retrieval tool with a full input schema and output schema present, the description is minimally adequate. However, it lacks guidance on how to choose this tool over chat_list or chat_export, and does not mention any operational nuances, making it only barely complete for an agent.

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 input schema has 100% description coverage, clearly documenting notebook_id and conversation_id, including the default behavior. The description adds little beyond the schema, so the baseline score 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 clearly states the action ('Get') and the resource ('full transcript of a specific chat session'). It is specific enough to convey what the tool does, though it does not explicitly distinguish itself from sibling tools like chat_list or chat_export.

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 guidance is provided about when to use this tool versus alternatives such as chat_list or chat_export. The agent is left to infer the appropriate context from the name and description alone.

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 conveys a read-only enumeration behavior ('List') and the notebook scoping, but does not disclose ordering, pagination behavior beyond the limit parameter, or whether returned chat sessions include full messages. The presence of an output schema mitigates the need to describe return values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler. It conveys the action, resource, and scope efficiently, and every word 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?

For a low-complexity list tool with 100% schema coverage and an output schema, the description is largely complete. It lacks explicit alternative routing and detailed behavioral notes, but an agent can correctly invoke it with the provided schema and description.

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 parameters. The description adds only the notebook scoping context for notebook_id and does not add semantic detail beyond the schema, matching the baseline for high coverage.

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 uses a specific verb ('List') and resource ('chat sessions') and scopes them to a notebook, clearly differentiating it from sibling tools like chat_get, chat_configure, and chat_export, which operate on individual chats or configure 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 description implies when to use the tool: when you need a list of chat sessions for a notebook. However, it does not explicitly contrast it with alternatives (e.g., chat_get for a single session) or mention exclusions, so guidance is only implicit.

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 of behavioral disclosure. It only restates the action of creating without mentioning side effects, persistence, authentication requirements, error behavior, or any other behavioral trait that would help an agent predict the outcome beyond the name itself.

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 very concise with no filler words; the single sentence states the essential action efficiently. It is slightly redundant with the title, and it lacks structure for additional context, but as a brief description it is not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a simple create operation with full schema parameter coverage and an output schema, which helps. However, with no annotations and no behavioral context, the description leaves important contextual gaps such as when to choose this over collection_edit, whether there are side effects, and what expectations exist around the created collection.

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 parameters and the optional notebook_ids list. The description adds no parameter-level meaning, but because the schema fully covers parameter semantics, the baseline score 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 clearly states a verb ('Create') and a resource ('new collection'), making the core purpose unambiguous. It also implicitly distinguishes itself from sibling tools like collection_edit, collection_delete, and collection_list by the creation action, though it does not explicitly contrast with 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?

There is no explicit guidance on when to use this tool versus alternatives like collection_edit or collection_delete. The only usage signal is the word 'create', which implies a new collection should be made, but no context, exclusions, or alternative conditions are provided.

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 provided, the description carries the full disclosure burden. It clearly communicates that the operation is permanent and does not cascade to notebooks. It could mention the need for confirm=true in the tool description itself, but 'permanently' and the non-deletion caveat cover the most critical behavioral traits.

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 no filler. The core action is front-loaded, and the critical caveat about notebooks is placed immediately after, giving high information density with minimal verbosity.

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 operation, the description captures permanence, non-cascading behavior, and the essential parameters are fully covered by the schema. The output schema exists, so return-value documentation is not necessary. Minor gap: the tool description itself does not state that confirm=true is required, though the schema covers this.

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 are already well documented: collection_id is a UUID, and confirm must be true after user approval. The tool description adds no additional parameter semantics beyond what the schema provides, 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 states a specific verb and resource ('Delete a collection permanently') and clearly distinguishes itself from notebook deletion tools by noting that notebooks inside the collection are NOT deleted. This makes its purpose immediately 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?

The description implicitly tells the agent when to use this tool: when a collection should be permanently removed while preserving its notebooks. It does not explicitly name alternatives, but the caveat about notebooks strongly implies that this is not for deleting notebooks.

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 plainly states that the operation mutates the collection's name and/or notebook list, which is useful given no annotations exist. However, it does not disclose auth requirements, whether the notebook list is replaced wholesale, or whether edits are reversible; the replacement semantics only appear in the schema's 'New complete list' wording.

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, tightly worded sentence contains the essential purpose with no filler, redundant details, or repetition of the tool name. It is front-loaded and easy 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 simple tool with fully documented parameters and an output schema, the description is nearly complete. It could be fuller with an explicit note about full-list replacement or a pointer to collection_set_emoji, but the schema and sibling names mitigate those gaps.

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 already has a clear description. The tool description adds no new parameter meaning beyond confirming that name and notebook_ids are the editable fields, so the schema carries the semantic weight.

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 action ('Edit'), a specific resource ('an existing collection'), and the exact fields affected ('name and/or list of notebooks'). It clearly distinguishes this tool from collection_create, collection_delete, and collection_set_emoji.

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 when to use it: when an existing collection's name or notebook membership must be changed. It does not explicitly say when not to use it or name alternatives, such as using collection_create for new collections or collection_delete for removal.

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 provided, the description carries the behavioral burden. 'List all native collections' clearly indicates a read-only operation with explicit scope. It does not describe pagination, ordering, or authentication, but for a zero-parameter list tool with an output schema, this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence with no filler. It front-loads the action and object, and every word contributes to meaning.

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, zero-parameter list operation, the description captures the essential operation and scope. The output schema is present, so return-value structure need not be repeated in prose. However, it does not explain what 'native collections' means relative to drive sources or other collection types, which could leave slight ambiguity.

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 input schema has zero properties, so there are no parameters to document. Schema description coverage is effectively 100%, and no parameter-level semantics are needed. A baseline of 4 is appropriate for a no-parameter tool.

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 uses a specific verb and resource: 'List' + 'native collections'. It clearly distinguishes this from sibling mutation tools like collection_create, collection_edit, and collection_delete, and from notebook_list by specifying collections rather than notebooks. The qualifier 'native' adds useful scope precision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives. It does not mention notebook_list for notebooks, source_list_drive for drive sources, or any exclusion such as filtering by workspace. An agent must infer selection from the tool name alone.

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 present, so the description carries the full burden of behavioral disclosure. It states the operation but does not mention side effects, permission requirements, reversibility, or idempotency for a mutating tool, leaving important behavioral context unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word 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 only two fully documented parameters and an output schema available, the description and schema together are sufficient for correct invocation. The main omission is behavioral context, but the tool's simple scope keeps this from being a major gap.

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 describes both parameters, including the empty-string clear behavior for emoji. The description does not add meaning beyond this, 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 uses a specific verb ('set or clear') with a specific resource ('the emoji marker on a collection'), making the tool's function unambiguous. This clearly distinguishes it from sibling tools like collection_edit, which would handle other collection properties.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this tool exactly when you need to set or clear a collection's emoji marker. It does not explicitly name alternatives or exclusions, but the operation is self-contained enough that an agent can infer when to invoke 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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the output shape—aggregated answers with per-notebook citations—but it does not mention rate-limit cautions on all=True, potential long-running behavior, or the async alternative notebook_query_start/status.

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 two concise sentences with no filler. The first sentence front-loads the core action and result, and the second covers selection modes efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema and full parameter coverage reduce the need for extra detail. However, because there are no annotations, the description would benefit from explicitly noting rate limits, async options, or the difference between this and the single-notebook query 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%, so the schema already documents all parameters. The description mostly restates the notebook selection options (by name, tags, all=True) without adding meaning beyond what the schema provides.

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 and resource: 'Query multiple notebooks' and defines the result as 'aggregated answers with per-notebook citations.' This clearly distinguishes it from the single-notebook sibling notebook_query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly communicates when to use the tool: when querying across multiple notebooks. It also gives the three selection modes: by name, by tags, or all notebooks. It does not explicitly name alternatives, but the cross-notebook scope is evident.

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 so admirably. It discloses directory creation, file naming and extension conventions, skipping of in-progress/failed artifacts, and partial-failure tolerance. These details go well beyond the structured 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?

The description is compact and front-loaded, starting with the core behavior before covering exceptions and edge cases. Every sentence adds value, and the example extension list is efficiently embedded without bloating the prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given seven params, no annotations, and rich behavior, the description covers the essential mechanics, edge cases, and failure semantics. The output schema exists, so not detailing the return value further is acceptable; the result is adequately characterized by the mention of skipped/failed artifacts being listed.

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. The description adds context about extensions and per-notebook folders, but does not materially deepen understanding of individual parameters beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action, 'Download all completed studio artifacts of one notebook — or every notebook,' identifying both the resource and scope. It clearly distinguishes itself from the single-item sibling download_artifact by emphasizing bulk and sweep behavior.

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 for downloading all artifacts or sweeping notebooks, but does not explicitly say when to prefer it over download_artifact or export_artifact. The output_dir parameter points to download_artifact for path restrictions, providing some cross-reference, but no direct when-to-use vs alternatives guidance 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses scope and unification, but says nothing about download-directory confinement, propagation waits, permissions, output side effects, or failure behavior; these traits are only discoverable by reading the parameter 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?

The description is short and front-loaded with the primary action ('Download any NotebookLM artifact') before supporting scope. There is no filler, though the artifact-type list somewhat duplicates information already present in the input 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?

Given a 9-parameter tool with no annotations, the top-level description is thin: it establishes the unified nature and supported artifact types but leaves sibling-tool selection and behavioral caveats to inference. The rich input schema compensates for most parameter-level gaps, so the definition is usable but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 9 parameters are already documented with defaults and constraints. The top-level description adds no parameter-level meaning beyond re-listing artifact type names, which the schema already covers with more detail; this meets the baseline but does not exceed it.

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 the specific action ('Download'), the resource ('NotebookLM artifact'), and the outcome ('to a file'), then enumerates the supported artifact types. It also identifies itself as the 'Unified download tool replacing 9 separate download tools,' which helps an agent recognize it as the general-purpose download entry point, though it does not explicitly contrast it with download_all_artifacts or export_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?

The description implies general usage with 'any NotebookLM artifact' and 'Unified download tool replacing 9 separate download tools,' but it never explicitly states when to prefer this tool over sibling tools like download_all_artifacts or export_artifact. There are no exclusions, prerequisites, or batch-vs-single-artifact routing cues.

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 of behavioral disclosure. It clearly states that the tool exports to an external Google destination and lists supported conversions, but it does not mention required Google authentication, file-creation side effects, or Drive permission implications. This is reasonable but not fully transparent.

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 short, front-loaded with the core action, and uses a compact bullet list to convey the supported mappings. Every sentence earns its place, and there is no redundant or vague 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?

The output schema and fully described parameters cover the return value and argument details, and the description covers the main usage mapping. However, because there are no annotations, the description should also disclose Google-side prerequisites such as authentication or Drive write behavior; this gap prevents full completeness for a mutating external export 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%, so the baseline is 3. The description adds value beyond the schema by mapping artifact types to export targets, thereby clarifying the meaning of export_type values 'docs' and 'sheets' in a way the raw schema does not.

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 opening sentence names a specific action (Export), a resource (NotebookLM artifact), and a destination (Google Docs or Sheets). The artifact-type mapping further clarifies scope and distinguishes this from sibling download tools like download_artifact, making the purpose 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?

The bullet list explicitly tells the agent which artifact types map to which export target: Data Tables → Google Sheets, Reports → Google Docs. This gives clear context for selecting the right export_type and target. It does not explicitly mention alternatives such as download_artifact or state when not to use this tool, so it stops 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?

No annotations are provided, so the description must carry behavioral context. It does disclose the 5+ source threshold for auto-labeling and that sources can belong to multiple labels simultaneously. However, the description itself does not surface that delete is permanent or that reorganize can replace all labels; those warnings live only in schema action 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?

The description is compact: a purpose line, two domain facts, and a bullet-style action list. It front-loads the key purpose and avoids verbose prose. The only minor redundancy is echoing the operation list that also appears in the action 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?

Given 9 parameters and 8 actions, the description is appropriately high-level while the schema and output schema carry the detailed parameter and return contract. It supplies essential domain constraints, such as the 5+ source requirement and multi-label membership, needed for selection. A short warning about destructive operations would improve it, but the overall definition is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description lists operation names, but the input schema already explains each operation and its required parameters with more detail. No additional parameter-level meaning is added.

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 'Manage source labels in a notebook,' naming a specific resource and a management verb, and positions itself as the 'Unified tool for all label operations.' The supported action list concretely scopes the tool. It doesn't explicitly differentiate from related siblings like 'tag,' 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?

The description tells the agent this is the central tool for label work ('Unified tool for all label operations') and gives a concrete condition: auto-labeling requires 5+ sources. It doesn't name exclusion cases or alternatives such as 'tag,' but the instruction to use this for label operations is clear.

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 of disclosing behavior, but it only lists operations. It does not mention that delete is permanent, that confirmation is required, or any other side effects, prerequisites, or safety considerations.

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 short, front-loaded, and easy to scan. The operation list is useful, though the phrase 'Unified tool for all note operations' is slightly redundant with the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives a high-level overview and covers the main operations, but it omits practical context such as destructive behavior, confirm requirements, or when to use sibling tools. The output schema reduces the need to explain return values, so this is adequate but not thorough.

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 adds no meaningful parameter semantics beyond what the schema already documents; the listed operations map to the action parameter but do not clarify action-dependent requirements.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as managing notes in a notebook and enumerates the supported operations: create, list, update, delete. It is clear enough about the resource and scope, though it does not explicitly differentiate itself from sibling tools like notebook_query or notebook_get.

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 phrase 'Unified tool for all note operations' implies when to use it, and the operation list gives concrete actions. However, there is no explicit guidance about when not to use it or which sibling tools might be preferable for note-related queries or notebook-level operations.

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 of disclosing behavior. 'Create a new notebook' transparently indicates a mutating action, which is the core behavior. However, it does not mention side effects, permissions, idempotency, or what happens when the optional title is omitted, leaving some gaps for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no redundant wording. It is concise and front-loaded with the main verb. While it could include more context without becoming bloated, its current length is appropriate for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple: one optional parameter and an output schema, so the description is nearly sufficient. However, the lack of usage guidance and behavioral detail, especially given no annotations, prevents the definition from being fully complete. An agent can infer basic use but not broader context within the notebook toolset.

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 title parameter is already well documented as 'Optional title for the notebook'. The description adds no additional parameter context, which aligns with the baseline of 3 when the schema fully covers 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?

The description states a specific verb ('Create') and resource ('new notebook'), making the tool's purpose unmistakable. It also distinguishes from siblings like notebook_list, notebook_get, and notebook_describe by naming the create action and target resource. The title 'Notebook Create' reinforces this without being a tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as collection_create or notebook_rename. There is no mention of prerequisites, intended workflows, or conditions that would make this tool the right choice. It is neutral but entirely without usage direction.

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 fully carries the safety burden. It discloses that the operation is permanent and irreversible and adds the guardrail that confirmation is mandatory. This is strong behavioral disclosure for a destructive mutation tool, despite not enumerating every possible side effect.

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 three short clauses with no filler, and the most important safety facts (permanent, irreversible, confirmation) are front-loaded. Every sentence contributes essential 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 two-parameter destructive tool, the description plus the fully documented schema and output schema leave the agent with everything it needs: the target ID, the confirmation requirement, and the irreversibility warning. No critical context 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 baseline is 3. The description's 'Requires confirm=True' restates the schema's own 'Must be True after user approval' without adding new syntactical or semantic detail about notebook_id.

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 uses a concrete verb and object ('Delete notebook') plus the critical modifier 'permanently,' making the destructive scope unmistakable. This clearly separates it from sibling tools like notebook_rename and notebook_describe, which do not destroy the notebook.

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 text gives clear context: this tool exists for permanent deletion, and it explicitly states the precondition 'Requires confirm=True.' It does not name alternative tools or exclusions, but the semantics and sibling names make the correct usage obvious.

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 provided, the description must stand alone. It adds useful behavioral context by noting the summary is AI-generated rather than stored, but it does not disclose latency, model dependency, cost, or confirm there are no side effects. This is a moderate gap for an operation that may invoke an AI model.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler or redundant restatement of the tool name. Every word adds meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, has one well-documented parameter, and an output schema exists, so the description does not need to enumerate return values. However, it lacks explicit routing among sibling lookup tools and does not address the operational implications of AI generation, making it only minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the only parameter, notebook_id, is already documented as a 'Notebook UUID'. The description adds no additional parameter meaning, 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 states a specific verb ('Get') and a specific deliverable ('AI-generated notebook summary with suggested topics'), which clearly differentiates this from sibling tools like notebook_get or notebook_list. The resource and nature of the result are 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?

The tool's purpose implies using it when an AI-generated summary is needed, but the description gives no explicit when-to-use guidance or alternatives. It does not mention that raw notebook content or metadata should be retrieved via notebook_query or notebook_get.

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 of behavioral disclosure. 'Get' implies a read operation and 'with sources' hints at the response content, but it does not disclose permission requirements, whether sources are fully resolved, error behavior, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no filler. The core operation and the distinctive 'with sources' detail are front-loaded. It loses the fifth point because it provides no additional context or structural differentiation.

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 get tool with an output schema, this is minimally adequate. The output schema covers return values, so the description need not detail them, but the absence of annotations and lack of disambiguation from notebook_describe leave meaningful gaps.

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 parameter notebook_id is documented as 'Notebook UUID'. The description adds no extra parameter meaning, but the baseline of 3 applies because the schema already handles parameter semantics adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete operation: get notebook details, and adds 'with sources' to indicate the scope of the result. However, it does not differentiate from sibling tools like notebook_describe or notebook_query, so it is clear but not fully distinguishable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives such as notebook_describe or notebook_query. The description only states what the tool does, not the conditions that make it the right choice.

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 of behavioral disclosure, but it only says 'List all notebooks.' It does not mention pagination, ordering, default limits, or that this is a read-only operation. The schema's max_results default of 100 also slightly conflicts with the claim of listing 'all' 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?

The description is a single sentence with no filler, and the core operation is front-loaded. It is appropriately short for such a simple tool, though it omits useful context that would have made it more complete.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and has full schema and output schema coverage, but the description lacks usage guidance, behavioral caveats, and qualification of the 'all' claim relative to max_results. It is minimally viable but leaves notable gaps for an agent deciding when and how to invoke it.

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 even with no parameter details in the description. The description adds no meaning about max_results, and the word 'all' could be mildly misleading given the default limit of 100, though the schema clarifies the constraint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'notebooks', and the word 'all' conveys scope, which helps distinguish it from single-notebook operations like notebook_get or notebook_describe. It does not explicitly differentiate from siblings, but the core 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?

There is no guidance on when to use notebook_list versus notebook_get, notebook_describe, or other notebook-related tools. The description gives no exclusions, alternatives, or selection criteria, leaving the agent to infer usage from the name alone.

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 disclosure burden. It does clarify an important scope constraint: the tool only queries existing notebook sources and is not for discovery. However, it does not state whether the query is read-only, whether it creates conversation state, whether it has significant cost/latency, or any auth prerequisites. Some of this is implied but not explicit.

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 two short sentences with no filler. The core scoping is front-loaded, and the exclusion/alternative is immediately actionable. Every phrase 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?

Given the rich input schema and presence of an output schema, the description covers the most important usage context: existing sources only and the main alternative for discovery. It does not address related siblings like notebook_query_start or cross_notebook_query, nor does it cover behavioral caveats such as cost or side effects, so it is strong but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema itself gives detailed, meaningful parameter descriptions including defaults, timeout behavior, source filtering, and conversation IDs. The description adds only high-level context about querying existing sources and does not need to repeat parameter details, so it stays at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: 'Ask AI about EXISTING sources already in notebook.' It also explicitly draws the boundary against finding new sources, which immediately distinguishes it from sibling tools like research_start. This is a clear, non-tautological purpose statement.

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 routing rule: 'Use research_start instead for: deep research, web search, find new sources, Drive search.' This directly tells the agent when not to use this tool and which alternative to pick, 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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the tool returns immediately with a query_id rather than waiting for the result, and that the result must be obtained by polling notebook_query_status. This is strong transparency, though it does not mention error behavior or side effects beyond asynchronous execution.

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 compact, front-loaded with the core purpose, and every sentence contributes: when to use it, timeout guidance, return behavior, and the follow-up workflow. There is no filler or redundant restating of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides a complete mental model for the agent: why this tool exists, when to prefer it, what to expect upon invocation, and how to retrieve the eventual result. The presence of an output schema further reduces the need to describe return values in prose.

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?

Input schema coverage is 100%, so the schema already documents all parameters meaningfully. The description reinforces the timeout guidance from the schema, but it does not add substantive new parameter-level semantics beyond that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (start an asynchronous query), a target use case (source-heavy notebooks or long questions), and a clear resource (notebook). It also distinguishes itself from sibling tools by naming notebook_query and notebook_query_status and explaining the async vs. polling relationship.

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 explicitly says to use this tool instead of notebook_query when the response may exceed the 120-second budget, and it provides a suggested 180-second timeout for source-heavy notebooks. It also gives a terse workflow: notebook_query_start -> notebook_query_status.

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 provided, the description carries the full burden of behavioral disclosure. It does this well by explaining the async nature, that it returns the query result when completed, and that it returns current status if still in progress. It also names terminal statuses ('completed' or 'error'), which helps the agent understand expected outcomes without needing to invoke the tool.

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 three short sentences, each earning its place: what it does, what it returns, and how to poll. It is front-loaded with the primary purpose and contains no redundant phrasing or 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 one-parameter polling tool with an output schema available, the description is complete. It explains the relationship to notebook_query_start, the expected return behavior, and the polling loop with terminal statuses. No critical information appears missing for an agent to invoke this tool 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%: the single query_id parameter is already documented as 'The query ID returned by notebook_query_start'. The description reinforces this relationship but adds no new parameter-level meaning. The baseline of 3 is appropriate when the schema already carries the full parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Check the status of an async notebook query'. It clearly distinguishes this from the sibling tool notebook_query_start by explicitly tying itself to queries 'started with notebook_query_start' and describing a polling role. The name alone is also 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?

The description provides clear context for when to use the tool: after starting a query with notebook_query_start. It also gives explicit polling guidance: 'Poll this tool every few seconds until status is completed or error.' It does not explicitly state when not to use it or name alternative status-type tools, but the workflow context is clear.

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 disclosure burden. 'Rename a notebook' implies a mutating title change, but it does not disclose side effects, whether the operation overwrites the existing title, permission requirements, or any conflict behavior.

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 extremely concise and front-loaded, with no filler words. It communicates the essential operation in one short sentence, though it misses opportunities to add useful context without becoming verbose.

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 rename operation with an output schema, the description covers the basic action. However, it omits behavioral guidance such as side effects, required permissions, and how this tool relates to notebook_create or notebook_delete, leaving gaps for an agent relying solely on this description.

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 parameters adequately. The description adds no additional meaning beyond what is already present in the input schema, resulting in the baseline score.

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 uses a specific verb 'Rename' and identifies the resource 'notebook', clearly stating the core operation. It does not explicitly differentiate this from sibling tools, but the rename operation is distinct from notebook_create, notebook_delete, and notebook_describe.

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 guidance is given about when to use this tool versus alternatives, what prerequisites exist (e.g., the notebook must already exist), or how it differs from notebook_create or notebook_edit-style operations. The intended usage is only implied by the operation name.

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 of behavioral disclosure. It only states that the tool invites multiple collaborators in one request, omitting key behaviors such as the need for confirm=True after user approval, the mutating nature of the action, and any side effects like email notifications. This is too minimal for a sensitive sharing 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?

The description is a single, front-loaded sentence with no filler or redundancy. It is concise, though it sacrifices necessary context. Conciseness itself is strong, but the terseness contributes to the overall incompleteness.

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 tool with a confirmation parameter and several sharing siblings, this one-sentence description is not complete enough. An agent cannot tell when to use batch sharing, that user approval is required, or how this differs from notebook_share_invite. The presence of an output schema does not compensate for the missing behavioral and usage context.

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 adds no parameter-level meaning beyond what the schema already provides; recipients, notebook_id, and confirm are each documented in the input schema, so the tool description does not need to repeat them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Invite') and the resource ('collaborators'), with 'multiple' and 'in a single request' conveying the batch nature, which loosely distinguishes it from the single-invite sibling (notebook_share_invite). However, it does not explicitly mention the notebook context or name alternatives, 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?

The description provides no guidance on when to use this tool versus notebook_share_invite or notebook_share_public, and it does not mention the confirm=True prerequisite that appears in the schema. An agent is left without context for choosing this tool or understanding the approval flow.

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 must carry the behavioral disclosure burden. It only says 'Invite a collaborator by email' and does not disclose whether an email is sent, whether invites can be duplicated, whether permissions are required, or what side effects occur.

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 six words and contains no filler, so it is very concise. However, its brevity comes at the cost of omitting useful behavioral and selection context.

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 invite tool with fully described parameters and an output schema, the basic call signature is covered. Yet the absence of annotations and any information about side effects or sibling alternatives leaves an agent with meaningful gaps about consequences and correct selection.

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 notebook_id, email, and role already described, including the default role value. The phrase 'by email' does not add meaningful parameter details beyond what the schema already provides, so the baseline score 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 uses a specific verb ('invite') and resource ('collaborator by email'), making the tool's core function clear. It is reasonably separable from sibling tools like notebook_share_public and notebook_share_batch because it emphasizes email invitation, though it does not explicitly name or contrast those 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 provides no guidance about when to use this tool versus notebook_share_batch, notebook_share_public, or notebook_share_status. It states the action but gives no selection criteria, prerequisites, or exclusions.

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 disclose behavior itself, and it does state the core mutation: enabling or disabling public link access. It does not mention side effects, permission requirements, or whether toggling affects existing access, but the simple boolean semantics keep this minimally transparent.

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 sentence states the action and object with no filler. It is front-loaded and appropriately sized for a two-parameter toggle tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple boolean toggle with an output schema and fully described parameters, the description covers the essential operation. It does not discuss when to use it versus sharing alternatives, but the low complexity means this is not a critical gap.

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 parameter descriptions already explain notebook_id and is_public. The tool description adds little beyond labeling the action 'public link access,' which maps directly to is_public, so it meets the baseline without adding new semantics.

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 uses a specific verb pair (enable/disable) and a clear resource (public link access), so an agent knows this tool toggles public sharing for a notebook. It does not explicitly name sibling tools, but the operation is distinct from notebook_share_status, notebook_share_invite, and notebook_share_batch.

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 intended use is implied by the description: call this when you need to turn a notebook's public link on or off. However, it gives no explicit guidance about when to prefer this over the sibling sharing tools or any prerequisites/exclusions.

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?

There are no annotations, so the description carries the full burden for behavioral disclosure. 'Get current...' clearly implies a read-only status operation rather than a mutation, but it does not mention permissions, session requirements, or explicitly state that no changes are made. It is minimally transparent but leaves some behavioral details to inference.

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 sentence that gets straight to the operation and target resource. There is no filler, repetition, or unnecessary detail.

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?

One parameter, an output schema, and a simple read operation make this a low-complexity tool. The description plus schema cover what the tool returns and what input is required, though the lack of usage guidance remains a minor gap.

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 single parameter is fully described in the schema as 'Notebook UUID,' so schema coverage is 100%. The description adds no additional parameter semantics, but the schema already provides the required meaning. A baseline 3 is appropriate here.

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 uses 'Get' as a specific verb and identifies the exact resource: current sharing settings and collaborators. This clearly distinguishes the tool from mutating share siblings like notebook_share_public, notebook_share_invite, and notebook_share_batch, and from general notebook_get/notebook_describe.

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 guidance is given on when to use this tool versus the other sharing tools or notebook_describe. The description states what the tool does but provides no condition, prerequisite, or 'use this when' cue.

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 must carry the burden of behavioral disclosure. 'Execute' implies that run triggers meaningful work, but the description does not state whether execution is asynchronous, long-running, destructive, or what side effects it may have on the notebook or related resources. Only 'list' is obviously safe by inspection.

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 compact, front-loaded with the resource, and uses a scannable bullet list for the two actions. Every line earns its place, with no redundant elaboration or 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-action dispatcher, the description sufficiently covers the tool's purpose while the schema covers parameter requirements and an output schema exists for return values. The main gap is behavioral context around execution side effects, but this is a minor omission for basic invocation.

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 already has a meaningful description, including required-for-run semantics and the $INPUT_URL substitution behavior. The tool description adds no parameter-level detail beyond naming the run/list actions, so the schema carries the interpretive weight; 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 clearly identifies the resource ('multi-step notebook pipelines') and enumerates two concrete operations, run and list, each with a one-line definition. It is specific enough to convey what the tool does, though it does not explicitly differentiate this tool from sibling tools such as batch or notebook_query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The action list provides clear context for selecting between run and list: run to execute a pipeline on a notebook, list to enumerate available pipelines. However, it gives no guidance on when to prefer this tool over alternative sibling tools, and prerequisites are left to the schema rather than stated in the description.

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 of behavioral disclosure. It explains that the tool either reloads tokens from disk or performs headless re-authentication, and states that it returns a success status. It could be more explicit about side effects like overwriting the current session, but the core behavior and outcome are disclosed.

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 compact and well structured: main behavior first, then use cases, then return value. Every sentence adds operational value and there is no redundant or vague phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless tool, this is complete. It explains when to call it, what it attempts to do, prerequisites (nlm login or Chrome saved login), and what the return status conveys. The output schema may hold richer detail, but the description covers the essentials an agent needs.

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 are zero parameters and schema coverage is 100%, so there is nothing parameter-specific to document. The baseline for zero-parameter tools is 4, and the description appropriately focuses on behavior and use context instead.

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 and resource: 'Reload auth tokens from disk or run headless re-authentication.' This clearly states what the tool does and distinguishes it from related tools like save_auth_tokens, which is about persisting tokens rather than refreshing 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 description gives concrete trigger conditions: call after running `nlm login` or when Chrome profile has saved login for automatic re-authentication. It does not explicitly contrast with save_auth_tokens or state when not to use it, but the guidance is sufficiently clear for a zero-parameter utility 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?

With no annotations, the description carries the behavioral burden. It discloses the key prerequisite and clearly implies a mutating import, but it does not describe idempotency, duplicate handling, or other side effects on the notebook. This is adequate but not deeply transparent.

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 two concise sentences: the first states the action, the second gives an operational precondition. 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?

The description covers the essential workflow context and the full parameter schema plus output schema handle the structural details. It lacks discussion of idempotency or duplicate imports, but these are not critical given the rich structured metadata.

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 all parameters already have descriptive text. The tool description itself adds no parameter-level meaning, 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?

The description states a specific verb ('Import'), object ('discovered sources'), and destination ('notebook'), which clearly differentiates this from research_start and research_status. 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?

It provides an explicit workflow precondition: 'Call after research_status shows status="completed"'. This tells the agent when to invoke the tool, but it does not name alternative tools or explicitly state when-not-to-use.

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 behavioral burden. The 'Workflow: research_start -> poll research_status -> research_import' line clearly conveys that this is an asynchronous first step, not a synchronous results-returning call. It also clarifies that the tool finds new sources rather than querying existing content, though side effects like notebook creation are left to 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?

The description is three compact sentences with no filler: purpose is front-loaded, followed by concrete usage examples and the workflow. Every sentence contributes useful selection and invocation 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?

The description covers what the tool does, when to use it, and where it fits in the start -> status -> import workflow, while the schema covers the parameters and an output schema exists. It is mostly complete, though it does not mention prerequisites such as Drive sync/auth or explicitly exclude use cases better served by query-focused siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the mode/source mapping ('deep research' -> mode, 'search Drive' -> source) but adds little meaning beyond what the schema already provides for query, title, and notebook_id.

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 resource ('web or Google Drive') and outcome ('FIND NEW sources'), so it is clearly a source-discovery tool. It also distinguishes itself from later-stage siblings like research_status and research_import through the workflow line.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit invocation contexts with natural-language examples: 'deep research on X', 'find sources about Y', 'search web for Z', 'search Drive'. It does not state when not to use the tool or name alternative query tools like notebook_query_start, so it stops 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 provided, the description carries full responsibility for behavioral disclosure. It does reveal the critical blocking behavior and timeout termination, which is valuable. However, it omits potential side effects such as auto_import behavior or what happens on timeout (e.g., partial results), leaving gaps for a caller to discover.

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 two short sentences with no filler. It front-loads the core action ('Poll research progress') and then states the key behavior. Every word 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?

The output schema and complete parameter documentation cover the return shape and inputs, so the description only needs to add behavioral and workflow context. It covers blocking behavior but lacks workflow placement (after research_start, before research_import) and does not distinguish from sibling status tools. This makes it adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no extra parameter-level detail beyond the schema, 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 uses a specific verb ('Poll') and a clear resource ('research progress'), and adds the key behavioral trait that it blocks until completion or timeout. It is distinct from research_start and research_import, though it does not explicitly differentiate itself from similar status tools like notebook_query_status.

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 its usage: call this to poll research progress and wait for completion. However, it gives no explicit guidance on when to use it versus alternatives, nor does it mention that it should follow research_start or precede research_import. This is implied usage, not explicit direction.

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 provided, the description carries the full burden of disclosing behavioral traits. It explains the fallback workflow but does not describe side effects, storage behavior, whether existing auth is overwritten, or what the tool returns after saving tokens.

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 short and front-loaded with the key fallback message. The bullet list repeats the 'try nlm login first' idea slightly, but overall it is efficient and well-structured for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides enough routing context for the agent to know when to use the tool, and the schema covers parameters and output. However, without annotations, the lack of behavioral and side-effect details leaves some context gaps for a sensitive auth-related 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 parameter descriptions already document each field well. The main description adds little parameter-specific meaning beyond identifying cookies as the required input, which is a reasonable baseline given the high schema coverage.

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 the action ('Save') and resource ('NotebookLM cookies'), and labels the tool as a FALLBACK method for authentication. It clearly conveys the purpose, though it does not explicitly differentiate from the sibling `refresh_auth` tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance: run `nlm login` first via Bash/terminal, and only use this tool if the automated CLI fails. This is clear, actionable, and leaves little room for an agent to misuse the 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?

With no annotations, the description carries the full burden and does so thoroughly. It explains the caching behavior, the 30-second staleness window, the mtime-based bypass, and the exact meaning of each auth_status value, including edge cases like unverified credentials still working.

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 longer than average, but most of the length is justified by detailed auth_status semantics and actionable assistant instructions. It is well-structured and front-loaded with the core purpose, though the return-field listing is partially redundant with the existing output 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?

The description is complete for a no-parameter informational tool. It explains what the tool returns, how to interpret each auth_status value, and what actions the assistant should take in different scenarios. The output schema covers the structured return details, so 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema fully documents the lack of 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?

The description clearly states that the tool retrieves version, auth status, and MCP capability visibility, using a specific verb and resource. It does not explicitly differentiate itself from sibling tools, but the resource is distinct enough that no direct comparison is necessary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong conditional guidance, such as informing the user when update_available is True and telling the assistant to have the user run `nlm login` when auth_status is stale. It also warns against assuming re-auth is needed when auth_status is unverified. It does not explicitly compare to sibling tools like refresh_auth, but the behavioral guidance is clear.

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 disclose safety and side-effect behavior, but it only restates the action and supported source types. It does not mention that adding a source creates a notebook resource, may be asynchronous unless wait=True, or has file-system/admission caveats; those live in the schema rather than the 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?

Three short sentences, no filler, and the operative verb and scope are front-loaded. Every sentence contributes by naming the resource, the unified nature, and the supported source types.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema is rich enough to guide per-parameter invocation, and an output schema exists, so the description does not need to discuss return values. However, for a tool with 11 parameters and no annotations, the description leaves general behavioral context and sibling-tool routing unstated; it is minimally adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all 11 parameters. The description's 'Supports: url, text, drive, file' matches source_type choices but adds no parameter-level meaning beyond the schema's existing 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?

Description names a specific action and resource ('Add a source to a notebook') and immediately lists supported source types, making it clear this is the ingestion tool rather than sibling operations like source_describe or source_delete. 'Unified tool for all source types' further establishes its scope.

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 when to use it (adding any of url, text, drive, file to a notebook) but does not explicitly contrast it with siblings such as source_list_drive, source_sync_drive, or source_get_content. There is no 'when not to use' guidance beyond the implied add-vs-manage distinction.

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 of behavioral disclosure. It clearly flags irreversibility and permanence ('IRREVERSIBLE', 'permanently') and the confirmation gate, which are the most important behavioral traits for a delete tool. Minor omissions like cascading effects or auth requirements do not outweigh this transparency.

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 extremely concise: three short, front-loaded statements with zero filler. Every phrase ('permanently', 'IRREVERSIBLE', 'Requires confirm=True') adds meaningful operational 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?

The essential context for a destructive tool is present: what it deletes, that it is permanent, and that confirmation is required. However, the schema lists no required parameters, and the description does not clarify that at least one of source_id or source_ids must be provided, nor what happens if both are supplied. The output schema covers return values, but this input ambiguity 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?

Schema coverage is 100%, so the schema already documents all three parameters with descriptions. The description adds only marginal value by implying bulk support with 'source(s)' and echoing 'confirm=True', which is already stated in 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 explicitly states the action ('Delete'), the target ('source(s)'), and the critical characteristic ('permanently', 'IRREVERSIBLE'). This makes the tool's destructive purpose unambiguous and distinguishes it from sibling source tools like source_describe, source_rename, or source_get_content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a prerequisite ('Requires confirm=True') but does not explicitly say when to use this tool versus alternatives, or that it should only be invoked after explicit user approval. The usage context is implied by the destructive purpose rather than fully stated.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It adds useful context by revealing that the summary is 'AI-generated' and that the response includes 'keyword chips', which suggests a non-trivial generation step. However, it does not mention whether the operation is read-only, whether it incurs latency/costs, or any side effects, so transparency is incomplete.

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 entire description is a single, front-loaded sentence that conveys the primary purpose and key output details in under 10 words. No filler or redundant information is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required parameter, 100% schema coverage, and an output schema), the description is mostly complete. It informs the agent of the result type. The only gap is the lack of explicit usage guidance relative to siblings, but the straightforward read-oriented purpose makes this a minor omission.

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% for the single parameter source_id, which is documented as 'Source UUID'. The description adds no additional meaning or context about the parameter 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 clearly states a specific verb ('Get') and resource ('AI-generated source summary with keyword chips'). It is obvious what the tool returns, and the name 'source_describe' aligns with this read action. However, it does not explicitly distinguish itself from sibling tools like source_get_content, so it misses the extra differentiation credit.

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 guidance is given about when to use this tool versus alternatives such as source_get_content, source_list_drive, or source_rename. The description only states what it does, leaving the agent to infer appropriate usage from the tool name and 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 provided, the description carries the transparency burden. It discloses that no AI processing occurs, that the raw indexed text is returned, and it even adds a performance trait. It does not mention potential edge cases like unindexed sources or the wait/polling behavior, but these are partially 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?

The description is two sentences with no fluff. The main verb and resource are front-loaded, immediately followed by clarifying details about what is returned and how it compares to an alternative tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, combined with the 100% schema coverage and existing output schema, gives an agent enough to select and invoke the tool correctly. It covers what the tool does, what it returns, and a performance-based comparison, though it could more explicitly address when a wait parameter would be needed.

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 parameters are already documented in the input schema. The tool description does not add parameter-specific meaning beyond noting the source types that back the source_id, so the baseline score 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 clearly states the specific action: retrieving raw text content from a source without AI processing. It also lists the supported source types and explicitly differentiates itself from notebook_query, making its purpose 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?

The description provides a clear usage context by noting it is 'Much faster than notebook_query for content export,' which implies when to prefer this tool over a key alternative. It lacks an explicit when-not-to-use statement or exclusions for other sibling tools, so it stops short of full 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?

There are no annotations, so the description carries the behavioral burden. It conveys that the tool lists sources and reports Drive freshness status, implying a read-only listing operation, but it does not explicitly discuss side effects, auth requirements, or performance implications of the freshness checks.

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 two short sentences with the primary action front-loaded. Every sentence contributes value: the first states what the tool does, and the second provides actionable usage context.

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 a 100%-covered schema and an output schema, the description covers the main contextual needs: what is listed and when to use it. It is slightly incomplete only because the absence of annotations leaves minimal room to clarify side effects or auth expectations.

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 skip_freshness are already fully explained in the input schema. The description adds no parameter-level detail beyond naming freshness status, so the baseline score 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?

The description uses the concrete verb 'List' and identifies the resource and scope: sources with types and Drive freshness status. The second sentence explicitly ties it to source_sync_drive, making the tool's role and distinction from the sync sibling clear.

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 explicitly says 'Use before source_sync_drive to identify stale sources,' giving agents a clear precondition and use case. This is strong guidance on when to call this tool versus the related sync tool.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the rename action and does not disclose whether the operation is limited to display title, whether it is reversible, or what side effects may occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence with no wasted words and the key action is front-loaded. It is appropriately concise, though slightly minimal in supporting context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema covers all parameters and an output schema exists, so basic invocation is clear. However, with no annotations and no usage guidance, the description leaves behavioral context and decision-making to the agent.

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 adds no parameter nuance beyond what the schema already provides, but the schema fully documents all three required parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Rename'), a clear resource ('a source'), and the containing context ('in a notebook'). This is distinct from sibling tools like source_delete, source_describe, and notebook_rename, so an agent can identify the correct operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance about when to prefer this tool over alternatives, nor does it name any excluded cases or prerequisites. The only usage signal is the verb itself, which is implicit rather than 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose a required confirmation flag and a prerequisite workflow, which is useful. However, it does not explain what 'sync' actually changes, whether it is destructive or reversible, or any permission/auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two short sentences that state the action, the mandatory flag, and the prerequisite call. Every sentence earns its place and the critical information 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 no annotations, the description is reasonably complete for a two-parameter tool with an output schema. It covers the confirmation requirement and the prerequisite listing step, but it omits any explanation of sync side effects, permissions, or what happens to existing content, leaving some ambiguity for an agent.

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 parameters. The description adds meaningful context by linking source_ids to the output of source_list_drive and emphasizing that confirm must be true, enriching the agent's understanding of how to populate and invoke the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Sync Drive sources with latest content.' This clearly identifies the action and distinguishes it from sibling tools like source_list_drive or source_get_content, especially by referencing the listing tool as a prerequisite.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance: 'Requires confirm=True' and 'Call source_list_drive first to identify stale sources.' This tells the agent when and how to prepare, but it does not explicitly state when not to use this tool or mention alternative tools for similar operations.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Create' and lists types; it does not disclose the important confirm=True/user-approval requirement, side effects, or whether creation is synchronous or requires follow-up status checks. This is a significant gap for a mutation tool.

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 compact and front-loaded with the key action and resource. The supported-types list is scannable. Minor redundancy exists between 'Create any NotebookLM studio artifact' and 'Unified creation tool', but overall there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 22 parameters, no annotations, and only 18% schema coverage, this description is far too sparse to support correct invocation. It omits the confirmation/approval workflow, how artifact types map to relevant parameters, and how this tool relates to studio_revise and studio_delete. The output schema does not compensate for these missing invocation details.

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 only 18%, so the description needed to compensate by explaining artifact-specific parameters, but it only repeats the artifact_type values already present in the schema. It adds no meaning for title, source_ids, formats, focus_prompt, difficulty, orientation, or other fields that are mostly undocumented.

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 ('Create'), a clear resource ('NotebookLM studio artifact'), and enumerates the supported artifact types. This distinguishes it from siblings like studio_revise and studio_delete by establishing it as the creation entry point.

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 is positioned as a 'Unified creation tool', but there is no explicit guidance on when to use it versus alternatives, nor exclusions/preconditions. No mention of when studio_revise or studio_delete should be chosen instead, and no mention of prerequisites like notebook existence, source selection, or user approval.

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