MCP server that exposes semantic dependency engine tools to AI agents (Cursor, Claude Code, Gemini). Provides cryptographic change propagation, architectural decision tracking, and semantic chain validation.
Reponoesis MCP exposes 8 semantic dependency tools with generally clear naming (verb_noun pattern: rpn_impact_map, rpn_validate, rpn_query, rpn_acknowledge, rpn_get_context, rpn_record_concept, rpn_record_decision, rpn_record_violation). All tools have descriptions (50-200 chars baseline met). Input schemas are present with type definitions and required fields. However, descriptions lack actionable context for LLM selection (missing WHEN to call, prerequisites, recovery guidance). Parameter descriptions are minimal or absent in several tools. Output schemas are not documented, LLMs cannot predict return structure. Error handling is not visible in tool definitions. Tool composition is sound (each does one thing), but chaining guidance is missing.
Acknowledge a broken chain as intentional drift (when you have reviewed and decided no update is needed). This creates an immutable audit entry and moves the chain state from CHAIN_BROKEN to ACKNOWLEDGED_DRIFT. Use when you have intentionally removed a concept and the referencing file correctly does not need updating.
[Call at SESSION START] Load the full project architectural context into your working memory. Returns: - All active ADR decisions with full WHY rationale (why we chose X over Y) - Which files each decision governs - Concept map: what semantic concepts are tracked and where they live - Recent audit events (what changed, who changed it) - Chain health summary - A compact briefing string you can use as context ALWAYS call this first at the start of every new agent session to prevent amnesia. This is your "getting oriented" tool — know the project before touching anything.
[Call BEFORE making changes] Returns a complete map of what will be semantically impacted if you modify the specified files. Shows: - Direct syntactic dependencies (imports, calls) — CRITICAL severity - Cross-file business rule instances — HIGH severity - Policy/legal files that govern the changed concepts — HIGH severity - Files sharing semantic concepts — MEDIUM severity Use this BEFORE editing any file to understand the full blast radius. Always update ALL impacted files in the same session to maintain chain integrity.
Search for all locations across the codebase where a specific concept lives. Returns every file section that encodes the concept, with: - File path and line range - Chain state (VALID / CHAIN_BROKEN / ACKNOWLEDGED_DRIFT) - Confidence level (STRUCTURAL / CONSENSUS / SINGLE_MODEL) Use this to understand the full scope of a concept before modifying it. Example: rpn_query("ad_tracking") before removing ad SDK
Output schemas not documented. LLMs cannot predict return structure (broken_chains, chain_link_hashes, concept_map, audit_events, etc.). Forces agents to guess field names and types.
Parameter descriptions are minimal or missing. 'files' param in rpn_impact_map lacks format guidance (absolute paths? relative? glob patterns?). 'confidence' enum in rpn_record_concept lacks explanation of CONSENSUS vs SINGLE_MODEL semantics.
Descriptions lack actionable context for LLM selection. 'rpn_get_context' says 'Load full project context' but does not explain WHEN to call it (session start? before every edit?) or what happens if skipped. Missing dependency hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
[YOU are the brain] Record a semantic concept that YOU have identified in the code. Reponoesis does NOT extract concepts automatically — YOU are the extractor. When you read code and understand what it means semantically, call this tool to write that understanding into the Merkle graph. This creates a cryptographic anchor that will alert future agents if this code changes without documentation. Use snake_case labels. Be specific. Examples: - "billing_model" for pricing/fee logic - "auth_strategy" for authentication approach - "data_retention_policy" for GDPR/retention rules - "rate_limiting" for API rate limit logic The concept will be automatically linked (CONCEPT_SHARED edge) to all other sections that already carry the same label.
[YOU are the brain] Create an Architecture Decision Record (ADR) from your own analysis. Call this when the developer makes a significant decision and you want to preserve the WHY for future agents — "why we chose Postgres over MongoDB", "why $10 not $50", "why we use JWT not sessions". This AUTOMATICALLY binds the decision to all listed files in one call. No separate rpn bind command needed. The body should capture: - What was decided - WHY (tradeoffs you considered, alternatives you rejected) - What this means for the codebase going forward After calling this, run rpn_validate to confirm all chains are clean.
[YOU are the brain] Record a semantic logic contradiction or drift that YOU have identified between two files. Reponoesis does not run background headless checks — you represent the human intelligence that detects when two pieces of code are saying contradictory things.
[Call AFTER making changes] Validates that all semantic dependency chains are intact after your edits. Returns: - Broken chains: files that became stale as a result of your changes - Chain link hashes: cryptographic proof of which links broke - Suggested next steps for each broken chain Always call this after completing a set of related changes to ensure zero semantic drift.
No error handling guidance visible in tool definitions. If rpn_query finds no matches, rpn_acknowledge receives invalid concept_ids, or rpn_record_decision fails to bind files, LLMs have no recovery path.
Tool composition lacks chaining guidance. rpn_impact_map returns impacted files, but tool definition does not state that output feeds into rpn_validate. rpn_get_context returns 'compact briefing string' but does not explain how to use it in downstream calls.