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., "@Blind-Auditor-MCP audit this Python function for security issues and style compliance"
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.
"Code -> audit -> amend -> audit again -> pass."
Blind Auditor is a mandatory code auditing system built on the MCP (Model Context Protocol). It uses a unique "Thinking Isolation" mechanism to force AI Agents to enter an independent "audit phase" and self-review their code before outputting the final result.
Traditional AI coding is often "generate and output," which allows errors and biases to slip through. Blind Auditor introduces a middle layer:
Intercept: When the Agent wants to output code, it must first submit it to Blind Auditor.
Isolate: Blind Auditor does not return the result immediately. Instead, it injects a mandatory system instruction, forcing the Agent to pause its current persona and switch to a "Ruthless Auditor" role.
Audit: In this isolated context, the Agent must scan the generated code line by line against the predefined rules.json.
Release: The code is unlocked and returned to the user only when the audit score meets the threshold (default > 80) and there are no Critical issues.
Related MCP server: MeshMind
🛡️ Zero Trust Architecture: Default distrust of the Agent's initial draft; it must pass an audit.
💰 Zero Extra Cost: Reuses the host IDE's current session model, requiring no additional API Key.
⚖️ Bias Removal: Forces a perspective switch via Prompt injection to break generation inertia.
📏 Strict Compliance: Hard-codes team code standards (rules.json) into the generation process, which is more effective than simple Prompts.
🔄 Auto-Fix Loop: Automatically triggers a "fix-resubmit" loop upon audit failure until compliance is met or the maximum retry count is reached.
This project requires Python 3.10+ and uv.
# Install uv (if not already installed)
curl -LsSf https://astral.sh/uv/install.sh | sh
# Enter project directory
cd blind-auditor
# Install dependencies (automatically creates virtual environment)
uv syncrules.json)Create or edit rules.json in the project root. This is the auditor's "Rulebook".
{
"project_name": "MyCoreProject",
"strict_mode": true,
"max_retries": 3,
"rules": [
{
"id": "SEC-001",
"severity": "CRITICAL",
"description": "Strictly prohibit hardcoding any API Keys, passwords, or sensitive Tokens.",
"weight": 50
},
{
"id": "PERF-001",
"severity": "WARNING",
"description": "Avoid database queries or IO operations inside loops.",
"weight": 15
},
{
"id": "STYLE-001",
"severity": "PREFERENCE",
"description": "Use snake_case for variable names.",
"weight": 5
}
]
}Configuration Fields:
severity:
CRITICAL: Fatal error. If found, the audit fails immediately. Usually carries a high penalty.
WARNING: Warning. Moderate penalty; accumulation can lead to failure.
PREFERENCE: Style preference. Low penalty.
weight: The penalty points deducted when this rule is violated (Total score: 100).
To ensure the Agent knows it must use this tool, add the following instruction to your .cursorrules or IDE System Prompt settings:
# Blind Auditor Protocol
**CRITICAL INSTRUCTION**:
You are integrated with the **Blind Auditor MCP**.
Whenever you generate code for a user request, you **MUST NOT** output the code block directly to the user.
**Execution Protocol**:
1. **Draft**: Generate the code internally in your thought process.
2. **Submit**: Call the `submit_draft` tool with your code and language.
3. **Obey**: The tool will return a strict "Audit Instruction". You MUST follow it exactly to audit your own code.
4. **Finalize**: Only when the tool returns "✅ AUDIT PASSED" can you display the final code to the user.
**Prohibited**:
- Do NOT output code blocks before passing the audit.
- Do NOT skip the audit step for "simple" changes.Add the following to your MCP client configuration file (e.g., claude_desktop_config.json or IDE settings):
Note: Replace /path/to/your/blind-auditor with the actual absolute path where you cloned this repository.
{
"mcpServers": {
"blind-auditor": {
"command": "uv",
"args": ["run", "--directory", "/path/to/your/blind-auditor", "blind-auditor"]
}
}
}submit_draftSubmit a code draft.
Input: code (content), language (programming language)
Behavior: Locks the session and returns mandatory audit instructions.
submit_audit_resultSubmit your audit conclusion.
Input:
passed (bool): Whether you believe it passed.
issues (list): List of issues found.
score (int): Score from 0-100.
Behavior:
If score < 80, forces passed=False.
If passed, unlocks the code.
If failed, increments retry count and requires the Agent to fix and resubmit.
reset_sessionResets the state and clears the retry count.
graph TD
User["User Request"] --> Agent
Agent["Agent Generates Draft"] -->|1. submit_draft| MCP
MCP -->|2. Inject Audit Instructions| Agent
subgraph Isolation ["Thinking Isolation"]
Agent -->|3. Self-Review| Agent
Agent -->|4. submit_audit_result| MCP
end
MCP -->|5. Verdict| Decision{"Passed?"}
Decision -->|No - Issues Found| Retry["Retry Count +1"]
Retry -->|Limit Not Reached| Fix["Agent Fixes Code"]
Fix -->|Resubmit| Agent
Decision -->|Yes - Score >= 80| Final["✅ Output Final Code"]
Retry -->|Limit Reached| Force["⚠️ Force Output - With Warning"]Q: The Agent always outputs code directly without calling tools. A: Check if the System Prompt is configured correctly. You must explicitly tell the Agent "Do NOT output code directly". You can also manually remind it in the chat: "Please audit via Blind Auditor first".
Q: Why does it fail even if I give the code 100 points?
A: Check if any CRITICAL rules in rules.json were triggered. Current logic mainly relies on the score passed by the Agent, but if passed is True while score < 80, the system will force a rejection.
Q: Which programming languages are supported?
A: Theoretically, all languages are supported. Blind Auditor itself does not parse code syntax but relies on the Agent's understanding to match descriptions in rules.json.
# Run server
uv run blind-auditor
# Or run directly with Python module
uv run python -m src.main
# Debug mode (output to stderr)
# View print statements in src/main.pyMIT License
Reset the current audit session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Reset' implies a destructive or state-changing operation, but the description doesn't clarify what gets reset (e.g., data loss, session state), whether authentication is needed, or any side effects. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary elaboration. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 tool has 0 parameters, 100% schema coverage, and an output schema exists, the description's minimal approach is somewhat adequate. However, as a mutation tool ('reset') with no annotations, it lacks critical behavioral context like effects or permissions, making it incomplete for safe invocation.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and the baseline for this scenario is 4, as it appropriately avoids redundant information.
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 action ('reset') and target resource ('current audit session'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'submit_audit_result' or 'update_rules' which also operate on audit sessions, so it doesn't reach the highest score.
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 no guidance on when to use this tool versus alternatives like 'submit_draft' or 'update_rules'. There's no mention of prerequisites, timing considerations, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit the audit result.
| Name | Required | Description | Default |
|---|---|---|---|
| passed | Yes | ||
| issues | Yes | ||
| score | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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. 'Submit' implies a write operation, but the description fails to disclose critical behavioral traits such as whether this requires specific permissions, what happens after submission (e.g., irreversible changes, notifications), or any rate limits. This leaves the agent with significant uncertainty about the tool's 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?
The description is extremely concise—a single four-word sentence—and front-loaded with the core action. However, this brevity comes at the cost of under-specification; while there is no wasted text, the description fails to provide necessary context that would help the agent use the tool effectively.
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 complexity of a submission tool with three parameters (two required) and no annotations, the description is incomplete. While an output schema exists (which might cover return values), the description lacks essential context about the tool's purpose, usage, behavior, and parameter meanings. This makes it inadequate for safe and effective use by an agent.
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%, meaning none of the three parameters (passed, issues, score) are documented in the schema. The description adds no parameter semantics beyond what the schema provides—it doesn't explain what 'passed' means, what constitutes an 'issue', how 'score' is used, or the relationship between these parameters. This leaves all parameters effectively undocumented.
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 'Submit the audit result' is a tautology that essentially restates the tool name 'submit_audit_result'. It provides no additional specificity about what resource is being submitted, to whom, or what the audit entails. While it does contain a verb ('submit') and a resource ('audit result'), it lacks any distinguishing details that would help differentiate it from potential alternatives.
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 offers no guidance on when to use this tool versus alternatives like 'submit_draft' or 'update_rules'. There is no mention of prerequisites, appropriate contexts, or exclusions. The agent must infer usage solely from the tool name and parameters, which is insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a code draft for audit.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| language | No | python |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'submit' implying a write operation, but fails to describe key traits like whether this requires authentication, what happens after submission (e.g., triggers an audit process), or any rate limits. This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence with no wasted words, making it easy to parse. It is appropriately sized for a simple tool, though this conciseness comes at the cost of missing details in other dimensions.
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 tool has an output schema, the description doesn't need to explain return values. However, with no annotations, 2 parameters (0% schema coverage), and a mutation implied by 'submit', the description is incomplete—it lacks behavioral context and parameter details, making it only minimally adequate for a basic submission 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 0%, so the description must compensate for undocumented parameters. It does not explain the 'code' or 'language' parameters beyond what the schema provides (e.g., what format 'code' should be in, what 'language' options exist beyond the default 'python'). This adds minimal value, failing to address the coverage gap adequately.
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 action ('submit') and resource ('code draft for audit'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'submit_audit_result' or 'update_rules', which also involve submission or updating processes in the audit context.
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 no guidance on when to use this tool versus alternatives like 'submit_audit_result' or 'update_rules'. It lacks context about prerequisites, such as whether a draft must be prepared first or if this is part of a workflow, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update audit rules configuration.
Args:
action: Operation to perform - "add", "remove", "update", or "list"
rule_id: Rule identifier (required for add/remove/update)
severity: Rule severity level - "CRITICAL", "WARNING", or "PREFERENCE" (for add/update)
description: Rule description (for add/update)
weight: Point deduction weight 0-100 (for add/update)
Returns:
Status message with operation result
Examples:
# List all rules
update_rules(action="list")
# Add a new rule
update_rules(
action="add",
rule_id="SEC-001",
severity="CRITICAL",
description="No hardcoded API keys",
weight=50
)
# Remove a rule
update_rules(action="remove", rule_id="SEC-001")
# Update a rule
update_rules(
action="update",
rule_id="SEC-001",
description="Updated description"
)
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| rule_id | No | ||
| severity | No | ||
| description | No | ||
| weight | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 that the tool performs operations like 'add', 'remove', 'update', and 'list', implying mutation capabilities. However, it lacks details on behavioral traits such as permission requirements, whether changes are reversible, rate limits, or error handling. The description adds basic context but misses critical information for a mutation tool with no annotation coverage.
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 well-structured with clear sections (purpose, args, returns, examples) and uses bullet points for readability. It's appropriately sized, with each sentence earning its place by explaining parameters or providing examples. However, the 'Args' section could be more front-loaded with the purpose statement, and some redundancy exists in parameter explanations.
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 tool's complexity (5 parameters, mutation operations) and no annotations, the description does a good job covering inputs with detailed parameter semantics and examples. Since an output schema exists, it doesn't need to explain return values beyond the brief 'Status message' note. The main gap is lack of behavioral context like permissions or side effects, but overall it's fairly complete for the provided context.
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 description coverage is 0%, so the description must compensate fully. It provides detailed semantics for all 5 parameters: 'action' with operation types, 'rule_id' as identifier with usage contexts, 'severity' with levels, 'description' as rule text, and 'weight' as point deduction range. This adds significant meaning beyond the bare schema, effectively documenting each parameter's purpose and constraints.
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 as 'Update audit rules configuration' with a specific verb ('update') and resource ('audit rules'). It distinguishes itself from sibling tools like 'submit_audit_result' or 'submit_draft' by focusing on rule management rather than audit submissions. However, it doesn't explicitly differentiate from 'reset_session' which might also affect configurations.
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 through the 'action' parameter values ('add', 'remove', 'update', 'list'), suggesting when to use each operation. It provides examples for different scenarios but doesn't explicitly state when to choose this tool over alternatives like 'reset_session' or mention prerequisites such as authentication needs. The guidance is contextual but lacks explicit exclusions or comparisons.
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.
reset_sessionsubmit_audit_resultsubmit_draftupdate_rulesEach tool has a clearly distinct purpose with no overlap: reset_session handles session management, submit_audit_result and submit_draft handle different submission types (final results vs. code drafts), and update_rules handles rule configuration. The tools target different resources and actions, making misselection unlikely.
Three tools follow a consistent verb_noun pattern (reset_session, submit_audit_result, submit_draft), while update_rules also fits this pattern but uses a different verb style ('update' vs. 'reset'/'submit'). The naming is mostly consistent with only minor deviation in verb choice.
With 4 tools, this is well-scoped for an audit server. Each tool earns its place by covering core audit workflow stages: session management, rule configuration, draft submission, and result submission. The count is neither too sparse nor bloated for the domain.
The toolset covers the essential audit lifecycle: configure rules, submit drafts, submit results, and manage sessions. A minor gap exists in lacking a tool to retrieve or review audit results/history, but agents can work around this using the existing submission tools. Core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
An MCP server that gives your AI access to the source code and docs of all public github repos
Cloudflare Workers MCP server: ai-agent-scratchpad
MCP server teaching AI agents to implement TideCloak: auth, E2EE, IGA, security analysis
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sim-xia/Blind-Auditor'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
