Which integrations are available for this server?

Analyzes composer.json and composer.lock files to extract project metadata and identify known vulnerabilities (CVEs) in project dependencies. Audits .env configuration files for security misconfigurations such as enabled debug modes, missing application keys, and insecure session settings. Performs comprehensive security audits on Laravel projects, including route analysis, Blade template scanning for XSS, and configuration verification. Executes static code analysis on PHP files to detect risky patterns like SQL injection, Remote Code Execution (RCE), and hardcoded credentials.

How do I use Laraguard MCP?

1. Click on "Install 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., "@Laraguard MCP run a full security audit on this Laravel project" 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.

Laraguard MCP

by ecr17dev

Overview Schema Related Servers Score Discussions

TypeScript

Local

Laraguard MCP

A security audit MCP server for Laravel projects — built with TypeScript and stdio transport.

License: MIT Node.js TypeScript MCP SDK Version

Overview

Laraguard MCP is a standalone Model Context Protocol (MCP) server that performs security audits on Laravel projects. It is implemented in pure TypeScript using the official @modelcontextprotocol/sdk and communicates over stdio, making it natively compatible with any MCP-capable IDE or client (Cursor, Claude Desktop, VS Code MCP extensions, etc.).

The server analyses a Laravel project as an external target — it does not require Laravel to be running. It returns structured JSON findings categorised by severity, covering configuration issues, risky code patterns, and dependency hygiene.

Related MCP server: DevSecOps MCP Server

Features

🔍 Static code scanning — 15+ rules covering SQL injection, RCE, hardcoded credentials, weak crypto, mass assignment, and LFI
🎭 Blade XSS scanner — detects unescaped {!! !!} output and raw input rendering in templates
🛣️ Route & middleware audit — flags admin routes without auth, API routes without auth:sanctum, login routes without throttle, and CSRF exceptions
📦 Dependency CVE feed — queries the OSV.dev API for real CVEs across all composer.lock packages
⚙️ Configuration audit — inspects .env (DEBUG, APP_KEY, APP_ENV, secure cookies) and config/cors.php
🗂️ Project metadata — reads composer.json to identify Laravel and PHP version constraints
💥 Active attack simulation — fires HTTP probes (SQL injection, XSS, CSRF, auth bypass, rate limiting) against a running app
🔒 Path traversal prevention — strict allowlist enforcement for all file operations
✂️ Secret redaction — sensitive values are masked in textual output before reaching the MCP client
🚀 stdio transport — zero-config network; works inside any IDE that supports MCP

MCP Tools

The server exposes 8 tools. All static tools accept a single path parameter. attack_simulate additionally requires a baseUrl.

Tool	Input	Description
`project_info`	`path`	Returns metadata from `composer.json`: project name, Laravel/PHP version constraints, engine info.
`dependency_audit`	`path`	Parses `composer.lock` and queries OSV.dev for real CVEs with severity and fix versions.
`config_audit`	`path`	Inspects `.env` (DEBUG, APP_KEY, APP_ENV, session cookies) and `config/cors.php` (wildcard origins).
`code_scan`	`path`	15+ static pattern rules across all PHP files — credentials, weak crypto, mass assignment, RCE, LFI, SQL injection.
`blade_scan`	`path`	Scans `resources/views/` Blade templates for unescaped output (`{!! !!}`) and XSS-prone patterns.
`route_audit`	`path`	Audits route files and middleware for missing auth, missing throttle, and CSRF exception wildcards.
`attack_simulate`	`path` + `baseUrl`	Fires 6 live HTTP probes against a running app: SQL injection, XSS, CSRF, auth bypass, rate limiting, error disclosure.
`full_audit`	`path`	Runs `dependency_audit` + `config_audit` + `code_scan` + `blade_scan` + `route_audit` in parallel and returns a consolidated report.

Code Scan — Detected Patterns

Pattern	Severity	Finding Type
`->whereRaw(`	High	`SQL_INJECTION`
`DB::raw(`	Medium	`RAW_SQL_USAGE`
`unserialize(`	Critical	`UNSAFE_UNSERIALIZE`
`shell_exec(` / `exec(` / `system(` / `passthru(`	Critical	`RCE_RISK`
`eval(`	Critical	`EVAL_USAGE`
`password = 'literal'`	Critical	`HARDCODED_PASSWORD`
`api_key = 'literal'`	Critical	`HARDCODED_API_KEY`
Long hardcoded tokens/secrets	High	`HARDCODED_SECRET`
`md5(`	High	`WEAK_HASH_MD5`
`sha1(`	Medium	`WEAK_HASH_SHA1`
`protected $guarded = []`	High	`MASS_ASSIGNMENT_UNGUARDED`
`file_get_contents($request…)`	Critical	`PATH_TRAVERSAL_RISK`
`include/require($request…)`	Critical	`LFI_RISK`

Audit Report Schema

Every tool returns a structured JSON report:

{
  "summary": {
    "critical": 0,
    "high": 1,
    "medium": 2,
    "low": 0,
    "info": 1
  },
  "findings": [
    {
      "severity": "high",
      "type": "SQL_INJECTION",
      "title": "Potential SQL injection via whereRaw",
      "file": "app/Http/Controllers/UserController.php",
      "line": 42,
      "evidence": "->whereRaw('email = ' . $email)",
      "recommendation": "Avoid raw SQL with user input. Use parameter binding/query builder."
    }
  ],
  "metadata": {
    "scannedPath": "/absolute/path/to/laravel-project",
    "engine": "Laraguard MCP",
    "version": "3.0.0",
    "timestamp": "2025-01-01T00:00:00.000Z",
    "durationMs": 312
  }
}

Architecture

src/
├── index.ts      — MCP server bootstrap and tool registration
├── config.ts     — Environment variable loading and validation
├── security.ts   — Path allowlist enforcement and secret redaction
├── files.ts      — Safe file enumeration and reading
├── tools.ts      — Audit tool implementations
├── reports.ts    — Report aggregation and severity summarization
└── types.ts      — Domain types (Finding, AuditReport, Severity, etc.)

Runtime stack:

Component	Technology
Runtime	Node.js 20+
Language	TypeScript 5.x
Protocol	Model Context Protocol (MCP)
Transport	`stdio`
Schema validation	Zod
MCP SDK	`@modelcontextprotocol/sdk`

Requirements

Node.js 20 or higher
npm 10 or higher

Verify your environment:

node -v
npm -v

Installation

Clone the repository and install dependencies:

git clone https://github.com/ecr17dev/Laraguard-MCP.git
cd "Laraguard MCP"
npm install

Configuration

Copy the example environment file and customise it:

cp .env.example .env

Environment Variables

Variable	Default	Description
`MCP_BASE_PATH`	—	Single allowed root path for project scanning.
`MCP_BASE_PATHS`	—	Comma-separated list of allowed root paths. Takes precedence over `MCP_BASE_PATH`.
`MCP_MAX_FILES`	`5000`	Maximum number of files to enumerate per scan.
`MCP_MAX_FILE_SIZE_BYTES`	`300000`	Maximum file size (in bytes) to read per file.
`MCP_TIMEOUT_SECONDS`	`30`	Logical timeout for audit operations.

Priority order: MCP_BASE_PATHS → MCP_BASE_PATH → current working directory.

Example `.env`

# Allow scanning two project roots
MCP_BASE_PATHS="/Users/yourname/projects/my-laravel-app,/srv/workspaces/api"

# Scan limits
MCP_MAX_FILES=5000
MCP_MAX_FILE_SIZE_BYTES=300000
MCP_TIMEOUT_SECONDS=30

Development

Available Scripts

Command	Description
`npm run dev`	Runs the MCP server directly from TypeScript source using `tsx` (recommended for development)
`npm run build`	Compiles TypeScript to `dist/`
`npm run start`	Runs the compiled server from `dist/index.js`
`npm run check`	Type-checks the project without emitting output

Running in Development Mode

npm run dev

Building for Production

npm run check   # Validate types first
npm run build   # Emit to dist/
npm run start   # Run compiled output

Integration with MCP Clients

Generic MCP Configuration (JSON)

Add the following to your MCP client's configuration file, replacing the path with the absolute path to your installation:

{
  "mcpServers": {
    "laraguard": {
      "command": "node",
      "args": ["/absolute/path/to/Laraguard MCP/dist/index.js"],
      "env": {
        "MCP_BASE_PATHS": "/absolute/path/to/your-laravel-project"
      }
    }
  }
}

Using Development Mode (tsx)

If you prefer to run without building first:

{
  "mcpServers": {
    "laraguard": {
      "command": "npx",
      "args": ["tsx", "/absolute/path/to/Laraguard MCP/src/index.ts"],
      "env": {
        "MCP_BASE_PATHS": "/absolute/path/to/your-laravel-project"
      }
    }
  }
}

Cursor IDE

Open Settings → MCP and paste the JSON block above. Cursor will detect the server on the next reload.

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) and add the laraguard entry under mcpServers.

Tool Usage Reference

`project_info`

{ "path": "/absolute/path/to/laravel-project" }

Returns basic project metadata without performing any security checks. Use it to confirm the target is a valid Laravel project and inspect framework and PHP version constraints before auditing.

`dependency_audit`

{ "path": "/absolute/path/to/laravel-project" }

Parses composer.lock, extracts all locked package names and versions, and queries the OSV.dev batch API for known CVEs. Each vulnerability is returned as a finding with:

CVE/GHSA identifier and summary
Severity (mapped from CVSS score)
Affected package version and recommended fix version
Direct link to the advisory page

`config_audit`

{ "path": "/absolute/path/to/laravel-project" }

Check	File	Severity
`APP_DEBUG=true`	`.env`	High
`APP_ENV=local`	`.env`	Medium
`APP_KEY=` (empty)	`.env`	Critical
`SESSION_SECURE_COOKIE=false`	`.env`	Medium
Wildcard CORS origin (`'*'`)	`config/cors.php`	Medium

`code_scan`

{ "path": "/absolute/path/to/laravel-project" }

Performs line-by-line static analysis across all PHP files. Returns every matching finding with file path, line number, and evidence snippet. See the Code Scan — Detected Patterns table above for the full rule set.

`blade_scan`

{ "path": "/absolute/path/to/laravel-project" }

Scans all .blade.php files under resources/views/ for XSS-prone output patterns:

Check	Severity
`{!! $variable !!}` — unescaped variable	High
`{!! request( !!}` / `{!! old( !!}` — raw user input	Critical
`echo $_GET` / `echo $_POST` in blade PHP blocks	High

`route_audit`

{ "path": "/absolute/path/to/laravel-project" }

Reads routes/web.php, routes/api.php, and app/Http/Middleware/VerifyCsrfToken.php:

Check	File	Severity
Admin/dashboard route without `auth` middleware	`routes/web.php`	Critical
API route without `auth:sanctum` / `auth:api`	`routes/api.php`	High
Login/register route without `throttle` middleware	Route files	Medium
Wildcard pattern in `VerifyCsrfToken::$except`	`VerifyCsrfToken.php`	High

`attack_simulate`

{
  "path": "/absolute/path/to/laravel-project",
  "baseUrl": "http://localhost:8000"
}

⚠️ Only use against local or staging environments. Never run against production.

Fires 6 live HTTP probes against the running application:

Probe	Method & Endpoint	What it Tests
`error_disclosure`	`GET /__invalid_route__`	Framework/stack-trace info leakage
`sql_injection_login`	`POST /login` with SQLi payload	SQL injection in login form
`reflected_xss`	`GET /search?q=<script>…`	Reflected XSS in search/query params
`csrf_not_enforced`	`POST /login` without CSRF token	CSRF token enforcement (expects HTTP 419)
`auth_bypass`	`GET /api/user` without auth header	Unauthenticated access to protected API
`rate_limit`	10× rapid `POST /login`	Brute-force rate limiting (expects HTTP 429)

The report includes a probes metadata array with the status code, duration, and triggered state for every probe.

`full_audit`

{ "path": "/absolute/path/to/laravel-project" }

Runs dependency_audit, config_audit, code_scan, blade_scan, and route_audit in parallel and merges all findings into a single consolidated report. The metadata includes per-section summaries.

Security Design

Laraguard MCP implements the following controls to ensure it operates safely even when handling untrusted project paths:

Strict path allowlisting — all file access is validated against MCP_BASE_PATHS / MCP_BASE_PATH; path traversal attempts are rejected immediately.
File count limit — configurable cap (MCP_MAX_FILES) prevents runaway enumeration on large monorepos.
File size limit — configurable cap (MCP_MAX_FILE_SIZE_BYTES) prevents memory exhaustion from binary or generated files.
Directory and extension exclusions — vendor/, node_modules/, .git/, and binary file types are excluded from scans.
Secret redaction — sensitive values (passwords, tokens, keys) are masked in textual output before being returned to the MCP client.
Attack simulation guard — attack_simulate always targets only the explicitly provided baseUrl; no automated discovery or production detection is performed.

Important Notes

Laraguard MCP analyses a Laravel project as an external auditor — the Laravel application itself does not need to be running for static tools.
attack_simulate requires the application to be running and should never target production.
The server is framework-agnostic at the transport level: any client that supports MCP stdio can use it.
All findings are informational. Always combine automated scanning with manual code review and dedicated DAST/SAST tooling (OWASP ZAP, Burp Suite) for production security assessments.

License

This project is licensed under the MIT License. See LICENSE for details.

Available Tools

8 tools

attack_simulateA

Run active HTTP security probes against a running Laravel application. Probes: error/debug disclosure, SQL injection on /login, reflected XSS, CSRF enforcement, auth bypass on /api/user, and brute-force rate limiting. WARNING: only use against local or staging environments — never production.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path of the target Laravel project
`baseUrl`	Yes	Base URL of the running Laravel application (e.g. http://localhost:8000)

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden and does well: it discloses the tool's active, potentially intrusive nature ('active HTTP security probes'), lists specific attack types, and includes a critical warning about environment restrictions. It doesn't detail output format or error handling, but covers key behavioral risks adequately.

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?

Two sentences with zero waste: the first explains purpose and scope, the second provides critical usage warning. Every element earns its place, and the warning is appropriately front-loaded for safety.

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?

For a complex, potentially destructive tool with no annotations and no output schema, the description is strong: it explains what the tool does, lists probe types, and gives critical environment warnings. It doesn't describe output format or error cases, but given the context, it's sufficiently complete for safe use.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters (path and baseUrl). The description doesn't add any parameter-specific details beyond what the schema provides, such as examples for path or clarifications on baseUrl usage. Baseline 3 is appropriate when schema does the heavy lifting.

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 verb ('Run active HTTP security probes') and resource ('against a running Laravel application'), with specific examples of probes (error/debug disclosure, SQL injection, etc.). It distinguishes from siblings like blade_scan or code_scan by focusing on active HTTP attacks rather than static analysis.

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

Usage Guidelines5/5

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

Explicit guidance is provided: 'only use against local or staging environments — never production.' This clearly defines when to use (non-production) and when not to use (production), addressing critical safety concerns without needing to reference specific alternatives.

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

blade_scanA

Scan Laravel Blade templates in resources/views/ for XSS vulnerabilities. Detects unescaped output ({!! !!}), raw user input rendering, and unsafe PHP echo in templates.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path of the target Laravel project

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 carries the full burden. It describes what the tool detects (unescaped output, raw user input, unsafe PHP echo) but doesn't disclose behavioral traits like whether it's read-only, what permissions are needed, how results are returned, or if it modifies files. For a security scanning tool with zero annotation coverage, this leaves significant gaps.

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 appropriately sized and front-loaded, with two sentences that efficiently convey the tool's purpose and detection scope without unnecessary details. Every sentence earns its place by adding value.

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 moderate complexity (security scanning with one parameter) and lack of annotations or output schema, the description is partially complete. It covers what the tool does and what it detects but misses behavioral context like result format, error handling, or integration with siblings. It's adequate but has clear gaps for a tool with no structured safety or output information.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the single parameter 'path' as an absolute path to the Laravel project. The description doesn't add any parameter-specific semantics beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.

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 tool's purpose with specific verbs ('scan', 'detects') and resources ('Laravel Blade templates in resources/views/'), and distinguishes it from siblings by specifying it focuses on XSS vulnerabilities in Blade templates rather than general code scanning or other audit types.

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?

The description implies usage context (scanning for XSS vulnerabilities in Laravel Blade templates) but doesn't explicitly state when to use this tool versus alternatives like 'code_scan' or 'full_audit'. No exclusions or prerequisites are mentioned.

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

code_scanA

Run static pattern analysis across all PHP source files. Detects SQL injection, RCE risks (eval/shell_exec/exec/system), unsafe unserialize, hardcoded credentials, weak cryptography (MD5/SHA1), mass assignment, path traversal, and LFI risks.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path of the target Laravel project

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 carries the full burden of behavioral disclosure. It describes what the tool does (static analysis for specific vulnerabilities) but lacks details on behavioral traits such as execution time, output format, error handling, or any side effects (e.g., whether it modifies files). This is a significant gap for a 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.

Conciseness5/5

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

The description is appropriately sized and front-loaded, starting with the core action and resource, followed by a concise list of detected risks. Every sentence earns its place by providing essential information without redundancy or unnecessary details.

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 complexity (static analysis with multiple vulnerability checks) and lack of annotations and output schema, the description is incomplete. It covers the purpose and scope but misses critical behavioral and output details. However, it does provide enough context for basic usage, making it minimally viable but with clear gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the single parameter ('path') with its type and description. The description does not add any meaning beyond what the schema provides, as it does not mention the parameter or elaborate on its usage. Baseline 3 is appropriate when the schema does the heavy lifting.

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 tool's purpose with specific verbs ('Run static pattern analysis') and resources ('across all PHP source files'), and it distinguishes itself from siblings by listing the specific vulnerability types it detects (SQL injection, RCE risks, etc.), which none of the sibling tools explicitly mention in their names or likely 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?

The description implies usage for scanning PHP files in a Laravel project (based on the input schema), but it does not explicitly state when to use this tool versus alternatives like 'blade_scan' or 'full_audit'. There is no guidance on exclusions or prerequisites, leaving the agent to infer context from the tool's name and description alone.

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

config_auditC

Audit risky Laravel environment and configuration settings: APP_DEBUG, APP_ENV, APP_KEY, SESSION_SECURE_COOKIE, and CORS wildcard origins.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path of the target Laravel project

TDQS

C2.9/5.0

Behavior2/5

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 'audit' and 'risky' settings, implying a read-only analysis without mutations, but doesn't specify output format, error handling, or performance characteristics. For a security-focused tool, this is a significant gap in transparency about what the audit entails and how results are presented.

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, efficient sentence that front-loads the purpose (audit risky settings) and lists specific configurations to check. Every word earns its place with zero waste, making it highly concise and well-structured for quick comprehension.

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

Completeness2/5

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

Given the complexity of security auditing and lack of annotations or output schema, the description is incomplete. It doesn't explain what constitutes 'risky' settings, how findings are reported, or what the agent should expect as a result. For a tool with no structured behavioral data, this leaves critical gaps in understanding its operation and outcomes.

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

Parameters3/5

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

Schema description coverage is 100%, with the single parameter 'path' documented in the schema as 'Absolute path of the target Laravel project'. The description adds no additional parameter semantics beyond implying the path should point to a Laravel project for config auditing. This meets the baseline of 3 since the schema adequately covers the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool audits specific Laravel configuration settings (APP_DEBUG, APP_ENV, APP_KEY, SESSION_SECURE_COOKIE, CORS wildcard origins) for risk assessment. It distinguishes itself from siblings like 'dependency_audit' or 'code_scan' by focusing on environment/config auditing rather than code or dependencies. However, it doesn't explicitly mention the verb 'audit' in relation to the resource 'configuration settings' beyond the tool name.

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 like 'full_audit' (which might include config auditing) or other siblings. It implies usage for Laravel projects with configuration concerns but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer based on tool names alone.

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

dependency_auditA

Audit Composer dependencies against the OSV.dev vulnerability advisory database. Parses composer.lock and reports CVEs with severity and fix versions.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path of the target Laravel project

TDQS

A3.7/5.0

Behavior3/5

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 describes the tool's core behavior (parsing composer.lock, querying OSV.dev, reporting CVEs) but lacks important operational details like whether it requires network access, what format the output takes, whether it modifies files, error handling, or performance characteristics. The description provides basic functionality but misses key behavioral context.

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 perfectly concise - two sentences that efficiently convey the tool's purpose, scope, and output. Every word earns its place with no redundancy or unnecessary elaboration. The information is front-loaded with the core functionality stated immediately.

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 no annotations and no output schema, the description provides adequate basic functionality but lacks completeness. For a security auditing tool, important contextual information is missing: output format, error conditions, network requirements, authentication needs, rate limits, or what happens when vulnerabilities are found. The description covers what the tool does but not how it behaves operationally.

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

Parameters3/5

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

The schema description coverage is 100%, so the schema already fully documents the single 'path' parameter. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., format examples, validation rules, or edge cases). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.

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 tool's purpose with specific verbs ('audit', 'parses', 'reports') and resources ('Composer dependencies', 'composer.lock', 'OSV.dev vulnerability advisory database', 'CVEs'). It distinguishes itself from siblings by focusing specifically on dependency vulnerability checking rather than general code scanning or configuration auditing.

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?

The description implies usage context (checking Laravel project dependencies for vulnerabilities) but doesn't explicitly state when to use this tool versus alternatives like 'code_scan' or 'full_audit'. No guidance is provided about prerequisites, limitations, or when this tool would be preferred over other audit tools in the sibling list.

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

full_auditA

Run all static audits in parallel: dependency CVE check (OSV.dev), environment config, PHP code scan, Blade XSS scan, and route/middleware audit. Returns a single consolidated report with per-section summaries.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path of the target Laravel project

TDQS

A4/5.0

Behavior3/5

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 clearly states the tool runs audits in parallel and returns a consolidated report, which is valuable context. However, it doesn't mention execution time, resource requirements, error handling, or whether it modifies the target project, leaving some behavioral aspects unclear.

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 efficiently structured in two sentences: the first specifies the action and audits performed, and the second describes the output. Every word contributes essential information with no redundancy or fluff, making it highly concise and front-loaded.

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?

Given the tool's complexity (running multiple audits) and lack of annotations/output schema, the description does a good job explaining what it does and what it returns. However, it could be more complete by detailing the report structure or potential side effects, which would help an agent understand the full context better.

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

Parameters3/5

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

The schema description coverage is 100%, with the single parameter 'path' well-documented in the schema. The description doesn't add any additional semantic context about the parameter beyond what the schema provides (e.g., examples of valid paths or constraints), so it meets the baseline for high schema coverage.

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 tool's purpose with specific verbs ('Run all static audits in parallel') and enumerates the exact types of audits performed (dependency CVE check, environment config, PHP code scan, Blade XSS scan, route/middleware audit). It distinguishes itself from sibling tools by being comprehensive rather than focused on individual audit types.

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

Usage Guidelines4/5

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

The description implies this tool should be used when a comprehensive audit is needed, as it runs 'all static audits in parallel.' However, it doesn't explicitly state when to use this versus the individual audit sibling tools (like blade_scan or dependency_audit), nor does it mention any prerequisites or exclusions for usage.

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

project_infoA

Return metadata for a Laravel project: composer constraints, framework detection, PHP version.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path of the target Laravel project

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 carries the full burden of behavioral disclosure. It states the tool returns metadata, which implies a read-only operation, but does not specify whether it requires specific permissions, what happens if the path is invalid, or any rate limits. The description adds minimal behavioral context beyond the basic purpose, leaving gaps in understanding how the tool behaves in edge cases.

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, efficient sentence that front-loads the purpose ('Return metadata for a Laravel project') and lists specific metadata types without unnecessary words. Every part of the description earns its place by clarifying the tool's function, making it highly concise and well-structured.

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 low complexity (single parameter, no annotations, no output schema), the description is complete enough for basic understanding. It specifies the resource and metadata types, but lacks details on output format, error handling, or integration with sibling tools. This makes it adequate but not fully comprehensive for an agent to use the tool confidently in all scenarios.

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

Parameters3/5

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

The input schema has 100% description coverage, with the single parameter 'path' documented as 'Absolute path of the target Laravel project'. The description does not add any additional meaning beyond this, such as format examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract from the schema's information.

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 specific action ('Return metadata') and resource ('Laravel project'), with explicit details about what metadata is returned ('composer constraints, framework detection, PHP version'). It distinguishes from sibling tools like 'code_scan' or 'dependency_audit' by focusing on project-level metadata rather than security or dependency analysis.

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?

The description implies usage context through the resource specification ('Laravel project'), suggesting it should be used when metadata about a Laravel project is needed. However, it does not explicitly state when to use this tool versus alternatives like 'config_audit' or 'full_audit', nor does it provide exclusions or prerequisites, leaving some ambiguity in tool selection.

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

route_auditA

Audit Laravel route files (routes/web.php, routes/api.php) for security misconfigurations. Detects admin routes without auth middleware, API routes without authentication, login routes without throttle, and CSRF exception wildcards in VerifyCsrfToken.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path of the target Laravel project

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only partially discloses behavioral traits. It specifies what security issues are detected (admin routes without auth, API routes without authentication, etc.), but doesn't mention output format, whether it's read-only/destructive, permission requirements, or error handling. The description provides some behavioral context but leaves significant gaps.

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 efficiently structured in a single sentence that front-loads the core purpose and follows with specific detection examples. Every element earns its place with zero wasted words, making it immediately clear what the tool does.

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 security-focused nature and lack of annotations/output schema, the description provides adequate basic context about what's being audited and what issues are detected. However, for a security audit tool with no structured behavioral annotations, it should ideally mention output format, severity levels, or how results are presented to be more complete.

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

Parameters3/5

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

Schema description coverage is 100% with only one parameter ('path'), so the schema already documents it adequately. The description doesn't add any parameter-specific information beyond what the schema provides, such as path format examples or validation details. Baseline 3 is appropriate when schema does the heavy lifting.

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 specific action ('Audit Laravel route files') and resource ('routes/web.php, routes/api.php'), with detailed scope ('for security misconfigurations'). It distinguishes from siblings by focusing specifically on route security rather than general scanning or other audit types.

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?

The description implies usage context (Laravel projects needing security review) but doesn't explicitly state when to use this tool versus alternatives like 'config_audit' or 'full_audit'. No guidance is provided about prerequisites, exclusions, or comparative advantages with sibling tools.

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

Install Server

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

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: attack_simulate runs active probes, blade_scan focuses on Blade templates, code_scan analyzes PHP source, config_audit checks environment settings, dependency_audit reviews Composer dependencies, full_audit consolidates other audits, project_info provides metadata, and route_audit examines route configurations. The descriptions explicitly differentiate their scopes, eliminating any ambiguity.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with clear verb_noun structures: attack_simulate, blade_scan, code_scan, config_audit, dependency_audit, full_audit, project_info, and route_audit. The naming is predictable and readable throughout, with no deviations in style or convention.

Tool Count5/5

With 8 tools, the set is well-scoped for Laravel security auditing, covering active testing, static analysis, dependency checks, configuration reviews, and metadata. Each tool earns its place by addressing a specific aspect of security, avoiding redundancy while providing comprehensive coverage for the domain.

Completeness5/5

The tool surface offers complete coverage for Laravel security auditing: it includes active simulation (attack_simulate), static analysis (code_scan, blade_scan), configuration auditing (config_audit, route_audit), dependency management (dependency_audit), a consolidated audit option (full_audit), and project metadata (project_info). There are no obvious gaps, and the tools support a full security assessment workflow from start to finish.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
Frogeye Security Scanner A
io.github.frogeye-ai
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security Penetration Testing
2
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
Android Security Analyzer A
io.github.ako2345
MCP server for static security analysis of Android source code
Security Code Analysis Testing & QA Tools
422

Related MCP Servers

Adversary MCP Server
Penetration Testing Code Analysis Developer Tools
brettbergin
A
license
A
quality
D
maintenance
A security-focused server that integrates with Cursor IDE to provide real-time vulnerability detection, exploit generation, and security insights during software development.
Updated a year ago (2025-08-26 18:40 UTC)
7
2
MIT
DevSecOps MCP Server
Testing & QA Tools Security Developer Tools
JesusDavidQuarksoft
A
license
B
quality
D
maintenance
An MCP server that integrates SAST, DAST, and SCA security tools to enable AI-driven vulnerability scanning and automated security reporting. It allows AI assistants to execute and analyze results from tools like Semgrep, OWASP ZAP, and Trivy within a DevSecOps workflow.
Updated 7 months ago (2026-02-04 02:27 UTC)
6
MIT
VulScan-MCP
Penetration Testing Security Developer Tools
abhishekrai43
F
license
Not graded
quality
D
maintenance
MCP server that scans project dependencies for security vulnerabilities (CVEs) and provides fix instructions directly in VS Code via Copilot.
Updated 10 months ago (2025-11-09 04:50 UTC)
3
Smart Contract Security
Blockchain Security Code Analysis
uitkhoanna
F
license
Not graded
quality
C
maintenance
An MCP server that statically audits Solidity smart contracts for common vulnerabilities like reentrancy and access control, enabling developers to identify and fix security issues via natural language.
Updated 3 months ago (2026-06-13 18:46 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ecr17dev/Laraguard-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Laraguard MCP

Overview

Features

MCP Tools

Code Scan — Detected Patterns

Audit Report Schema

Architecture

Requirements

Installation

Configuration

Environment Variables

Example .env

Development

Available Scripts

Running in Development Mode

Building for Production

Integration with MCP Clients

Generic MCP Configuration (JSON)

Using Development Mode (tsx)

Cursor IDE

Claude Desktop

Tool Usage Reference

project_info

dependency_audit

config_audit

code_scan

blade_scan

route_audit

attack_simulate

full_audit

Security Design

Important Notes

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Example `.env`

`project_info`

`dependency_audit`

`config_audit`

`code_scan`

`blade_scan`

`route_audit`

`attack_simulate`

`full_audit`