ichnus2
Click on "Install 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., "@ichnus2Locate the bug in /home/user/project: login fails with empty password"
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.
Ichnus is a stigmergic ant-swarm for bug localization. Isolated LLM ants score one file each against a bug report, deposit confidence-weighted heat onto a shared board, and spread it along the import graph with hop decay.
A median-of-3 pass catches random noise. A prosecutor / judge catches confidently wrong answers. You get a HOT / WARM / COLD markdown heatmap plus a full JSON audit trail — callable from Claude Code via MCP.
uv sync
ICHNOS_MOCK=0 uv run python -m ichnos2.demo_runner /path/to/repo \
"query string drops the first parameter" ""Why it exists
Grepping a bug description finds similar code. Agents that read the whole repo burn tokens and still guess. Ichnus treats localization as a swarm search with a hard spend ceiling:
Ants never talk to each other — they only write the board (O(A) cost, not O(A²))
Heat propagates along real import edges, so neighbours of a hot file get scouted next
Total ant spend is bounded — wave i uses
A0 / 2^i, so spend stays< 2 · A0Two verifiers, two failure modes — median-of-3 for random noise; prosecutor/judge for confidently wrong answers
Related MCP server: QA Radar
Architecture
System
Pipeline
Stigmergy
Ant-scored heat is a measurement and never evaporates. Propagated heat is a hypothesis and does. Recruitment makes this a swarm instead of a fixed ranked list: the next wave follows the trail.
Verification
Stage 7 catches random variance. Stage 8 catches systematic error — a model that is confidently wrong every time. Median-of-3 cannot fix that; changing the question can.
Quick start
Requires Python 3.11+ and uv.
git clone https://github.com/Sharann-del/Ichnus.git
cd Ichnus
uv syncOffline demo (no API key)
uv run python -m ichnos2.demo_runner /path/to/repo \
"login fails with empty password" ""Live run
Put a key in .env (never commit it):
GEMINI_API_KEY=...
# or
OPENROUTER_API_KEY=...Then set mock mode explicitly whenever a key is present:
ICHNOS_MOCK=0 uv run python -m ichnos2.demo_runner /path/to/repo \
"bug description" "optional stack trace"Variable | Purpose |
|
|
|
|
| Override the default cheap scout model |
|
|
|
|
| Optional separate model for Stage 8 |
Gemini free tier is the practical default for multi-ant waves. OpenRouter’s free quota is easy to exhaust on a mid-size repo; Ichnus fails fast with the reset time rather than spinning on a spent daily limit.
Tests
uv run pytest tests/test_algorithm.py -v98 tests, no network required.
MCP (Claude Code / any MCP client)
.mcp.json in the project root:
{
"mcpServers": {
"ichnus2": {
"type": "stdio",
"command": "uv",
"args": ["run", "python3", "-m", "ichnos2.mcp_server"],
"env": {
"ICHNOS_MOCK": "0",
"ICHNOS_PROVIDER": "gemini"
}
}
}
}Tool: locate_bug_tool(repo_path, bug_description, stack_trace="")
Returns the same markdown heatmap as the CLI. Audit JSON lands at <repo>/.ichnos2/last_audit.json.
uv run python -m ichnos2.mcp_server
# or
uv run ichnos2-mcpWhat you get
Markdown heatmap — HOT / WARM / COLD bands with scores, reasons, line ranges, and verification notes.
JSON audit — full board state, ant verdicts, cache provenance, and demotion history under .ichnos2/.
The heatmap is a suggestion for where to read next, not a verdict. Keep using normal file tools after.
How a wave spends budget
Wave i scouts roughly A0 / 2^i files. Across any finite number of waves:
total spend = A0 · (2 − 2^(1−n)) < 2 · A0This is asserted in the test suite (test_total_budget_bound_proof), not just documented.
Tests and example apps are excluded from scouting by default. A path named in a stack trace is always kept.
Verified results
Measured on this codebase — not invented:
Check | Result |
Test suite | 98 passed |
Express real bug (prose symptom, no stack) |
|
Seeded Python bug via OpenRouter | Culprit HOT, defect line pinned; Stage 8 upheld |
Mock e2e | Stage 8 overturns a planted confident decoy |
MCP stdio |
|
Stage 1 recall (tiny synthetic sample) | 0.8 (4/5) |
Design choices that matter
Confidence-weighted deposit — ranking uses
relevance × confidenceHop decay —
γ^hopfrom the nearest ant-sourced HOT file; cycle-safe BFSBounded demotion — never below
floor × peakProvenance-aware cache — mock and live scores never poison each other
Rate-limit aware client — per-minute limits waited out; daily quota stops the run
Overlapping file windows — strongest finding wins (averaging dilutes the truth)
Limitations
Accuracy is solidly shown on one real bug (Express) plus synthetics — not a broad hit-rate study
Ants read one file at a time; they cannot run a repro or reason about whole-repo architecture
Non-Python import edges are regex-based; only Python uses AST for authoritative contradictions
“Embedding” similarity in Stage 1 is a bag-of-words TF cosine proxy, not a neural embedding
Live mode sends file contents to Gemini or OpenRouter — no local-model path yet
Free-tier quotas can make “fast” and “works” mutually exclusive
Project layout
ichnos2/
locate_bug.py
candidate_filter.py
budget.py / priority.py
ants.py
board.py
reliability.py
verify.py
aggregate.py
llm_client.py
mcp_server.py
demo_runner.py
tests/
test_algorithm.pyLicense
MIT © 2026 Sharann Manojkumar
Available Tools
1 toollocate_bug_toolA
Locate the files most likely responsible for a bug, via a stigmergic ant-swarm search over the repo. Returns a markdown HOT/WARM/COLD heatmap with per-file evidence and, for HOT files, adversarial verification notes. This is a suggestion to prioritize reading, not a verdict -- always read the flagged files yourself before concluding.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | ||
| stack_trace | No | ||
| bug_description | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the result is a 'suggestion' and warns to 'always read the flagged files yourself before concluding'. It also reveals the output includes 'adversarial verification notes' for HOT files, adding transparency about the tool's analytical rigor and limitations.
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 three sentences, each serving a distinct purpose: action/method, output format, and usage caution. There is no redundant phrasing, and the technical term 'stigmergic ant-swarm' adds specificity without being wasteful.
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?
The description covers the core purpose, output format, and a critical caveat. It mentions the return format (markdown heatmap) which aligns with the existence of an output schema. However, it does not clarify how the optional stack_trace parameter affects behavior or provide any implementation details, leaving a moderate gap in completeness given no annotations.
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?
Schema description coverage is 0%, and the description does not explain any parameter semantics. It neither specifies what repo_path should contain, how to phrase bug_description, nor the optional nature of stack_trace. The parameter names are self-explanatory, but the description adds no explicit guidance, failing to compensate for the schema's lack of descriptions.
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 clearly states the tool's purpose: 'Locate the files most likely responsible for a bug' via a specific method ('stigmergic ant-swarm search'). It also details the output format (HOT/WARM/COLD heatmap), making the tool's functionality unmistakable. With no sibling tools, differentiation is not needed, but the verb+resource+method structure is strong.
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?
The description provides clear context: use this when you want to prioritize files to read for a bug. It explicitly frames the output as 'a suggestion to prioritize reading, not a verdict', which guides interpretation. However, it does not mention when not to use this tool or any alternatives, as there are no siblings listed.
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. Dates show when Glama detected each change.
1 tool update
v0.1.0- First observed
locate_bug_tool
TDQS
With only one tool, there is no possibility of confusing it with another. The tool's purpose is clearly described and unambiguous.
The single tool name 'locate_bug_tool' follows a clear verb_noun pattern and is internally consistent. There are no other names to contradict it.
The server has exactly one tool, which feels thin for a typical server scope. However, the tool itself is substantial and not trivial, so it is borderline rather than severely undercounted.
The tool fully addresses its stated purpose of locating bug-related files and provides a comprehensive heatmap with evidence. There are no obvious missing operations within the narrow domain of bug localization.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Repo intel for AI coding agents: overview, PRs, contributors, hot files, CI, deps. Remote MCP.
Voice-powered bug reporting with 13 MCP tools. Record bugs by talking; let AI find and fix them.
295k+ bug-fix patterns with MCP Hub proxy, PII filtering, and code search
Security + bug + perf + refactor audit for Python. Returns 0-10 score + MD report.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceEnables AI agents to scan codebases for prioritized findings (TODO, FIXME, XXX) and retrieve results in table, JSON, or SARIF format via MCP.-
- AlicenseNot gradedqualityCmaintenanceAnalyzes codebases to produce structured quality health reports with risk-scored modules based on git churn, test coverage, and test-to-source mapping, acting as an MCP server for AI coding agents and a standalone CLI.MIT
- FlicenseNot gradedqualityCmaintenanceScans MCP tools for trust drift, composition risks, and runtime policy violations, with optional LLM explanations.-
- AlicenseNot gradedqualityCmaintenanceEnables automated security code auditing using LLM and MCP, including AST parsing, taint analysis, dataflow tracing, and automated PoC generation for multi-language codebases.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sharann-del/Ichnus'
If you have feedback or need assistance with the MCP directory API, please join our Discord server