Laraguard MCP

by ecr17dev

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.0.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.
Average 3.6/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Laraguard-MCP MCP server](https://glama.ai/mcp/servers/ecr17dev/Laraguard-MCP/badges/card.svg)](https://glama.ai/mcp/servers/ecr17dev/Laraguard-MCP)

Score Badge

Copy to your README.md:

[![Laraguard-MCP MCP server](https://glama.ai/mcp/servers/ecr17dev/Laraguard-MCP/badges/score.svg)](https://glama.ai/mcp/servers/ecr17dev/Laraguard-MCP)

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