Loading ToolBench
MCP server exposing sensegrep's semantic + structural code search to AI agents, delivering smaller, more relevant context.
Sensegrep MCP exhibits strong overall definition quality with well-articulated tool purposes, comprehensive parameter schemas, and clear guidance on tool usage patterns. However, it lacks output schema documentation, error handling guidance, and tool annotations. The tool naming convention is consistent and verb-based. Descriptions are generally good (100-300 chars, well above the 10-char minimum), explicitly guiding LLM selection with 'when to use' clarity. Parameters are well-typed with JSON Schema, though some lack detailed constraint documentation. All 9 tools are explicitly defined in packages/mcp/src/server.ts. The server targets code understanding workflows with READ_ONLY operations (except sensegrep_index which is WRITE), making security lower-risk than state-modifying tools.
Cluster code theme: find semantically related definitions across the codebase to understand implementation patterns and architecture.
Retrieve semantic context for a location: imports, dependents, and semantic relationships without full AST analysis.
Find semantically similar code across the codebase: duplicate functions, methods, and patterns that may be candidates for refactoring.
Code graph analysis: query references, impact analysis, and dependency traces for understanding code dependencies and call chains.
Index or reindex a project for semantic search: build embeddings, extract AST metadata, and prepare for all search operations.
Exact-text verification tool for a known string or regex, exhaustive occurrence checks, and refinement after semantic discovery. Do not use it for behavior, concepts, or initial codebase exploration; start with sensegrep_search. It makes no embedding calls.
Output schemas are not documented. No tool returns a documented response structure, making it impossible for LLMs to plan downstream calls or extract specific fields from results.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next (e.g., 'Index not found. Call sensegrep_index first.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Default tool for code discovery and understanding. Search by behavior, concept, or structure using semantic + lexical retrieval and AST metadata; use this before literal search when you do not already know the exact text.
Display full source code for identified results, symbol definitions, or arbitrary file ranges with syntax highlighting and semantic metadata.
Survey code domain: list top-level definitions, entry points, and high-level structure for rapid codebase understanding.
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint metadata, preventing MCP clients from making intelligent decisions about retryability, caching, or user confirmation.
Missing pagination guidance in list/search tools. sensegrep_search accepts a 'limit' parameter but does not document total counts, cursors, or how to fetch additional results beyond the limit.
Parameter constraints underspecified. Several numeric parameters (limit, depth, threshold, minScore, maxPerFile) lack min/max bounds in descriptions. E.g., sensegrep_graph.depth accepts 1-20 but the description does not state this range, forcing the LLM to infer or guess.
sensegrep_context and sensegrep_show lack clear usage guidance. When should an LLM call 'context' vs 'show'? The descriptions do not contrast their purposes, risking redundant or incorrect tool selection.
sensegrep_index is a WRITE tool with minimal safety guardrails. No description warns about reindexing costs (CPU, time, token spend), and no dry-run or confirmation mechanism exists to prevent accidental full reindex.