What can you do with this server?

The kasra-mcp server provides local code security scanning and rule management by integrating with the Kasra API. It reads local file content directly from your machine and is designed to integrate with AI tools such as Claude Desktop, Cursor, and Claude Code. * Scan files or directories (kasra_scan_file): Provide a path to a single file or an entire directory; the server reads the contents locally and submits them to the Kasra API. It detects issues such as SQL injection, XSS, hardcoded secrets, Docker/Kubernetes misconfigurations, and more across all major programming languages and config formats. * List security rules (kasra_get_rules): Retrieve all loaded security rules with their severity levels, actions, and enabled/disabled status. Optionally filter by severity (P0, P1, P2) or show only enabled rules. * Check API health (health): Verify that the Kasra API is reachable and the scanning engine is operational.

How do I use kasra-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kasra-mcp scan src/main.py for security issues" 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.

kasra-mcp

by yuanjianking

Overview Schema Source Related Servers Discussions Admin

Local

kasra-mcp

Kasra MCP Server — local code review via the Model Context Protocol.

Reads files on your machine and sends them to the Kasra API for security scanning. Designed to work with AI tools like Claude Desktop, Cursor, Claude Code, and any MCP-compatible client.

Install

pip install kasra-mcp

Requires Python 3.11+.

Related MCP server: Codebase MCP Server

Quick Start

# Verify installation
python3 -m kasra_mcp.server --help

The server connects to a Kasra API instance (default: http://localhost:8090).

Configuration

Environment variables:

Variable	Default	Description
`KASRA_API_URL`	`http://localhost:8090`	Kasra API base URL
`KASRA_API_KEY`	`""`	API key for authentication

Tools

`kasra_scan_file`

Scan a file or directory for security vulnerabilities.

Parameter	Type	Description
`path`	`string`	Path to a file or directory to scan

Supports both single files and directories. Ignores common non-source files (images, binaries, .git, node_modules, etc.).

`kasra_get_rules`

List all loaded security rules.

Parameter	Type	Description
`severity`	`string?`	Filter by severity (P0, P1, P2)
`enabled_only`	`boolean?`	Only return enabled rules

`health`

Check the Kasra API connection and engine status.

Integration with AI Tools

Claude Desktop

{
  "mcpServers": {
    "kasra": {
      "command": "python3",
      "args": ["-m", "kasra_mcp.server"],
      "env": {
        "KASRA_API_URL": "http://localhost:8090",
        "KASRA_API_KEY": "your-api-key-here"
      }
    }
  }
}

Paste this into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows).

Cursor

{
  "mcpServers": {
    "kasra": {
      "command": "python3",
      "args": ["-m", "kasra_mcp.server"],
      "env": {
        "KASRA_API_URL": "http://localhost:8090",
        "KASRA_API_KEY": "your-api-key-here"
      }
    }
  }
}

Claude Code

{
  "mcpServers": {
    "kasra": {
      "command": "python3",
      "args": ["-m", "kasra_mcp.server"],
      "env": {
        "KASRA_API_URL": "http://localhost:8090",
        "KASRA_API_KEY": "your-api-key-here"
      }
    }
  }
}

How it works


 Claude Desktop / Cursor / Claude Code
        │
        │  stdio (JSON-RPC over stdin/stdout)
        ▼
 ┌─────────────────┐        POST /v1/scan/file     ┌────────────────┐
 │   kasra-mcp     │ ─────────────────────────────→ │  Kasra API     │
 │                 │        POST /v1/rules/export   │  (Docker)      │
 │  reads local    │ ←───────────────────────────── │  193 rules     │
 │  file content   │        findings + results      │  CR scanning    │
 └─────────────────┘                                └────────────────┘

Claude Desktop starts kasra-mcp as a subprocess (stdio transport)
When the user asks to scan a file, Claude calls kasra_scan_file with a path
kasra-mcp reads the file content from local disk
Sends the content to the Kasra API via POST /v1/scan/file
Kasra API runs 83 code review rules, returns findings
kasra-mcp returns the results to Claude

The MCP server never stores your code — it reads, sends, and discards.

License

This project is licensed under the MIT License.

Development

git clone <repo>
cd kasra-mcp
pip install -e .
python3 -m kasra_mcp.server

Available Tools

3 tools

healthA

Check the Kasra API health status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the tool checks health status, without mentioning latency, authentication requirements, or return value structure. Minimal 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?

A single, clear sentence with no wasted words. Perfectly concise for the tool's simplicity.

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

Completeness3/5

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

Given zero parameters and an existing output schema (though not shown), the description is adequate but could mention what the health check returns (e.g., status, latency). Lacks detail about the output.

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?

No parameters exist, and schema description coverage is 100% trivially. The description adds no parameter info, but with zero params, the baseline is 4. No contradiction or missing details.

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 'Check the Kasra API health status' uses a specific verb ('Check') and identifies a clear resource. It distinguishes itself from sibling tools (kasra_get_rules, kasra_scan_file) which perform different functions.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. For a health check, context like 'use when verifying API connectivity' would help, but it's missing.

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

kasra_get_rulesB

List all loaded security rules with their severity, action, and status.

ParametersJSON Schema

Name	Required	Description	Default
`severity`	No
`enabled_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations provided, the description carries full behavioral burden. It implies a read-only operation by stating 'List', but does not disclose authentication needs, side effects, or other behavioral traits. The transparency is adequate for a simple list function but could be more explicit.

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 a single sentence containing exactly the essential information: verb, resource, and listed attributes. There is no wasted text, and the most critical purpose is front-loaded.

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

Completeness3/5

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

Given the tool's simplicity and the presence of an output schema (though not shown), the description covers the primary action and return fields. However, it omits parameter usage guidance (filtering by severity or enabling status) and does not address pagination, ordering, or errors. It is adequate but not fully comprehensive.

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

Parameters2/5

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

Schema description coverage is 0%, meaning the description does not explain the 'severity' and 'enabled_only' parameters. The description only hints at output fields ('severity, action, and status'), not input semantics. This adds minimal value beyond the schema structure.

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 action ('List'), the resource ('all loaded security rules'), and the specific fields returned ('severity, action, and status'). It effectively distinguishes from sibling tools like 'health' and 'kasra_scan_file' by focusing on listing rules rather than health checks or file scanning.

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

Usage Guidelines2/5

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, nor does it mention any prerequisites or exclusions. Sibling tool names offer some context, but the description itself lacks explicit usage direction.

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

kasra_scan_fileA

SECURITY: Scan a file or directory for security vulnerabilities. Reads local file content and sends it to the Kasra API for analysis. Runs code review rules (SQL injection, XSS, hardcoded secrets, Docker/K8s misconfigurations, etc.). Supports all major programming languages and config formats.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Discloses that the tool reads local file content and sends it to the Kasra API for analysis, implying network communication and no modification. Also notes it runs code review rules. No annotations provided, so description carries burden; it does well.

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

Conciseness4/5

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

Three sentences, front-loaded with security warning and clear action. Efficient but could be slightly more compact without losing meaning.

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 main purpose and scope well. Output schema exists (not shown but noted) which likely explains return format. Missing parameter details but acceptable given simplicity of single param.

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

Parameters2/5

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

Only one required parameter 'path' with no description in schema (0% coverage). Tool description does not specify path format, whether it can be a directory, or any constraints beyond type string. Minimal added value.

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 scans a file/directory for security vulnerabilities, lists specific vulnerability types (SQL injection, XSS, secrets, misconfigurations), and supports all major languages. Distinguishes from sibling tools (health, kasra_get_rules) which serve different purposes.

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

Usage Guidelines3/5

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

Implies usage for security scanning but no explicit guidance on when to use vs alternatives or when not to use. Sibling tools are given but no comparison or criteria for selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.1.0Jul 15, 2026
- First observedhealth
- First observedkasra_get_rules
- First observedkasra_scan_file

Deploy Server

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

TDQS

A3.6/5.0

Scored 2026-07-15 04:10 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: health checks API status, kasra_get_rules lists rules, and kasra_scan_file performs vulnerability scanning. No overlap in functionality.

Naming Consistency3/5

Two tools follow a 'kasra_' prefix pattern, but 'health' does not. This inconsistency could cause confusion about naming conventions, though it remains readable.

Tool Count4/5

Three tools is appropriate for a focused security scanning server. While minimal, each tool serves a core function without being overly numerous.

Completeness3/5

The set covers health check, rule listing, and scanning, but lacks retrieval of past scan results or rule management operations, which are notable gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp A
ai.promptarch
Research-backed linting + generation for agent context files (CLAUDE.md, AGENTS.md, Cursor rules).
Agent Orchestration Developer Tools
32
TrentOAuth
ai.trent
Security reviews, threat models over a repo or website, and remediation tracking, in your editor.
Security Penetration Testing Code Analysis
19
Opzyai Pro
com.opzyai
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Code Analysis Penetration Testing Security
2
OrchaOAuth
io.github.westonhancock
Securely search and manage workspace context files for AI agents and teams.
Search File Systems Knowledge & Memory
1

Related MCP Servers

Code Summarizer MCP
Code Analysis Documentation Access Developer Tools
nicobailon
F
license
Not graded
quality
D
maintenance
Allows LLM tools like Claude Desktop and Cursor AI to access and summarize code files through a Model Context Protocol server, providing structured access to codebase content without manual copying.
Updated a year ago (2025-03-25 14:05 UTC)
6
-
Codebase MCP Server
Code Analysis Developer Tools
cmaujean
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that analyzes application codebases with real-time file watching, providing AI assistants like Claude with deep insights into project structure, code patterns, and architecture.
Updated a year ago (2025-08-12 00:32 UTC)
MIT
Local Code MCP Server
Developer Tools Code Analysis File Systems
udittripathi
F
license
B
quality
D
maintenance
Provides LLMs with safe, read-only access to local codebases for searching, reading files, and finding function definitions. All source code remains local, ensuring privacy while enabling AI assistants to explore project structures and functionality.
Updated 8 months ago (2026-01-19 13:16 UTC)
4
-
Local Filesystem MCP Server
File Systems Developer Tools
saravanarjun
A
license
Not graded
quality
B
maintenance
Enables AI assistants to securely browse, search, inspect, and understand local project files through Model Context Protocol tools.
Updated 2 months ago (2026-07-09 13:13 UTC)
MIT