Integrates ESLint for static code analysis to detect security vulnerabilities in JavaScript/TypeScript code.
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., "@Spotter-SAST Scan my project for security vulnerabilities using Semgrep"
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.
A comprehensive Model Context Protocol (MCP) server providing enterprise-grade Static Application Security Testing (SAST) with advanced compliance verification, multi-tenant management, AI-powered analysis, and automated remediation workflows.
Spotter-SAST is an advanced security analysis platform that combines multiple industry-standard SAST tools with intelligent automation, continuous monitoring, comprehensive compliance verification, and enterprise-grade reporting. Built on the Model Context Protocol (MCP), it provides both real-time security analysis and long-term security posture management with support for 9 major compliance frameworks.
🔧 Multi-Tool Integration: Seamlessly integrates Semgrep, Bandit, ESLint, and njsscan
🏛️ Compliance Verification: Support for HIPAA, GDPR, PCI DSS, ISO 27001, SOX, NIST CSF, CCPA, FISMA/FedRAMP
🔄 Compliance Drift Detection: Monitor compliance posture changes over time
🏢 Multi-Tenant Management: Manage multiple organizations with different compliance requirements
🔒 Evidence Collection: Cryptographically signed evidence with chain of custody
🤖 Automated Remediation: Framework-specific remediation workflows with SLA tracking
📊 Advanced Analytics: Predictive compliance analytics and executive dashboards
🤖 AI-Powered Fixes: Intelligent vulnerability remediation with confidence scoring
👁️ Continuous Monitoring: Real-time file system monitoring with automated alerts
📈 Enterprise Reporting: Multiple formats including HTML, JSON, Markdown, and SARIF
🛡️ Enterprise Security: OAuth 2.0, RBAC, audit logging, and session management
Related MCP server: security-framework-mcp
MultiToolScanner: Orchestrates multiple SAST tools for comprehensive analysis
SecurityManager: Handles authentication, authorization, and audit logging
ContinuousMonitor: Provides real-time file monitoring and scheduled scans
AdvancedReporting: Generates comprehensive reports in multiple formats
AIAutoFixer: Intelligent vulnerability remediation with validation
ComplianceDriftDetector: Monitors compliance posture changes and detects degradation
MultiTenantComplianceManager: Manages compliance for multiple organizations/teams
ComplianceEvidenceCollector: Collects and secures compliance evidence with cryptographic integrity
ComplianceRemediationEngine: Automated remediation workflows with SLA tracking
Path | Description |
| Contains the core application source code. |
├── | The main MCP server, integrating over 15 tools. |
├── | Houses all compliance-related logic. |
│ ├── | Contains the 4 core compliance verification classes. |
│ ├── | Includes 10 compliance-specific MCP tools. |
│ └── | Stores detailed compliance audit logs. |
└── | Stores general application logs. |
| All configuration files for the application. |
├── | Definitions for 9 supported compliance frameworks. |
├── | User-defined compliance configurations. |
├── | Settings for advanced compliance features. |
├── | Organization-specific custom compliance rules. |
├── | Custom security policy definitions. |
├── | Configuration for application monitoring. |
├── | Role-Based Access Control (RBAC) role definitions. |
└── | Configurations for multi-tenant deployments. |
| Infrastructure as Code (IaC) and related scripts. |
├── | Contains Docker configurations and Dockerfiles. |
└── | Helper and management scripts. |
├── | A script for managing compliance tasks. |
└── | Utility script for Docker operations. |
| Stores baseline configurations for drift detection. |
| Contains cryptographically signed evidence for audits. |
| Generated reports from the remediation workflow. |
| Automated tests for the application. |
└── | The testing suite specifically for compliance features. |
| Comprehensive project documentation. |
Language | Tools | Extensions |
JavaScript/TypeScript | Semgrep, ESLint, njsscan, Patterns |
|
Python | Semgrep, Bandit, Patterns |
|
Java/Kotlin | Semgrep, Patterns |
|
C#/.NET | Semgrep, Patterns |
|
Go | Semgrep, Patterns |
|
PHP | Semgrep, Patterns |
|
Ruby | Semgrep, Patterns |
|
C/C++ | Semgrep, Patterns |
|
Rust | Semgrep, Patterns |
|
Node.js Dependencies:
npm installPython Security Tools:
pip install -r requirements.txtRequired tools:
Semgrep - Multi-language static analysis
Bandit - Python security linter
ESLint - JavaScript/TypeScript security rules
Create environment configuration:
cp .env.example .envKey environment variables:
# Organization Configuration
ORGANIZATION_INDUSTRY=general # healthcare, finance, ecommerce, government, general
ORGANIZATION_NAME=Your Organization
CONTACT_EMAIL=compliance@yourorg.com
# Security Configuration
JWT_SECRET=your-secure-jwt-secret
ENABLE_RBAC=true
ENABLE_AUDIT_LOGGING=true
# Enhanced Compliance Features
ENABLE_ENHANCED_COMPLIANCE=true
ENABLE_COMPLIANCE_DRIFT_DETECTION=true
ENABLE_MULTI_TENANT_MANAGEMENT=true
ENABLE_EVIDENCE_COLLECTION=true
ENABLE_AUTOMATED_REMEDIATION=true
ENABLE_ADVANCED_ANALYTICS=true
# Framework-Specific (auto-enabled based on ORGANIZATION_INDUSTRY)
ENABLE_HIPAA=false
ENABLE_GDPR=false
ENABLE_PCI_DSS=false
ENABLE_ISO27001=false
ENABLE_SOX=false
ENABLE_NIST_CSF=truenpm startThe server will start with:
✅ 15+ MCP tools (8 core + 7 compliance tools)
✅ Multi-tool SAST capabilities (Semgrep, Bandit, ESLint, njsscan)
✅ Real-time compliance monitoring with drift detection
✅ Multi-tenant compliance management
✅ Cryptographic evidence collection with chain of custody
✅ Automated remediation workflows with SLA tracking
✅ AI-powered auto-fixes with validation
✅ Advanced analytics and executive dashboards
enhanced_scan_fileComprehensive multi-tool SAST scan for individual files with AI analysis
{
"filepath": "/path/to/file.js",
"tools": ["semgrep", "eslint"],
"policies": ["owasp", "pci"],
"includeFixSuggestions": true,
"user_token": "jwt-token"
}enhanced_scan_directoryDirectory-wide security analysis with continuous monitoring
{
"dirpath": "/path/to/project",
"enableMonitoring": true,
"schedule": "0 */6 * * *",
"policies": ["owasp", "enterprise_security"]
}compliance_scanComprehensive compliance scanning with framework-specific analysis
{
"filepath": "/path/to/code",
"frameworks": ["hipaa", "gdpr", "pci_dss"],
"industry": "healthcare",
"include_recommendations": true
}compliance_frameworks_manageManage compliance frameworks (enable/disable/configure)
{
"action": "enable",
"framework": "hipaa",
"industry": "healthcare"
}compliance_drift_baselineCreate compliance baselines for drift detection
{
"project_path": "./src",
"frameworks": ["hipaa", "gdpr"],
"baseline_name": "production_baseline"
}compliance_drift_detectDetect compliance drift from established baselines
{
"project_path": "./src",
"frameworks": ["hipaa", "gdpr"]
}register_compliance_tenantRegister organization/team for multi-tenant compliance management
{
"tenant_id": "acme_healthcare",
"tenant_config": {
"name": "ACME Healthcare",
"industry": "healthcare",
"template": "healthcare_hipaa",
"riskTolerance": "zero"
}
}tenant_compliance_assessmentPerform tenant-specific compliance assessment
{
"tenant_id": "acme_healthcare",
"project_path": "./patient_portal"
}collect_compliance_evidenceCollect cryptographically signed compliance evidence
{
"scan_path": "./src",
"frameworks": ["hipaa", "pci"],
"collector": "security@company.com",
"notes": "Pre-deployment compliance scan"
}generate_compliance_audit_reportGenerate comprehensive audit reports with evidence chain
{
"frameworks": ["hipaa", "pci"],
"time_range": {
"start": "2024-01-01T00:00:00Z",
"end": "2024-12-31T23:59:59Z"
},
"report_format": "detailed"
}trigger_compliance_remediationTrigger automated compliance remediation workflows
{
"finding": {
"type": "hardcoded_secrets",
"severity": "Critical",
"file": "./config/database.js"
},
"framework": "hipaa",
"automation_level": "semi_automatic"
}compliance_analytics_dashboardAdvanced compliance analytics with predictive insights
{
"time_range": {
"start": "2024-01-01T00:00:00Z",
"end": "2024-12-31T23:59:59Z"
},
"frameworks": ["hipaa", "gdpr", "pci"],
"include_predictions": true
}ai_enhanced_auto_fixIntelligent vulnerability remediation with validation
{
"filepath": "/path/to/file.js",
"strategy": "balanced",
"validate_fixes": true,
"create_backup": true
}start_continuous_monitoringReal-time security monitoring with automated alerts
{
"project_path": "/path/to/project",
"schedule": "0 */6 * * *",
"alert_thresholds": {
"critical": 0,
"high": 5
}
}security_dashboardReal-time security metrics and alerts dashboard
{
"time_range": "24h",
"include_trends": true,
"include_alerts": true
}generate_enhanced_reportComprehensive security reporting with executive summaries
{
"scan_path": "/path/to/project",
"report_dir": "./reports",
"format": "sarif",
"include_executive_summary": true,
"include_compliance_matrix": true
}manage_security_policiesPolicy and compliance management
{
"action": "check",
"policy_name": "owasp",
"scan_results": {...}
}get_enhanced_vulnerability_infoComprehensive vulnerability information with OWASP mapping
{
"vuln_type": "sql_injection"
}Framework | Industry | Auto-Enabled | SLA | Key Features |
HIPAA | Healthcare | ✅ healthcare | 4 hours | PHI detection, breach notification |
GDPR | All | ✅ ecommerce | 72 hours | Data subject rights, privacy by design |
PCI DSS | Finance/Ecommerce | ✅ finance/ecommerce | 2 hours | Cardholder data protection |
ISO 27001 | Enterprise | ✅ general | - | Information security management |
SOX | Financial | ✅ finance | 8 hours | Financial reporting controls |
NIST CSF | All | ✅ all industries | - | Cybersecurity framework |
CCPA | All | ✅ ecommerce | - | California consumer privacy |
FISMA | Government | ✅ government | - | Federal information security |
FedRAMP | Government | ✅ government | - | Federal cloud security |
Baseline Management: Cryptographic snapshots of compliance state
Change Detection: Configurable thresholds (5%, 15%, 25%)
Early Warning: Automated alerts on compliance degradation
Trend Analysis: Historical compliance trajectory tracking
Industry Templates: Healthcare, Finance, Government, Enterprise
Risk Tolerance: Zero, Minimal, Low, Medium, High levels
Custom Frameworks: Per-tenant compliance requirements
Isolated Assessments: Tenant-specific compliance scoring
Cryptographic Integrity: SHA-256 hashing, digital signatures
Audit Trail: Tamper-proof evidence chain of custody
Legal Grade: Court-admissible compliance evidence
Automated Collection: Evidence from every compliance scan
Framework-Specific: HIPAA (4hr SLA), PCI DSS (2hr SLA), GDPR (72hr SLA)
Automation Levels: Automatic, Semi-automatic, Manual
Stakeholder Notification: Role-based alert distribution
SLA Tracking: Compliance violation response times
Category | OWASP Mapping | CWE | Severity | Compliance Impact |
SQL Injection | A03_Injection | CWE-89 | Critical | HIPAA, GDPR, PCI DSS |
Cross-Site Scripting | A03_Injection | CWE-79 | High | All frameworks |
Hardcoded Secrets | A02_Cryptographic_Failures | CWE-798 | Critical | HIPAA, PCI DSS, GDPR |
Command Injection | A03_Injection | CWE-78 | Critical | All frameworks |
Weak Cryptography | A02_Cryptographic_Failures | CWE-327 | Medium | HIPAA, PCI DSS |
Path Traversal | A01_Broken_Access_Control | CWE-22 | High | All frameworks |
Insecure Random | A02_Cryptographic_Failures | CWE-338 | Medium | PCI DSS, HIPAA |
Debug Code | A09_Security_Logging_Monitoring_Failures | CWE-489 | Low | SOX, ISO 27001 |
Insecure Deserialization | A08_Software_Data_Integrity_Failures | CWE-502 | High | All frameworks |
Role | Level | Key Permissions | Compliance Access |
Security Admin | 4 | Full administrative access ( | All compliance tools |
Compliance Officer | 4 | Compliance management, audit reports | All compliance tools |
Security Analyst | 3 | Analysis, reporting, policy management | Read/execute compliance tools |
Developer | 2 | Scanning, fix suggestions, basic reporting | Limited compliance access |
Auditor | 1 | Read-only access to scans and compliance | Read-only compliance data |
Viewer | 0 | Basic dashboard and report viewing | Dashboard viewing only |
# 1. Configure for healthcare industry
echo "ORGANIZATION_INDUSTRY=healthcare" >> .env
echo "ENABLE_HIPAA=true" >> .env
echo "ENABLE_NIST_CSF=true" >> .env
# 2. Register healthcare tenant
echo '{
"tenant_id": "acme_medical",
"tenant_config": {
"name": "ACME Medical Center",
"industry": "healthcare",
"template": "healthcare_hipaa",
"riskTolerance": "zero",
"complianceOfficer": "Dr. Sarah Johnson",
"contactEmail": "compliance@acmemedical.com"
}
}' | node src/server.js register_compliance_tenant
# 3. Create compliance baseline
echo '{
"project_path": "./patient-portal",
"frameworks": ["hipaa", "nist"],
"baseline_name": "patient_portal_baseline"
}' | node src/server.js compliance_drift_baseline
# 4. Perform HIPAA compliance scan
echo '{
"tenant_id": "acme_medical",
"project_path": "./patient-portal"
}' | node src/server.js tenant_compliance_assessment# Configure for financial industry
echo "ORGANIZATION_INDUSTRY=finance" >> .env
echo "ENABLE_PCI_DSS=true" >> .env
echo "ENABLE_SOX=true" >> .env
# Register financial tenant with strict controls
echo '{
"tenant_id": "banking_corp",
"tenant_config": {
"name": "Banking Corporation",
"industry": "finance",
"template": "financial_pci",
"riskTolerance": "minimal"
}
}' | node src/server.js register_compliance_tenant# Configure for e-commerce
echo "ORGANIZATION_INDUSTRY=ecommerce" >> .env
echo "ENABLE_PCI_DSS=true" >> .env
echo "ENABLE_GDPR=true" >> .env
echo "ENABLE_CCPA=true" >> .env# 1. Perform comprehensive scan
node src/server.js enhanced_scan_directory ./src
# 2. Collect cryptographic evidence
echo '{
"scan_path": "./src",
"frameworks": ["hipaa", "gdpr"],
"collector": "audit@company.com",
"notes": "Quarterly compliance audit scan"
}' | node src/server.js collect_compliance_evidence
# 3. Generate audit report
echo '{
"frameworks": ["hipaa", "gdpr"],
"time_range": {"start": "2024-01-01T00:00:00Z", "end": "2024-12-31T23:59:59Z"},
"report_format": "detailed"
}' | node src/server.js generate_compliance_audit_report# Trigger HIPAA violation remediation
echo '{
"finding": {
"type": "hardcoded_secrets",
"severity": "Critical",
"file": "./config/database.js",
"line": 15
},
"framework": "hipaa",
"automation_level": "semi_automatic",
"stakeholders": ["security-team", "compliance-officer"]
}' | node src/server.js trigger_compliance_remediation# Start real-time monitoring with compliance checking
echo '{
"project_path": "./production-app",
"schedule": "0 */2 * * *",
"alert_thresholds": {"critical": 0, "high": 1}
}' | node src/server.js start_continuous_monitoring
# Monitor compliance drift
echo '{
"project_path": "./production-app",
"frameworks": ["hipaa", "pci_dss"]
}' | node src/server.js compliance_drift_detectHTML: Interactive reports with charts, compliance matrices, and executive summaries
JSON: Machine-readable structured data with compliance mappings
Markdown: Human-readable documentation format with compliance sections
SARIF: Industry-standard Static Analysis Results Interchange Format
Dashboard: Real-time web-based metrics, trends, and compliance analytics
📈 Risk Scores: Overall risk assessment with compliance impact
🎯 Severity Distribution: Critical, High, Medium, Low vulnerability counts
🏛️ Compliance Status: Framework-by-framework compliance verification
💡 Action Items: Prioritized recommendations with timelines
🔍 Line-by-Line Findings: Vulnerability analysis with remediation guidance
🧪 Multi-Tool Correlation: Cross-tool validation and confidence scoring
🏛️ Compliance Mapping: Framework-specific control mapping (HIPAA, GDPR, etc.)
🔧 AI-Powered Fixes: Intelligent remediation suggestions with confidence levels
✅ Framework Status: PASS/FAIL status for each enabled framework
📋 Control Mapping: Specific regulatory control violations
🎯 Risk Assessment: Compliance-weighted risk scoring
📊 Trend Analysis: Compliance posture over time
📈 Predictive Insights: Forecast compliance risks and trends
🎯 Risk Hotspots: Identify high-risk code areas and patterns
📊 Tool Effectiveness: SAST tool performance and coverage analysis
🔄 Drift Detection: Compliance baseline comparison and degradation alerts
🛡️ Enhanced SAST Compliance Report
📂 Scanned: /healthcare-app
🏛️ Frameworks: hipaa, gdpr, nist_csf
📊 Overall Status: NON_COMPLIANT
🎯 Average Score: 73.5%
📋 Framework Results:
❌ HIPAA: FAIL (65.2%)
Violations: 164.312(a)(2)(i) - Hardcoded PHI credentials
164.312(e)(2)(ii) - Unencrypted PHI transmission
SLA: 4 hours remaining
✅ GDPR: PASS (89.3%)
Status: All data protection requirements met
⚠️ NIST CSF: PARTIAL (71.0%)
Issues: PR.DS-1 - Data security controls need enhancement
💡 Immediate Actions Required:
1. [CRITICAL] Fix hardcoded PHI credentials (4 hours)
2. [HIGH] Implement TLS 1.3 for PHI transmission (24 hours)
3. [MEDIUM] Enhance NIST data security controls (7 days)
🔒 Evidence Collected:
Evidence ID: EVD_20240815_ABC123
Integrity Hash: sha256:a1b2c3d4...
Chain of Custody: 3 entriesname: Enhanced SAST Security & Compliance Scan
on: [push, pull_request]
jobs:
security-compliance-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '18'
- name: Setup Python
uses: actions/setup-python@v4
with:
python-version: '3.9'
- name: Install Dependencies
run: |
npm install
pip install -r requirements.txt
- name: Create Compliance Baseline (if not exists)
run: |
echo '{"project_path": "./src", "frameworks": ["owasp", "nist"]}' | \\
node src/server.js compliance_drift_baseline || true
- name: Enhanced Security Scan with Compliance
run: |
echo '{"dirpath": "./", "policies": ["owasp", "nist"]}' | \\
node src/server.js enhanced_scan_directory
- name: Collect Compliance Evidence
run: |
echo '{
"scan_path": "./src",
"frameworks": ["owasp", "nist"],
"collector": "github-actions",
"notes": "CI/CD pipeline compliance scan"
}' | node src/server.js collect_compliance_evidence
- name: Detect Compliance Drift
run: |
echo '{"project_path": "./src", "frameworks": ["owasp", "nist"]}' | \\
node src/server.js compliance_drift_detect
- name: Generate Enhanced SARIF Report
run: |
echo '{
"scan_path": "./",
"report_dir": "./reports",
"format": "sarif",
"include_compliance_matrix": true
}' | node src/server.js generate_enhanced_report
- name: Upload SARIF Results
uses: github/codeql-action/upload-sarif@v2
with:
sarif_file: reports/enhanced-sast-report-*.sarif
- name: Check Compliance Gate
run: |
# Fail build if critical compliance violations found
if grep -q '"status": "FAIL"' reports/*.json; then
echo "❌ Compliance gate failed - critical violations found"
exit 1
fi# Enhanced Dockerfile with compliance features
FROM node:18-alpine
WORKDIR /app
# Install Python and security tools
RUN apk add --no-cache python3 py3-pip
COPY requirements.txt .
RUN pip install -r requirements.txt
# Install Node.js dependencies
COPY package*.json ./
RUN npm ci --only=production
# Copy application code
COPY src/ ./src/
COPY config/ ./config/
COPY infra/ ./infra/
# Create compliance directories
RUN mkdir -p compliance-baselines compliance-evidence incident-reports logs
# Compliance environment variables
ENV ENABLE_ENHANCED_COMPLIANCE=true
ENV ORGANIZATION_INDUSTRY=general
ENV DEFAULT_COMPLIANCE_FRAMEWORKS=owasp,nist_csf
ENV EVIDENCE_RETENTION_YEARS=7
# Expose health check port
EXPOSE 3000 3001
# Health check
HEALTHCHECK --interval=30s --timeout=10s --start-period=40s --retries=3 \\
CMD curl -f http://localhost:3001/health || exit 1
# Start with compliance initialization
CMD ["node", "src/server.js"]version: '3.8'
services:
spotter-sast:
build: .
ports:
- "3000:3000"
- "3001:3001"
environment:
- ORGANIZATION_INDUSTRY=healthcare
- ENABLE_HIPAA=true
- ENABLE_EVIDENCE_COLLECTION=true
volumes:
- ./code-to-scan:/scan-target:ro
- ./compliance-reports:/app/reports
- ./compliance-evidence:/app/compliance-evidence
- ./compliance-baselines:/app/compliance-baselines
depends_on:
- postgres
- redis
postgres:
image: postgres:15
environment:
POSTGRES_DB: compliance_db
POSTGRES_USER: compliance_user
POSTGRES_PASSWORD: secure_password
volumes:
- postgres_data:/var/lib/postgresql/data
redis:
image: redis:7-alpine
volumes:
- redis_data:/data
volumes:
postgres_data:
redis_data:# .pre-commit-config.yaml
repos:
- repo: local
hooks:
- id: spotter-sast-security
name: Spotter-SAST Security Scan
entry: node src/server.js enhanced_scan_file
language: system
files: \\.(js|ts|py|java|go|php|rb|rs)$
- id: spotter-sast-compliance
name: Spotter-SAST Compliance Check
entry: ./infra/scripts/compliance.sh quick-scan
language: system
pass_filenames: false
always_run: trueFile System Watching: Instant detection of code changes with compliance impact assessment
Automated Scanning: Triggered on file modifications with framework-specific checks
Smart Filtering: Focuses on security-relevant file types and compliance-critical areas
Performance Optimized: Efficient resource usage with intelligent caching and batching
Compliance Drift Detection: Continuous monitoring of compliance posture changes
Console Logging: Immediate terminal notifications with compliance context
File Logging: Structured logging to src/logs/ and src/compliance/logs/
Security Events: Comprehensive audit trail with chain of custody
Webhook Support: Slack, Teams, and custom webhook integrations
Email Notifications: SMTP-based alerts for compliance violations
SMS Alerts: Emergency notifications for critical compliance breaches
🔴 Critical Vulnerabilities: Immediate attention required (0 tolerance)
🟠 High Severity Issues: Address within framework SLA (2-72 hours)
⚖️ Compliance Violations: Policy threshold breaches with stakeholder notification
📊 Compliance Drift: Baseline degradation alerts (5%, 15%, 25% thresholds)
🔄 Monitoring Failures: System health and evidence collection notifications
🏢 Multi-Tenant Alerts: Tenant-specific notifications with custom escalation
Critical → Immediate: Compliance Officer, CISO, CEO
→ 1 hour: Legal Team, Board Chair
→ 4 hours: External Counsel
High → 1 hour: Compliance Officer, Security Team
→ 4 hours: Department Heads
→ 24 hours: Executive Team
Medium → 4 hours: Security Team
→ 24 hours: Compliance Officer
→ Weekly: Management TeamWhen you set ORGANIZATION_INDUSTRY in your .env file, the system automatically enables appropriate compliance frameworks:
# Healthcare Organizations
ORGANIZATION_INDUSTRY=healthcare
# Auto-enables: HIPAA + NIST CSF
# Features: PHI detection, HIPAA breach workflows, medical data patterns
# Financial Services
ORGANIZATION_INDUSTRY=finance
# Auto-enables: PCI DSS + SOX + NIST CSF
# Features: Payment data protection, financial controls, audit trails
# E-commerce Platforms
ORGANIZATION_INDUSTRY=ecommerce
# Auto-enables: PCI DSS + GDPR + CCPA
# Features: Customer data protection, payment security, privacy rights
# Government Agencies
ORGANIZATION_INDUSTRY=government
# Auto-enables: FISMA + FedRAMP + NIST CSF
# Features: Government security standards, federal compliance
# General/Enterprise
ORGANIZATION_INDUSTRY=general
# Auto-enables: OWASP + NIST CSF + ISO 27001
# Features: General security best practices, enterprise standards# Organization Configuration
ORGANIZATION_NAME=Your Organization
ORGANIZATION_INDUSTRY=general
ORGANIZATION_SIZE=medium
CONTACT_EMAIL=compliance@yourorg.com
# Security Configuration
JWT_SECRET=your-256-bit-secret-key
ENABLE_RBAC=true
TOKEN_EXPIRY=24h
ENABLE_AUDIT_LOGGING=true
# Enhanced Compliance Features (v2.1.0)
ENABLE_ENHANCED_COMPLIANCE=true
ENABLE_COMPLIANCE_DRIFT_DETECTION=true
ENABLE_MULTI_TENANT_MANAGEMENT=true
ENABLE_EVIDENCE_COLLECTION=true
ENABLE_AUTOMATED_REMEDIATION=true
ENABLE_ADVANCED_ANALYTICS=true
# Framework Configuration
DEFAULT_COMPLIANCE_FRAMEWORKS=owasp,nist_csf
AUTO_ENABLE_INDUSTRY_FRAMEWORKS=true
# Individual framework controls
ENABLE_HIPAA=false
ENABLE_GDPR=false
ENABLE_PCI_DSS=false
ENABLE_ISO27001=false
ENABLE_SOX=false
ENABLE_NIST_CSF=true
# Monitoring Configuration
DEFAULT_SCAN_SCHEDULE=0 */6 * * *
COMPLIANCE_SCAN_FREQUENCY=daily
ALERT_THRESHOLD_CRITICAL=0
ALERT_THRESHOLD_HIGH=5
# Evidence & Audit Configuration
EVIDENCE_RETENTION_YEARS=7
EVIDENCE_CRYPTOGRAPHIC_SIGNING=true
COMPLIANCE_EVIDENCE_RETENTION_DAYS=2555
AUDIT_TRAIL_IMMUTABLE=trueCreate tenant-specific configurations in config/tenants/:
{
"tenant_id": "healthcare_division",
"config": {
"name": "Healthcare Division",
"industry": "healthcare",
"riskTolerance": "zero",
"enabledFrameworks": ["hipaa", "nist"],
"customRules": ["phi_detection", "encryption_required"],
"contactEmail": "compliance@healthcare-div.com",
"complianceOfficer": "Dr. Sarah Johnson",
"escalationMatrix": {
"critical": ["ciso@company.com", "legal@company.com"],
"high": ["security@company.com", "compliance@healthcare-div.com"]
}
}
}Customize security policies in config/custom-policies.json:
{
"healthcare_strict": {
"name": "Healthcare Strict Security Policy",
"requiredChecks": ["hardcoded_secrets", "weak_crypto", "phi_exposure"],
"failThresholds": {
"critical": 0,
"high": 0,
"medium": 2
},
"complianceFrameworks": ["hipaa", "nist"],
"automatedRemediation": true,
"evidenceCollection": true
},
"enterprise_standard": {
"name": "Enterprise Standard Policy",
"requiredChecks": ["owasp_top_10"],
"failThresholds": {
"critical": 0,
"high": 5,
"medium": 20
}
}
}Detailed framework settings in config/compliance-frameworks.json:
{
"hipaa": {
"version": "2013_final_rule",
"enabled": true,
"riskTolerance": "zero",
"requiredControls": ["164.312(a)", "164.312(c)", "164.312(e)"],
"patterns": {
"phi_patterns": [
"(?i)(ssn|social\\\\s*security)\\\\s*[:=]?\\\\s*\\\\d{3}-?\\\\d{2}-?\\\\d{4}",
"(?i)(patient|medical)\\\\s*id\\\\s*[:=]?\\\\s*\\\\d+"
]
},
"slaHours": 4,
"automatedWorkflows": ["phi_exposure", "audit_trail"]
}
}# Performance Tuning
MAX_CONCURRENT_COMPLIANCE_SCANS=3
COMPLIANCE_SCAN_TIMEOUT=1800
CACHE_COMPLIANCE_RESULTS=true
COMPLIANCE_CACHE_EXPIRATION=60
SCAN_PARALLEL_WORKERS=4
EVIDENCE_BATCH_SIZE=100
ANALYTICS_QUERY_TIMEOUT_SECONDS=30
# Scalability Settings
MAX_TENANTS_PER_INSTANCE=100
BASELINE_COMPARISON_CACHE_SIZE=1000
ANALYTICS_HISTORICAL_RETENTION_MONTHS=24
EVIDENCE_RETENTION_YEARS=7Use the enhanced compliance script for comprehensive management:
# Setup & Configuration
./infra/scripts/compliance.sh setup # Initialize compliance system
./infra/scripts/compliance.sh configure-industry healthcare # Configure for industry
./infra/scripts/compliance.sh enable hipaa # Enable specific framework
./infra/scripts/compliance.sh list # List available frameworks
# Scanning & Analysis
./infra/scripts/compliance.sh quick-scan ./src # Quick compliance scan
./infra/scripts/compliance.sh scan ./project hipaa,gdpr html # Full scan with frameworks
./infra/scripts/compliance.sh baseline ./src hipaa # Create compliance baseline
# Monitoring & Reporting
./infra/scripts/compliance.sh start-monitoring ./src "0 */6 * * *" # Start monitoring
./infra/scripts/compliance.sh report ./project html # Generate comprehensive report
./infra/scripts/compliance.sh status # Check system status
./infra/scripts/compliance.sh validate # Validate configurationFor large-scale deployments, configure database backend:
# Database Configuration
USE_DATABASE_STORAGE=true
DATABASE_TYPE=postgresql
DATABASE_HOST=your-db-host
DATABASE_PORT=5432
DATABASE_NAME=compliance_db
DATABASE_USER=compliance_user
DATABASE_PASS=your-secure-password
DATABASE_SSL=true
DATABASE_CONNECTION_POOL_SIZE=10
# Redis Caching
REDIS_ENABLED=true
REDIS_HOST=your-redis-host
REDIS_PORT=6379
REDIS_PASSWORD=your-redis-password
REDIS_CACHE_TTL_SECONDS=3600Add organization-specific patterns to vulnerability detection:
// In config/custom-compliance-rules.json
{
"custom_patterns": {
"company_api_leak": {
"patterns": ["(?i)ACME-API-KEY-[A-Za-z0-9]{32}"],
"severity": "Critical",
"owaspCategory": "A02_Cryptographic_Failures",
"description": "Company API key detected in code",
"complianceMapping": {
"hipaa": ["164.312(a)(2)(i)"],
"pci_dss": ["3.4"]
}
},
"internal_service_creds": {
"patterns": ["(?i)(internal[_-]?service)[_-]?(key|token|secret)\\\\s*[:=]\\\\s*[\"'][^\"'\\\\s]{10,}"],
"severity": "High",
"description": "Internal service credentials detected"
}
}
}# Configure Slack webhook in .env
SLACK_WEBHOOK_URL=https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK
NOTIFICATION_CHANNELS=email,slack
IMMEDIATE_NOTIFY_SEVERITIES=critical,high# Configure Teams webhook in .env
TEAMS_WEBHOOK_URL=https://outlook.office.com/webhook/YOUR/TEAMS/WEBHOOK
WEBHOOK_RETRY_ATTEMPTS=3
WEBHOOK_TIMEOUT_SECONDS=30# For repositories with 100,000+ files
SCAN_PARALLEL_WORKERS=8
MAX_CONCURRENT_COMPLIANCE_SCANS=5
COMPLIANCE_SCAN_TIMEOUT=3600
EVIDENCE_BATCH_SIZE=500
# Memory optimization
NODE_OPTIONS=--max-old-space-size=8192
# Caching optimization
CACHE_COMPLIANCE_RESULTS=true
COMPLIANCE_CACHE_EXPIRATION=120
BASELINE_COMPARISON_CACHE_SIZE=5000# Single file scan with compliance frameworks
echo '{"filepath": "/path/to/file.js", "policies": ["hipaa", "gdpr"]}' | \\
node src/server.js enhanced_scan_file
# Directory scan with compliance evidence collection
echo '{"dirpath": "/path/to/project", "enableMonitoring": true}' | \\
node src/server.js enhanced_scan_directory
# Generate compliance report
echo '{"scan_path": "/path/to/project", "report_dir": "./reports", "format": "html"}' | \\
node src/server.js generate_enhanced_reportimport { McpClient } from "@modelcontextprotocol/sdk/client/mcp.js";
const client = new McpClient();
await client.connect();
// Enhanced scan with compliance
const result = await client.callTool("enhanced_scan_file", {
filepath: "/path/to/file.js",
policies: ["hipaa", "gdpr"],
includeFixSuggestions: true
});
// Multi-tenant compliance assessment
const assessment = await client.callTool("tenant_compliance_assessment", {
tenant_id: "healthcare_division",
project_path: "./patient-portal"
});
// Collect compliance evidence
const evidence = await client.callTool("collect_compliance_evidence", {
scan_path: "./src",
frameworks: ["hipaa", "gdpr"],
collector: "security@company.com",
notes: "Quarterly audit scan"
});Parallel Tool Execution: Multiple SAST tools run concurrently with compliance analysis
Intelligent Caching: Scan result caching for repeated analyses with compliance state
Incremental Scanning: Only scan changed files in monitoring mode with drift detection
Resource Management: Memory and CPU optimization for large codebases and compliance workloads
Batched Processing: Efficient handling of large directory structures with evidence collection
Multi-Tenant Isolation: Performance isolation between tenant assessments
Compliance Baseline Caching: Fast drift detection through optimized baseline comparisons
Scan Speed: ~100-500 files/minute (depending on file size, complexity, and compliance frameworks)
Memory Usage: ~50-200MB base + ~1-5MB per concurrent file scan + ~10-50MB for compliance features
Tool Detection: Sub-second tool availability checking with compliance framework validation
Report Generation: ~1-10 seconds for comprehensive reports, ~5-30 seconds for compliance reports
Evidence Collection: ~100-500ms per scan for cryptographic evidence generation
Baseline Creation: ~1-5 seconds for project baseline snapshot creation
Drift Detection: ~500ms-2s for baseline comparison and drift analysis
Concurrent Scans: Up to 8 parallel compliance scans per instance
Multi-Tenant Support: 100+ tenants per instance with isolation
Evidence Storage: Handles millions of evidence records with integrity verification
Baseline Management: 1000+ project baselines with efficient comparison algorithms
Large Repositories: Tested with 100,000+ files and multiple compliance frameworks
Real-Time Monitoring: Supports monitoring 10+ projects simultaneously
CPU: 2 cores, 2.0 GHz
Memory: 4 GB RAM
Storage: 10 GB (including logs and evidence)
Node.js: 18.0.0+
Python: 3.9+
CPU: 4+ cores, 3.0 GHz
Memory: 8+ GB RAM
Storage: 50+ GB SSD (for evidence and baseline storage)
Database: PostgreSQL 15+ (for enterprise evidence storage)
Cache: Redis 7+ (for performance optimization)
Security Tools Not Found
# Install missing SAST tools
pip install semgrep bandit
npm install -g eslint
# Verify tool installation
semgrep --version
bandit --version
eslint --versionPermission Denied
Check RBAC configuration in config/roles.json
Verify JWT token validity and expiration
Ensure user has required permissions for compliance operations
Check file system permissions for evidence collection
Memory Issues with Large Codebases
# Increase Node.js heap size
node --max-old-space-size=4096 src/server.js
# Optimize compliance scanning
export MAX_CONCURRENT_COMPLIANCE_SCANS=2
export SCAN_PARALLEL_WORKERS=2Authentication Failed
Verify JWT_SECRET environment variable is set
Check token expiration settings in configuration
Review user role assignments in config/roles.json
Ensure compliance officer permissions are configured
Compliance Framework Issues
# Validate compliance configuration
./infra/scripts/compliance.sh validate
# Check framework status
echo '{"action": "list"}' | node src/server.js compliance_frameworks_manage
# Reset compliance configuration
./infra/scripts/compliance.sh setupEvidence Collection Failures
# Check evidence directory permissions
mkdir -p compliance-evidence
chmod 755 compliance-evidence
# Verify cryptographic signing capability
echo '{"test": "evidence"}' | openssl dgst -sha256Baseline Creation/Drift Detection Issues
# Check baseline directory
ls -la compliance-baselines/
# Recreate baseline if corrupted
echo '{
"project_path": "./src",
"frameworks": ["owasp", "nist"]
}' | node src/server.js compliance_drift_baselineMulti-Tenant Configuration Issues
# Validate tenant configuration
node -c config/tenants/tenant_id.json
# Check tenant permissions
ls -la config/tenants/Enable comprehensive debug logging:
# Debug mode with compliance details
export LOG_LEVEL=debug
export DEBUG_COMPLIANCE_ENGINE=true
export COMPLIANCE_DEBUG_MODE=true
npm start
# Monitor compliance logs
tail -f src/compliance/logs/compliance.log# Check system health
curl http://localhost:3001/health
# Validate compliance components
./infra/scripts/compliance.sh status
# Test compliance frameworks
echo '{"action": "list"}' | node src/server.js compliance_frameworks_manage# Monitor resource usage during scans
top -p $(pgrep -f "node src/server.js")
# Check compliance scan performance
time echo '{"dirpath": "./src"}' | node src/server.js enhanced_scan_directory
# Analyze evidence collection performance
time echo '{
"scan_path": "./src",
"frameworks": ["owasp"],
"collector": "test@example.com"
}' | node src/server.js collect_compliance_evidence📖 Documentation:
docs/COMPLIANCE_FEATURES.md - User guide for compliance features
docs/ENHANCED_COMPLIANCE_FEATURES.md - Technical documentation
docs/COMPLIANCE_MODULE_SUMMARY.md - Implementation overview
🐛 Issues: GitHub Issues for bug reports and feature requests
💬 Discussions: GitHub Discussions for community support
📧 Compliance Support: compliance-support@company.com
🔧 Technical Support: Maintainer contact via GitHub profile
We welcome contributions! Please see our contributing guidelines:
Fork the Repository
Create Feature Branch: git checkout -b feature/amazing-feature
Add Tests: Ensure all new functionality is tested
Follow Code Style: Use existing patterns and conventions
Update Documentation: Include relevant documentation updates
Submit Pull Request: Clear description of changes and impact
# Clone repository
git clone https://github.com/george-mellow/spotter-sast.git
cd spotter-sast
# Install dependencies
npm install
pip install -r requirements.txt
# Run in development mode
LOG_LEVEL=debug npm start# Run security scan on test files
npm test
# Run compliance-specific tests
node test/test-compliance.js
# Test individual compliance features
./infra/scripts/compliance.sh validateEnhanced Compliance Verification: 9 regulatory frameworks (HIPAA, GDPR, PCI DSS, etc.)
Compliance Drift Detection: Baseline management and degradation monitoring
Multi-Tenant Management: Industry-specific templates and risk tolerance levels
Evidence Collection: Cryptographically signed evidence with chain of custody
Automated Remediation: Framework-specific workflows with SLA tracking
Advanced Analytics: Predictive compliance analytics and executive dashboards
Docker Support: Containerized deployment with compliance features
Enterprise RBAC: Role-based access control with compliance permissions
Advanced Reporting: HTML, JSON, Markdown, SARIF with compliance matrices
Web Dashboard: Browser-based security and compliance dashboard
Slack/Teams Integration: Enhanced real-time alert notifications
API Gateway: RESTful API for external compliance integrations
Mobile Dashboard: Mobile app for compliance monitoring
Enhanced ML Features: Advanced vulnerability prediction with compliance context
Cloud-Native Integration: AWS/Azure/GCP native compliance integrations
Compliance Automation Platform: No-code compliance workflow builder
Advanced Threat Modeling: AI-powered threat modeling with compliance mapping
Regulatory Intelligence: Automatic updates for changing compliance requirements
Cross-Platform CLI: Enhanced CLI tools for compliance management
Enterprise SSO: SAML/OIDC integration for enterprise authentication
Compliance Marketplace: Third-party compliance plugin ecosystem
🤖 AI Compliance Officer: Fully automated compliance management and reporting
🌐 Global Compliance Hub: Multi-region compliance management platform
📊 Compliance Intelligence: Machine learning-powered compliance insights
🔗 Ecosystem Integration: Deep integration with popular enterprise security tools
📱 Executive Mobile App: C-suite mobile dashboard for compliance oversight
🎯 Predictive Compliance: AI-powered prediction of regulatory changes and impacts
MIT License - see LICENSE file for details.
Copyright (c) 2025 george-mellow
Important: This tool performs security analysis but does not guarantee complete security. Always complement automated scanning with:
👥 Manual Security Reviews: Expert human analysis
🎯 Penetration Testing: Real-world attack simulation
🔄 Dynamic Analysis (DAST): Runtime vulnerability testing
📦 Dependency Scanning: Third-party library security
🐳 Container Security: Docker/Kubernetes security scanning
🔐 Infrastructure Security: Cloud and network security assessment
Version: v2.1.0 (Enterprise-grade with Enhanced Compliance)
Languages: JavaScript/Node.js, Python
Dependencies: 12+ Node.js packages, 8+ Python packages
SAST Tools: 4 integrated tools (Semgrep, Bandit, ESLint, njsscan)
MCP Tools: 15+ tools (8 core + 7 compliance-specific)
File Types: 20+ supported file extensions across 9 programming languages
Compliance Frameworks: 9 major regulatory frameworks (HIPAA, GDPR, PCI DSS, ISO 27001, SOX, NIST CSF, CCPA, FISMA, FedRAMP)
Vulnerability Categories: 9+ categories with comprehensive OWASP Top 10 2021 mapping
Industry Templates: 5 industry-specific compliance templates
Risk Tolerance Levels: 5 configurable levels (Zero, Minimal, Low, Medium, High)
Report Formats: 5 formats (HTML, JSON, Markdown, SARIF, Dashboard)
Multi-Tenant Support: 100+ tenants per instance with isolation
Evidence Management: Cryptographically signed evidence with chain of custody
Baseline Management: 1000+ project baselines for drift detection
Automated Workflows: Framework-specific remediation with SLA tracking
Analytics Engine: Predictive compliance analytics with trend analysis
Performance Optimization: Parallel processing with intelligent caching
Role-Based Access: 6 predefined roles with granular permissions
Audit Logging: Comprehensive audit trail with compliance evidence
Real-Time Monitoring: Continuous file system monitoring with alerts
Integration Ready: CI/CD, Docker, webhook, and API integrations
Scalability: Tested with enterprise-scale codebases (100,000+ files)
Security: Enterprise-grade authentication, authorization, and encryption
🎯 Elevate your security posture with enterprise-grade SAST analysis powered by AI and comprehensive compliance verification.
Built with ❤️ for secure software development and regulatory compliance
Apply AI-powered intelligent fixes with validation and rollback capability
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | Absolute path to the file to fix | |
| finding_ids | No | Specific finding IDs to fix | |
| strategy | No | Fix application strategy | balanced |
| validate_fixes | No | Validate fixes before applying | |
| create_backup | No | Create backup before applying fixes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions validation and rollback capabilities but lacks specifics on behavioral implications (e.g., file modification, permissions, side effects). No annotations provided.
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?
Single sentence, no wasted words, effectively conveys core purpose.
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?
With 5 parameters and no output schema, description lacks detail on validation, rollback semantics, and strategy differentiation.
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 covers 100% of parameters with descriptions; description adds minimal extra meaning beyond 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?
Clearly states 'Apply AI-powered intelligent fixes' with validation and rollback, but does not explicitly distinguish from sibling 'auto_fix_file'.
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 on when to use this tool vs alternatives like auto_fix_file, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy: Use ai_enhanced_auto_fix instead
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | ||
| create_backup | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description discloses no behavioral traits (e.g., destructive, readonly, side effects). The agent has no information about what happens if the tool is invoked.
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?
Single sentence, front-loaded with the most critical information (legacy status and replacement). No unnecessary words; highly concise.
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 deprecated tool, the description provides the essential context: do not use, use ai_enhanced_auto_fix instead. It is complete for the agent's decision to avoid this tool.
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 description adds no meaning to the parameters (filepath, create_backup). Schema coverage is 0%, and the description does not mention them at all.
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 does not state what the tool does; it only declares it as legacy and directs to an alternative. There is no verb+resource or functional description.
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?
Explicitly tells the agent not to use this tool and provides the exact alternative sibling tool (ai_enhanced_auto_fix). The usage context is clear and direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect compliance evidence with chain of custody
| Name | Required | Description | Default |
|---|---|---|---|
| scan_path | Yes | Path to scan for evidence collection | |
| frameworks | Yes | Compliance frameworks | |
| collector | Yes | Evidence collector name | |
| notes | No | Additional notes |
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 does not disclose any behavioral traits such as destructive potential, authorization needs, or side effects. 'Chain of custody' hints at logging but is not explicit.
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 states the core purpose without wasted words. It could be more informative, but it is not verbose.
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?
With 4 parameters, no output schema, and no behavioral details, the description is insufficient for full context. It does not explain what constitutes evidence, how chain of custody is maintained, or what the return value is.
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 descriptions for all four parameters. The description adds no further meaning beyond the schema, so baseline 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 ('collect') and resource ('compliance evidence') with a qualifier ('with chain of custody'), making it clear what the tool does. It distinguishes from sibling tools like 'compliance_drift_detect' or 'generate_compliance_audit_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, no prerequisites, and no conditions for appropriate use. It is a bare statement without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate advanced compliance analytics and insights
| Name | Required | Description | Default |
|---|---|---|---|
| time_range | Yes | Analysis time range | |
| frameworks | No | Specific frameworks to analyze | |
| include_predictions | No | Include predictive analytics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only vs. mutation, required permissions, side effects, or output format. The description is too brief to provide 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 very short (one sentence), which is concise but at the cost of necessary detail. It is not structured or informative enough to be effective.
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 presence of nested parameters, no output schema, and many sibling tools, the description fails to explain what the tool actually does, what output to expect, or how it differs from others like compliance_status_overview. Completeness is low.
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%, so parameters are documented in the schema. The description does not add meaning beyond the parameter names and descriptions, but it does not hurt. Baseline 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 'Generate advanced compliance analytics and insights' indicates it produces analytical results, but it is generic and does not differentiate from similar tools like compliance_status_overview or security_dashboard. The word 'advanced' is vague.
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 sibling tools. There is no mention of prerequisites, limitations, or alternatives. The agent receives no help in deciding context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create compliance baseline for drift detection
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Project path to baseline | |
| frameworks | Yes | Compliance frameworks to include | |
| baseline_name | No | Custom baseline name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states creation but fails to disclose permission requirements, overwrite behavior, or other side effects for a mutation operation.
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?
Single sentence, front-loaded and efficient, but could be slightly expanded for completeness without verbosity.
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 3 parameters, no output schema, and no annotations, the description lacks details on what happens when a baseline already exists, return values, or integration with drift detection.
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 descriptive names and short descriptions. Description adds no extra meaning beyond schema, so baseline 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 'Create compliance baseline for drift detection' uses a specific verb ('Create') and resource ('compliance baseline'), and distinguishes from siblings like 'compliance_drift_detect' which performs detection.
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 on when to use this tool vs alternatives (e.g., 'compliance_drift_detect' for detection). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect compliance drift from baseline
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Project path to scan | |
| frameworks | Yes | Compliance frameworks to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'detect', implying a read operation, but does not confirm read-only nature, mention side effects, rate limits, or authentication needs, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. However, it could benefit from a second sentence introducing what the tool returns or its relation to the baseline, balancing brevity with completeness.
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 two required parameters and no output schema or annotations, the description is incomplete. It fails to explain return format, failure states, or the need for a pre-existing baseline, which is critical given sibling tools like compliance_drift_baseline.
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 clear descriptions for both parameters ('Project path to scan', 'Compliance frameworks to check'). The description adds 'from baseline' but does not enhance parameter understanding beyond schema, so baseline score of 3 applies.
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 detects compliance drift from baseline, identifying its action and resource. It distinguishes from sibling tools like compliance_drift_baseline (which sets baseline) and compliance_status_overview (which shows current status), but could elaborate on what 'drift' entails.
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 lacks any guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., a baseline must exist) or exclusions, leaving the agent without context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive compliance status overview
| Name | Required | Description | Default |
|---|---|---|---|
| tenant_id | No | Specific tenant to analyze | |
| include_recommendations | No | Include actionable recommendations | |
| risk_threshold | No | Minimum risk level to report | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. However, it only says 'Get comprehensive compliance status overview' without mentioning whether the operation is read-only, what side effects exist, or what data is returned. This is insufficient for an agent to understand behavioral traits.
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, which is concise. However, it is too brief to convey meaningful information, trading substance for brevity. It is not wasteful, but it lacks the detail needed for a tool with many siblings.
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 (compliance overview with three parameters) and the presence of many sibling tools, the description is incomplete. There is no output schema, and the description does not explain what 'comprehensive' means or how it relates to other compliance tools. The agent would need more context to use it correctly.
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 input schema covers all three parameters with descriptions (100% coverage). The tool's description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate. No additional param information is provided in the description.
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 states 'Get comprehensive compliance status overview', which is a verb+resource but remains vague. It does not specify the scope (e.g., tenant-level, global) or what exactly 'compliance status' entails, making it hard to distinguish from siblings like 'tenant_compliance_assessment' or 'compliance_analytics_dashboard'.
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 given on when to use this tool versus alternatives. With many sibling tools covering compliance assessment, analytics, and recommendations, the description fails to indicate the tool's unique use case or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Echoes any message passed to it.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message to echo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden of behavioral disclosure. It describes the tool as echoing a message, which implies idempotent and safe operation. No additional behavioral traits (e.g., side effects, limitations) are mentioned, but given the trivial nature of the tool, this is adequate.
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 that is concise and directly to the point. Every word serves a purpose, and there is no fluff.
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 extreme simplicity (single string parameter, no output schema, no annotations), the description is complete. It provides all necessary information for an AI agent to understand and invoke the tool correctly.
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 has 100% coverage with a single parameter 'message' described as 'The message to echo'. The description adds 'Echoes any message passed to it', which essentially paraphrases the schema. With high schema coverage, baseline 3 is appropriate, and the description does not significantly enhance parameter meaning.
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 'Echoes any message passed to it' uses a specific verb ('echoes') and resource ('message'), clearly stating the tool's function. It is distinct from all sibling tools, which are security/compliance-related, so there is no confusion.
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 explicit guidance on when to use this tool vs. alternatives is provided. However, due to its simplicity and the unrelated nature of sibling tools, the lack of guidance is not a major issue, but still a gap for minimal viable score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform comprehensive multi-tool SAST scan on directory with continuous monitoring option
| Name | Required | Description | Default |
|---|---|---|---|
| dirpath | Yes | Absolute path to the directory to scan | |
| enableMonitoring | No | Enable continuous monitoring | |
| schedule | No | Cron schedule for monitoring (e.g., '0 */6 * * *') | |
| policies | No | Compliance policies to enforce | |
| user_token | No | Authentication token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool performs a scan with monitoring, but does not mention whether it modifies files, requires authentication (despite having a 'user_token' parameter), or any side effects. Critical behavioral context is missing.
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, front-loaded sentence that conveys the core functionality. It is concise but could be restructured to include more detail without becoming verbose.
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?
With 5 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain what 'comprehensive' and 'multi-tool' entail, the monitoring lifecycle, or the output format. Sibling tools like 'scan_directory' suggest a simpler variant, but no differentiation is provided.
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 covers all 5 parameters with descriptions, so baseline is 3. The tool description does not add additional meaning or context beyond the schema, such as clarifying the relationship between 'enableMonitoring' and 'schedule', or the expected format of 'policies'.
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 action ('Perform comprehensive multi-tool SAST scan') and the resource ('directory'), and highlights the key differentiator ('continuous monitoring option'). This distinguishes it from sibling tools like 'scan_directory'. However, it could be more specific about what 'multi-tool' means.
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 explicit when-to-use or when-not-to-use guidance is provided. The description does not contrast with sibling tools or specify prerequisites. The only implicit guidance is the 'continuous monitoring' option, but no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform comprehensive multi-tool SAST scan on a single file with AI-powered analysis
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | Absolute path to the file to scan | |
| tools | No | Specific tools to use (default: auto-detect) | |
| policies | No | Compliance policies to check (owasp, pci, nist) | |
| includeFixSuggestions | No | Generate AI-powered fix suggestions | |
| user_token | No | Authentication token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'multi-tool SAST' and 'AI-powered analysis' but does not disclose any behavioral traits such as authentication requirements (user_token), rate limits, side effects, or whether the scan modifies files. This leaves significant gaps for an AI agent.
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 14 words, which is concise. However, it is too brief; it could benefit from additional structure (e.g., bullet points) to convey important details without sacrificing conciseness.
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 (5 parameters, no output schema, no annotations), the description is incomplete. It does not explain return values, error conditions, or prerequisites. An AI agent would lack critical context for invoking this tool correctly.
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%, so baseline is 3. The description adds no extra meaning beyond the schema; it does not explain parameter relationships or provide context that the schema lacks.
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 verb ('scan'), resource ('single file'), and scope ('comprehensive multi-tool SAST scan with AI-powered analysis'), distinguishing it from siblings like 'scan_file' (basic) and 'enhanced_scan_directory' (directory-level).
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 for comprehensive single-file scans, but does not explicitly state when to use this tool vs alternatives like 'scan_file' or 'enhanced_scan_directory'. 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.
Generate comprehensive audit report with evidence chain
| Name | Required | Description | Default |
|---|---|---|---|
| frameworks | Yes | Frameworks to include in audit | |
| time_range | Yes | Time range for audit | |
| report_format | No | detailed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden but only vaguely mentions 'evidence chain', failing to disclose side effects (e.g., is it read-only?), authorization needs, or output characteristics. The behavior is underspecified.
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 with no waste, but it is too terse and lacks front-loading of key information. It does not leverage any structural elements like bullet points for clarity.
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?
The description is incomplete for the tool's complexity (3 params, no output schema). It fails to explain 'evidence chain', expected output, or how it integrates with other compliance tools, leaving critical gaps.
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 67% (medium). The description adds no extra meaning beyond the schema's parameter descriptions, which are already functional. The nested 'time_range' and enum 'report_format' are adequately explained in 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 clearly states the verb 'generate' and resource 'audit report', with 'evidence chain' hinting at added value. However, it lacks specificity on what 'comprehensive' entails and how it differs from similar tools like 'compliance_status_overview'.
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 on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use, or refer to sibling tools, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate comprehensive security report with executive summary, compliance matrix, and recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| scan_path | Yes | Path that was scanned | |
| report_dir | Yes | Directory to save reports | |
| format | Yes | Report format | |
| include_executive_summary | No | Include executive summary | |
| include_compliance_matrix | No | Include compliance matrix | |
| include_recommendations | No | Include actionable recommendations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only lists outputs (executive summary, compliance matrix, recommendations) but does not disclose side effects, permissions required, whether the tool modifies state, or any constraints. With no annotations, the description carries full burden but fails to provide safety or behavioral context beyond the output.
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 concise (one sentence, nine words) and front-loaded. However, it lacks depth, and while brevity is valued, it compromises completeness. It could include more context without exceeding an appropriate length.
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 has 6 parameters and no output schema, the description should clarify what the tool returns and how it integrates with other tools. It only lists report components but omits return format, success criteria, or error handling, making it incomplete for effective use.
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 input schema has 100% description coverage, so the schema already defines all parameters. The description adds no extra parameter details beyond the schema, meeting the baseline expectation.
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 it generates a 'comprehensive security report' with specific components like executive summary, compliance matrix, and recommendations. However, it does not differentiate from sibling report-generation tools such as 'generate_compliance_audit_report' or 'generate_sast_report', which may have overlapping 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 like 'generate_compliance_audit_report' or 'enhanced_scan_directory'. There are no mentions of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy: Use generate_enhanced_report instead
| Name | Required | Description | Default |
|---|---|---|---|
| scan_path | Yes | ||
| report_dir | Yes | ||
| format | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only labels the tool as 'Legacy', which implies it may be outdated or unsupported, but does not disclose any behavioral details such as potential side effects or deprecation consequences. Without annotations, the description carries the burden of transparency and fails to provide substantive 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loads the critical deprecation notice. While very brief, it purposefully avoids extraneous detail for a deprecated tool, earning its place.
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 that the tool is deprecated and the sibling tools include the recommended replacement, the description is functionally complete for its purpose. It directs agents to the correct tool without needing further elaboration.
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 input schema has three parameters with 0% description coverage, and the tool description adds no meaning or context for any parameter. Agents receive no guidance on what 'scan_path', 'report_dir', or 'format' represent or how to use them.
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 does not specify the tool's function beyond indicating it is legacy. The name 'generate_sast_report' hints at generating a SAST report, but the description provides no clarification of its purpose, making it nearly tautological.
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 explicitly states to use 'generate_enhanced_report' instead, providing clear and direct guidance on when to avoid this tool and which alternative to choose. This is optimal for a deprecated tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive vulnerability information with OWASP mapping, CWE references, and remediation guidance
| Name | Required | Description | Default |
|---|---|---|---|
| vuln_type | Yes | Type of vulnerability |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It implies a read operation but does not explicitly state idempotency, side effects, or permission requirements. The promise of 'comprehensive' information lacks specifics about scope or reliability.
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 single-sentence description is concise and front-loaded with the key action and resource. However, it omits usage guidelines that could be incorporated without significant bloat, preventing a perfect score.
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 purpose to deliver detailed vulnerability info and the lack of an output schema, the description provides minimal context about what the response contains (OWASP, CWE, remediation). It does not mention severity, affected components, or examples, leaving gaps.
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% and the only parameter 'vuln_type' is well-defined with an enum and a description. The tool description adds no extra meaning beyond 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 states the action (Get), the resource (vulnerability information), and specifies included content (OWASP mapping, CWE references, remediation guidance). It effectively distinguishes from sibling tools like scanning or fixing, which address 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 siblings such as 'enhanced_scan_file' or 'scan_directory', nor are there any prerequisites or exclusions mentioned. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available compliance frameworks with their status
| Name | Required | Description | Default |
|---|---|---|---|
| industry_filter | No | Filter by industry (healthcare, finance, etc.) | |
| enabled_only | No | Show only enabled frameworks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by listing frameworks, but with no annotations to confirm, it relies on inference. It discloses the output includes 'status' but does not detail behavior beyond listing. Adequate, not explicit.
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?
A single concise sentence of 10 words clearly conveys the tool's purpose with no wasted words. Efficiently structured for quick consumption.
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?
With no output schema, the description does not clarify the return format or what 'status' entails. The presence of many sibling tools suggests the need for more context, but the description is minimally adequate for a simple list tool.
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% and each parameter has a description. The tool description adds no additional meaning beyond what the schema provides, so 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 states the verb 'List' and resource 'compliance frameworks' with detail 'with their status', making the tool's function explicit. It is specific enough to understand the core action, though it could better differentiate from sibling tools like 'compliance_status_overview'.
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. Given siblings like 'compliance_status_overview' that may serve similar purposes, the absence of usage context makes selection ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage security policies and compliance frameworks
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Policy management action | |
| policy_name | No | Policy name for get/check actions | |
| scan_results | No | Scan results for compliance checking |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits (e.g., read-only via list/get/check, side effects, authentication needs). The verb 'manage' is ambiguous.
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?
Only one sentence that is underspecified, not concise in a helpful way. It omits critical information while being short, failing to earn its place.
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?
With no output schema, no annotation, and many siblings, the description is severely incomplete. It does not explain the relationship between actions, policy_name, scan_results, or what the tool returns.
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 has 100% description coverage with minimal but clear parameter descriptions. The tool description adds no additional meaning beyond the schema, meeting the baseline but not exceeding it.
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?
Description 'Manage security policies and compliance frameworks' is vague and largely restates the tool name without specifying distinct capabilities. It does not differentiate from sibling tools like list_compliance_frameworks or compliance_analytics_dashboard.
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 on when to use this tool versus the many compliance-related siblings. Missing context about actions, prerequisites, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register new tenant with compliance configuration
| Name | Required | Description | Default |
|---|---|---|---|
| tenant_id | Yes | Unique tenant identifier | |
| tenant_config | Yes | Tenant configuration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'Register...', lacking details on side effects (e.g., idempotency, what if tenant exists), authentication needs, or error conditions.
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, short sentence with no extra words. It is front-loaded with the verb and resource.
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 being a registration tool with a complex nested object and no output schema, the description provides no information about return values, success conditions, or validation rules. It feels incomplete.
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 covers 100% of parameters with descriptions. The tool description adds no additional meaning beyond the schema, 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 clearly states the action (Register) and the resource (new tenant with compliance configuration). It is specific and distinguishes itself from sibling tools, none of which have a 'register' operation.
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 prerequisites or exclusions. The description simply states the purpose without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy: Use enhanced_scan_directory instead
| Name | Required | Description | Default |
|---|---|---|---|
| dirpath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authorization needs, or return behavior. The only information is that it is legacy.
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 one short sentence, which is concise, but it lacks structure and does not serve as a proper tool description. It reads as a warning rather than informative content.
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 (one parameter, no output schema), the description is insufficient. It does not explain the tool's original purpose or why it is legacy, leaving the agent with no understanding of the tool's functionality.
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 input schema has one required parameter (dirpath) with no description, and schema description coverage is 0%. The description adds no meaning to the parameter, failing to compensate for the lack of schema documentation.
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 does not state what the tool does. It only says 'Legacy: Use enhanced_scan_directory instead,' which is a deprecation notice, not a description of the tool's function.
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 clearly advises against using this tool and explicitly names the alternative (enhanced_scan_directory). This provides strong usage guidance, although it doesn't explain when one might still need to use this legacy version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy: Use enhanced_scan_file instead
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait disclosed is that the tool is legacy/deprecated. No other behavior (e.g., what it does, side effects, permissions) is described, and no annotations exist to fill the gap.
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?
A single, brief sentence that conveys the essential deprecation message without any 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?
For a legacy tool, the description is too sparse. It does not explain the tool's function, return values, or whether it still works, which may confuse an agent considering invocation.
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 has one parameter (filepath) with 0% description coverage, and the description adds no information about it, failing to compensate for the schema gap.
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 does not state what the tool does (e.g., scans a file for vulnerabilities). It only marks it as legacy and directs to enhanced_scan_file, which implies a scanning function but leaves the purpose vague.
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?
Explicitly says to use enhanced_scan_file instead, providing clear guidance on when not to use this tool and a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time security dashboard with metrics, trends, and alerts
| Name | Required | Description | Default |
|---|---|---|---|
| time_range | No | Time range for metrics | 24h |
| include_trends | No | Include trend analysis | |
| include_alerts | No | Include active alerts | |
| user_token | No | Authentication token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It implies read-only behavior but does not disclose authentication needs (user_token parameter exists), rate limits, or consequences of invocation. The term 'real-time' is vague.
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 8 words, very concise. However, its brevity sacrifices informativeness; it could be expanded without losing conciseness.
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?
With 4 parameters, no output schema, and no annotations, the description fails to explain return format, data freshness, or authentication requirements. It is insufficient for an agent to fully understand usage.
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%, so baseline is 3. The description mentions 'metrics, trends, and alerts' which loosely maps to include_trends and include_alerts, but does not add meaningful detail 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 clearly states it retrieves a real-time security dashboard with metrics, trends, and alerts. However, it does not differentiate from sibling tools like 'compliance_analytics_dashboard', which could be confused.
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 (e.g., compliance dashboards). There are no prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start continuous security monitoring for a project with real-time alerts
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Project directory to monitor | |
| schedule | No | Cron schedule for comprehensive scans | 0 */6 * * * |
| alert_thresholds | No | Alert thresholds by severity | |
| user_token | No | Authentication token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions 'real-time alerts' but fails to explain continuous background execution, how to stop monitoring, resource consumption, or authentication expectations beyond the token parameter.
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 that front-loads the core purpose. While efficient, it could include more context without sacrificing conciseness.
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 complexity of a continuous monitoring tool (4 parameters, nested object, no output schema), the description lacks crucial details about return values, lifecycle management, and side effects, making it insufficient for complete understanding.
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%, and each parameter has a schema description. The tool description adds no additional semantics beyond the schema, so a 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 states the action ('start') and the target ('continuous security monitoring with real-time alerts'), distinguishing it from one-time scan tools like scan_directory.
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 (e.g., one-time scans), nor does it mention prerequisites or scenarios where it is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform compliance assessment for specific tenant
| Name | Required | Description | Default |
|---|---|---|---|
| tenant_id | Yes | Tenant identifier | |
| project_path | Yes | Project path to assess |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the assessment is read-only, destructive, or requires specific permissions. The agent has no insight into side effects or constraints.
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 extremely concise—a single sentence that front-loads the action. It is efficient, but the brevity leaves out important details. Still, it is well-structured for quick parsing.
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?
With no output schema, no annotations, and a minimalist description, the tool lacks critical context. The agent has no information about what the assessment returns, whether it is a long-running operation, or how results are formatted. Significant gaps exist for a compliance-related tool.
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?
Input schema has 100% coverage with descriptions for both parameters (tenant_id, project_path). The description adds minimal value beyond what the schema already provides, so a 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 states the verb 'perform' and the resource 'compliance assessment for specific tenant', which conveys the core function. However, it does not distinguish from sibling tools like collect_compliance_evidence or compliance_drift_detect, which also involve compliance assessments.
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. The description lacks any context about prerequisites, appropriate scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger automated compliance remediation workflow
| Name | Required | Description | Default |
|---|---|---|---|
| finding | Yes | Vulnerability finding | |
| framework | Yes | Compliance framework | |
| automation_level | No | semi_automatic | |
| stakeholders | No | Additional stakeholders to notify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states 'trigger automated compliance remediation workflow' without mentioning side effects, state changes, authentication needs, or rate limits. It does not even indicate if it is a read or write operation.
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 five words, making it concise but not adequately structured. While it states the core purpose, it omits important details, making it minimally viable but not optimally informative.
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 has 4 parameters including a nested object, no output schema, and no annotations, the description is entirely insufficient. It does not explain the workflow's behavior, return values, or how to use the parameters effectively.
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 input schema covers 75% of parameters with descriptions. The tool's description adds no additional meaning beyond what the schema provides, and fails to explain the nested 'finding' object or the 'automation_level' enum.
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 indicates it initiates an automated compliance remediation workflow, using the verb 'trigger' and specifying the resource. However, it does not distinguish this from sibling tools like 'ai_enhanced_auto_fix' or 'collect_compliance_evidence', which may have overlapping 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?
The description provides no guidance on when to use this tool vs alternatives, nor any prerequisites or limitations. For example, it does not clarify if this should be used after a compliance scan or if specific findings are required.
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.
v2.1.0ai_enhanced_auto_fixauto_fix_filecollect_compliance_evidencecompliance_analytics_dashboardcompliance_drift_baselinecompliance_drift_detectcompliance_status_overviewechoenhanced_scan_directoryenhanced_scan_filegenerate_compliance_audit_reportgenerate_enhanced_reportgenerate_sast_reportget_enhanced_vulnerability_infolist_compliance_frameworksmanage_security_policiesregister_compliance_tenantscan_directoryscan_filesecurity_dashboardstart_continuous_monitoringtenant_compliance_assessmenttrigger_compliance_remediationSeveral tools overlap or are redundant, especially legacy tools (auto_fix_file, generate_sast_report, scan_directory, scan_file) that are explicitly superseded. The compliance tools are numerous and have subtle distinctions, while the echo tool is unrelated to the domain. Agents may struggle to select the correct tool.
Tool names predominantly follow a verb_noun convention using snake_case, e.g., ai_enhanced_auto_fix, collect_compliance_evidence. A few names start with a noun (compliance_analytics_dashboard) breaking the pattern slightly, but overall consistency is high.
23 tools is high for a security scanner, especially with 4 legacy tools that could be removed. The domain (SAST + compliance) is broad, but the count feels slightly bloated. The echo tool seems unnecessary.
The tool set covers scanning, vulnerability info, reporting, compliance management, remediation, and monitoring. Minor gaps: no direct tool for user/team management, and legacy tools might cause confusion. Overall, core workflows are well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
MCP server for static security analysis of Android source code
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/george-mellow/spotter-sast'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
