RepoGraph-Honest MCP Server
Summary: This MCP server gives AI coding agents deterministic, repository-grounded verification of Python code to catch hallucinated APIs and undefined symbols before they move on.
Scan a file via the exposed
scan_file(path)tool, passing an absolute path to a Python file.Detect invented APIs — calls to methods/functions that don't exist in the indexed codebase (e.g.
UserClient.refresh_token()when onlyrefresh_access_token()exists).Detect undefined symbols — missing names, imports, or module attributes.
Detect incorrect API calls — including wrong arities and mismatched call signatures.
Auto-index the project from the file path, so checks are grounded in the repository rather than just the single file.
Return actionable evidence — findings include
kind,owner,evidence(such asavailable_methodsanddid_you_meansuggestions),confidence, andaction, plus a human-readable text summary, enabling the agent to self-correct.Optional extended tools (via
HONESTCODE_TOOLS=all, not in the default schema):verify_file,index_project,load_project_deps,check_symbol,check_api,validate_types.
Runs fully locally — no LLM calls or network access required.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@RepoGraph-Honest MCP ServerScan src/utils.py for undefined symbols"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
HonestCode
The deterministic verification layer for AI coding agents.
Catch invented APIs, undefined symbols, wrong calls, and other code hallucinations before your agent moves on.

The problem
AI coding agents hallucinate. They invent function names, fabricate library APIs, and call methods that do not exist.
HonestCode is the layer that checks what the agent just wrote against the repository it is supposed to be grounded in.
Agent
↓
writes code
↓
HonestCode
↓
evidence
↓
Agent fixes
↓
verified codeNo LLM calls. No network. Pure AST + symbol resolution.
Related MCP server: javalens-mcp
Demo
The agent was asked to "add authentication using the existing UserClient."
It generated:
client.refresh_token()The real project only has:
class UserClient:
def refresh(self): ...
def refresh_access_token(self): ...HonestCode catches it deterministically:
✗ verification failed — 1 issue in app/login_broken.py
[invented_api] app/login_broken.py:9
`UserClient.refresh_token()` does not exist.
did you mean: refresh_access_token()?
available methods:
- refresh()
- refresh_access_token()
confidence: deterministic · action: reviseRun it yourself:
cd demos/invented-api
python run.pyWhy not just use Ruff / Pyright?
HonestCode is not a replacement — it is a verification layer that answers a specific question: did the agent's code actually come from this repository?
Error | Ruff | Pyright | HonestCode |
Syntax error | ✓ | ✓ | ✓ |
Type mismatch | — | ✓ | structural only |
Undefined symbol | ✓ | ✓ | ✓ |
Invented API | partial | partial | core |
Wrong method call | — | partial | core |
Agent-generated API mismatch | — | — | core |
The key difference is repository grounding. Ruff checks the file. Pyright
types the call. HonestCode checks whether the call resolves to a real symbol
that exists in the codebase the agent is editing. (HonestCode does not do full
type inference — its structural checks catch mismatched arities, iterating
None, and calling constants, not general type errors.)
What a call site is checked against depends on how the receiver's type is known:
an annotation (client: UserClient), a constructor assignment
(client = UserClient()), self/cls, and an inline constructor
(UserClient().refresh()) are all resolved. A receiver produced by a factory
function (make_client().refresh()) is not judged — function signatures
carry no return type in the surface model, and guessing there would trade a
missed finding for a false one.
Install
pip install honestcodeRequires Python >= 3.10. 100% local.
30-second setup with Claude Code
# Add HonestCode as an MCP server
claude mcp add honestcode -- honestcode-mcpOr add it manually to your Claude Code config (~/.claude/config.json on
macOS/Linux, %LOCALAPPDATA%\Claude\config.json on Windows):
{
"mcpServers": {
"honestcode": {
"command": "honestcode-mcp",
"args": []
}
}
}Restart Claude Code. You now have two verification tools available:
scan_file(path)— legacy tool, returnsissuesplus the new evidence shape.verify_file(path)— agent-facing tool, returnsstatus,findingswithevidence, and a human-readabletextsummary.
Try prompting Claude:
Add a login endpoint using the existing UserClient, then run verify_file on the
file you just wrote and fix anything it reports.HonestCode auto-discovers the project root from the file path, indexes the codebase, and returns grounded evidence.
Real example
# auth/client.py
class UserClient:
def refresh_access_token(self): ...
# auth/login.py
from auth.client import UserClient
def login(client: UserClient):
client.refresh_token() # invented API>>> from honestcode.mcp.tools import verify_file
>>> verify_file("auth/login.py")
{
"status": "fail",
"file": "auth/login.py",
"findings": [
{
"line": 7,
"kind": "invented_api",
"symbol": "refresh_token",
"owner": "UserClient",
"message": "`UserClient.refresh_token()` does not exist.",
"evidence": {
"available_methods": ["refresh", "refresh_access_token"],
"did_you_mean": "refresh_access_token"
},
"confidence": "deterministic",
"action": "revise"
}
],
"text": "✗ verification failed — 1 issue in auth/login.py\n ..."
}Agent output protocol
verify_file returns evidence an agent can act on directly, not just an error
message:
{
"status": "fail",
"file": "auth/client.py",
"line": 42,
"kind": "invented_api",
"symbol": "refresh_token",
"owner": "UserClient",
"message": "UserClient.refresh_token() does not exist.",
"evidence": {
"available_methods": ["refresh", "refresh_access_token"]
},
"confidence": "deterministic",
"action": "revise"
}How it works
Auto-index the project (or reuse the cached symbol index).
Parse the target file with the standard-library
astmodule.Resolve every call site to a concrete symbol:
infer the receiver type from annotations, constructors, and imports;
reconstruct the class's member surface from the repository AST;
mark the surface as unknown when a base class cannot be resolved or the class defines
__getattr__.
Emit findings with
kind,owner,evidence,confidence, andaction.
The loop is deterministic and auditable.
MCP tools
By default only scan_file is exposed. Set HONESTCODE_TOOLS=all to enable the
full set, including:
Tool | Purpose |
| Scan a file for invented APIs, undefined calls, and wrong arities. |
| Return the agent-facing structured evidence protocol. |
| Build or reuse the project symbol index. |
| Load dependency APIs from |
| Verify a symbol is defined. |
| Verify a library API call exists. |
| Structural type checks. |
See the old tool reference below for the complete list.
Benchmark
HonestCode includes three benchmark suites that run automatically in CI on every
push and pull request to main:
Agent-accuracy benchmark
benchmarks/agent_accuracy/ is a deterministic, LLM-free benchmark that
measures how well HonestCode catches common agent hallucinations (recall).
Each task is a tiny agent episode: the agent writes a broken file, HonestCode verifies it, then the file is replaced with the fix and verified again.
cd benchmarks/agent_accuracy
python run.pyCurrent results (6 tasks, deterministic verification):
task | expected issue | broken detected | fixed clean | broken ms | fixed ms |
invented_method | invented_api ( | yes | yes | 16.1 | 17.7 |
invented_module_attr | invented_api ( | yes | yes | 16.9 | 16.9 |
undefined_import | undefined_symbol ( | yes | yes | 15.8 | 14.3 |
wrong_signature | wrong_call ( | yes | yes | 22.2 | 16.8 |
cross_file_new_symbol | invented_api ( | yes | yes | 18.5 | 182.2 |
dep_alias_and_pypi_name | invented_api ( | yes | yes | 15.9 | 17.5 |
Summary: precision 1.0, recall 1.0, F1 1.0, false-positive rate 0.0, median verify time 33.7 ms.
The cross_file_new_symbol task pins the agent-session flow (write a module,
then a file importing it — the index must be fresh, never stale); the
dep_alias_and_pypi_name task pins dependency grounding through aliased
submodules and PyPI-named requirements (PyYAML → yaml).
Real-world false-positive benchmark
benchmarks/realworld_fp/ measures precision on real code: it scans a
vendored snapshot of psf/requests (19 files, ~6.4k LOC, Apache-2.0) and
asserts HonestCode reports zero findings. Real code exercises the
constructs synthetic tasks never do — stdlib imports, keyword-call style,
@staticmethod members, classes inheriting stdlib ABCs, compat re-export
modules — and any finding on this corpus is, by construction, a false
positive.
python benchmarks/realworld_fp/run.py
# files: 19 findings: 0 elapsed: 5.4s (286 ms/file)Performance benchmark
scripts/benchmark.py measures the latency of core operations (index, scan,
graph, dead code detection, similarity search) on the repository itself.
python scripts/benchmark.py # text output
python scripts/benchmark.py --format markdown # table for README
python scripts/benchmark.py --repo psf/requests # benchmark a real-world repoAll three benchmarks run in CI (.github/workflows/ci.yml) as separate jobs:
benchmark-accuracy, benchmark-realworld, and benchmark-performance. A benchmark failure blocks
the build if precision or recall drops below 1.0.
See benchmarks/agent_accuracy/README.md for the dataset format and how to
add new accuracy tasks.
Architecture
honestcode/
├── verify/ # Evidence protocol + repository-grounded verification
├── mcp/ # MCP server layer
├── honest/ # Symbol index + project binding
├── graph/ # Persistent call graph (SQLite)
├── structure/ # AST extraction
├── sandbox/ # Sandboxed execution
└── cli.py # Command-line interfaceverify_file is the agent interface. scan_file is the default MCP tool and
returns both the new evidence shape and the legacy issues list.
Roadmap
v0.1 — Repository grounding (now)
symbol / API / function / class / method / import / call verification
invented API detection with structured evidence
auto-index on
scan_file
v0.2 — Semantic contract verification
function expects
UserID, agent passesUser→ suspicious
v0.3 — Execution verification
static verification → tests → runtime evidence
v1.0 — Verification Runtime for Coding Agents
Coding Agent
│
┌───────▼───────┐
│ HonestCode │
│ Verification │
│ Runtime │
└───────┬───────┘
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Static Semantic Runtime
Verification Verification Verification
│ │ │
└──────────────┼──────────────┘
↓
Evidence
↓
AgentDevelopment
git clone https://github.com/Fengrru/honestcode.git
cd honestcode
python -m venv .venv
.venv\Scripts\activate # Windows
# source .venv/bin/activate # macOS/Linux
pip install -e ".[dev]"
pytest
ruff check honestcode tests scriptsRun benchmarks locally:
# Accuracy benchmark
python benchmarks/agent_accuracy/run.py
# Performance benchmark
python scripts/benchmark.pySee CONTRIBUTING.md for pull request guidelines.
Security
See SECURITY.md for vulnerability reporting.
Telemetry
HonestCode collects no telemetry. There are no analytics libraries, no background services, and no phone-home endpoints.
License
MIT - Copyright (c) 2026 HonestCode Team
Available Tools
1 toolscan_fileB
Scan a file for potential hallucinations: undefined symbols, missing imports, and incorrect API calls.
Args: file_path: Absolute path to the Python file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description doesn't state whether the scan is read-only, whether any side effects occur, what the return format looks like, or any ownership/permission requirements. For a tool with zero annotations, this lacks adequate transparency about what happens during execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—a one-sentence summary plus a single documented parameter with its arg meaning. It is appropriately brief with no filler. Minor deduction for the Args section being a lightweight docstring format rather than a structured rich description, but overall it earns its sentences well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 1 parameter, no output schema, and no annotations, the tool is relatively simple. The description covers the purpose and the single parameter adequately, but lacks detail on what the scan result looks like (e.g., return format, whether it returns findings or just a pass/fail) and no behavioral context. It's adequate for a minimal tool but leaves the agent guessing about output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema description coverage is 0%, the description does add value by explaining file_path is 'Absolute path to the Python file,' adding format (absolute) and type (Python) constraints beyond the schema's bare 'string' type. With only one parameter, this adds sufficient semantic meaning, though the name/schema combination was already fairly clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Scan a file') and clarifies the domain (potential hallucinations) with concrete examples: undefined symbols, missing imports, incorrect API calls. It clearly states what the tool does, though it doesn't need sibling differentiation as no siblings exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There's no mention of language scope beyond 'Python file' in the arg description, no prerequisites (e.g., file must exist), no context on when scanning is appropriate. The only implicit context is scanning for hallucination-type issues, which is weak guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
scan_file1 field changed- changed
Input schema / titlePrevious value: -"scan_fileArguments"New value: +"_mcp_scan_fileArguments"
1 tool update
v0.2.0- First observed
scan_file
TDQS
Scored across 1 tool
With only a single tool, there is no possibility of confusion or overlap between tools. The purpose of scan_file is clearly isolated and distinct.
Only one tool exists, so consistency is trivially satisfied. The name follows a sensible verb_noun pattern (scan + file) that would fit well if more tools were added.
A single trivial tool for a server named 'RepoGraph-Honest' is extremely thin. Scanning individual files for hallucinations is a narrow capability that does not justify an MCP server's scope.
The tool only scans a single file at a time with no support for scanning directories, repos, or batch operations. There are no complementary tools for viewing results history, scanning modules, or handling related analysis tasks, leaving significant gaps in the stated purpose.
Maintenance
Related MCP Connectors
MCP server for developer documentation, generated by doc2mcp.
A MCP server built for developers enabling Git based project management with project and personal…
An MCP server that provides asset auto generator
MCP registry & directory: search, find & install 31k+ MCP servers & tools. Catalog and marketplace.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA modular MCP server that provides tools for file operations, regex-based code searching, and structural analysis of functions and classes across multiple programming languages. It also includes AI-powered features for intelligently updating files according to architectural changes.-
- AlicenseAqualityBmaintenanceAn MCP server providing 63 semantic analysis tools for Java, built directly on Eclipse JDT for compiler-accurate code understanding.7542MIT
- AlicenseBqualityDmaintenanceA high-performance MCP server for intelligent documentation search, proactive bug detection, and semantic analysis of codebases.2515 npmMIT
- AlicenseAqualityBmaintenanceAn MCP server that empowers AI coding agents to work effectively with Minecraft mod development, providing static analysis of decompiled source code and runtime interaction with a running Minecraft instance.3130 npm15MIT