Loading ToolBench
MCP server for code analysis and semantic search over project codebases using structural AST patterns, semantic embeddings, full-text search, and code graph relationships
Project Cortex presents 5 well-defined search and analysis tools with comprehensive parameter schemas and clear descriptions. All tools have explicit input schemas with typed parameters and descriptions. Tool names follow verb_noun patterns (cortex_search, cortex_exact, cortex_graph, cortex_pattern, cortex_files). Descriptions are detailed (150-400 chars) and explain both purpose and use cases. However, there are no documented output schemas, the source code shows tool registration but not response structure definitions. Parameter descriptions are thorough with constraints (limits, enums, operators), but output formatting for downstream tool chaining is not specified. Error handling is not visible in the provided source. The composition pattern is sound: each tool has a single responsibility (search, exact match, graph query, pattern matching, SQL-like metadata), and names distinguish tools clearly.
Full-text keyword search using FTS5 query syntax. Supports phrase search, boolean operators, prefix wildcards, and filters by language and file path.
Query code statistics and metadata using SQL-like JSON queries. Use for quantitative questions about project structure, module sizes, test coverage, and aggregations. Supports SELECT operations with field filtering, WHERE clauses with comparison operators, JOIN operations, GROUP BY with aggregations, ORDER BY, LIMIT and OFFSET.
Query structural code relationships for refactoring, impact analysis, and dependency exploration. Operations: callers (who calls this function), callees (what does this function call), dependencies (packages this imports), dependents (packages importing this), type_usages (where is this type used).
Search code using structural AST patterns. Use for finding anti-patterns, code smells, language-specific idioms, and complex structural patterns that text search cannot handle.
Search for relevant context in the project codebase and documentation using semantic search. Returns code chunks, documentation, symbols, and definitions ranked by relevance.
No documented output/response schemas. While input parameters are well-defined, the structure and fields of tool responses are not specified in visible source code. This forces LLMs to guess what fields are returned and breaks the tool-chaining pattern (e.g., what IDs or references are returned for downstream calls?)
Error handling not visible. No recovery guidance, error classification, or actionable error messages shown in tool definitions. When a search returns no results or a query fails, it's unclear what the LLM should do next.
cortex_files parameter 'query' is an untyped object with no field-level schema. The description explains available fields (fields, from, where, joins, groupBy, etc.) but provides no formal JSON Schema constraints on those nested fields. LLMs cannot validate query structure before sending.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
cortex_pattern 'strictness' parameter mentions 5 enum values (cst, smart, ast, relaxed, signature) in description but no formal enum constraint is visible in the schema definition. Should use JSON Schema enum array.
cortex_search 'chunk_types' parameter accepts an array with 4 documented options (documentation, symbols, definitions, data) but no formal enum constraint enforces these values. Same for cortex_graph 'operation' parameter, enum is visible but validation is code-side only.
No pagination guidance for search results. cortex_search and cortex_exact accept 'limit' but no mention of 'offset', 'cursor', or 'total_count' in responses. If a search returns 15 results (the default), how does the LLM fetch the next 15? No next_cursor or page indicator visible.