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., "@Aedile check for existing date formatting utility before writing new code"
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.
Claude Code
│
▼
"Build authentication"
│
▼
Aedile MCP
┌────────────────────┐
│ Existing helper? │
│ Stdlib available? │
│ Import cycles? │
│ Layer violation? │
└────────────────────┘
│
▼
Minimal implementationModern coding assistants know how to write code. They usually don't know your architecture.
That leads to:
duplicate utilities
unnecessary dependencies
circular imports
broken layering
inconsistent implementations
Aedile verifies the repository before code generation begins, giving coding assistants real project context instead of relying solely on prompts.
Related MCP server: Carto MCP Server
Without Aedile
AI: "I'll install requests."
↓
Repository already has httpx.
↓
Duplicate dependency.With Aedile
AI: "Repository already uses httpx."
↓
Reuse existing client.
↓
No duplicate dependency.Aedile implements the Model Context Protocol (MCP). The assistant calls a single tool—aedile_consult—before generating any code.
Developer
│
▼
Claude
│
▼
Aedile MCP
│
├── Architecture Verifier
├── Workspace Index
└── Decision Engine
│
▼
Advice
│
▼
Claude
│
▼
ImplementationAedile never modifies your code. It only observes and advises.
pip install aedileGenerate the local prompt templates:
python -m aedile compile-rulesThen add python -m aedile as an MCP server in your coding assistant. See SUPPORTED_AGENTS.md for step-by-step guides.
Aedile works out of the box with zero configuration. Advanced options are documented in CONFIGURATION.md.
Agent | Status |
Claude Code | ✓ Supported |
Cursor | ✓ Supported |
Windsurf | ✓ Supported |
Continue | ✓ Supported |
Full setup guides are in SUPPORTED_AGENTS.md.
Benchmarks were measured using identical prompts on the same repository, before and after enabling Aedile.
Environment
Hardware: Apple M2 Pro, 16 GB RAM
Python: 3.11
Agent: Claude 2.1
Repository: 42 modules, ~8,000 lines of Python
Results
Metric | Without Aedile | With Aedile |
Reasoning Cost (avg tokens) | 1,850 | 350 |
Context Window (tokens) | 4,200 | 1,200 |
Duplicate Code Written | Yes | No |
Tool Calls Executed | 3 | 1 |
Full methodology and raw data: BENCHMARKS.md.
Why not use static prompting (e.g., .cursorrules)?
Static prompts drift. As the context window fills, the model's adherence to static text degrades. Aedile enforces constraints through a live tool interface—the model receives current repository facts on every call, not instructions it may ignore.
Does Aedile require internet access?
No. All scanning, indexing, and analysis runs locally. There is no outbound network traffic and no telemetry.
Contributions are welcome. Please read CONTRIBUTING.md and CODE_OF_CONDUCT.md before opening a pull request.
Aedile is released under the MIT License.
Consult Aedile before implementing. Returns codebase symbol matches, stdlib alternatives, dependency reuse options, and checks proposed imports for cycles or layering violations.
| Name | Required | Description | Default |
|---|---|---|---|
| proposed_plan | Yes | General description of the feature logic you want to implement. | |
| proposed_changes | No | Optional list of files and imports you plan to add or modify. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It publicly states it 'returns' analysis results, implying read-only behavior. It lists specific checks and reuse options, giving a good picture of what the tool does without side effects.
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?
Two sentences, highly efficient. First sentence delivers the core purpose; second sentence itemizes the return types. No wasted words.
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?
For a tool with 2 parameters and no output schema, the description adequately covers behavior and what the user receives. However, it does not explain the format of results (e.g., structured vs plain text) or any ordering/pagination, which would be helpful for a consultation tool.
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 100%, so baseline is 3. The description does not add meaningful semantic detail beyond the schema's own parameter descriptions. It mentions plan and changes but no additional constraints or usage tips.
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?
Description clearly states the verb 'Consult' and resource 'Aedile', and enumerates four specific return types (codebase symbol matches, stdlib alternatives, dependency reuse options, and import cycle/layering checks). No sibling tools require differentiation.
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?
Explicitly advises to consult before implementing, establishing a clear usage context. However, no exclusion criteria or alternatives are mentioned, though the lack of siblings reduces the need for explicit when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0aedile_consultScored across 1 tool
Only one tool exists, so there is no ambiguity. The agent cannot confuse it with other tools.
With a single tool, the naming pattern is perfectly consistent. 'aedile_consult' follows a descriptive noun_verb pattern.
A single tool is too few for effective agent workflow. The server's purpose (code consultation) would benefit from additional tools for actions like implementing suggestions.
The lone tool tries to cover multiple consultation aspects (symbols, stdlib, dependencies, imports), but the absence of any action tools leaves obvious gaps in the implementation workflow.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Codebase intelligence for AI agents — dead code, blast radius, ownership.
AI Agent with Architectural Memory. Impact analysis (free), tests and code from the graph (pro).
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
