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

Annotations already flag the tool as non-readOnly and non-destructive, and the description adds valuable behavioral detail: text chunking, compression ratio (15-60×), and the promise of '100% data integrity'. It does not contradict the idempotentHint, and it explains the internal processing enough for an agent to predict effects.

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

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

Two sentences carry the entire message with no filler: the first states the action and mechanism, the second adds scope and use cases. Every clause contributes, and the core purpose is front-loaded before any supporting detail.

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

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

With an output schema present, the description need not explain return values. It covers the action, the compression behavior, the target use cases, and indirectly signals input expectations. There are no prerequisites or side-effect caveats that an agent would need beyond this description and the structured fields.

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

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

Schema description coverage is 100%, so the baseline is 3; the description's compression details loosely connect to n_max's role but do not add parameter-level meaning beyond the schema. The schema already documents name format, text minimum length, and n_max range/default, so the description adds no essential 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 opens with a specific verb and resource ('Creates a new knowledge library') and immediately distinguishes itself from sibling tools by detailing the compression mechanism ('gravitational memory', 'split into chunks', 'compressed 15-60×'). It clearly targets creation rather than querying, deleting, or verifying, making it unmistakable among the sibling 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 description provides clear context for when to use the tool: it is 'Perfect for large documents, codebases, or research papers,' which signals the intended input scale. It does not explicitly exclude alternatives or name sibling tools for other operations, so it stops short of a 5, but the use-case framing gives adequate guidance.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=true, so the safety profile is carried by structured data. The description adds the 'permanently' qualifier, which conveys irreversibility beyond the annotations, but it does not disclose the blast radius — such as whether documents contained in the library or dependent data are also destroyed.

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 six-word sentence with the verb front-loaded and zero filler: 'Permanently deletes a knowledge library.' Every word earns its place, and nothing from the title or schema is redundantly repeated.

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?

Complexity is low (one required parameter, no enums, no nesting) and an output schema exists, so return values need no explanation. However, for a destructive operation, the scope of deletion is underspecified — an agent cannot tell from the description what happens to the library's contents or to related entities used by sibling tools, which is the most important missing context.

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

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

Schema description coverage is 100%, with library_name documented as 'Name of the library to delete.' The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb ('permanently deletes') on a specific resource ('a knowledge library'), and it is unambiguous against the sibling list, where no other tool performs deletion. However, it mostly restates the tool's name and title; the only added semantic value is the 'permanently' qualifier, so it stops short of a 5.

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

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

There is no guidance about when to invoke this tool, no prerequisites (e.g., that the library must exist), and no caution about confirming the target before a destructive call. Usage is only implied by the verb 'deletes'; no alternatives or exclusion conditions are mentioned.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context by explaining that files are compressed into temporary libraries, which clarifies the ephemeral nature and the internal processing that occurs. It does not contradict the annotations and enriches the agent's understanding of side effects.

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

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

The description is concise and front-loaded, with the core behavior stated in the first sentence. The second sentence provides a use case but partially repeats 'permanent libraries' from the first sentence, which is a minor redundancy. Overall, it is efficient with negligible waste.

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

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

The tool has full schema coverage, annotations, and an output schema, so the description does not need to explain return values. It clearly conveys the tool's purpose, usage context, and behavioral characteristics (temporary libraries). Nothing critical is missing for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the schema completely documents all parameters (query, top_k, file_paths). The description does not add significant meaning beyond the schema, aside from implying that files are processed and a query is answered. This meets the baseline for fully covered schemas but does not exceed it.

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

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

The description clearly specifies the tool's function: loading multiple files, compressing them into temporary libraries, and retrieving context for a query. It distinguishes itself from permanent library tools by emphasizing 'temporary libraries' and 'without creating permanent libraries.' The purpose is unambiguous and differentiates from siblings like create_knowledge_library.

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 situational context: use for quickly understanding large codebases or document sets without permanent libraries. It implies a contrast with permanent library creation tools, but does not explicitly name alternatives or state when not to use. This is clear context without formal exclusion criteria.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the scoping detail that statistics are for a specific library, but it does not disclose what statistics are included or how they are computed; the output schema presumably covers return shape.

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

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

The description is a single, focused sentence that states the action and object directly. There is no redundant wording or unnecessary detail.

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

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

For a simple one-parameter, read-only tool with an output schema and supporting annotations, the description provides adequate context for selection and invocation. It is missing only minor guidance about what 'detailed statistics' contains or how it relates to sibling library tools, but this is not critical.

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

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

Schema description coverage is 100%, and the library_name parameter already includes a clear description. The tool description adds little beyond rephrasing that the library is specific, so it does not improve on the schema's parameter documentation.

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

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

The description uses a clear verb ('Retrieves') and a specific resource ('detailed statistics for a specific knowledge library'). It distinguishes itself from sibling tools like list_knowledge_libraries by emphasizing a single specific library, though it does not explicitly name alternatives.

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

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

The purpose implies this tool should be used when detailed statistics for one particular library are needed, rather than listing all libraries. However, it provides no explicit guidance on when to prefer this over siblings such as list_knowledge_libraries or verify_library_integrity.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the result includes statistics, which is useful, but it does not disclose details like ordering, pagination, or access requirements. No contradiction exists.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and the core action plus output scope are stated immediately.

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

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

With no parameters, an output schema present, and annotations covering side-effect behavior, the description is complete enough for an agent to invoke the tool correctly. It communicates the tool's scope and result content without needing extra detail.

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 schema description coverage is 100%, so there are no parameter gaps to compensate for. The description's mention of 'all available' and 'statistics' adds mild context about what a parameterless call returns, but its main value is simply confirming the scope.

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-resource pair: 'Lists all available knowledge libraries' and adds the output detail 'with their statistics.' It clearly contrasts with create/delete/query operations, although it does not explicitly differentiate from the overlapping sibling get_library_stats.

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 usage context is implied: call this tool when you need an inventory of all knowledge libraries and their statistics. However, the description gives no explicit guidance about when to prefer this over get_library_stats or list-like alternatives, so the agent must infer the boundary.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that the tool returns extended context chunks, but it does not disclose other behavioral traits such as pagination, failure modes, or dependency on library existence.

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 with no redundancy. The primary action ('Queries a knowledge library...') is front-loaded, and the second sentence adds valuable context about how the output should be used.

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

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

For a simple retrieval tool with complete schema documentation, read-only annotations, and an output schema, the description covers the essential purpose and output use. It could be more complete by explicitly pointing to sibling tools, but that is not required for correct invocation.

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

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

Schema description coverage is 100%, with all three parameters documented in the input schema. The tool description provides no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

Description states a specific verb ('Queries'), a clear resource ('knowledge library'), and outcome ('retrieves the most relevant chunks'). It is clear and actionable, but it does not explicitly differentiate from sibling tools like search_documents, so it stops short of a 5.

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

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

The description provides a clear use case: returning extended context to answer questions requiring more detail than fits in a normal LLM context window. It gives context for when the tool is useful, but does not mention alternatives 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?

Annotations already communicate readOnly, idempotent, and non-destructive behavior. The description adds that it returns previews with relevance scores, which is useful but minimal. It does not contradict the annotations.

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

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

A single, information-dense sentence that front-loads the core action and expected output. There is 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?

Given the presence of a full output schema, complete parameter documentation, and annotations covering safety and idempotency, the description covers the essentials. The only notable gap is not clarifying how this tool relates to 'query_knowledge_library'.

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

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

Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

States a clear verb ('searches'), resource ('knowledge library'), and output ('previews with relevance scores'). However, it does not differentiate from the sibling tool 'query_knowledge_library', which sounds functionally similar.

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 it is used for searching content within a knowledge library, and the input schema clarifies the required 'query' and 'library_name'. But there is no explicit guidance on when to choose this tool over 'query_knowledge_library' or other sibling tools.

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

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

Annotations already pin the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description adds behavioral context beyond them: the check is exhaustive ('all chunks') and hash-based, with a strict '100%' success criterion implying a hard pass/fail. It does not disclose potential cost of a full-library scan or failure-report behavior, but the output schema covers return details.

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

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

The entire description is one front-loaded sentence of about 16 words: verb, resource, scope, and method, with zero filler. Nothing is repeated from the title or schema.

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

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

For a single-parameter, read-only tool with full annotations and an output schema, the description covers everything needed to call it: what it verifies, how, and how strictly. The only gap is usage context (when verification is warranted), which is a minor omission given the strong default clarity.

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

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

Schema description coverage is 100% – library_name is already defined as 'Name of the library to verify' with a minLength constraint. The description's mention of 'a library' adds no parameter-level semantics beyond the schema, so the baseline of 3 applies.

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

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

The description names a specific verb ('verifies'), a specific resource ('all chunks in a library'), and a concrete method ('checking hashes'), which clearly distinguishes it from the sibling create/query/delete/search/stats tools. The '100% data integrity' scope makes its job 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?

Usage context is implied but not explicit: the hash-checking language signals a health-check/verification role, but the description never states when to run it (e.g., after ingestion or suspected corruption) or names alternatives. With get_library_stats as a sibling, explicit routing between a stats read and an integrity check would reduce ambiguity.

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