mcp2agy
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| analyze_codeC | Scan source files for 0day vulnerabilities using 72+ research-calibrated patterns. Returns structured candidate records with CWE, priority, confidence tiers, data-flow, and grounding anchors. |
| calculate_cvssB | Calculate CVSS v3.1 base score, severity, and metric breakdown from a vector string. |
| get_patternsA | List vulnerability detection patterns with optional filtering by priority, CWE, language, or vulnerability class. |
| profile_targetA | Profile a target project: detect ecosystem, languages, frameworks, entry points, manifest files, and file manifest with hashes and line counts. Phase 0 of the audit pipeline. |
| scan_fileB | Scan a single file for vulnerabilities and return structured candidate records with grounding anchors (file hash + line count). |
| verify_findingA | Verify a scan candidate: check reachability, run 7-class confounder elimination, calibrate CVSS score, and generate per-CWE PoC template. Requires high/medium confidence and cleared confounders for CONFIRMED status. |
| check_reachabilityA | Trace data flow from entry point to sink for a scan candidate. Returns reachability status, data-flow path, auth gates, sanitizers, and confidence level. |
| generate_pocB | Generate a per-CWE Proof-of-Concept template with setup, trigger, expected output, cleanup, and Dockerfile. |
| generate_reportB | Generate a security report from verified findings. Mode A = internal audit report, Mode B = GHSA advisory draft, Mode C = public writeup. |
| chain_findingsA | Synthesize verified findings into multi-step, publication-grade exploit chains (e.g. Traversal + Write -> Persistent RCE; Header Injection -> Agent Escape). |
| generate_fixB | Generate a contextual fix based on candidate line range, actual snippet, and verified finding. |
| check_fix_completenessC | Check if a fix has been applied at ALL vulnerable call sites in a file, cross-referenced with known candidates. |
| list_fix_templatesA | List all available per-CWE fix templates with their fix class and description. |
| audit_pipelineA | Run the full resilient 0day audit pipeline: Scan → Verify → Chain → Report → Fix. Writes complete persistent artifacts into mcp2agy_workspace/runs// and returns a compact executive summary. |
| detect_platformA | Detect the current host operating system (Windows, Linux, macOS), architecture, shell, homedir, path separators, permission commands, and OS-specific vulnerability nuances. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools have distinct purposes (e.g., calculate_cvss vs generate_poc), but scan_file and analyze_code both scan for vulnerabilities with overlapping output structures, and check_reachability is a subset of verify_finding's workflow. Descriptions help differentiate, but some confusion is possible.
All tool names follow a consistent snake_case verb_noun pattern (generate_fix, scan_file, verify_finding, audit_pipeline). No mixed conventions or vague verbs; naming is highly predictable.
With 15 tools, the server is well-scoped for a comprehensive security audit pipeline. Each tool addresses a distinct stage (profiling, scanning, verification, fixing, reporting, chaining), and none feel redundant or excessive.
The tool surface covers the full audit lifecycle: profile_target (discovery), scan_file/analyze_code (detection), verify_finding/check_reachability (validation), calculate_cvss (scoring), generate_poc (exploitation), generate_fix/check_fix_completeness (remediation), chain_findings (synthesis), and generate_report (output). The audit_pipeline orchestrates everything, leaving no major dead ends.