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

Annotations are absent, so the description carries full responsibility for disclosing behavior. It only states an action without noting side effects, requirements, or return values, leaving the agent uninformed about what happens on success or failure.

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. However, it is too minimal, providing only the core action without additional context or structure, making it borderline under-specified rather than efficiently 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?

Given the tool has one parameter, no annotations, and no output schema, the description should explain more about the create operation, such as what the notebook contains, whether duplicate names are allowed, or what is returned. It fails to provide any contextual completeness.

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 one required parameter 'name' with no description. The description does not clarify the format, constraints, or purpose of the name beyond the obvious, offering no added meaning to help the agent formulate correct arguments.

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 'Create a notebook.' clearly identifies the action (create) and the resource (notebook), distinguishing it from sibling tools like notebook_list, notebook_delete, and notebook_query. Although brief, it is unambiguous and maps directly to the tool's function.

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 others. No mention of prerequisites, alternatives (e.g., if a notebook already exists), or use cases.

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 explicitly states that deletion cascades to sources, chunks, and vectors, which is critical for an agent to understand the destructive scope. However, it does not mention irreversibility, permissions, or other side effects, keeping it below a perfect score.

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

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

The description is a single, front-loaded sentence that immediately states the action and object, then adds the cascade detail. There is no wasted wording, making it highly concise and structurally clear.

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 captures the core effect (cascade deletion) but lacks context such as when deletion is appropriate, whether it is reversible, or any confirmation steps. Given the destructive nature and absence of an output schema, the description is adequate but leaves gaps for an agent to act safely.

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

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

The schema has 0% description coverage for the single parameter notebook_id. The description adds no meaning beyond the parameter name and type; it does not explain how to find the notebook_id or any format expectations. Since coverage is low, the description should compensate, but it 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 description clearly identifies the action ('Delete'), the target resource ('a notebook'), and the cascading scope ('and all its sources, chunks, and vectors'). This distinguishes it from sibling tools like notebook_create or source_delete by specifying the full recursive deletion 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?

No guidance is provided on when to use this tool versus alternatives such as source_delete for deleting individual sources. The description implies usage for deleting entire notebooks but does not explain prerequisites, exclusions, or when not to use 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?

No annotations are provided, so the description carries the full burden. It adds the useful detail that results include source counts, but does not explicitly state read-only status, pagination, or authentication needs. This is minimal but acceptable for a simple list 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 concise sentence that is front-loaded and contains no redundant information.

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

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

Given the tool's simplicity (zero parameters, output schema present), the description is adequate: it conveys the purpose and the key output detail. A slight gap is the absence of usage context relative to sibling tools, but this is minor for a list 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?

The tool has zero parameters, and the schema is empty. The baseline for no parameters is 4, and the description does not need to elaborate on 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 clearly states the action ('List'), the resource ('notebooks'), and a defining output detail ('with source counts'). This distinguishes it from sibling tools like source_list and 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?

No guidance is given on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or compare with sibling tools like notebook_query or source_list.

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 weight and does so impressively: it discloses the hybrid fusion algorithm, the difference between remote (dense) and local (FTS5) processing, the privacy flag's effect, the flagging of excluded remote spaces, and the return of per-stage latency. This gives the agent a clear model of the tool's 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 efficiently front-loaded with the primary purpose, then adds a compact list of critical parameter details and return metadata. Every sentence contributes unique information, 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?

For a tool with no output schema, the description covers return values ('raw chunks' and 'latency_ms') and critical behavioral nuances. Given the tool's moderate complexity and the clear sibling context, the description is sufficient for an agent to select and invoke the 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 0%, so the description must compensate for missing parameter info. It explicitly explains the 'mode' parameter (hybrid | dense | lexical) and the 'private' parameter semantics (avoids remote dense-embedding, FTS5 still runs), which are not self-evident from the raw schema. Other parameters like notebook_id and top_k are obvious from their names and 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 clearly states a specific verb+resource: 'Hybrid search within a notebook' and details the mechanism (dense KNN + FTS5 lexical, fused with RRF). This distinguishes it from sibling tools like notebook_create or source_list, which are not search operations.

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 and how to configure it (e.g., setting private=true for sensitive queries). While it does not explicitly name alternative tools or state when not to use it, the sibling tools are disparate enough that no alternative search tool exists, making the usage context sufficient.

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 burden of explaining behavior. It discloses that this tool aggregates status and includes source_count, but it does not mention side effects (likely none), permissions, error behavior, or the exact shape of the returned status. It adds useful context beyond the schema but lacks deeper 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?

The description is two short sentences, front-loaded with the main purpose, and the comparison to source_status is valuable. No redundant or filler language.

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 (1 param, no output schema), and the description gives a high-level idea of the return value (aggregate status + source_count). However, without an output schema or more detail on the response structure, an agent may not know exactly what 'status' entails. The reference to source_status is helpful but assumes familiarity with that sibling.

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 needed to compensate for the notebook_id parameter. It does not explain how to obtain or interpret notebook_id, beyond the schema's bare type and title. For a single simple parameter this is a minor gap, but the rubric requires compensation when coverage is low.

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 ('Aggregate') and resource ('status across all sources in a notebook'), and clearly distinguishes itself from the sibling source_status by noting 'Same rollup as source_status, plus source_count'. It also captures user intent with 'is my corpus ready'.

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 context for when to use this tool: to get an aggregate view of notebook readiness. It explicitly references source_status as a comparison point, indicating an alternative exists, though it does not explicitly state when to prefer one over the other.

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 and excels: it discloses that the tool returns after embed+store (queryable immediately), runs no inline DeepSeek, defaults to public with remote API embedding, offers private=true for fully-local embedding, and includes a nuanced security warning about cloud hosts.

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 efficiently covers behavioral details, security caveats, and enrichment semantics in four sentences. Every sentence adds value with no redundancy 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?

Given the lack of annotations and output schema, the description covers the essential lifecycle: fetching, embedding, storage, queryability, privacy options, enrichment behavior, and a security warning. It provides enough context for an agent to invoke the tool correctly and anticipate consequences.

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%, so the description must compensate. It does explain private (fully-local embedding) and enrich (background contextualization for private sources), which are non-obvious. However, it does not give explicit semantics for url, notebook_id, or display_name beyond their schema titles, leaving some parameters reliant on inference from context.

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's function with a specific verb+resource: 'Fetch and ingest a source.' This distinguishes it from sibling tools like source_list, source_delete, source_refresh, and source_enrich as the creation/ingestion operation, and the need for a notebook_id further clarifies 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?

It provides clear usage context for the private and enrich parameters, including security considerations and when enrichment applies. However, it does not explicitly name alternatives or state when not to use this tool versus source_refresh or source_enrich, so it stops short of full when/when-not guidance.

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

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

The description discloses the cascading deletion of chunks/vectors, a critical behavioral trait. However, with no annotations provided, it does not mention irreversibility, permissions, or error states, leaving a significant transparency gap for a destructive action.

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 words. It efficiently communicates the core action and its main 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 simple delete tool, the description covers the core behavior and one side effect. However, it omits critical operational context such as whether deletion is irreversible, required permissions, or how it relates to notebook_id, 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 0%, and the description does not explain the two parameters (source_id, notebook_id). The schema itself only provides names and types, so the tool provides no additional meaning to guide parameter usage.

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 ('Delete') and identifies the resource ('a source') along with a key side effect ('its chunks/vectors'). This clearly distinguishes it from sibling tools like source_add or source_list.

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 tool name and description: when you want to remove a source. However, there is no explicit guidance on when to prefer this over other source tools, nor any exclusion or prerequisite information.

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

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

No annotations are provided, so the description carries the full burden. It discloses the processing pipeline (DeepSeek contextualization, local re-embedding, marking as enriched) and the scope limitation to private sources. However, it does not explain side effects, cost, idempotency, or the role of the force parameter, leaving important behavioral gaps.

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

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

The description is two sentences, front-loaded with the core action, and contains no filler. The parenthetical about public sources is concise and informative, earning 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 lack of annotations, output schema, and parameter descriptions, the description is not sufficient for full confidence. It omits the behavior of force, what happens after enrichment (e.g., status changes, searchable effects), and any return value. It gives a good overview but fails to cover critical usage 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 0%, so the description must compensate. It does not explain the force parameter at all and only implicitly refers to source_id. This is a significant omission because force is a boolean that could alter the tool's behavior, and the description adds no parameter-level 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 clearly states the tool runs DeepSeek contextualization on a PRIVATE source's pending chunks, re-embeds locally, and marks them enriched. It explicitly distinguishes from public sources, setting it apart from sibling tools like source_refresh and source_add.

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 explicitly says public (context-3) sources are already contextual, implying the tool should only be used for PRIVATE sources. This is a clear when-not-to-use signal, though it does not name alternative tools for public sources.

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 burden of behavioral disclosure. It successfully communicates that this is a read-only list operation, but does not mention any edge cases, authentication needs, or error behavior. The listed output fields add some context but not deep 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?

The description is a single, concise sentence: 'List sources with chunk counts, enrichment progress, and per-model cost.' It is front-loaded with the verb and contains no filler or redundancy.

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 list tool with an output schema and one parameter, the description gives the core purpose and return fields. However, it omits the notebook context and does not clarify how this tool relates to siblings like source_status, making it only partially 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 0%, and the description does not mention the notebook_id parameter at all. The description says 'List sources' but fails to indicate that sources are scoped to a specific notebook, which is a required parameter. This leaves the agent without meaningful guidance on parameter 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 the specific verb 'List' with the resource 'sources' and details what is included (chunk counts, enrichment progress, per-model cost). This clearly distinguishes it from sibling tools like source_add or source_delete, which have different actions.

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 (when you want to see sources with their metrics) but does not explicitly state when to use this tool versus alternatives like source_status. No exclusions or alternative recommendations are given, so it only meets the 'implied usage' level.

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 discloses key behaviors: re-ingest only on hash change and background execution. Yet it omits side effects like whether existing data is overwritten, whether it returns immediately or a job ID, and any permission requirements, leaving notable gaps.

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

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

Two sentences, each earning its place. The first explains the core action and condition, the second clarifies a parameter nuance. No filler or redundancy.

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 primary refresh workflow and the enrich option, but without an output schema it fails to mention return values, errors, or how the background re-ingest is tracked. For a 3-parameter tool with no annotations, this leaves moderate 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%, so the description must compensate. It explains the enrich parameter but leaves source_id and notebook_id undocumented in both schema and description. The required identifiers are not given any semantic context beyond their names, making this insufficient for low 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 clearly specifies the action: re-fetch a source and re-ingest only if the content hash changed. This distinguishes it from sibling tools like source_add (new source) and source_enrich (enrichment), making the 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?

It implies when to use this tool (to refresh an existing source) and gives specific guidance for the enrich parameter ('Pass enrich=true to re-enrich private sources after re-ingest'). However, it does not explicitly contrast with siblings such as source_enrich, so the usage context is clear but excludes alternatives only implicitly.

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 exist, so the description carries the full burden. It thoroughly discloses behavior: derived from current DB state, return fields/chunk counts, queryable semantics (partial coverage searchable, failed-enrichment chunks still queryable), backend/summary inclusion, and the absence of retrieval progress. This is exceptional 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?

Three dense, information-rich sentences: foundational purpose, detailed return values, and a performance caveat. Every sentence earns its place with no redundancy or fluff.

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 status tool with no output schema and no annotations, the description delivers complete guidance: return fields, queryable behavior in partial/failure states, performance expectations, and what not to expect (retrieval progress). Nothing essential 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 0% and the description does not explicitly define source_id. However, the single parameter is self-evident from its name and the phrase 'for a source'. The lack of explicit compensation is noted, but the triviality of the parameter reduces the impact.

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's function: returning ingestion/enrichment status for a source. It uses a specific resource and scope, and distinguishes itself from sibling tools by noting it is DB-derived and pollable, with no streaming and no retrieval progress.

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 explicitly instructs to 'Poll this to track progress' and clarifies 'no streaming — stdio is request/response', giving clear when-to-use context. It does not explicitly name alternative tools, but the guidance is unambiguous.

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