Loading ToolBench
This server has 4 tools with explicit definitions visible in main.py. All tools have descriptions and parameter schemas, but quality is uneven. Naming follows verb_noun pattern well (project_insights, search_code, generate_feature_plan, fetch_dedalus_context). However, parameter descriptions are sparse or generic, schemas lack detailed constraints, and output structure is undocumented. Most parameters default to sensible values, which is good. The tools themselves are read-only and relatively safe, but the definitions lack the rigor expected of production tools. Schema definitions are present but incomplete (missing type annotations in some places, no examples). Error handling exists but is minimal, fetch_dedalus_context raises ValueError on network failure with a message, but search_code and project_insights silently skip failures. No tool annotations (readOnlyHint, destructiveHint) are declared.
Fetch and summarize title, metadata, and first links from dedaluslabs.ai.
Generate an implementation checklist and risks for a requested feature.
Inspect repository structure and key files for onboarding and planning.
Search code with plain text query across files with optional extension filtering.
Parameter descriptions are minimal or missing actionable guidance. E.g., 'root_path' is described as 'Root path for repository inspection' (41 chars) but does not state expected format, whether absolute/relative, or what happens if invalid. 'max_depth' lacks guidance on why the constraint is 1 - 6. LLMs cannot infer constraints from names alone.
Output schemas are not documented. Tools return plain strings (project_insights returns a multi-line string tree, search_code returns line-by-line results, etc.). LLMs need to know what structure to expect so they can parse results and chain to downstream tools. No structured JSON response format is defined.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Tool annotations are missing. No @tool decorator parameters or hints indicate that these are read-only operations. The MCP spec supports readOnlyHint, destructiveHint, and idempotentHint annotations; none are present. This forces LLMs to reason about side effects rather than being told explicitly.
Error handling is inconsistent and lacks recovery guidance. fetch_dedalus_context raises ValueError on network failure, but search_code and project_insights silently skip errors (UnicodeDecodeError, OSError) and return partial/empty results without notifying the LLM. No errors include suggestions for what to do next (e.g., 'Try expanding max_depth or checking file permissions').
Parameter constraints are enforced in code but not declared in descriptions. search_code enforces max_results ≤ 200 in code, project_insights enforces max_depth ∈ [1,6] in code, but these constraints do not appear in the parameter descriptions. A description reading 'Maximum number of results to return' (41 chars) does not tell the LLM the bounds are 1 - 200.
No pagination support. search_code returns up to 40 results by default but has no cursor, offset, or next_token to retrieve more. If an agent needs to search across a large codebase, it cannot page through results, it must requery with different keywords or accept truncation.