Loading ToolBench
MCP server exposing RPG navigation tools for semantic code graph analysis and exploration
RPG-Encoder MCP server has 22 well-named tools with generally solid descriptions and parameter schemas. Naming follows verb_noun conventions consistently (search_node, fetch_node, explore_rpg, build_rpg, update_rpg). Descriptions are substantive (100-300+ chars) and explain WHEN to use each tool vs alternatives. However, critical gaps exist: (1) NO input schemas are visible in the provided source, only tool names, descriptions, and parameter name lists. (2) Output schemas are entirely undocumented, tools return structured data but the response field types are not declared. (3) Many parameters lack complete specifications (e.g., 'line_nums' array items type is visible but max/min bounds missing; 'batch_size' has no range). (4) Error handling is not described, no guidance on what errors each tool can raise or how to recover. (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic distinction (read-only vs write tools are marked in source but not in MCP schema). Tools like 'build_rpg', 'update_rpg', 'set_project_root', 'submit_lift_results' perform state mutations but lack confirmation/dry-run patterns. Tools are well-composed and chain correctly (search → fetch → explore). Descriptions avoid example values (good). Parameter naming is consistent and uses suffixes (entity_id, entity_ids, scope, etc.). However, without visible input schemas in the provided code, formal validation cannot be assessed.
Apply a hierarchy edit operation (move, rename, or restructure). Updates entities and persists the changes.
Build a Repository Planning Graph from source code. Parses all relevant source files, extracts entities (functions, classes, modules), builds semantic features, constructs the hierarchy, and persists the graph. Run this once at project start, or after a major refactor.
Compute data flow within a region (area) of the code. Shows what data flows in/out of a set of entities and their dependencies. Useful for understanding data pipelines.
Create a snapshot of the current hierarchy state for reference during interactive hierarchy editing sessions.
PREFER THIS OVER CHAINED GREPS FOR DEPENDENCY QUESTIONS. Explore the dependency graph starting from an entity. Traverses import, invocation, inheritance, composition, render, state-read/state-write, and dispatch edges. Use direction='downstream' to see what the entity calls, 'upstream' to see what calls it, 'both' for full picture. Replaces the manual "grep for X, then grep each result, then grep those" loop with one graph walk.
Export the graph in a specific format (DOT for Graphviz, Mermaid flowchart, or TOON). Useful for visualization and external analysis.
NO INPUT SCHEMAS VISIBLE. All 22 tools lack visible JSON Schema definitions in provided source. Parameter types (string, integer, array, object, enum) are inferred from names and descriptions only. Cannot verify type safety, constraint validation, or enum definitions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
PREFER THIS OVER cat OR WHOLE-FILE READS FOR A SINGLE ENTITY. Fetch detailed metadata and source code for a known entity by ID. Returns the entity's semantic features (what it does), dependencies (what it calls, what calls it), hierarchy position, and full source code. Use this instead of reading the whole file when you only need one function/class/method.
Retrieve a batch of entities ready for LLM semantic lifting. Returns up to `batch_size` entities (respecting `max_batch_tokens`), with metadata and source code. Use this to fetch work for autonomous LLM-driven feature extraction.
Get LLM-driven suggestions for improving the code hierarchy based on semantic analysis and best practices.
Check the status of semantic feature lifting (LLM-driven). Returns coverage stats (how many entities have lifted features), stale entity counts (features that need re-lifting), and recommendations for batching large lifting jobs.
Retrieve pending routing decisions previously stored by resolve_routing. Used by sub-agents to check if they have work assigned.
Get a high-level summary of the loaded RPG. Returns entity counts, language breakdown, semantic coverage stats, git metadata, and stale status. Use this to understand the state of the graph before diving into search/explore.
Fetch semantic features for an entity. Returns the list of 'what it does' descriptions extracted during lifting or parsing.
List entities that have changed since a given commit. Useful for understanding what's new/modified in recent changes.
List all entities of a specific type (e.g., functions, classes, modules). Returns basic metadata for each entity. Useful for getting an overview of what entities exist in a particular category.
Build a paper-style reconstruction execution plan (topological sort + batches). Returns a schedule of entities in dependency order, grouped into batches for parallel execution. Useful for understanding execution dependencies and planning reconstruction/refactoring.
Resolve routing decisions for a set of entities (e.g., which sub-agent handles which chunk). Stores the routing plan and retrieves it later for execution.
PREFER THIS OVER grep/rg FOR ANY QUESTION ABOUT CODE BEHAVIOR OR NAMES. Search for code entities by intent or keywords. Returns entities with file paths, line numbers, and relevance scores. Use mode='features' for semantic intent search (e.g., 'validate user input') — finds code by what it DOES even when names don't match. Use mode='snippets' for name/path matching (e.g., 'FilterGroupManager' or 'src/auth/'). Use mode='auto' (default) to try both. This replaces grep/rg for every structural query.
Switch the active project root at runtime. Reloads the graph and config from the new project directory. Allows a single long-lived MCP session to analyze multiple projects without restart.
Submit semantic feature results back to the server after LLM lifting. Updates entities with their newly-lifted semantic features, marks them as 'lifted', and persists the graph.
Incrementally update the RPG from git changes. Detects what has changed since the last build/update, re-parses only modified files, updates the graph structure, and preserves lifted semantic features for unchanged entities. Much faster than a full rebuild.
Validate graph integrity. Checks for orphaned entities, dangling edges, inconsistencies in the hierarchy, and other structural issues. Returns a report of any problems found.
OUTPUT SCHEMAS UNDOCUMENTED. Tools like search_node, fetch_node, explore_rpg return structured data but response field types and structure are not declared. LLMs cannot plan what fields to extract or how to chain results to downstream tools. Examples: does search_node return 'entities' array with 'id', 'path', 'relevance' fields? Does fetch_node return 'source_code' as string or array? Does explore_rpg return an edge list or adjacency structure?
MISSING TOOL ANNOTATIONS. Destructive tools (build_rpg, update_rpg, set_project_root, submit_lift_results, resolve_routing, create_hierarchy_snapshot, apply_hierarchy_edit) lack destructiveHint=true annotation. Read-only tools lack readOnlyHint=true. Idempotent operations are not marked. Agents cannot distinguish safe from unsafe tools without explicit annotations per current MCP spec.
NO ERROR HANDLING GUIDANCE. Tool descriptions do not mention error conditions, recovery paths, or retry strategies. Examples: what happens if build_rpg encounters an unsupported language? What if explore_rpg traverses past available memory? Does fetch_node return partial results or fail entirely? Agents lack actionable guidance per pattern:recovery-guide.
MISSING CONFIRMATION/DRY-RUN FOR STATE-MUTATING TOOLS. build_rpg, update_rpg, set_project_root, submit_lift_results, resolve_routing, create_hierarchy_snapshot, apply_hierarchy_edit modify persistent state. No dry-run option or confirmation step described. Agents cannot preview changes before commit. Per pattern:confirmation-request, irreversible operations should support preview.
PARAMETER CONSTRAINTS UNDERDOCUMENTED. Examples: 'line_nums' is described as array with integer items, but no min/max bounds stated. 'batch_size' and 'max_batch_tokens' lack numeric ranges. 'scope' is vague ('Restrict search to a hierarchy scope', what format? globs? paths?). 'limit' parameter has no stated range. Agents cannot validate inputs without explicit constraints per pattern:constrained-input.
PAGINATION NOT CLEARLY SPECIFIED. Tools like list_entities_by_type accept 'limit' but no offset/cursor or total_count return is documented. search_node's result cardinality is not stated. If results exceed limit, is pagination offered? Does the response include a 'next_cursor' or 'has_more' field? Per pattern:paginated-result, list-returning tools must support efficient pagination.
AMBIGUOUS PARAMETER DEPENDENCIES. 'scope' parameter appears in multiple tools with different semantics: search_node's scope is 'hierarchy scope', get_entities_for_lifting's scope is 'file glob, hierarchy path, or *'. Undocumented interdependencies: does 'line_nums' in search_node apply only in 'snippets' mode? Per pattern:tool-description, interdependent parameters must be documented in both parameter descriptions.