get_wisdom

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

No annotations are provided, so the description carries the burden. It discloses that the tool 'loads' knowledge and mentions it returns an overview vs specific results, which adds some transparency. However, it never mentions read-only nature (though implied), potential for large payloads, or side effects. It's reasonable but not richly transparent.

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

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

Four sentences, front-loaded with the purpose statement. The workflow guidance is useful but slightly verbose; it could be tightened. Overall efficient and well-structured without waste, though not maximally concise.

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 5 parameters and no annotations/output schema, the description does a good job tying usage together through the recommended workflow. It explains the overview→file→keyword progression and hints at what results contain (accumulated project knowledge). It's not exhaustive for all 5 parameters but provides a functional mental model for the core workflow.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the semantic distinction between call modes (overview vs file_path vs keyword) in the recommended workflow, which goes beyond the individual parameter schema descriptions. This workflow context adds real meaning to how parameters combine.

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 uses a specific verb+resource ('Load relevant wisdom') and clearly states the tool's purpose: retrieving accumulated project knowledge from previous sessions. It distinguishes itself from siblings by describing the context-loading use case, which is distinct from list_wisdom (which presumably lists) and save_wisdom (which writes).

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?

Provides an explicit recommended workflow with a call sequence: get_wisdom() overview → get_wisdom(file_path) → get_wisdom(keyword). This gives clear when-to-use guidance for different call modes and explains the drill-down pattern, which is effectively guidance for distinguishing between this and alternative approaches.

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