Code Firewall MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OLLAMA_URL | No | Ollama server URL | http://localhost:11434 |
| EMBEDDING_MODEL | No | Ollama embedding model | nomic-embed-text |
| FIREWALL_DATA_DIR | No | Data storage directory | /tmp/code-firewall |
| NEAR_MISS_THRESHOLD | No | Near-miss recording threshold | 0.70 |
| SIMILARITY_THRESHOLD | No | Block threshold (0-1) | 0.85 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {
"tasks": {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
},
"prompts": {
"get": {}
},
"resources": {
"read": {}
}
}
}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| firewall_system_checkA | Check if system meets requirements for Ollama embeddings. Verifies: macOS, Apple Silicon (M1/M2/M3/M4), RAM, Homebrew installed. Use before attempting Ollama setup. |
| firewall_setup_ollamaB | Install Ollama via Homebrew (macOS). Args: install: Install Ollama via Homebrew start_service: Start Ollama as a background service pull_model: Pull the embedding model (nomic-embed-text) model: Model to pull (default: nomic-embed-text) |
| firewall_setup_ollama_directA | Install Ollama via direct download (macOS) - no Homebrew, no sudo. Args: install: Download and install Ollama to ~/Applications start_service: Start Ollama server in background pull_model: Pull the embedding model (nomic-embed-text) model: Model to pull (default: nomic-embed-text) |
| firewall_ollama_statusA | Check Ollama server status and embedding model availability. Args: force_refresh: Force refresh the cached status |
| firewall_checkA | Check if code is safe to pass to execution tools like rlm_exec. Parses the code, normalizes to structural skeleton, embeds via Ollama, and checks similarity against blacklisted dangerous patterns. Args: file_path: Path to the code file to check Returns: { "allowed": bool, # True if safe to proceed "blocked": bool, # True if matched blacklist "similarity": float, # Similarity to closest blacklist match (0-1) "matched_pattern": str, # ID of matched pattern (if blocked) "reason": str, # Why it was blocked (if blocked) "near_miss": bool, # True if close but not blocked "structure_hash": str, # Hash of normalized structure } |
| firewall_check_codeB | Check if code string is safe (without requiring a file). Args: code: The code to check language: Programming language (default: python) Returns: Same as firewall_check |
| firewall_blacklistA | Add a code pattern to the blacklist. Either file_path or code must be provided. Args: file_path: Path to code file to blacklist code: Code string to blacklist (alternative to file_path) reason: Why this pattern is dangerous severity: critical, high, medium, low language: Programming language (used if code is provided) Returns: {"status": "added", "pattern_id": str, "structure_hash": str} |
| firewall_record_deltaA | Record a near-miss variant to help sharpen the classifier. Use this when code is similar to a blacklisted pattern but represents a legitimate use case, or when a new variant of a dangerous pattern is discovered. Args: file_path: Path to code file code: Code string (alternative to file_path) similar_to: Pattern ID this is similar to notes: Notes about why this is being recorded language: Programming language Returns: {"status": "recorded", "delta_id": str} |
| firewall_list_patternsB | List patterns in the blacklist or delta collection. Args: collection_name: "blacklist" or "deltas" limit: Maximum number of patterns to return Returns: {"patterns": [...], "count": int} |
| firewall_remove_patternC | Remove a pattern from the blacklist or delta collection. Args: pattern_id: The pattern ID to remove collection_name: "blacklist" or "deltas" Returns: {"status": "removed", "pattern_id": str} |
| firewall_statusB | Get firewall status and statistics. Returns: { "ollama_available": bool, "chromadb_available": bool, "tree_sitter_available": bool, "blacklist_count": int, "delta_count": int, "similarity_threshold": float, "near_miss_threshold": float, } |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Most tools have distinct purposes, but firewall_check and firewall_check_code are very similar—both check code safety, differing only in input method (file vs. string). This could cause confusion, though their descriptions clarify the distinction. Other tools like blacklist, remove_pattern, and status are clearly differentiated.
All tool names follow a consistent 'firewall_' prefix with descriptive suffixes in snake_case, such as firewall_blacklist, firewall_check, and firewall_status. This pattern is uniform across all 11 tools, making them predictable and easy to identify.
With 11 tools, the count is well-suited for a code firewall server, covering core operations like blacklisting, checking, setup, and status. Each tool serves a specific role in the domain, avoiding redundancy while providing comprehensive functionality.
The toolset covers key aspects of a code firewall: blacklist management (add, list, remove), safety checks (file and code variants), setup (Ollama installation), and status monitoring. A minor gap is the lack of a tool to update existing patterns, but agents can work around this by removing and re-adding.