Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Vulnerability Reporting Create a vulnerability report for SQL injection on https://example.com/login"
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.
Professional vulnerability report generator for security assessments. This MCP server creates standardized, well-formatted security reports following industry best practices.
This MCP does not use pre-written templates. Instead, the AI (Claude) generates all report content based on the specific vulnerability instance. The report structure follows the template format from /Users/orhanyildirim/Desktop/mcp-browser-injection-extented/report.md, but the content is dynamically created for each unique finding.
✅ Vulnerability Overview (educational description of the vulnerability type)
✅ Specific Findings (detailed analysis of this instance)
✅ Steps to Reproduce (customized for the target application)
✅ Recommendations (actionable remediation guidance)
✅ Impacts (business and technical impact analysis)
✅ References (OWASP, CWE, security resources)
Related MCP server: VulneraMCP
AI-Powered Content Generation: Claude generates comprehensive, contextual report content for each vulnerability
Template Structure Compliance: Maintains the exact format from your report template
Flexible Content: Adapts to different vulnerability types, severities, and application contexts
CVSS Scoring: Automated CVSS v3.1 score and vector calculation
Evidence Management: Support for screenshots, HTTP requests/responses, PoC code
Markdown Export: Professional markdown reports ready for bug bounty submissions or pentest deliverables
Reference Database: Fallback to default OWASP/CWE references if AI doesn't provide custom ones
npm install
npm run buildAdd to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"browser-automation": {
"command": "node",
"args": ["/Users/your-username/Desktop/mcp-browser-injection-extented/dist/index.js"]
},
"vulnerability-reporting": {
"command": "node",
"args": ["/Users/your-username/Desktop/mcp-vulnerability-reporting/dist/index.js"]
}
}
}create_vulnerability_reportCreates a new vulnerability report with AI-generated content following the template structure.
IMPORTANT: The AI must generate all content sections. This tool does NOT use pre-written templates.
Parameters:
vulnerability: Object containing vulnerability details
type: Vulnerability type (e.g., SQL_INJECTION, XSS, SSTI)
severity: Severity level (Critical, High, Medium, Low, Informational)
url: Target URL
parameter: Vulnerable parameter name
payload: Successful payload
affectedEndpoint (optional): Specific endpoint
method (optional): HTTP method
overview: AI-GENERATED - General description of the vulnerability type (what is it, how does it work, why is it dangerous)
findings: Object with specific findings
specificDescription: AI-GENERATED - Detailed description of this specific instance
detectedBehaviors: Array of observed behaviors (from testing)
confidence: Detection confidence level
stepsToReproduce: AI-GENERATED - Array of step-by-step reproduction instructions
recommendations: AI-GENERATED - Array of remediation recommendations with format:
"- **Bold Header**: Detailed explanation"
impacts: AI-GENERATED - Array of potential impacts with format:
"- **Bold Header**: What could happen"
references (optional): Array of security references
If not provided, template defaults are used
Returns: Report ID for future operations
add_evidence_to_reportAdds evidence to an existing report.
Parameters:
reportId: Target report ID
evidenceType: Type of evidence (screenshot, request, response, poc, code)
content: Evidence content or file path
description: Evidence description
calculate_cvss_scoreCalculates CVSS score and vector for a report.
Parameters:
reportId: Target report ID
export_reportExports report as markdown file.
Parameters:
reportId: Report ID to export
outputPath: Output file path
list_reportsLists all generated reports.
get_report_previewPreviews report in markdown format.
Parameters:
reportId: Report ID to preview
get_report_templateGets the exact report template format that AI should follow. Use this before creating reports to understand the required structure.
Parameters: None
Returns: The template with detailed formatting instructions for AI content generation
Here's how to use both MCPs together. Claude generates all report content:
User: "Test https://vulnerable-site.com/login for SQL injection and create a professional report"
Claude uses Browser MCP:
1. browser_navigate({ url: "https://vulnerable-site.com/login" })
2. browser_test_payload({
targetSelector: "#username",
payload: "' OR 1=1--",
submitSelector: "#login"
})
// Returns: { isVulnerable: true, confidence: "high", detectedBehaviors: [...] }
3. browser_screenshot({ path: "./evidence/sqli-bypass.png" })
Claude uses Reporting MCP (AI GENERATES ALL CONTENT):
4. get_report_template()
// Returns: Template with exact structure and formatting requirements
5. create_vulnerability_report({
vulnerability: {
type: "SQL_INJECTION",
severity: "Critical",
url: "https://vulnerable-site.com/login",
parameter: "username",
payload: "' OR 1=1--",
method: "POST"
},
// AI WRITES THIS OVERVIEW:
overview: "SQL Injection is a code injection technique that exploits security vulnerabilities in an application's database layer. This vulnerability occurs when user-supplied input is incorporated into SQL queries without proper sanitization...",
findings: {
// AI WRITES THIS SPECIFIC DESCRIPTION:
specificDescription: "The login form at /login endpoint is vulnerable to SQL injection via the username parameter. The application directly concatenates user input into SQL queries without using parameterized statements...",
detectedBehaviors: ["SQL_ERROR_MESSAGE", "AUTHENTICATION_BYPASS"],
confidence: "high"
},
// AI GENERATES THESE STEPS:
stepsToReproduce: [
"Navigate to https://vulnerable-site.com/login",
"In the username field, enter: ' OR 1=1--",
"In the password field, enter any value",
"Click the login button",
"Observe successful authentication bypass",
"Verify by checking session cookie"
],
// AI WRITES THESE RECOMMENDATIONS:
recommendations: [
"- **Use Parameterized Queries**: Implement prepared statements with parameterized queries for all database interactions...",
"- **Input Validation**: Implement strict server-side input validation...",
"- **Principle of Least Privilege**: Configure database accounts with minimal permissions..."
],
// AI WRITES THESE IMPACTS:
impacts: [
"- **Complete Authentication Bypass**: An attacker can bypass the login mechanism entirely...",
"- **Sensitive Data Exfiltration**: Using UNION-based attacks, attackers can extract database contents...",
"- **Database Manipulation**: Attackers could modify or delete records..."
]
})
6. add_evidence_to_report({
reportId: "vuln_report_xxx",
evidenceType: "screenshot",
content: "./evidence/sqli-bypass.png",
description: "Authentication Bypass - Successfully logged in as admin"
})
7. calculate_cvss_score({ reportId: "vuln_report_xxx" })
8. export_report({
reportId: "vuln_report_xxx",
outputPath: "./reports/sql-injection-login-bypass.md"
})See USAGE_EXAMPLE.md for a complete detailed example.
Reports follow the exact template structure from /Users/orhanyildirim/Desktop/mcp-browser-injection-extented/report.md:
## Vulnerability Overview
[AI-generated general description of vulnerability type]
### Finding Details
[AI-generated specific findings for this instance]
### Steps To Reproduce
1. [AI-generated step]
2. [AI-generated step]
...
## Recommendations
To address this finding, implement the following:
[AI-generated recommendations with bold headers]
## References
See the following for more information:
[AI-generated or template default references]
## Impacts
If not addressed, this finding could lead to the following:
[AI-generated impacts with bold headers]Template Loading: MCP reads report.md template from its directory
AI Reads Template: Use get_report_template() to see the exact structure required
Template Structure: The markdown format is fixed and matches your report template exactly
AI Content: Claude generates all descriptive content based on:
The specific vulnerability found during testing
Security best practices and industry standards
Context from the target application
Severity and confidence levels
Template format guidelines
Flexibility: Content adapts to different vulnerability types, applications, and contexts
Fallback References: If AI doesn't provide custom references, the vulnerability database provides defaults for common types (SQL Injection, XSS, SSTI, Command Injection, NoSQL, LDAP, XXE)
# Run in development mode
npm run dev
# Build for production
npm run build
# Run production build
npm startindex.ts: Main MCP server implementation
vulnerability-db.ts: Vulnerability knowledge base with templates
dist/: Compiled JavaScript output
This MCP is designed to work seamlessly with the mcp-browser-injection-extended MCP server. The browser MCP handles:
Automated vulnerability testing
Payload generation and testing
Evidence collection (screenshots, HTTP responses)
The reporting MCP then transforms those findings into professional security reports.
MIT
Contributions welcome! Please submit issues and pull requests.
Add evidence (screenshots, requests, responses, PoC code) to an existing report
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Evidence content (for request/response/code) or file path (for screenshots) | |
| reportId | Yes | The report ID to add evidence to | |
| description | Yes | Description of this evidence | |
| evidenceType | Yes | Type of evidence being added |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states that evidence is added, but doesn't disclose side effects (append vs. replace), required existence of the report, error handling, or permissions. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and resources. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with fully documented schema (4/4 params described) and no output schema, the description is sufficient. It establishes purpose and the report existence constraint. Missing behavioral details are covered by the transparency score, so this dimension remains adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage, so the baseline is 3. The description adds no meaningful detail beyond paraphrasing the evidence types already in the enum. It doesn't clarify format constraints or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' with a clear resource 'evidence' and target 'existing report'. It lists the types of evidence (screenshots, requests, responses, PoC code), which distinguishes it from sibling tools like create_vulnerability_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing report' clearly indicates this tool is for modifying an existing report, not creating one. While it doesn't explicitly name alternatives, the context is clear and would guide selection away from creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate CVSS score and vector for a report
| Name | Required | Description | Default |
|---|---|---|---|
| reportId | Yes | The report ID to calculate CVSS for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether it modifies the report, what inputs are expected beyond reportId, or what the output format might be. The calculation behavior and side effects are entirely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose without unnecessary words or repetition. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and no nested objects, the description omits important details such as the return format (score and vector values) and any behaviors like validation or error conditions. With no output schema and no annotations, the description should compensate but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with reportId described as 'The report ID to calculate CVSS for.' The description adds no extra meaning beyond this, but the schema is already clear. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates a CVSS score and vector for a report, using a specific verb ('Calculate') and resource ('CVSS score and vector'). This distinguishes it from sibling tools like create_vulnerability_report or export_report, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only says 'for a report' but does not elaborate on scenarios or why a user might choose this over other report-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a professional vulnerability report following the standardized template format.
IMPORTANT FOR AI - BE CONCISE AND BRIEF:
OVERVIEW: 2-3 sentences explaining what this vulnerability type is and why it's dangerous
FINDINGS: 2-3 sentences describing what you found in this specific instance
RECOMMENDATIONS: 3-4 brief bullet points with bold headers (e.g., "- Input Validation: Sanitize all user inputs")
IMPACTS: 2-3 brief bullet points with bold headers (e.g., "- Data Breach: Attackers could access sensitive data")
REFERENCES (optional): 2-3 relevant OWASP/CWE links
KEEP IT SHORT - Focus on key points only. No long paragraphs.
| Name | Required | Description | Default |
|---|---|---|---|
| impacts | Yes | AI-GENERATED (2-3 ITEMS): Brief impact statements. Format: '- **Header**: One sentence'. Keep each under 20 words. | |
| findings | Yes | ||
| overview | Yes | AI-GENERATED (2-3 SENTENCES): Brief explanation of what this vulnerability type is and why it's dangerous. Keep it concise. | |
| references | No | AI-GENERATED (optional): Relevant references (OWASP, CWE, PortSwigger, etc.). If not provided, template defaults will be used. | |
| vulnerability | Yes | ||
| recommendations | Yes | AI-GENERATED (3-4 ITEMS): Brief remediation steps. Format: '- **Header**: One sentence explanation'. Keep each under 20 words. | |
| stepsToReproduce | Yes | AI-GENERATED (4-6 BRIEF STEPS): Short, clear reproduction steps. One sentence per step. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does disclose that the AI should be concise and brief, and provides a template structure for generated fields, but it does not state whether the tool persists data, returns a report ID, or requires authentication. This leaves the agent without key behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized and uses a numbered list for clarity. However, it duplicates much of the information already in the parameter schema, and the 'IMPORTANT FOR AI' repetition could be trimmed. It is structured but not maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, nested objects, no output schema), the description omits important contextual details such as return value, error conditions, or how it relates to the report lifecycle. It covers the content format for AI-generated fields but leaves the overall workflow unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, and many parameter descriptions already contain length/format constraints. The main description largely reiterates these constraints (e.g., '2-3 sentences', '3-4 brief bullet points') without adding new syntax or type information. Thus it provides minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb-action: 'Create a professional vulnerability report following the standardized template format.' This clearly identifies the tool's purpose and distinguishes it from sibling tools like list_reports or export_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing browser_test_payload results), nor does it differentiate from sibling tools like add_evidence_to_report or get_report_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export vulnerability report as markdown file
| Name | Required | Description | Default |
|---|---|---|---|
| reportId | Yes | The report ID to export | |
| outputPath | Yes | Output file path (e.g., './reports/sqli-report.md') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It only states 'export', which implies a file write, but does not mention side effects like whether it overwrites existing files, requires specific permissions, or creates directories. There is also no mention of return values or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately says what the tool does. It is front-loaded and contains no filler words, making it highly concise and structured effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, the description is minimally viable. However, it lacks behavioral context (side effects, permissions) and does not differentiate from sibling tools, leaving the agent to infer when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (reportId and outputPath) having descriptive meanings. The description itself adds no parameter details, but the schema is sufficient, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'export' with a clear resource ('vulnerability report') and format ('as markdown file'). This clearly distinguishes it from sibling tools like create_vulnerability_report, get_report_preview, and get_report_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user wants to save a report to a file. However, it does not explicitly state when to use this tool over alternatives like get_report_preview or get_report_template, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a preview of the generated markdown report
| Name | Required | Description | Default |
|---|---|---|---|
| reportId | Yes | The report ID to preview |
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 only states the action and resource without describing what the preview includes (e.g., truncated, rendered, full report) or any side effects. This is insufficient for an agent to predict the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the action and resource effectively, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description is under-specified. It fails to explain what a 'preview' entails (e.g., snippet, full report, rendered view) and how it differs from export_report. The presence of sibling export_report makes this distinction critical, yet it's absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single parameter reportId with 'The report ID to preview'. The description adds no extra semantic context beyond what's in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action 'get' and resource 'preview of the generated markdown report'. It is distinct enough from siblings like export_report and list_reports, though it doesn't explicitly highlight the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like export_report or get_report_template. It neither states typical use cases nor exclusions, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the report template format that should be followed. Use this to understand the exact structure and formatting requirements for vulnerability reports.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates the tool retrieves a template format and mentions 'exact structure and formatting requirements,' which gives some insight into what the agent will receive. However, it does not specify the actual return format, whether it's a simple read operation, or any details about the template's contents, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the core purpose front-loaded in the first sentence. It wastes no words, clearly stating what the tool does and why to use it. It is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description provides sufficient context for the agent to understand its role. It explains that the tool provides the template format to follow, which is complete enough for the task. However, it could have briefly distinguished itself from get_report_preview to fully contextualize within the sibling set, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Since there are no parameters to explain, the description does not need to provide parameter details. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the tool's purpose without any parameter-related gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Get the report template format' and clearly states the purpose as understanding the exact structure and formatting requirements for vulnerability reports. This distinguishes it from sibling tools like create_vulnerability_report (creation), get_report_preview (preview of a specific report), and list_reports (listing existing reports).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by saying 'Use this to understand the exact structure and formatting requirements for vulnerability reports,' implying it should be used when preparing to create or format a report. It does not explicitly mention alternatives or when not to use, but the guidance is clear enough for the agent to decide when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all generated vulnerability reports
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only states the core action but does not disclose whether the listing is paginated, what fields are returned, or any side effects. For a read-only list, this is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, extremely concise and front-loaded. Every word contributes to the meaning with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no annotations, no output schema), the one-sentence description is mostly complete. However, it does not specify what data the list returns, leaving some ambiguity compared to sibling tools like get_report_preview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema is vacuously complete. The baseline for zero parameters is 4, and the description adds no irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all generated vulnerability reports, using a specific verb and resource. This distinguishes it from sibling tools like create_vulnerability_report and get_report_preview, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for listing all reports, but it does not explicitly contrast it with alternatives such as get_report_preview or export_report. There is no when-not-to-use guidance, making usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_evidence_to_reportcalculate_cvss_scorecreate_vulnerability_reportexport_reportget_report_previewget_report_templatelist_reportsMost tools have distinct purposes, but get_report_preview and get_report_template could be confused as both relate to report formatting. Additionally, export_report and get_report_preview both produce markdown output, though one saves to file and the other displays inline.
All tool names follow a consistent snake_case verb_noun pattern (create, calculate, add, export, list, get, get). The pattern is predictable and readable, with no mixed conventions or vague verbs.
Seven tools is well-scoped for a vulnerability reporting server, covering creation, scoring, evidence, export, listing, preview, and template retrieval. Each tool serves a clear purpose without redundancy or bloat.
The tool surface lacks update and delete operations for reports, and while get_report_preview provides a partial retrieval, there is no full report getter. This creates notable lifecycle gaps, though add_evidence_to_report offers a limited update mechanism.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Scan a website for vulnerabilities: OWASP Top 10, CVEs, SSL, headers - with plain-English fixes
CVE intelligence: exploitation (KEV/EPSS), detection coverage, fixed versions. All tools keyless.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/badchars/mcp-vulnerability-reporting'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
