Delivers centralized security rules and instructions to GitHub Copilot, allowing for consistent security policy enforcement across repositories without manual file maintenance.
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., "@CodeGuard MCP Server get security rules for password hashing in Python"
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.
Security rules for AI code generation via Model Context Protocol.
Built upon Project CodeGuard: This MCP server integrates the comprehensive security instruction rules from Project CodeGuard, solving scaling and central governance challenges by delivering them via Model Context Protocol instead of per-repository file duplication.
GitHub Copilot can use .github/instructions/ files for security rules, but this sucks for orgs:
22+ files duplicated in every repo
No central control
Pain to update
This MCP server centralizes all security rules in one place.
Related MCP server: RulesetMCP
npm install -g @isagasi/codeguard-mcp-serverWindows:
# Get the global npm modules path
$npmPath = npm root -g
$serverPath = Join-Path $npmPath "@isagasi\codeguard-mcp-server\dist\index.js"
# Create configuration using node with args for reliable stdio
$config = @"
{
"servers": {
"codeguard": {
"type": "stdio",
"command": "node",
"args": ["$($serverPath -replace '\\', '\\\\')"],
"autoStart": true
}
}
}
"@
[System.IO.File]::WriteAllText("$env:APPDATA\Code\User\mcp.json", $config, (New-Object System.Text.UTF8Encoding $false))
Write-Host "✓ mcp.json created at: $env:APPDATA\Code\User\mcp.json"macOS/Linux:
# Get the global npm modules path
NPM_PATH=$(npm root -g)
SERVER_PATH="$NPM_PATH/@isagasi/codeguard-mcp-server/dist/index.js"
# Create configuration using node with args for reliable stdio
cat > ~/Library/Application\ Support/Code/User/mcp.json << EOF
{
"servers": {
"codeguard": {
"type": "stdio",
"command": "node",
"args": ["$SERVER_PATH"],
"autoStart": true
}
}
}
EOF
echo "✓ mcp.json created"code --install-extension alankyshum.vscode-mcp-autostarterPress Ctrl+Shift+P → "Developer: Reload Window"
Ctrl+Shift+P → "MCP: List Servers" → Should show codeguard running ✅
Done! Server is now active and will auto-start with VS Code.
Verify the MCP server is actually being invoked by Copilot:
Test 1: Password Hashing
@workspace Generate a Python function to hash a passwordExpected: Copilot should generate code using bcrypt or Argon2 (not MD5 or SHA1)
Test 2: Database Query
@workspace Create a PostgreSQL query function in Node.jsExpected: Code should use parameterized queries, not string concatenation
Test 3: API Key Storage
@workspace Show how to store an API key in a Python appExpected: Should suggest environment variables (os.getenv), not hardcoded strings
If Copilot generates insecure code (MD5 passwords, SQL injection, hardcoded keys), the MCP server may not be loaded. Retry steps 4-5.
The server provides 23 default security instruction files + 3 custom org rules:
Crypto rules (no MD5, use Argon2/bcrypt)
Auth/authz best practices
Input validation, SQL injection prevention
API security, logging, container hardening
Custom rules can override defaults
Copilot Chat can query these via MCP tools when generating code.
Add org-specific rules in rules/custom/:
---
applyTo: '**/*.ts'
description: Company API Standards
---
# API Standards
All REST endpoints must:
- Use company error format
- Log to ELK stack
- Rate limit: 100 req/minCustom rules get +25 priority and override defaults.
Update to latest version:
npm update -g @isagasi/codeguard-mcp-server
# Then reload VS CodePublishing new versions (Maintainers):
Update version: npm version patch (1.0.8 → 1.0.9)
Push tags: git push --follow-tags
Workflow auto-publishes to npm ✅
Server not running:
Check: Ctrl+Shift+P → "MCP: List Servers"
Should see codeguard with status "running"
If not listed, verify mcp.json path and reload VS Code
Error: spawn ENOENT or spawn EINVAL:
This means the command path is incorrect or the binary wrapper isn't compatible
Use the node with args configuration shown in Step 2 (not codeguard-mcp command)
The MCP protocol requires clean stdio - using node directly ensures compatibility
View server logs:
Open VS Code: View → Output
Select "MCP Auto-Starter" from dropdown
Check for startup errors or protocol violations
Reinstall package:
npm uninstall -g @isagasi/codeguard-mcp-server
npm install -g @isagasi/codeguard-mcp-server
# Reload VS CodeThis project integrates the security instruction rules from Project CodeGuard, a comprehensive collection of security best practices for AI-assisted code generation.
The MCP server architecture solves the scaling and central governance challenges inherent in per-repository instruction files, enabling organizations to maintain a single source of truth for security standards across all projects.
MIT
Get security instructions for code generation. Returns applicable security rules based on language, context, or file path.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Programming language (python, javascript, typescript, java, c, etc.) | |
| context | No | Context keywords (auth, crypto, database, api, password, hash, etc.) | |
| filepath | No | File path for pattern matching (e.g., src/auth/login.ts) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states that it 'Returns applicable security rules' but does not mention edge cases like empty results, error behavior, or any side effects. While the tool name suggests a read-only operation, this is not explicitly stated, leaving the agent with limited insight into its 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 two concise sentences, front-loaded with the primary action and followed by a clear summary of input logic. Every word contributes value, with no redundancy or filler.
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 straightforward retrieval tool with no output schema and three optional parameters, the description covers the core purpose and input relationships. It is complete enough for an agent to select and invoke it, though a brief mention of the sibling tool would improve contextual completeness.
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 already provides 100% parameter descriptions, meeting the baseline. The description's mention of 'language, context, or file path' reinforces the schema but adds no new semantic detail about parameter interactions, precedence, or formatting. It neither enhances nor degrades the schema's clarity.
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 action ('Get security instructions') and its scope ('for code generation'), with specific input dimensions ('language, context, or file path'). This distinguishes it from the sibling tool 'validate_code_security', which focuses on validation rather than fetching instructions.
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 a clear use case ('for code generation'), implying when to use it. However, it does not explicitly mention alternatives or exclusions, such as when to prefer 'validate_code_security' instead. Thus it lacks the full alternative guidance seen in higher-scoring examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate code snippet against security rules and return applicable instructions
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Code snippet to validate | |
| language | Yes | Programming language of the code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that validation returns instructions, but does not disclose potential side effects, authentication requirements, or the nature of the validation. For a security-related tool, this is insufficiently 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 sentence that is front-loaded with the core action ('Validate code snippet against security rules') and contains no redundant words. It is extremely concise and well-structured for easy scanning.
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 tool has no output schema and no annotations, yet the description only minimally addresses the return value ('return applicable instructions'). It does not explain what these instructions are, how validation works, or provide any safety/caveat context, leaving the tool under-specified for 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?
The input schema provides complete descriptions for both parameters (code and language), giving 100% schema coverage. The description adds no additional parameter meaning beyond what the schema already provides, so a baseline 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 description clearly states the tool validates a code snippet against security rules and returns applicable instructions. It distinguishes from the sibling tool get_security_instructions by emphasizing validation of a provided snippet rather than simply retrieving instructions, though the return of instructions creates some overlap.
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 when to use the tool (when a code snippet needs validation) but does not explicitly contrast with get_security_instructions or state when not to use it. No exclusions or alternative recommendations are provided, leaving the guidance implicit.
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.10get_security_instructionsvalidate_code_securityScored across 2 tools
The two tools have distinct purposes: one retrieves security instructions based on context, the other validates code against rules. However, both involve security instructions, which could cause minor confusion without careful reading.
Both tool names follow a consistent verb_noun pattern in snake_case, 'get_security_instructions' and 'validate_code_security', making them predictable and clear.
With only two tools, the server feels thin for a security-focused service. While the core operations are present, the scope appears limited, and additional tools for rule management would be expected.
The server lacks tools for managing or listing security rules, and the validation tool does not provide detailed violation reports. This leaves notable gaps in a typical security workflow.
Zero-install security baseline for AI coding agents — OWASP/CWE-cited rules over MCP.
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security reviews, threat models over a repo or website, and remediation tracking, in your editor.