Loading ToolBench
Cognitive engine and agent framework with knowledge store integration and plug-callable tools
Ampere exposes a single tool, KnowledgeQueryTool, with a well-structured schema and clear intent. The tool definition is explicit in the source code, with input/output serializable data classes. However, the tool name lacks a leading action verb, which is a critical naming convention violation in the rubric. The description is adequate but could be more LLM-optimized. The parameter descriptions are present but vary in completeness. Error handling is not visible in the provided source excerpt, which limits confidence in recovery guidance.
Searches the on-device knowledge store for chunks relevant to a query. Inputs: query text, optional scope set (e.g., 'work', 'personal'), and a result limit. Output: ranked chunks with text, source URI, and similarity score. Scope-restricted plugs must hold the matching KnowledgeQuery permission grant.
Tool name 'Query Knowledge' does not follow verb_noun pattern. Should be 'search_knowledge' or 'query_knowledge' to match LLM expectations. Current name 'Query Knowledge' (title case, no underscore) deviates from production conventions where 90% of A+ tools start with an action verb.
Error handling and recovery guidance not visible in provided source. The executeAsOutcome method shows a failure case (Failure(executorId, ...)) but the full error structure, retry eligibility classification, and actionable error messages are cut off. Cannot verify compliance with pattern:recovery-guide.
Parameter 'mode' has enum constraint [HYBRID, KEYWORD, SEMANTIC] but description is minimal ('Query mode (HYBRID, KEYWORD, SEMANTIC)'). Should explain when each mode is preferred and how results differ.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter 'scopes' description mentions permission grant requirements ('Scope-restricted plugs must hold the matching KnowledgeQuery permission grant') but this is infrastructure context, not a guide for LLM input. Description should focus on what values are valid (e.g., 'e.g., work, personal, research') and let the permission gate enforce grants.