vitest_lookup_knowledge_bank

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

With no annotations provided, the description carries the burden of disclosing behavior. 'Queries' does imply a non-destructive read operation, and the returned content is enumerated. However, it does not explain behavior for unknown signatures, response format, or whether any side effects such as logging or learning recording occur.

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

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

The description is a single, tightly worded sentence that front-loads the action and resource, then states the value returned. There is no filler, repetition, or unnecessary detail.

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

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

For a simple one-parameter lookup tool, the description covers what the tool does, what it operates on, and what outputs to expect. There is no output schema, so the explicit mention of diagnosis, root cause, and fix template is valuable. The only notable gap is no-match behavior, but that is not essential for selecting or invoking 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?

The input schema already fully describes the only parameter, errorMessage, as the failing test error message or stack trace, so schema coverage is 100%. The description adds the idea of 'known error signatures' but provides no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific action ('Queries'), a specific resource ('the permanent Knowledge Bank'), and an explicit output ('diagnosis, root cause, and fix template'). It is easy to distinguish from sibling tools like vitest_record_learning or vitest_list_knowledge_rules because it focuses on looking up known signatures rather than recording or listing all rules.

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 usage is implied: when you have a failing error message or stack trace and want a known diagnosis, root cause, and fix template. However, the description does not explicitly state when to prefer this over siblings such as vitest_list_knowledge_rules, nor does it mention any exclusions.

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