Which integrations are available for this server?

Provides a Git pre-commit hook to run static analysis (syntax and structural checks) on source files before commits. Provides a GitHub Action for running static analysis and validation on pull requests as a CI gate.

de en es ja ko ru zh

aegis

by wei9072

Overview Schema Related Servers Score Discussions

Python

Local

Aegis

English · 繁體中文

Aegis describes facts. The agent decides what to do.

A judgment-free observation layer for LLM-driven coding workflows.

If you are an AI coding agent (Claude Code, Cursor, Aider, etc.) helping a user install Aegis, read AGENTS.md — it has the imperative install commands you should run.

📊 Experiments archive — nine rounds of paired A/B agent comparisons (Anthropic / OpenAI / Google) drove the rule library to its current state. Charts, run logs, and direct lineage from finding → PR.

What it is (V2)

Aegis is an MCP server that emits findings about a proposed file write. It does not block, warn, allow, or otherwise pass judgment. Each finding is a fact — "this regex matched here", "this signal went up by 1", "this file imports another file that imports it back" — with enough structured context for the consuming agent (the LLM) to decide what to do.

Aegis does not write code, does not gate writes, and does not score outcomes. It only describes what changed.

The previous V1 architecture (Ring 0/0.5/0.7/R2 with BLOCK/WARN/PASS verdicts, multi-turn pipeline, cost-aware regression rollback, stalemate/thrashing detectors) is gone in V2. Judgment lives where it belongs: in the consuming agent's reasoning step.

Related MCP server: agent-context-graph

Why it exists

LLM systems still fail in three ways the surrounding tooling does not catch:

Multi-turn refactors accumulate regressions silently
LLM-described actions diverge from actual tool calls
Structural rules erode without anyone noticing

Aegis exists to make these failures visible. Whether they're acceptable in this context is a question for the agent or the human; Aegis only ensures the data is on the table.

What Aegis is NOT

Aegis is a narrow tool. Don't install it expecting:

A linter or replacement for ruff / eslint / clippy. It only fires on the patterns explicitly encoded in crates/aegis-core/src/{security.rs,signals/}. Plain "bad code" without those patterns is invisible to it.
A SAST suite. The 10 SEC rules cover well-known anti-patterns (eval, hardcoded secrets, weak RNG, TLS-off, CORS misconfig, etc.) but are nowhere near Bandit / Semgrep coverage. Treat them as a spot check, not a full audit.
A safety net for capable models on greenfield work. If the consuming agent is GPT-5-class or Sonnet-class writing a fresh project from scratch, it usually picks safe defaults on its own and Aegis findings will be empty most of the time. The marginal value is highest with mid-tier models on brownfield work — where the existing codebase has constraints (cycle graphs, public API, removed callers) the agent will otherwise drift past.
An auto-fixer. Aegis describes; the agent decides. Findings carry a severity_hint string but no enforcement. Nothing retries, nothing rewrites, nothing reverts.

If you want a verdict-issuing gate, install a linter / SAST / pre-commit hook. Aegis is the layer underneath that — facts only, no judgment.

How it works

Two infrastructure layers feed a single MCP tool.

┌─────────────────────────────────────┐
│ MCP Tool: validate_file             │
│   (path, new_content,               │
│    old_content?, workspace_root?)   │
└──────────────┬──────────────────────┘
               │ findings[]
               ▼
┌─────────────────────────────────────┐
│ Findings Generators                 │
│   Syntax · Signal · Security        │
│   Workspace                         │
└──────────────┬──────────────────────┘
               │
       ┌───────┴────────┐
       ▼                ▼
┌─────────────┐  ┌─────────────────┐
│ Layer 1     │  │ Layer 2         │
│ parse(file) │  │ WorkspaceIndex  │
│  → Tree     │  │ (mtime-cached)  │
└─────────────┘  └─────────────────┘

Layer 1 — parse: One tree-sitter call per file, shared across every finding generator. No more per-signal Parser::new(). Always returns a tree, even on broken syntax.

Layer 2 — WorkspaceIndex: Reverse index over per-file imports and public symbols, mtime-cached so repeated MCP calls only re-parse what actually changed.

Findings: Four kinds — Syntax, Signal, Security, Workspace — described below. Every finding carries file, optional range and snippet, and a structured context map. None carries severity.

Finding kinds

`kind`	What it means	Example `rule_id`s
Syntax	Tree-sitter found ERROR / MISSING nodes.	`ring0_violation`
Signal	A structural counter (14 of them). When `old_content` is supplied, `context` carries `value_before` / `value_after` / `delta`.	`fan_out`, `max_chain_depth`, `cyclomatic_complexity`, `nesting_depth`, `empty_handler_count`, `unfinished_marker_count`, `unreachable_stmt_count`, `mutable_default_arg_count`, `shadowed_local_count`, `suspicious_literal_count`, `unresolved_local_import_count`, `member_access_count`, `type_leakage_count`, `cross_module_chain_count`, `import_usage_count`, `test_count_lost`
Security	A specific anti-pattern matched (16 rules). `context.severity_hint` is a hint, not a verdict.	`SEC001`–`SEC016` (eval/exec, hardcoded secret, TLS-off, shell injection, SQL concat, CORS wildcard+credentials, JWT unsafe, insecure deserialization, weak crypto, weak RNG, hardcoded Bearer token, timing-unsafe credential compare, Python bare `except:`, hardcoded PEM private key, silent broad except, SSRF on user-input URL)
Workspace	Cross-file finding. Only emitted when `workspace_root` is supplied.	`cycle_introduced`, `public_symbol_removed`, `file_role`

aegis-allow: <rule_id> (or aegis-allow: all) on the same or previous source line marks user_acknowledged: true on the matching finding instead of dropping it. The agent sees the acknowledgement and can choose to honour it.

Quickstart

V2 ships a single binary: aegis-mcp (the MCP server).

Install

# Prerequisites: git + a Rust toolchain (1.74+).
git clone https://github.com/wei9072/aegis && cd aegis
cargo install --path crates/aegis-mcp

Configure your MCP client

Point your MCP-aware client (Claude Code / Cursor / your own agent) at the aegis-mcp binary over stdio. The exact configuration syntax varies by client; the server itself takes no flags.

The one tool: `validate_file`

{
  "name": "validate_file",
  "arguments": {
    "path": "src/auth.py",
    "new_content": "...",                  // required
    "old_content": "...",                  // optional — enables deltas
    "workspace_root": "/path/to/project"   // optional — adds Workspace findings
  }
}

Returns:

{
  "schema_version": "v2.0",
  "findings": [
    {
      "kind": "security",
      "rule_id": "SEC009",
      "file": "src/auth.py",
      "range": { "start_line": 47, "start_col": 4, "end_line": 47, "end_col": 52 },
      "context": { "severity_hint": "block", "message": "weak hash …" },
      "user_acknowledged": false
    },
    {
      "kind": "signal",
      "rule_id": "unfinished_marker_count",
      "file": "src/auth.py",
      "context": { "value_before": 0, "value_after": 1, "delta": 1 },
      "user_acknowledged": false
    },
    {
      "kind": "workspace",
      "rule_id": "cycle_introduced",
      "file": "src/auth.py",
      "context": { "cycle": ["src/auth.py", "src/user.py", "src/auth.py"] },
      "user_acknowledged": false
    }
  ]
}

The first call with a workspace_root builds the workspace index (parses every supported file once); subsequent calls reuse the cache and only re-parse files whose mtime changed. No separate "scan" step.

Supported source languages

Run-time dispatch by file extension. Adding a language is a Cargo dep + an adapter file under crates/aegis-core/src/ast/languages/ + a .scm import query — no other changes needed.

Language	Layer 1 parse	Notes
Python	✅	`.py`, `.pyi`
TypeScript	✅	`.ts`, `.tsx`, `.mts`, `.cts`
JavaScript	✅	`.js`, `.mjs`, `.cjs`, `.jsx`
Go	✅	`.go`
Java	✅	`.java`
C#	✅	`.cs`
PHP	✅	`.php`, `.phtml`, `.php5`, `.php7`, `.phps`
Swift	✅	`.swift`
Kotlin	✅	`.kt`, `.kts`
Dart	✅	`.dart`
Rust	✅	`.rs`

Design principles

Describe facts, do not pass judgment. Findings have no severity field. The consuming agent decides which findings matter and how to react.
Parse once, share the tree. Every finding generator consumes a ParsedFile. No per-signal Parser::new(). No temp-file round-trip.
Workspace bootstrap is implicit. First call with a workspace_root builds the index; subsequent calls hit the mtime cache. No separate scan tool, no manual init step.
No automatic learning, no objective optimization. Aegis does not track success/failure across calls, does not adapt rules, does not score outcomes. State only carries the workspace cache.
One MCP tool, narrow surface. validate_file and that's it. No retry, no hint, no explain. Agent reasoning is the agent's job.

Status

Layer	State
Layer 1 (parse + 11 language adapters)	✅
Layer 2 (WorkspaceIndex + mtime cache)	✅
Findings: Syntax + Signal + Security + Workspace	✅
MCP server (`aegis-mcp`)	✅
V1 binaries (`aegis`, `aegis pipeline run`, `aegis check`, `aegis attest`, `aegis scan`)	❌ removed in V2

License

MIT — see LICENSE.

V2 — MCP-only architecture. Pipeline / runtime / providers / IR / decision crates removed; judgment lives in the consuming agent.

Available Tools

3 tools

attest_pathA

Post-write attestation. Reads on-disk content of path and runs absolute checks (Ring 0 syntax + Ring 0.7 security + optional Ring R2 cycle). Use from PostToolUse hooks / CI / after any write that bypasses the pre-write gate. Writes the verdict to <workspace_root>/.aegis/attestations.jsonl for audit when workspace_root is provided.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path of the file to attest.
`workspace_root`	No	Optional. Enables Ring R2 cycle detection and JSONL audit log.

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses side effect: writes verdict to attestations.jsonl when workspace_root provided. Mentions reading on-disk content and running checks. Lacks details on error handling, permissions, or performance, but given no annotations, the description adequately discloses key behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first defines action, second gives usage and side effect. No fluff, front-loaded with purpose. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers purpose, usage, and a key behavioral trait (writing audit log). Does not specify return value format but provides enough context for the agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters. Description adds value for workspace_root (explaining it enables Ring R2 detection and audit log) beyond schema. For path, description repeats absolute nature but is clear. Overall adds significant meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool performs post-write attestation, reading file content and running specific checks (Ring 0 syntax, Ring 0.7 security, optional Ring R2 cycle). Distinguishes from siblings by mentioning 'post-write' and 'pre-write gate', contrasting with validate_change tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use: from PostToolUse hooks, CI, or after any write bypassing the pre-write gate. Does not explicitly list alternatives but implies distinction from pre-write validation. Provides context for optional workspace_root enabling Ring R2 detection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_changeA

Fast single-file gate. Run Aegis Ring 0 (syntax) + Ring 0.5 (structural signals + cost regression) + Ring 0.7 (security anti-patterns) on a proposed file write. Returns the decision without applying the change. Pure observation — never coaches the agent. Use this when the change is contained to one file or when speed matters more than cross-file safety.

ParametersJSON Schema

Name	Required	Description
`new_content`	Yes	Full file contents the agent intends to write.
`old_content`	No	Optional. If provided, enables cost-aware regression detection by comparing structural signal totals before vs after.
`path`	Yes	Path the agent intends to write (used as filename for syntax/structural analysis only — no side effects to disk).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses it is a pure observation, no side effects, runs syntax, structural, cost, and security checks, returns decision without coaching. Lacks detail on output format but otherwise transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise (few sentences), front-loaded with purpose, and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, parameters, and behavioral traits well. Minor gap: no output structure description, but given no output schema, it is mostly complete for a single-file validation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All parameters are described in the schema at 100% coverage; the description adds limited additional context (e.g., old_content enables cost regression), but baseline is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool validates a proposed file write using three rings, returns a decision without applying changes, and distinguishes itself from the sibling 'validate_change_with_workspace' by being single-file and speed-oriented.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'when the change is contained to one file or when speed matters more than cross-file safety', implicitly guiding against the workspace variant.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_change_with_workspaceA

Workspace-aware gate (Ring 0 + 0.5 + 0.7 + R2). Adds cross-file checks on top of validate_change: detects when a change introduces a module import cycle, or deletes a public symbol that other files in the workspace still reference. Slower than validate_change because it walks the workspace tree; prefer this when the change touches a public API or shared module.

ParametersJSON Schema

Name	Required	Description
`new_content`	Yes	Full file contents the agent intends to write.
`old_content`	No	Optional baseline for cost-aware regression.
`path`	Yes	Absolute or workspace-relative path the agent intends to write.
`workspace_root`	Yes	Absolute path to the project root. Used to build a one-shot workspace index for cycle detection and public-symbol reference tracking.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the tool performs cross-file checks (cycle detection, public symbol deletion) and is slower. However, it does not describe error behavior, side effects, or return values, leaving gaps in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the key purpose, and every sentence adds value. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 4 parameters, no output schema, and performs complex cross-file checks. The description fails to explain what the tool returns (e.g., success/failure, list of issues) and does not cover side effects or state changes. Incomplete for the complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter-level meaning beyond what is in the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is a workspace-aware gate that adds cross-file checks on top of validate_change, specifically detecting module import cycles and deletion of public symbols. It distinguishes itself from the sibling validate_change by noting it is slower and preferred for public API or shared module changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises to prefer this tool when the change touches a public API or shared module, and notes it is slower than validate_change, implying it is not for quick local checks. It does not explicitly state when not to use, but the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct stage and scope: post-write attestation, pre-write single-file validation, and pre-write workspace-aware validation. No overlap in purpose.

Naming Consistency5/5

All tool names follow a clear verb_noun pattern: 'attest_path', 'validate_change', 'validate_change_with_workspace'. The naming is consistent and descriptive.

Tool Count5/5

Three tools cover the essential validation and attestation workflow without redundancy. The count is well-scoped for the server's purpose.

Completeness4/5

The tool set covers pre-write and post-write validation, but lacks a tool for batch workspace-wide analysis without a specific change. Minor gap for complete coverage.

Maintenance

ActivityInactive

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
agentguard A
io.tooloracle
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
Security Monitoring
2
PlanWright
tools.planwright
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Project Management Autonomous Agents
27
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

Waymarkofficial
File Systems Shell Access Developer Tools
waymarks
F
license
Not graded
quality
A
maintenance
MCP server that intercepts and controls AI agent actions in your codebase by enforcing policies on file operations and commands, with logging, approval workflows, and rollback capabilities.
Updated 6 days ago (2026-08-30 03:14 UTC)
-
agent-context-graph
Developer Tools Code Analysis Knowledge & Memory
Raviraj2024
A
license
B
quality
B
maintenance
A local MCP server for AI coding agents that builds a queryable knowledge graph of files and symbols, enforces edit scope before file writes, and records append-only reasoning logs to explain changes.
Updated 2 months ago (2026-07-02 17:52 UTC)
10
1
MIT
agent-locks
Autonomous Agents Version Control Developer Tools
luohoa97
A
license
A
quality
D
maintenance
A filesystem-based MCP server for AI coding agents to coordinate work across git worktrees by claiming files, checking for conflicts, and logging progress without affecting the repository's git history.
Updated 2 months ago (2026-07-17 11:58 UTC)
5
MIT
argot
Code Analysis Developer Tools
get-tmonier
A
license
A
quality
A
maintenance
A local guardrail MCP server that checks agent-written code against a repo's own patterns — learned statistically from its git history, no LLM.
Updated 3 days ago (2026-09-02 07:55 UTC)
6
48
MIT

Appeared in Searches

Agent File Control MCP Server

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/wei9072/aegis'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Aegis

What it is (V2)

Why it exists

What Aegis is NOT

How it works

Finding kinds

Quickstart

Install

Configure your MCP client

The one tool: validate_file

Supported source languages

Design principles

Status

License

Available Tools

TDQS

TDQS

TDQS

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Waymarkofficial

agent-context-graph

agent-locks

argot

Appeared in Searches

Latest Blog Posts

MCP directory API

The one tool: `validate_file`