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

No annotations exist, so the description carries the full burden. It does disclose non-obvious behavior: an engine selector ('auto', 'gcp_rest', 'rpc_bridge') and a `wait` flag that blocks on source indexing completion — genuinely useful context an agent could not infer. It omits mutation/irreversibility, auth requirements implied by the notebook_login sibling, duplicate-source handling, and side effects on the target notebook, which is a real gap for an unannotated write 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 purpose sentence is correctly front-loaded and each Args line is short and earns its place. There is minor duplication — the supported source kinds are enumerated in the opening sentence and again in the source_type entry — and the raw Python docstring formatting is slightly heavier than needed, but nothing is 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 output schema exists, so return values need not be explained. However, with zero annotations and zero schema description coverage on an 8-parameter mutation tool, the description should also establish required permissions/state and what happens to the notebook after insertion; it covers the mechanics but not the operating contract.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate and largely does — every parameter gets a line, including the conditional constraint that mime_type applies only when source_type == 'gdrive', and the default behavior of notebook_id falling back to the workspace-attached notebook. Two entries remain thin: `engine` lists the allowed values without saying which to choose or why, and 'workspace_dir override' does not explain what is being overridden.

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

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

States a specific verb (Add) and resource (source) with an explicit enumeration of supported source kinds: text, web URL, YouTube video, Google Drive document. That is far beyond a tautology. It does not, however, contrast itself with siblings such as notebook_sync_files, which plausibly also introduces content into a notebook, so the differentiation bar for a 5 is not met.

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

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

Usage is implied by the source_type enumeration — an agent can infer this is the tool for registering one source at a time. But there is no explicit when-to-use versus notebook_sync_files (bulk file ingestion) or notebook_attach, and no prerequisites such as requiring a completed notebook_login or an existing notebook_id.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that attachment writes to `.agents/notebook.json` and that aliases allow multiple notebooks to be registered, but it omits auth requirements, overwrite or alias-collision behavior, and what the `engine`, `active_source_ids`, or `workspace_dir` parameters affect.

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 the alias example earns its place. It is efficient but somewhat sparse for a seven-parameter mutation 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?

An output schema exists, so return values need not be explained. But for a seven-parameter, unannotated state-changing tool with 0% schema description coverage, the description is incomplete: most parameters and key behavioral details are 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 0%, so the description must compensate for seven parameters. It explains only `alias` meaningfully, with examples, and implies `notebook_id`, but leaves `title`, `engine`, `workspace_dir`, `active_source_ids`, and `gcp_project_number` entirely 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 and resource: attach a Gemini Notebook to the active workspace, and names the backing file `.agents/notebook.json`. It is clear enough to distinguish from create/get/list siblings, though it does not explicitly name 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?

Usage is implied: register a notebook in the active workspace, optionally with an alias for multiple notebooks. However, there is no explicit when-to-use guidance versus notebook_create, notebook_get, or notebook_invoke, and no mention of 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?

No annotations are provided, so the description carries the full behavioral burden for a mutation tool. It does not state required permissions, what 'attach' does to the workspace, whether the title must be unique, how 'engine' selection behaves, or what side effects occur. The API/RPC mention is implementation detail rather than behavioral disclosure.

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

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

A single front-loaded sentence with no repetition. The 'via GCP v1alpha REST API or RPC bridge' clause is somewhat implementation-heavy and does not help an agent decide or invoke, but the overall statement remains tight.

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 six-parameter mutation tool with no annotations and 0% schema coverage, this description is too thin. The output schema means return values need not be explained, but missing details about prerequisites, engine selection, workspace attachment, and parameter behavior leave significant 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 0% across six parameters, so the description must compensate. It only loosely hints at attach_to_workspace with 'optionally attach it' and says nothing about title, alias, emoji, engine (including valid values beyond the default 'auto'), or workspace_dir. Most parameter meaning is left 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?

States a specific verb and resource: 'Create a new Gemini Notebook.' The mention of GCP v1alpha REST API or RPC bridge adds implementation context, and 'optionally attach it' hints at a post-create step. It doesn't explicitly contrast with siblings like notebook_attach or notebook_list, but the create action 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 this versus notebook_attach, notebook_list, or whether the workspace must already exist. The phrase 'optionally attach it' implies a workflow choice but does not explain the condition or prerequisites such as authentication or an existing workspace.

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, yet it only names a transport ('GCP v1alpha REST or RPC bridge'), which is implementation detail rather than agent-relevant behavior. It does not say whether generation is synchronous or long-running (despite a `wait` parameter), what permissions are needed, or what happens to existing audio overviews.

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 single sentence is front-loaded and wastes no words, which is good structurally. However, given a 9-parameter tool with zero schema coverage, this level of brevity is under-specification rather than genuine conciseness.

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 9-parameter generation tool with no annotations and 0% schema description coverage, the description omits nearly everything an agent needs: parameter meanings, async behavior, engine selection, and output timing. The existence of an output schema only relieves the need to describe return values, not inputs.

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?

All 9 parameters have 0% schema description coverage, and the description mentions none of them. Critical fields like `engine`, `audio_length`, `audio_format`, `episode_focus`, and `source_ids` are left completely unexplained, so the agent has no basis for setting them correctly.

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: 'Generate an Audio Overview podcast on the notebook,' which tells an agent this produces audio content rather than notes or research. It does not explicitly distinguish itself from the sibling notebook_generate_artifact, which could plausibly overlap.

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 this versus notebook_generate_artifact or other generation tools, and no prerequisites or exclusions are mentioned. The agent must infer usage entirely from the 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?

Annotations are absent, so the description carries the full behavioral burden for a destructive operation. It names the backend mechanism ('v1alpha batchDelete or RPC bridge') but says nothing about irreversibility, cascade effects on sources/notes, required permissions, or batch partial-failure semantics. The implementation detail adds little for an agent deciding whether to call it.

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

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

A single front-loaded sentence with the verb and resource first and no padding. The trailing backend-mechanism clause is the only part that doesn't clearly earn 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?

Output schema exists, so return values needn't be described, but for a destructive multi-delete tool with no annotations and 0% parameter coverage the description is substantially under-specified. Nothing tells an agent about safety, scope of deletion, or the meaning of the two optional parameters.

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

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

Schema coverage is 0% and three parameters exist, yet the description only indirectly implies notebook_ids. The 'engine' parameter (default 'auto', presumably selecting batchDelete vs RPC bridge) and 'workspace_dir' are completely undocumented in both schema and prose, leaving an agent to guess their 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?

States a specific verb and resource: 'Delete one or more Gemini Notebooks.' The batch scope ('one or more') separates it from single-resource operations and from notebook_delete_sources, which acts on sources rather than notebooks. It never names a sibling explicitly, so the differentiation is implicit rather than stated.

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

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

No guidance on when to use this versus notebook_delete_sources or notebook_list/notebook_get for verification. No prerequisites, no cautions, no mention of what happens when some IDs in the batch are invalid.

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 signals mutation but does not disclose that deletion is permanent/irreversible, whether missing or invalid source_ids cause partial failure, or how engine 'auto' selects a backend. With no annotations to carry the destructiveHint or readOnlyHint signals, the description carries the full burden and falls well short.

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

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

A single front-loaded sentence with no filler. It is efficient, though its brevity is a result of under-specification rather than disciplined editing.

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

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

An output schema exists so return values need not be explained. But for a destructive, unannotated tool with four undocumented parameters, an agent lacks sufficient information to call it safely or correctly in varied contexts.

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

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

Schema description coverage is 0%, so the description must compensate; it only hints that source_ids is a list ('one or more'). It says nothing about engine ('auto'), notebook_id, or workspace_dir, leaving three of four parameters with no semantic context anywhere.

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

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

The description gives a specific verb and resource: 'Delete one or more sources from a Gemini Notebook'. It implicitly distinguishes itself from notebook_delete (notebook-level) and notebook_add_source, though it never names those siblings explicitly.

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

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

It states no when-to-use context, no alternative tool for removing content, and no prerequisites. There is also no guidance on which of notebook_delete vs notebook_delete_sources to pick when a whole notebook should go.

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 burden and largely drops it: it never says whether generation is synchronous or asynchronous, what `wait`/`timeout` do, whether artifacts persist to `workspace_dir`, or whether jobs can be polled later via notebook_status. It is not misleading, just silent on everything beyond the artifact name list.

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

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

A single front-loaded sentence with the enumerated types in a parenthetical; no filler. Slightly dense with the long type list, but every element is informative.

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 9-parameter generation tool with an output schema, the description omits the operational essentials: blocking vs. async behavior, source/notebook scoping, and where output lands. The presence of an output schema excuses return-value explanation, but not the missing invocation 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 0% across 9 parameters, so the description must compensate and doesn't. It only implicitly enumerates the allowed `artifact_type` values (genuinely useful since the schema has no enum), while `source_ids`, `notebook_id`, `instructions`, `language_code`, `report_format`, and `workspace_dir` are left entirely undefined.

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

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

The description gives a concrete verb and resource ('Generate a NotebookLM Studio Artifact') and enumerates the artifact types, so an agent knows exactly what comes out. It stops short of a 5 because it doesn't separate this from the sibling notebook_create_audio, which plausibly overlaps with the 'audio'/'video' types listed here.

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

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

There is no statement of when to use this tool versus notebook_create_audio or notebook_research, no preconditions (e.g., that a notebook or sources must exist first), and no note about how `wait`/`timeout` change the calling pattern. The list of artifact types is the only context 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 behavioral burden. 'Get' implies a read, but it says nothing about authentication requirements, whether the call fails without notebook_login, what 'Dual-Engine' entails, or how the 'auto' engine default is resolved; only the return payload is covered by the output schema.

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

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

A single front-loaded sentence with no filler or repetition. It is appropriately sized for what it chooses to say, though its brevity leaves the gaps noted in other dimensions.

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 three undocumented parameters, no annotations, and 21 sibling notebook tools, this one-sentence description is not complete enough. The output schema covers return values, but selection guidance, parameter meaning, and auth/prerequisite context are all 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 0%, so the description must compensate, and it does not. It never explains notebook_id (or what happens when it is null), workspace_dir, or the 'engine' parameter beyond the vague phrase 'Dual-Engine'.

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

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

The description names a specific verb ('Get') and a concrete resource set ('metadata, AI summary, and list of sources for a Gemini Notebook'), so an agent knows exactly what comes back. It does not explicitly distinguish itself from close siblings like notebook_list, notebook_status, or notebook_get_source_text, so it stops short of 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?

There is no guidance on when to call this versus notebook_list (enumerate notebooks) or notebook_status (presumably lighter status check), nor any mention of prerequisites such as being logged in. Usage is only implied by the word 'Get' and the object 'Gemini Notebook'.

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, yet it does not say the operation is read-only, what happens if the source is not indexed, whether text is truncated, or what the returned guide contains. The one piece of real context is that the guide is an optional AI summary/keywords artifact.

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 tight sentence with the resource and scope front-loaded; nothing is padded. It is arguably too terse for a four-parameter tool, but that is a completeness issue rather than a conciseness one.

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

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

An output schema exists so return values need not be explained, but with no annotations and 0% parameter coverage the description leaves the agent guessing about the roles of notebook_id and workspace_dir and about failure behavior. For a four-parameter tool this is under-described.

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

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

Schema description coverage is 0% across four parameters, and the description only touches include_guide indirectly ('optional AI summary/keywords guide'). It says nothing about source_id, notebook_id, or workspace_dir — notably why a notebook_id is needed when a source_id is already supplied.

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

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

The description gives a specific verb ('Fetch') and resource ('the full indexed text ... of a specific source'), and the 'full indexed text' phrasing separates it from search-style siblings like notebook_search_sources. It does not name a sibling explicitly, so it stays at 4 rather than 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?

There is no statement of when to use this tool versus notebook_get, notebook_search_sources, or notebook_query, and no prerequisites or exclusions are given. The only hint is that it targets 'a specific source', which the agent must infer.

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 disclosure burden, and it does describe what each mode returns (synthesized answer, citations, follow-ups; metadata, summary, topics, sources). That is meaningful behavioral detail, but it says nothing about read-only vs mutating nature, permission/auth requirements, or rate limits, which are the gaps annotations would normally cover.

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

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

Front-loaded with the core action, then cleanly separated into two conditional bullets. Nearly every sentence earns its place, with only minor verbosity in the return-value enumeration.

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

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

An output schema exists, so return shapes needn't be documented, yet three of five parameters have no explanation in schema or description, and the tool's permission/side-effect profile is unstated. Adequate for the dual-mode behavior but not complete for a zero-coverage five-parameter 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 0% for five parameters. The description clarifies only `question` behavior and implicitly maps `target` to 'ID, workspace alias, or title', but `engine`, `workspace_dir`, and `include_sources` are entirely unexplained anywhere, which is a substantial gap at this coverage level.

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

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

Names a specific verb and resource ('Invoke a Gemini Notebook') and clarifies the identifying keys (ID, workspace alias, title). It does not distinguish this from close siblings like notebook_query or notebook_get, so an agent cannot be fully certain which sibling is the right call without reading both schemas.

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

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

The two-bullet branch explains when the tool behaves one way versus the other (question present vs omitted), which is useful internal routing guidance. However, it offers no comparison to alternatives such as notebook_query or notebook_get, leaving the agent to guess whether invoking is preferred over querying.

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 disclosure burden. It reveals the transport (GCP v1alpha REST or RPC bridge) but says nothing about authentication requirements, given that a sibling notebook_login exists, pagination behavior tied to page_size, or rate/size limits on listing.

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

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

A single front-loaded sentence with the verb and resource first and the optional filter trailing. No redundant filler, though it omits the operational context that would have earned a 5.

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

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

An output schema exists, so return values need not be described. But for a four-parameter tool with zero annotation coverage and no parameter documentation, the description leaves an agent unable to choose an engine, size pages, or understand prerequisites before calling.

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

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

Schema description coverage is 0% across four parameters. The description explains only the title filter (query), leaving engine, page_size, and workspace_dir entirely undocumented in both schema and prose.

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

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

States a specific verb (List) and resource (Gemini Notebooks), plus the optional title filter, so an agent can distinguish it from mutating siblings like notebook_create or notebook_delete. It does not, however, differentiate itself from read siblings such as notebook_get or notebook_search_sources.

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

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

There is no statement of when to use this tool versus alternatives (e.g. notebook_get for a single notebook, or how the 'engine' choice should be made). The only implicit guidance is that a title filter may be supplied, which an agent could infer 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?

With no annotations, the description carries the full behavioral burden and discloses important traits: browser-cookie import versus official gcloud OAuth, the unofficial community RPC bridge versus official Google Cloud API, and that open_system_browser opens the OS default browser. It still omits behavior for fresh, account, browser, and timeout.

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

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

The description is front-loaded and organized into clear mode-based bullets. It is somewhat verbose in naming engine internals, but the structure makes the primary modes easy to scan.

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

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

The output schema exists, so return values need not be described. However, for a seven-parameter authentication tool with no annotations and zero schema descriptions, the description is only partially complete because several parameters and their effects are unexplained.

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

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

Schema description coverage is 0% across seven parameters, so the description must compensate. It explains gcloud, browser_cookies, and open_system_browser, but leaves fresh, account, browser, and timeout undocumented, and it does not clarify the distinction between browser and browser_cookies.

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: connect a Gemini Notebook session. It distinguishes authentication from Playwright sign-in automation, and it is obviously distinct from the notebook_* operational siblings, though it does not explicitly name or contrast 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?

It explains the default browser-cookie mode, the gcloud OAuth mode, and the open_system_browser verification mode. It does not explicitly say when this tool must be called versus notebook_status or other siblings, but the authentication 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 burden. It reveals nothing about the destructive nature of 'delete', whether notes persist across sessions, permission requirements, or how the default 'Agent Note' title and empty content behave.

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

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

A single front-loaded sentence with no waste, but the brevity here is under-specification rather than economy — the action list consumes the space that should have gone to per-action parameter requirements.

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 6-parameter, 5-action mutating tool with no annotations and no schema descriptions, the description is far too thin; the output schema covers return values, but nothing tells the agent which inputs are valid for which action or what delete does.

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

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

Schema description coverage is 0% across 6 parameters. The description only enumerates legal values for `action`; it never explains note_id, notebook_id, workspace_dir semantics, or which fields apply to which action — a critical gap for a multi-action tool with zero required params.

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

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

States a specific verb and resource: managing persistent notes inside a Gemini Notebook, with the action enumeration clarifying it is a multi-operation note CRUD tool. This distinguishes it from notebook-level siblings like notebook_create or notebook_get, though it doesn't explicitly say so.

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 usage modes, but there is no guidance on which parameters each action needs, no prerequisites, and no steering among the many notebook_* siblings (e.g., when to use notebook_notes vs notebook_attach or notebook_query).

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

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

With no annotations, the description carries the full burden, and it does disclose real behavioral traits: automatic fallback to active_source_ids, citation-bearing answers, and the state-changing side effect of save_as_note writing a note. It omits auth requirements, whether the query is read-only absent save_as_note, and any cost/latency or engine-selection 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?

Three short sentences, front-loaded with the purpose and followed by the two behavioral clauses that matter most. Minor clutter from inline backticks and JSON-path detail, but no filler sentences.

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

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

An output schema exists, so the answer/citation shape need not be described. But for an 8-parameter tool with zero schema description coverage and no annotations, three parameters (engine, workspace_dir, notebook_id) are entirely undocumented and the mutation boundary of save_as_note is only implied — the definition is adequate, not sufficient.

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 0% across 8 parameters, so the description must compensate. It adds genuine semantics for source_ids (default resolution), conversation_id (follow-up threading), and save_as_note/note_title (note persistence), but leaves engine, workspace_dir, and notebook_id completely unexplained.

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

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

States a specific verb and resource ('Ask a grounded question against a Gemini Notebook') plus the return shape ('answer + inline citations'), which cleanly distinguishes it from siblings like notebook_notes or notebook_search_sources. It stops short of naming an explicit alternative, but the retrieval-plus-generation framing makes the role obvious.

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 explains useful conditional behavior (default source filtering when source_ids is omitted) and the multi-turn path via conversation_id, which implicitly tells the agent when to reuse a conversation. It never says when to prefer this over notebook_search_sources, notebook_research, or notebook_get_source_text, so sibling selection still requires 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 behavioral burden. It usefully discloses an RPC bridge and a conditional config-file update side effect, but it does not state required permissions, what happens when no notebook is attached, or whether the operation is reversible.

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

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

The description is a single front-loaded sentence with no filler. Every clause contributes: the action, the target, the bridge, and the conditional side effect.

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 mutation tool with no annotations and 0% schema description coverage, one sentence is insufficiently complete. It omits parameter semantics, attachment prerequisites, and failure behavior; the output schema covers return values, but the call-side guidance remains thin.

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

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

Schema description coverage is 0%, and the description names none of the three parameters. It does not explain the required 'new_title', the optional 'notebook_id', or the role of 'workspace_dir', leaving the agent with no parameter meaning beyond what the schema titles weakly imply.

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') and resource ('Gemini Notebook'), and adds the mechanism ('via the RPC bridge') plus a conditional side effect. It is clearly distinct from create/delete/attach siblings, though it does not explicitly compare itself to 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?

There is no guidance on when to use this tool versus alternatives such as notebook_attach or notebook_create, and no prerequisites are stated beyond the conditional '.agents/notebook.json' note. The agent must infer usage conditions from the 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 must carry the full behavioral burden. It discloses useful traits like approximate fast-mode duration, deep-mode output format, and source import behavior, but does not explain timeout behavior, side effects on existing notebooks, authentication needs, or what happens when wait=False.

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

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

The description is front-loaded with the core action and then uses a tight bullet list to explain mode and parameter semantics. There is minimal fluff and every bullet conveys actionable information.

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

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

For an 11-parameter tool with no annotations, the description is only partially complete. It covers the most important mode and import semantics, but several behavioral and parameter details an agent would need to call it correctly are missing, even though the output schema handles return values.

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

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

Schema description coverage is 0%, so the description must compensate for all 11 parameters. It explains mode values, source values, wait/import_sources interaction, and create_notebook_title, but leaves cited_only, timeout, notebook_id, workspace_dir, allow_duplicate, and query undefined.

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

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

The description states a clear verb and resource (launch a research session on a Gemini Notebook) and distinguishes the three research modes. It does not explicitly compare itself to siblings like notebook_query or notebook_research_status, which keeps it from a 5.

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

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

It gives explicit guidance for choosing between modes: fast for rapid search, deep for exhaustive multi-step research, and discover for instant synchronous discovery. It lacks when-not-to-use guidance or explicit alternative-tool routing, so it falls short of 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 carries the full burden. It mentions waiting and cancelling but does not disclose that wait blocks up to a 600s default timeout, what cancel does to an in-flight run, whether import_sources has side effects on the notebook, or what happens when both wait and cancel are set.

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

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

A single front-loaded sentence with no filler, and the primary verb (Check status) leads. It is dense because four modes are squeezed into one line, but nothing is wasted.

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

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

This is a 9-parameter, multi-mode tool with zero annotation coverage and zero schema descriptions, and the description explains only about a third of the parameters and none of the mode interactions.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate and it largely doesn't: timeout, task_id, notebook_id, workspace_dir, cited_only, and allow_duplicate get no mention at all. Only wait, cancel, and import_sources are hinted at, and even those are not tied to their parameter names or defaults.

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 resource (a Fast/Deep Research run) and enumerates four concrete operations: check status, wait, import sources, cancel. This is specific enough to distinguish it from notebook_research (which presumably launches a run) and notebook_status (notebook-level status), though the multi-mode nature of one tool is somewhat compressed into a single clause.

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 lists the possible modes but never says when to pick which, whether flags are mutually exclusive, or how this differs from notebook_research/notebook_status. An agent must infer from parameter names that setting wait=true is the blocking variant, and nothing warns that import_sources/cancel mutate state.

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 mentions ranked chunks but does not disclose whether the operation is read-only, what permissions or indexing state are required, how pagination or ranking works, or how notebook_id and source_ids interact.

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 wasted words. It is efficiently structured, though it could include needed parameter or usage detail without becoming 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?

An output schema exists, so return values need not be explained in detail. However, with no annotations, five undocumented input parameters, and no usage guidance, the description is not complete enough for an agent to invoke the tool confidently.

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

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

Schema description coverage is 0% across five parameters, and the description does not explain any parameter names or semantics. It does not clarify query, limit, source_ids, notebook_id, or workspace_dir, leaving the agent without guidance beyond the bare schema types.

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: searching indexed passages across a Gemini Notebook's sources and returning ranked chunks. It is clear what the tool does, though it does not explicitly distinguish itself from similarly named siblings such as notebook_query or notebook_get_source_text.

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

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

The description offers no guidance on when to use this tool versus alternatives, when not to use it, or any prerequisites. The intended usage is only implied by the word 'Search'.

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

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

No annotations are provided, so the description carries the full burden; it only states the operation and two backends. It omits permissions/auth requirements, side effects, whether toggling public link sharing is reversible or destructive, and what notify_via_email does.

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?

Single front-loaded sentence with no filler, but it is too terse for a seven-parameter mutation and packs two distinct modes into parentheses rather than structuring them.

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 optional params, no annotations, no schema descriptions, and a mutation shape, the description is not complete enough for reliable invocation. The output schema helps only with return values, not with invocation semantics.

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

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

Schema description coverage is 0% across seven parameters, and the description only clarifies 'email' and 'public'. It leaves role, engine, notebook_id, workspace_dir, and notify_via_email unexplained, with no format or default semantics 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?

Names a specific verb ('Share') and resource ('Gemini Notebook'), and distinguishes the two sharing modes (email IAM vs public link RPC). It does not explicitly contrast with siblings, but none of the sibling tools cover sharing, so selection remains 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?

Gives the two modes but no guidance on when to select email vs public, prerequisites/permissions, or what happens when optional notebook_id/workspace_dir are omitted. The mode split is useful context, but it stops short of explicit when/when-not guidance.

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

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

With no annotations, the description must carry behavioral disclosure. 'Check' implies a read-only operation and the description adds scope about workspace binding and authentication across engines, but it does not explicitly state non-destructiveness, permission requirements, or 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 a single front-loaded sentence with no filler or repetition. It communicates the core check efficiently, though it could be clearer about 'both engines'.

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 low-complexity and has an output schema, so return values do not need description coverage. However, the missing parameter semantics and lack of usage guidance leave meaningful gaps for an agent deciding whether and how to call 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 0% for the single optional workspace_dir parameter. The description mentions 'current workspace' but does not explain how workspace_dir is supplied, what the default null means, or how it relates to the current workspace.

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

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

The description gives a clear verb and resource: checking current workspace Gemini Notebook binding and authentication status. It is distinguishable from login-oriented siblings by focusing on status, though the phrase 'both engines' is not explained and no sibling is explicitly named.

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 this is a status-checking tool, but it gives no explicit guidance on when to use it instead of alternatives such as notebook_login. No prerequisites, exclusions, or workflow context 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?

No annotations, so the description carries the full burden, yet it does not disclose that this is a mutating operation, whether uploads are synchronous or queued (the wait parameter implies async behavior), authentication requirements, or what happens when notebook_id is omitted. Only the accepted file types add useful behavioral detail.

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

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

A single front-loaded sentence with no filler and an efficient parenthetical file-type list. It is concise, though the brevity comes at the cost of missing information an agent needs.

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

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

An output schema exists, so return values need not be described. However, for a five-parameter mutating upload tool with zero annotation and zero schema-description coverage, the description omits critical operational details (async/wait semantics, engine selection, notebook targeting, login prerequisites).

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

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

Schema description coverage is 0% across five parameters. The description only loosely hints at file_paths via the file-type list and says nothing about wait, engine, notebook_id, workspace_dir, or the path-resolution interaction between file_paths and workspace_dir.

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

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

States a specific verb (upload) and resource (local workspace files) with an explicit list of accepted file types, and identifies the destination (Gemini Notebook). It does not differentiate from the sibling notebook_add_source, leaving an agent unsure which to choose when adding content to a 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?

No guidance on when to use this versus notebook_add_source, no prerequisites such as notebook_login, and no mention of when notebook_id or workspace_dir must be supplied. The agent must infer routing entirely from the name.

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