Loading ToolBench
Code intelligence MCP server for AI agents with graph-based code analysis, multimodal ingestion (OpenAPI/GraphQL/gRPC), and moldable exploration
CogniCode MCP presents 18 well-named, verb-prefixed tools with consistent descriptions (avg ~120 chars). All tools have input schemas with typed parameters and enums where appropriate. However, output schemas are not documented in the provided source, critical for LLM planning. Parameter descriptions are present but often generic (e.g., 'Graph identifier' repeated 17 times). No evidence of error handling guidance, recovery paths, or actionable error messages. Security considerations (secret injection, permission gates, audit trails) are absent from tool definitions. Composition is strong, tools are single-responsibility and chainable via graph_id. Naming follows verb_noun convention consistently (scan_project, analyze_call_graph, get_entity_details). This is a solid B-/C+ implementation: good structure, weak on LLM-facing guidance and error recovery.
Analyze project architecture including module boundaries, layering, and C4 model inference
Analyze call graphs to find entry points, dead code, circular dependencies, and call chains
Analyze data flow through functions including taint analysis and information flow
Analyze project dependencies, including import graphs, circular dependencies, and dependency metrics
Check code against architectural boundary rules and constraints
Delete a code graph and free associated resources
Ingest documentation sources (Markdown, OpenAPI, GraphQL schemas) and link them to code entities
Export code graph in various formats (JSON, GraphML, CSV) for external analysis
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what does analyze_call_graph return? Is it a list of functions, a graph structure, or a summary?). This forces agents to guess and wastes tokens on trial-and-error.
No error handling guidance. Tools lack recovery hints (e.g., 'If graph_id not found, call list_graphs() first'). Errors are likely raw exceptions with no actionable next steps for the LLM.
Destructive tool (delete_graph) lacks confirmation/dry-run pattern. No evidence of permission gates or audit logging. Agents could accidentally delete graphs without safeguards.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Find code patterns and anti-patterns using structural matching
Find all references to a code entity across the codebase
Retrieve source code snippet for a specific entity or location
Get detailed information about a code entity (function, type, module) including signature, documentation, and relationships
Get code metrics including complexity, coupling, cohesion, and maintainability indices
Search the code graph using JSONata queries to find functions, types, dependencies, and relationships
Ingest OpenAPI 3.1 specifications and link API endpoints to implementation code
List all available code graphs in the current session
Render a visual snapshot of the code graph (Mermaid diagram) for a specific view or subgraph
Scan a project directory and build a code graph with AST analysis, call graphs, and data flow
Parameter descriptions are generic and repetitive ('Graph identifier from scan_project' appears 17 times). LLMs benefit from context-specific guidance: when to use graph_search vs analyze_call_graph, what query syntax JSONata expects, etc.
No pagination or result-limiting documented. Tools like find_references, find_code_patterns, and export_graph could return thousands of results, blowing context windows. No limit parameter or guidance on max results.