Loading ToolBench
Semantic Code Intelligence Engine — MCP server for code analysis, indexing, and semantic understanding
Cortex MCP has 19 tools with basic schemas and descriptions, but significant quality gaps prevent production readiness. All tools have descriptions (10-100 chars, mostly adequate), and input schemas are present with type definitions. However, output schemas are entirely undocumented, LLMs cannot predict what fields to expect from responses, breaking tool chaining. Parameter descriptions are minimal (e.g., 'Path to the file' for file_path). No error handling guidance, no recovery paths, and no actionable error messages. Tools like call_search_context and call_get_impact_graph accept numeric parameters (token_budget, max_depth, max_nodes) with no documented ranges or constraints, inviting invalid LLM inputs. Memory and task management tools (call_save_observation, call_manage_todo) lack idempotency guarantees and confirmation steps for destructive operations. No tool annotations (readOnlyHint, destructiveHint) despite clear risk stratification. Naming is verb-first and mostly clear, but some tools conflate multiple concerns (e.g., call_manage_todo handles add/update/complete/delete in one tool).
Consolidate and summarize memory records
Create a task contract for tracking work
Find execution paths between two symbols or functions
Get git history for a file
Get the outline/structure of a file including symbols, functions, classes, and their locations
Get the impact graph showing dependencies and affected code
Get the current indexing status of the workspace
Get session context and memory for the current session
No output schemas documented. LLMs cannot predict response structure, breaking tool chaining and forcing agents to guess field names. E.g., call_search_context returns results but no schema specifies fields like 'matches', 'score', 'file_path', or 'line_number'.
Numeric parameters lack constraints. call_search_context accepts token_budget (default 4000) with no min/max. call_get_impact_graph accepts max_depth and max_nodes with no documented bounds. LLMs may pass absurd values (e.g., max_depth=999999) causing timeouts or resource exhaustion.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
Manage TODO items
Read a file and return its content with SHA256 hash
Read memory records
Replace exact text in a file
Resolve a symbol to its definition location and related information
Save an observation to memory
Search for code context based on query with token budget limit
Deep semantic search for code context with graph traversal
Search memory using full-text search
Synchronize session memory with global memory
Write to memory
No error handling guidance. Tools return errors as strings (e.g., 'file not found') with no recovery hints. LLMs cannot determine if an error is retryable, user-fixable, or fatal. No actionable error messages like 'File not found. Try call_search_context() to locate it.'
call_manage_todo conflates four operations (add/update/complete/delete) into one tool via an 'action' enum. This violates single-responsibility principle. Should split into call_add_todo, call_update_todo, call_complete_todo, call_delete_todo for clarity and independent error handling.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are clearly stratified by risk (READ_ONLY vs WRITE), but this is not exposed to the MCP client. Agents cannot determine which tools are safe to retry or which require confirmation.