Loading ToolBench
MCP server for converting structured prompt configurations into validated tools with semantic memory
Fegis has ONE visible tool (SearchMemory) with a complete input schema and clear description. However, the tool naming violates fundamental patterns (does not start with action verb, 'SearchMemory' should be 'search_memory'), parameter descriptions are minimal or absent, output schema is not documented, and error handling provides no recovery guidance. The server also generates dynamic archetype-based tools at runtime, but these are not statically visible in the source code, preventing full evaluation. The SearchMemory tool itself is READ_ONLY and semantic-search focused, which is a valid use case, but the definition quality falls short of production standards. Schema is present and mostly complete, but descriptions and error patterns are weak.
Search tool for retrieving memories using semantic search, filtering, and various result views
Tool naming violation: 'SearchMemory' does not follow verb_noun convention. Should be 'search_memory' or 'search_memories'. LLMs rely on action-verb-first naming to parse intent from the tool name alone.
Parameter 'filters' has no description or type constraints. Description states 'Array of filter objects for constraining search results' but does not explain the structure, required keys, or allowed values of each filter object. LLMs cannot construct valid filters without this detail.
Output schema not documented. Tool response includes 'search_results' (formatted memories) but the structure, field names, and types of individual memory objects are not specified. LLMs cannot reason about downstream tool calls or extract required data without knowing the response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Error handling does not guide recovery. The search tool may return 0 results or fail to connect to Qdrant storage, but there are no error messages that tell the LLM what to do next (e.g., 'No results found. Try broadening the query with fewer or shorter terms.' or 'Search service unavailable, check your Qdrant connection and retry.').
Dynamic archetype-based tools are registered at runtime (via load_archetype_tools) but their definitions are not visible in static source code. Tool names, schemas, and descriptions are loaded from YAML configuration files (archetype_path) that are not provided in this evaluation. Cannot assess these tools' naming, descriptions, or schema quality.
Parameter 'search_type' has an enum constraint (basic, filtered, by_memory_id) in the description but does not declare it as a JSON Schema enum. LLMs cannot parse enum constraints from text descriptions alone; they need formal JSON Schema enum definitions to reliably pick valid values.
Parameter 'detail' has an enum constraint (compact, summary, graph, or full) in the description but is not declared as a JSON Schema enum. Same issue as search_type.
No pagination support visible for SearchMemory results. The 'limit' parameter defaults to 3 and has no documented maximum. If a search returns hundreds of matching memories, the 'compact' detail mode might still exceed context window. No 'offset' or 'cursor' parameter documented for multi-page access.