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., "@senior-sde-mcp-guard Check src/main.py for AST violations"
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.
Universal AST Gatekeeper & Architectural Guardrail for AI Coding Agents (Antigravity, Cursor, Claude Code, Kiro)
Senior SDE MCP Guard is a high-performance, cross-platform Abstract Syntax Tree (AST) gatekeeper that prevents AI agents from generating messy, unmaintainable, or anti-pattern code. It acts as an active Senior Staff Software Engineer auditing file writes before they land in your codebase.
AI coding assistants (Antigravity, Cursor, Claude Code, Kiro) are incredible at writing fast code, but often produce architectural smells:
ā God Classes (300+ lines of bloated code dumping all responsibilities into one file)
ā Parameter Bloat (functions taking 7ā10 arguments instead of structured DTO objects)
ā Deep Control Nesting (The "Arrow Anti-Pattern" of nested if/for/try loops)
ā Silent Error Swallowing (except: pass or empty catch blocks)
ā Hardcoded Secrets (Accidentally writing API keys or tokens into source files)
Senior SDE MCP Guard executes deterministic AST analysis in < 10 milliseconds at $0.00 cost, rejecting bad architectural edits and forcing the AI agent to refactor immediately.
Related MCP server: mcp-edit-math
Install via pip (or run directly with uvx):
pip install senior-sde-mcp-guardYou can activate the Senior SDE Guard in Antigravity either Per-Project or Globally Across All Projects.
Add a .agents/AGENTS.md file to the root of your project directory:
Create directory .agents/ in your project root.
Create file .agents/AGENTS.md with these instructions:
# Project Rules for Antigravity
## Senior SDE Gatekeeper Rule
Whenever creating or editing code files in this workspace:
1. After editing or creating any `.py` file, execute the Senior SDE check:
`python -m senior_sde_guard.cli check <file_path>`
2. If any AST violations are reported (e.g. Class size > 300 lines, Function lines > 60, Parameter count > 5, bare exceptions, or missing type hints), immediately refactor the code to fix all reported violations before completing the task.To make Antigravity enforce the Senior SDE Guard automatically across every project on your computer without adding .agents to every folder:
Open your global user configuration directory:
Windows: C:\Users\<YourUsername>\.gemini\config\
macOS/Linux: ~/.gemini/config/
Create or edit the AGENTS.md file in that folder: C:\Users\<YourUsername>\.gemini\config\AGENTS.md
Add the following rule:
# Global Rules for Antigravity
## Senior SDE Gatekeeper Rule (Global)
Whenever creating or editing code files in any workspace:
1. After editing or creating any `.py` file, execute the Senior SDE check:
`python -m senior_sde_guard.cli check <file_path>`
2. If any AST violations are reported, immediately refactor the code to fix all reported violations before completing the task.Now Antigravity will automatically check and enforce Senior SDE standards on every codebase you work on!
Add senior-sde-guard to your mcp.json or claude_desktop_config.json:
{
"mcpServers": {
"senior-sde-guard": {
"command": "uvx",
"args": ["senior-sde-mcp-guard", "serve"]
}
}
}.gatekeeper.yaml)Place a .gatekeeper.yaml in your project root to customize your team's architectural thresholds:
version: 1
strict_mode: true
rules:
# Maintainability & Complexity (Pragmatic Enterprise Defaults)
max_file_lines: 600
max_class_lines: 300
max_function_lines: 60
max_function_params: 5
max_cyclomatic_complexity: 12
max_nesting_depth: 4
# Reliability & Security
block_bare_except: true
block_silent_errors: true
block_wildcard_imports: true
detect_secrets: true
require_type_hints: trueYou can also run the guardrail manually or via pre-commit hooks:
# Audit a single file
senior-sde-guard check src/services/order_service.pyā [Senior SDE Gatekeeper REJECTED] File 'src/services/order_service.py' failed 3 quality check(s):
ā¢ Line 42 [max_class_lines]: Class 'OrderManager' is 380 lines long (Max allowed: 300). Split responsibilities into sub-modules.
ā¢ Line 115 [max_function_params]: Function 'process_order' has 7 parameters (Max allowed: 5). Pass a configuration object or dataclass.
ā¢ Line 180 [block_bare_except]: Bare 'except:' statement detected. Catch specific exception classes.
ā ļø ACTION REQUIRED: Refactor the code to fix these architectural issues before writing to disk.Licensed under the MIT License. Built by Amir Madani.
Reads an existing workspace file from disk and audits it against Senior SDE AST rules.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute or relative path to the file on disk. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a read operation ('Reads') and the audit action, but does not mention side effects, error handling, or whether it modifies anything. The behavior is partially transparent but lacks depth.
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 a single sentence that is direct and free of filler. It front-loads the core action and purpose, earning every word.
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?
Given the low parameter count and an output schema that likely describes return values, the description sufficiently covers the tool's core behavior. It could mention prerequisites or limitations (e.g., file must be in workspace), but overall it is complete enough for a simple 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?
The schema describes 'file_path' as a path on disk. The description adds meaning by specifying 'workspace file' and 'existing', which constrains the parameter beyond the generic schema. This extra context is valuable.
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 specific verbs 'Reads' and 'audits' with a clear resource ('existing workspace file') and specifies the audit against 'Senior SDE AST rules'. This distinguishes it from the sibling tool by naming the specific rule set, making the purpose unmistakable.
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 implies usage for auditing files against AST rules, but it does not state when to prefer this tool over the sibling 'check_code_quality' or any exclusions. Usage context is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audits code against Senior Staff Software Engineer AST rules (Class size, Complexity, Parameter count, Type hints, Secret leakage, Bare exceptions).
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | The file path being created or modified. | workspace/file.py |
| code_content | Yes | The source code string to audit. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description carries the full burden of behavioral transparency. It discloses the specific rules checked, which adds context, but it does not mention side effects (e.g., read-only behavior), return format, or failure modes. This is adequate but not deeply transparent.
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 a single, well-structured sentence that front-loads the action and lists the audit rules without redundant wording. Every phrase contributes to understanding the tool's purpose.
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, combined with a complete parameter schema and an output schema (which likely documents return values), covers the essential aspects of the tool. However, the lack of usage guidance relative to 'audit_file' and the absence of behavioral details (e.g., side effects) prevent a perfect score.
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%, with both parameters (file_path and code_content) clearly described in the schema. The tool description adds no additional meaning to either parameter, so the baseline score of 3 is appropriate.
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 verb 'Audits' clearly specifies the action, and the description enumerates specific AST rules such as Class size, Complexity, and Secret leakage, making the tool's scope evident. However, it does not explicitly contrast with the sibling tool 'audit_file' beyond the rule list, so it falls short of a 5.
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 implies the tool is for checking code quality against predefined AST rules, but it provides no explicit when-to-use or when-not-to-use guidance. With a sibling tool 'audit_file' present, the absence of any differentiation or alternative mention limits the guidance to implied usage.
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. Dates show when Glama detected each change.
v0.1.0audit_filecheck_code_qualityThe two tools are distinct in their input: check_code_quality presumably audits code provided directly, while audit_file reads a file from disk. However, both perform the same core action (auditing against AST rules), causing minor potential for confusion if the input types are not obvious.
Both tool names follow a clear verb_noun pattern (check_code_quality, audit_file). The verbs are different but semantically similar, and the structure is consistent, making the naming predictable and easy to parse.
With only two tools, the server feels thin for its stated purpose of code quality auditing. It covers direct code and files, but the minimal count suggests a limited scope that may not handle broader workflows.
The domain is code quality auditing, and the tools cover auditing code snippets and files. However, there is no tool to list or retrieve the AST rules, adjust audit scope (e.g., directories), or provide remediation guidance, leaving notable gaps in the workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pre-commit code quality guardian. Detects semantic drift in AI-generated code.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Zenable cleans up sloppy AI code and prevents vulnerabilities with deterministic guardrails
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/amirmadani/senior-sde-mcp-guard'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
