Loading ToolBench
Wavelet-based multi-resolution context management for MCP
Wavescope-MCP demonstrates solid definition quality with well-structured tool schemas, consistent naming conventions, and meaningful descriptions. All 9 tools follow verb_noun patterns (query_, get_, update_, compute_, diff_). Descriptions are detailed and contextual, ranging 150-350 characters, well above the 34-char median. Input schemas use Zod with proper type constraints, enums where appropriate, and parameter descriptions. However, output schemas are not explicitly documented, responses are JSON-stringified but the structure is inferred from implementation rather than declared in schemas. Error handling is present but could be more recovery-focused. Tool compositions are clean and single-purpose. One moderate issue: some parameters have loose descriptions (e.g., 'min_coefficient' explanation is technical jargon-heavy rather than task-oriented). Security is good (no credentials exposed, file path validation present). Overall, this is a B-tier server, genuinely useful wavelet-based code analysis with minimal wasted complexity.
Compute a multi-scale complexity heatmap of a file using Haar decomposition and entropy analysis. Returns per-band entropy metrics and per-line irregularity scores.
Compare wavelet structural boundaries of a file between two git revisions. Shows which structural peaks (function/class boundaries, imports, etc.) were added, removed, shifted, or changed in magnitude. Omit targetRef to compare against the current working tree.
Get precomputed wavelet context around the current cursor position for a file. Returns cached context from the last cursor update without recomputation.
Get important positions near the current cursor, ranked by proximity and structural significance. Returns empty list if no cursor is set for the file.
Find structurally important positions (class/function boundaries, imports, etc.) in a file or directory. Returns positions sorted by wavelet coefficient magnitude. Provide exactly one of 'file' or 'directory'.
Output schemas not explicitly documented. Tools return JSON-stringified results, but the structure of returned objects is inferred from code comments rather than declared in a response schema. LLMs cannot plan downstream calls or validate output structure without explicit schema documentation.
Parameter descriptions are sometimes technical and context-specific rather than task-oriented. For example, min_coefficient and scale parameters use domain jargon (CWT coefficients, Haar decomposition, wavelet scales) without explaining when/why an LLM should adjust these values. Add task-oriented guidance like 'Lower values return more structural details; higher values give overview summaries.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Get a compressed/summarized view of a region using wavelet peaks at a given scale. Larger scales give coarser summaries. Omit `scale` for auto-selection based on region size.
Get raw wavelet coefficients for a range of lines at a specific scale. Scales: 1-2 (fine/detailed), 4-16 (medium), 32-128 (coarse/overview). If the requested scale isn't directly available, the response includes both the actual `scale` used and the original `requestedScale`.
Get a multi-resolution (fine/medium/coarse) view of code around a position. Fine band shows exact lines near the center, medium band shows function/class signatures, coarse band shows section-level structure. Use this to zoom in and out of a file.
Update the cursor position in a file. The server precomputes wavelet context around the cursor for faster subsequent queries.
Error handling is basic. ToolError responses return plain text messages without guidance for recovery. When a file is not found or permission denied, responses should suggest next steps: 'File not found at /path/to/file. Verify the path is correct and the file exists.'
The 'update_cursor_position' tool description does not explain what side effects happen. It mentions precomputation for 'faster subsequent queries' but does not clarify: is this per-file state? Is it in-memory or persisted? This affects how LLMs plan multi-step workflows.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. While all tools are READ_ONLY by design, explicit annotations in the schema would help MCP clients (e.g., safety checkers, UI hints) understand operation semantics.