This server provides a central interface to the USAP open-source cybersecurity agent skills library, enabling LLM clients to discover, validate, and route security workflows with human-approval gating.
Core capabilities:
list_skills – List all 79 USAP cybersecurity skills with descriptions, optionally filtered by domain (e.g., detection, appsec-devsecops, red-team, cloud-infra).
list_agents – List all 12 cs-* orchestrator agents (e.g., cs-security-analyst, cs-incident-responder).
get_skill – Retrieve the full SKILL.md system prompt for any skill by slug (e.g., vuln-scan, threat-hunting) to activate it as LLM context.
get_agent – Retrieve the full definition for any cs-* orchestrator agent to activate its persona in the client LLM.
validate_payload – Check whether a JSON payload conforms to the USAP 11-field output contract, returning PASS or a list of violations.
route_payload – (Phase 2) Determine which specialist downstream MCP (Splunk, CrowdStrike, Okta, AWS Security Hub, etc.) should handle a validated payload; enforces the human_approval_required gate and audits all decisions.
list_mcps – View all registered specialist MCPs, including their status, declared capabilities, and routing rules.
dispatch_after_approval – (Phase 3) After explicit human approval, invoke the downstream capability on the target MCP and record a full audit trail.
Signal Architecture · agents reason · humans approve · MCP executes
Open-source cybersecurity skills library that turns any LLM into an auditable, portable security workflow runtime for SOC and AppSec teams.
Each SKILL.md is a complete LLM system prompt — paste into Claude, ChatGPT, Gemini, Ollama, or AnythingLLM with no install. Apache 2.0, typed 11-field output contract, framework-mapped (MITRE ATT&CK, NIST CSF 2.0, OWASP Top 10, ATLAS, D3FEND, NIST AI RMF), L1–L4 autonomy with explicit human-approval gates.
If this is useful, star the repo — it's the cheapest signal to send and the only one that drives discovery. Want to contribute? The open invitations in
ROADMAP.mdare picked tasks, not vague areas.
▶ See every pillar run with real, reproducible output → examples/ · Install on your platform → INSTALLATION.md
If you have Claude Code installed, type these two slash commands in any project:
/plugin marketplace add jaskaranhundal/usap-skills
/plugin install usap@usapThat activates 7 slash commands (/usap:run, /usap:fortigate, /usap:orchestrate, /usap:challenge, /usap:compare, /usap:test, /usap:README) and 6 user-invocable orchestrator skills (@usap-alex, @usap-ciso, @usap-devsecops, @usap-incident-responder, @usap-program-manager, @usap-red-teamer).
Smoke test it:
/usap:fortigateAlex runs the AT + CA workflows against the bundled Fintech FortiGate zero-day scenario and produces a 7-task scorecard.
git clone https://github.com/jaskaranhundal/usap-skills.git
cd usap-skills
python3 shared/scripts/bundle_usap.py bundle --mode lite # → dist/USAP_LITE.md (32 KB)
# python3 shared/scripts/bundle_usap.py bundle --mode pro # → dist/USAP_PRO.md (185 KB — Gemini 1.5 Pro / 2.0 Flash)
# python3 shared/scripts/bundle_usap.py bundle --mode full # → dist/USAP_BUNDLE.md (744 KB — Claude Opus / GPT-5 / Gemini 2.5 Pro)Paste dist/USAP_LITE.md as the system prompt in any LLM. No npm, no Docker, no API key, no signup. The bundled file is one markdown blob that becomes Alex (cs-security-analyst) on any model.
Open docs/design-system/ui_kits/platform/index.html in any browser for the 3-screen click-through (Landing → Agent Console → Findings).
USAP also runs as a stdlib-only Model Context Protocol server. Add to your client's MCP config:
{
"mcpServers": {
"usap": {
"command": "python3",
"args": ["/absolute/path/to/usap-skills/tools/mcp_server.py"]
}
}
}Connect, then ask plain-English security questions — your client discovers and loads USAP skills and cs-* agents on demand. Read-only Phase 1 today; Phase 2 turns USAP into the master MCP routing security intents to downstream vendor MCPs (SIEM, EDR, firewall) with the contract's human_approval_required gate enforcing the human approval step. Full docs at docs/mcp-server.md.
Related MCP server: wrg-mcp-server
The diagram above is the architecture diagram — a Signal-Architecture-styled hex constellation with all 12 cs-* agents around the central USAP hub. Domain colour-coding on the border: security/ cyan · appsec/ violet · devsecops/ orange · executive/ blue · governance/ green. Regenerate with python3 tools/gen_architecture_svg.py.
flowchart LR
SK["79 skills across<br/>12 domains<br/>(SKILL.md + scripts/)"]:::skill --> A
subgraph A ["12 cs-* orchestrator agents"]
direction TB
subgraph S ["agents/security/"]
S1[cs-security-analyst]
S2[cs-incident-responder]
S3[cs-red-teamer]
S4[cs-blue-team-analyst]
S5[cs-cloud-investigator]
S6[cs-supply-chain-defender]
S7[cs-threat-intel-lead]
S8[cs-purple-team-lead]
end
subgraph P ["agents/appsec/"]
P1[cs-appsec-engineer]
end
subgraph D ["agents/devsecops/"]
D1[cs-devsecops-engineer]
end
subgraph E ["agents/executive/"]
E1[cs-ciso-advisor]
end
subgraph G ["agents/governance/"]
G1[cs-security-program-manager]
end
end
A --> OUT["11-field JSON output contract<br/>agent_slug · intent_type · action<br/>rationale · confidence · severity<br/>key_findings · evidence_references<br/>next_agents · human_approval_required<br/>timestamp_utc"]:::out
classDef skill fill:#06222b,stroke:#29d3f0,stroke-width:1px,color:#e6edf3
classDef out fill:#1c2230,stroke:#d2a8ff,stroke-width:1px,color:#e6edf3Skills are stateless prompt + tool packages (SKILL.md + stdlib scripts/). Orchestrator agents compose them via the v2 agent contract (standards/agent-contract.md). Every output validates against the typed 11-field contract (standards/output-contract.md).
Interactive UI kit: for the same flow as a clickable web demo (Landing → Agent Console → Findings), open
docs/design-system/ui_kits/platform/index.html— built on the USAP Design System: Signal Architecture visual language, 10 React components, 160+ CSS tokens.
Every skill emits the same shape. Below is a fully-populated payload from one run of vuln-scan against the in-repo SimpleStoreAPI fixture — all 11 required fields plus the optional tail (mitre_ttps, affected_assets, artifact_path). Byte-identical to appsec-devsecops/vuln-scan/expected_outputs/sample_output.json, validated against tools/output_contract.py in CI on every push.
{
"agent_slug": "vuln-scan",
"intent_type": "detect",
"action": "Hand off to finding-triage — 4 mapped findings, 1 unmapped, top severity high.",
"rationale": "Scanned SimpleStoreAPI against TM-001..TM-005. Found 5 distinct findings after dedup: hardcoded credential (TM-001 proximity 9), SQL string concat (TM-002 proximity 8), public S3 ACL (TM-002 proximity 7), permissive CORS (unmapped), missing input validation on /api/v1/profile (TM-001 proximity 9). Confidence dampened 0.05 per merge.",
"confidence": 0.82,
"severity": "high",
"key_findings": [
"VF-001 hardcoded-credential at src/config.py:14 — mapped to TM-001, proximity 9",
"VF-002 sql-string-concat at src/db/profile.js:42 — mapped to TM-002, proximity 8",
"VF-003 public-iac at infra/storage.tf:21 — mapped to TM-002, proximity 7",
"VF-004 missing-input-validation at src/routes/profile.js:11 — mapped to TM-001, proximity 9",
"VF-005 permissive-cors at src/middleware/cors.js:6 — UNMAPPED (no top-5 threat covers this)"
],
"evidence_references": [
{"source": "scanner", "ref": "src/config.py:14", "quote": "PASSWORD = \"changeme-prod\""},
{"source": "scanner", "ref": "src/db/profile.js:42", "quote": "db.query('SELECT * FROM users WHERE id = ' + req.params.id)"},
{"source": "scanner", "ref": "infra/storage.tf:21", "quote": "acl = \"public-read\""}
],
"next_agents": ["finding-triage"],
"human_approval_required": false,
"timestamp_utc": "2026-06-20T10:30:00Z",
"mitre_ttps": ["T1552.001", "T1190"],
"affected_assets": ["SimpleStoreAPI"],
"artifact_path": "/tmp/simple-store-api/VULN-FINDINGS.json"
}The 11 required fields are: agent_slug, intent_type, action, rationale, confidence, severity, key_findings, evidence_references, next_agents, human_approval_required, timestamp_utc. Optional extras after that. The CI gate fails any committed sample that drops a required field.
New here? Read: USAP vs Prompt Libraries — why a
SKILL.mdis more than a folder of prompts.
Open source, no SaaS, no waitlist. Apache 2.0. Drop the skills into Claude, ChatGPT, Gemini, Ollama, or AnythingLLM with no platform install. No vendor cloud, no per-seat pricing, no telemetry leaving your environment.
Standardized 11-field output contract. Every skill emits CVSS, MITRE ATT&CK technique IDs, evidence references, and an explicit human_approval_required flag (standards/output-contract.md). Safe to embed in production agent stacks where competitor copilots remain black boxes.
cs-* orchestrator agents. 12 named agents (cs-security-analyst, cs-incident-responder, cs-blue-team-analyst, cs-red-teamer, cs-cloud-investigator, cs-supply-chain-defender, cs-threat-intel-lead, cs-purple-team-lead, cs-appsec-engineer, cs-devsecops-engineer, cs-ciso-advisor, cs-security-program-manager) compose the skills into reproducible workflows.
Framework-mapped at the metadata layer. metadata.frameworks.{mitre_attack, nist_csf, mitre_atlas, owasp_top10, d3fend, nist_ai_rmf} arrays drive auto-generated ATT&CK Navigator and NIST CSF coverage docs in mappings/ — never hand-maintained.
L1–L4 autonomy model. Mutating intents (key rotation, isolation, account disablement) carry explicit human_approval_required: true gates. Predictable behaviour at every level.
agentskills.io spec-conformant. Every USAP SKILL.md validates against the open standard (verified on 2026-06-20). Drop USAP into any agentskills.io-compatible client — Claude Code, Cursor, Goose, OpenCode, GitHub Copilot, Gemini CLI, OpenAI Codex CLI, and 30+ others.
USAP is built for three teams that already own LLM access and don't want to rent another SaaS:
SOC and detection engineering teams (50–500-person security orgs) running Splunk / Sentinel + EDR who want a vetted, MITRE-mapped skills library to amplify analyst output. Activate cs-security-analyst for any alert; cascade to cs-blue-team-analyst, cs-threat-intel-lead, or cs-incident-responder.
DevSecOps and platform-security engineers at engineering-led orgs who use Claude Code or similar. Embed cs-devsecops-engineer and cs-appsec-engineer in CI; route runtime findings into webapp-security/.
MSSPs, security consultancies, and red teamers who need client-ready CVSS / MITRE / evidence-tagged deliverables. White-label the skills, embed in your own delivery stack, ship.
A real run of cs-appsec-engineer against the in-repo SimpleStoreAPI fixture. The animation above and the transcript below show the same data — every line of JSON is byte-identical to appsec-devsecops/vuln-scan/expected_outputs/sample_output.json. Regenerate the animation with python3 tools/gen_demo_svg.py.
You: Scan examples/SimpleStoreAPI for vulnerabilities and route any high findings to triage.
cs-appsec-engineer: Running vuln-scan against threat model TM-001..TM-005.
$ python3 appsec-devsecops/vuln-scan/scripts/vuln-scan_tool.py \
--input examples/SimpleStoreAPI/scan-context.json --output json{
"agent_slug": "vuln-scan",
"intent_type": "detect",
"action": "Hand off to finding-triage — 4 mapped findings, 1 unmapped, top severity high.",
"rationale": "Scanned SimpleStoreAPI against TM-001..TM-005. Found 5 distinct findings after dedup: hardcoded credential (TM-001 proximity 9), SQL string concat (TM-002 proximity 8), public S3 ACL (TM-002 proximity 7), permissive CORS (unmapped), missing input validation on /api/v1/profile (TM-001 proximity 9). Confidence dampened 0.05 per merge.",
"confidence": 0.82,
"severity": "high",
"key_findings": [
"VF-001 hardcoded-credential at src/config.py:14 — mapped to TM-001, proximity 9",
"VF-002 sql-string-concat at src/db/profile.js:42 — mapped to TM-002, proximity 8",
"VF-003 public-iac at infra/storage.tf:21 — mapped to TM-002, proximity 7",
"VF-004 missing-input-validation at src/routes/profile.js:11 — mapped to TM-001, proximity 9",
"VF-005 permissive-cors at src/middleware/cors.js:6 — UNMAPPED (no top-5 threat covers this)"
],
"evidence_references": [
{"source": "scanner", "ref": "src/config.py:14", "quote": "PASSWORD = \"changeme-prod\""},
{"source": "scanner", "ref": "src/db/profile.js:42", "quote": "db.query('SELECT * FROM users WHERE id = ' + req.params.id)"},
{"source": "scanner", "ref": "infra/storage.tf:21", "quote": "acl = \"public-read\""}
],
"next_agents": ["finding-triage"],
"human_approval_required": false,
"timestamp_utc": "2026-06-20T10:30:00Z"
}cs-appsec-engineer: Severity is high, next_agents points at finding-triage. Handing off.
Synthesis (operator-facing):
Five findings, four mapped to your threat model. The hardcoded production credential (
src/config.py:14) and the SQL string concatenation on the profile route are both proximity-9 hits against TM-001 — patch first. The public S3 bucket ACL is a separate proximity-7 TM-002 hit. The permissive CORS rule is unmapped, which usually means your threat model is incomplete — recommend revisiting TM coverage. No mutating actions taken;human_approval_requiredwas false because this was a read-only detect.
Try it yourself:
python3 appsec-devsecops/vuln-scan/scripts/vuln-scan_tool.py --output json | jq .
python3 tools/output_contract.py appsec-devsecops/vuln-scan/expected_outputs/sample_output.jsonClaim | Evidence |
Typed 11-field output contract |
|
Every skill emits a real payload |
|
MITRE ATT&CK Navigator layer is auto-generated |
|
NIST CSF 2.0 coverage doc is auto-generated | |
MITRE ATT&CK coverage doc |
|
L1-L4 autonomy + |
|
agentskills.io spec conformance |
|
The full layer at mappings/mitre-attack/attack-navigator-layer.json opens directly in MITRE's Navigator. Excerpt of the first two techniques:
{
"name": "USAP MITRE ATT&CK Coverage",
"versions": {
"attack": "16",
"navigator": "4.9.5",
"layer": "4.5"
},
"domain": "enterprise-attack",
"techniques": [
{
"techniqueID": "T1041",
"score": 1,
"color": "",
"comment": "USAP skills covering: detection/threat-intelligence",
"enabled": true,
"metadata": [],
"links": [],
"showSubtechniques": true
},
{
"techniqueID": "T1046",
"score": 1,
"color": "",
"comment": "USAP skills covering: detection/threat-hunting",
"enabled": true,
"metadata": [],
"links": [],
"showSubtechniques": true
}
]
}From mappings/nist-csf/csf-alignment.md:
Subcategory | Skill count | Covering skills |
| 3 |
|
| 2 |
|
| 1 |
|
These tables are not hand-maintained. They are emitted by tools/framework_extractor.py from each skill's metadata.frameworks.* arrays. The CI pipeline fails any PR that ships a drift between the source frontmatter and the generated docs.
One agent. Any security question. Paste and go.
Who you are | Paste this | Works on |
Anyone — business owner, IT admin, or security engineer |
| Claude, ChatGPT, Gemini, Ollama |
Security team needing full orchestration across specialist agents |
| Claude, ChatGPT, Gemini, Ollama |
Security program with all 79 skills embedded |
| Claude, ChatGPT, Gemini |
Generate your kit:
python3 shared/scripts/bundle_usap.py bundle --mode lite # → dist/USAP_LITE.md
python3 shared/scripts/bundle_usap.py bundle --mode pro # → dist/USAP_PRO.md
python3 shared/scripts/bundle_usap.py bundle --mode full # → dist/USAP_BUNDLE.mdAlex (cs-security-analyst) is the single entry point for all three kits. You do not need to know which agent or skill to use — Alex figures that out.
Lite: Alex answers directly from knowledge of all 79 USAP skills. Plain English by default; goes fully technical when you ask.
Pro / Full: Alex detects multi-domain problems, activates party mode (OR), delegates to specialist agents (cs-incident-responder, cs-ciso-advisor, etc.), and synthesizes one unified answer.
Any LLM: Paste the file as your system prompt. No install required.
Future: MCP connectors will let Alex pull live cloud inventory, SIEM, and EDR data automatically. Until then, paste logs or describe your environment.
Three ways — pick the one that fits your setup:
Go to aistudio.google.com
Click Create new prompt → set type to Chat
Paste the contents of dist/USAP_LITE.md into the System instructions field
Start chatting with Alex
Go to gemini.google.com → Gems → Create a Gem
Name: USAP Security Advisor
Instructions: paste the contents of dist/USAP_LITE.md
Save and chat
# Install the SDK
pip install google-generativeai
# Set your API key (get one free at aistudio.google.com)
export GEMINI_API_KEY="your-key-here"
# Start a chat session with Alex
python3 shared/scripts/gemini_chat.py --kit lite
# Use the pro kit (Alex + all 6 specialist agents)
python3 shared/scripts/gemini_chat.py --kit pro
# Use a different model
python3 shared/scripts/gemini_chat.py --kit lite --model gemini-1.5-proKit size guide:
Kit | Size | Recommended for |
| 32 KB | Any Gemini model, free tier |
| 121 KB | Gemini 1.5 Pro / 2.0 Flash |
| 684 KB | Gemini 1.5 Pro (2M context) |
USAP agents are registered as native slash commands in both Gemini CLI and Claude Code.
npm install -g @google/gemini-cli
cd usap-skills
gemini # GEMINI.md auto-loaded
/usap-alex # Activate cs-security-analystcd usap-skills
claude # CLAUDE.md auto-loaded
/usap-alex # Activate cs-security-analystCommand | Agent | Use for |
| cs-security-analyst | Any security question — universal entry point |
| cs-incident-responder | Active incidents, forensics, containment |
| cs-red-teamer | Red team planning and offensive security |
| cs-devsecops-engineer | Pipeline security, SAST/DAST, PR gates |
| cs-ciso-advisor | Board reports, risk posture, executive briefs |
| cs-security-program-manager | Security roadmap and program planning |
Situation | Start here | Then cascade to |
Any new security event |
| Routes to the right specialist |
Confirmed active incident, need command |
|
|
Need to contain an active threat |
| MCP execution layer |
Ransomware or destructive attack |
|
|
Forensic timeline and chain of custody |
|
|
Situation | Agent |
Secret/API key found in code or logs |
|
IAM anomaly, privilege escalation, root usage |
|
Unusual user behavior, insider threat indicators |
|
Cryptographic key management risk |
|
Situation | Agent |
Hypothesis-driven threat hunt |
|
IOC enrichment and actor attribution |
|
Anomaly or behavioral deviation |
|
Active network intrusion or lateral movement |
|
Situation | Agent |
CVE triage and prioritization |
|
Zero-day, no patch available |
|
Code scanning (SAST/DAST) results |
|
IaC misconfiguration |
|
Cloud posture and drift |
|
Dependency and SBOM analysis |
|
Situation | Agent |
AWS/Azure/GCP misconfiguration scan |
|
Container image vulnerability scan (Trivy/Grype/Snyk) |
|
Public attack surface mapping |
|
Network exposure and open ports |
|
Endpoint and OS security |
|
OT/ICS/IoT device security |
|
Build pipeline integrity |
|
Situation | Agent |
Write a detection rule for a new TTP |
|
Assess telemetry data quality |
|
Continuous automated pentesting results |
|
AI/LLM agent integrity and prompt injection |
|
Situation | Agent |
Threat model a new system or feature |
|
Security architecture review |
|
AI system ethics and governance |
|
AI agent security assessment |
|
Situation | Agent |
Map findings to compliance frameworks |
|
Track regulatory horizon changes |
|
Internal audit and SOC 2 evidence |
|
Privacy DPIA for a new feature |
|
Security policy and control assessment |
|
Cyber insurance risk inputs |
|
Quantum cryptography readiness |
|
Situation | Agent |
Dependency and package risk |
|
Supply chain attack simulation |
|
Vendor and third-party risk assessment |
|
Situation | Agent |
Red team campaign planning |
|
Red team execution and Kill Chain |
|
Safe, scoped exploitation |
|
Attack path analysis |
|
Security research and vulnerability discovery |
|
Situation | Agent |
Track and triage security findings |
|
Security metrics and KPI reporting |
|
Knowledge base and lessons learned |
|
Security awareness and training |
|
Orchestrate a multi-agent workflow |
|
7 cs-* agents that coordinate multiple skills into role-specific workflows:
Agent | Domain | Skills Orchestrated | Description |
Security | All 79 skills (full knowledge base) + 11 specialist agents | Universal security advisor — any question, any audience, any domain. Adapts to non-technical and expert users. Makes decisions. | |
Security | incident-commander, incident-classification, containment-advisor, forensics, zero-day-response | Full incident lifecycle — triage, containment, forensics, post-incident review | |
Security | red-team-planner, red-team-operations, safe-exploitation, attack-path-analysis, continuous-pentesting | Offensive security coordinator — engagement scoping, attack path mapping, findings report | |
DevSecOps | secure-sdlc, sast-dast-coordinator, devsecops-pipeline, build-integrity, supply-chain-risk, appsec-code-review, pipeline-security-scan | Security-in-pipeline engineer — PR gate, pipeline hardening, SBOM generation | |
Executive | enterprise-risk-assessment, compliance-mapping, metrics-reporting, security-posture-score, ciso-brief-generator, cyber-insurance | Executive advisor — board reports, risk posture reviews, regulatory gap assessments | |
Governance | security-roadmap-planner, security-debt-tracker, findings-tracker, metrics-reporting, vulnerability-management | Passive lifecycle orchestrator — program planning, proactive scanning, facilitation | |
Security | threat-hunting, threat-intelligence, behavioral-analytics, telemetry-signal-quality, incident-classification, forensics, containment-advisor, detection-engineering | Blue Team commander — alert triage, proactive hunting, DFIR, detection engineering | |
AppSec | webapp-risk-triage, owasp-top10-classifier, api-security-posture, sast-dast-coordinator, secure-sdlc | Runtime + build-time AppSec orchestrator — finding triage, OWASP classification, API posture scoring | |
Security | cloud-security-posture, cloud-workload-protection, identity-access-risk, threat-hunting | Cloud incident investigation — CSPM triage, workload runtime, IAM anomaly correlation | |
Security | supply-chain-risk, build-integrity, supply-chain-simulation, sast-dast-coordinator | Software supply chain defense — SBOM analysis, malicious package detection, SLSA verification | |
Security | threat-intelligence, threat-hunting, behavioral-analytics, incident-classification | Intelligence-driven SOC — IOC enrichment, attribution, intel-driven hunts | |
Security | red-team-planner, red-team-operations, detection-engineering, threat-hunting | Purple team orchestrator — detection validation, gap analysis, exercise readiness |
See agents/CLAUDE.md for the agent development guide.
Domain | Skills |
threat-hunting, secrets-exposure, behavioral-analytics, telemetry-signal-quality, network-exposure, attack-surface-management, threat-intelligence, deception-honeypot | |
incident-commander, incident-classification, containment-advisor, forensics, zero-day-response, zero-day-response-governance | |
enterprise-risk-assessment, risk-threat-modeling, compliance-mapping, regulatory-horizon, privacy-dpia, cyber-insurance, internal-audit-assurance, security-posture-score | |
cloud-security-posture, iac-security, container-image-scan, endpoint-os-security, ot-iot-device-security, cloud-workload-protection | |
secure-sdlc, sast-dast-coordinator, devsecops-pipeline, build-integrity, supply-chain-risk, supply-chain-simulation, appsec-code-review, pipeline-security-scan | |
identity-access-risk, data-security-classification, cryptography-key-management, insider-physical-risk | |
red-team-operations, red-team-planner, safe-exploitation, continuous-pentesting, attack-path-analysis, ai-red-teaming | |
security-architecture, security-policy-control, security-awareness, findings-tracker, vulnerability-management, metrics-reporting, security-posture-score, ciso-brief-generator | |
orchestrator, tool-execution-broker, guardrail, agent-integrity-monitor, ai-agent-security, ai-ethics-governance, ai-red-teaming | |
os-hardening | |
web-app-pentest, pentest-reporting |
Slug | Level | Category | Description |
| L4 | Red Team | Adversarial testing of AI/ML systems: prompt injection, model inversion, jailbreak detection |
| L3 | Detection | Monitors AI agent outputs for integrity violations, prompt injection, and manipulation |
| L3 | Detection | Security assessment of AI/LLM agents: input validation, output sanitization, trust boundaries |
| L2 | Governance | AI ethics review, bias assessment, and responsible AI governance for AI system deployments |
| L3 | Analysis | Maps attacker lateral movement paths through network topology to reach target assets |
| L3 | Analysis | Discovers and inventories public-facing attack surface: domains, IPs, ports, web assets |
| L3 | Detection | UEBA: entity risk scoring, insider threat pattern detection, account takeover identification |
| L3 | Detection | Verifies software build pipeline integrity: artifact signing, provenance, reproducibility |
| L4 | Cloud | CSPM: AWS/Azure/GCP posture evaluation against CIS Benchmarks, drift detection, compliance mapping |
| L2 | Compliance | Maps security findings to regulatory frameworks: GDPR, PCI DSS, HIPAA, SOC 2, ISO 27001 |
| L3 | Cloud | Classifies Trivy/Grype/Snyk findings by component (base-image OS package, app dependency, implanted layer) into block-deploy/fix/track/accept |
| L3 | Response | Recommends containment strategies across 10 threat types; assesses blast radius and production impact |
| L3 | Testing | Interprets and prioritizes automated continuous penetration testing results |
| L3 | Identity | Assesses cryptographic key lifecycle risk: weak algorithms, key rotation gaps, HSM gaps |
| L2 | Governance | Evaluates cyber insurance coverage adequacy against incident scenarios and risk profile |
| L3 | Data | Classifies data assets by sensitivity, maps to regulatory requirements, recommends controls |
| L3 | Detection | Designs and validates SIEM/EDR detection rules in Sigma, KQL, SPL, YARA with MITRE mapping |
| L3 | DevSecOps | Security gate assessment for CI/CD pipelines: secrets scanning, SAST, DAST, SCA integration |
| L4 | Endpoint | Endpoint and OS security assessment: patch status, EDR coverage, hardening baselines |
| L2 | Risk | Board-level enterprise risk assessment: risk aggregation, heat maps, risk appetite alignment |
| L3 | Operations | Tracks, triages, deduplicates, and ages security findings across the vulnerability lifecycle |
| L3 | Response | Legally defensible digital forensics: DFRWS six-phase framework, chain-of-custody, dwell time |
| L3 | Governance | Enforces USAP output contracts and intent classification guardrails on agent outputs |
| L3 | DevSecOps | Infrastructure-as-Code security analysis: Terraform, CloudFormation, Kubernetes manifests |
| L4 | Identity | IAM anomaly detection, privilege escalation analysis, CloudTrail pattern matching (5 patterns) |
| L3 | Response | Universal first-triage: classifies events into 14 types, assigns severity, identifies false positives |
| L2 | Response | Active incident command (ICS model): SEV1-4 declaration, response tracks, regulatory deadlines |
| L3 | Detection | Insider threat and physical security risk assessment combining behavioral and physical indicators |
| L2 | Compliance | Internal audit evidence collection: SOC 2, ISO 27001, SOX IT general controls |
| L2 | Operations | Security knowledge base management: lessons learned, runbook quality, knowledge gap identification |
| L2 | Reporting | Security KPI and metrics reporting: MTTR, MTTD, patch coverage, SLA compliance |
| L3 | Network | Network exposure assessment: open ports, firewall rule analysis, internet-facing service inventory |
| L2 | Orchestration | Multi-agent workflow orchestration: routes events, sequences agents, manages cascade logic |
| L4 | OT/IoT | OT/ICS/IoT device security: protocol analysis, firmware assessment, network segmentation gaps |
| L2 | Compliance | Data Protection Impact Assessment for GDPR-applicable features and processing activities |
| L2 | Risk | Post-quantum cryptography readiness: identifies vulnerable algorithms, migration planning |
| L3 | Red Team | Kill Chain execution planning: OPSEC, C2 design, lateral movement, exfil staging (requires authorization) |
| L3 | Red Team | Red team campaign planning: objectives, scope, RoE, phase map, authorization validation |
| L2 | Compliance | Tracks emerging regulatory requirements and their security control implications |
| L1 | Risk | STRIDE/PASTA/LINDDUN threat modeling: DFDs, risk scoring (Likelihood × Impact), MITRE mapping |
| L3 | Testing | Scoped, safe exploitation execution with minimal footprint and mandatory abort conditions |
| L3 | DevSecOps | Coordinates and interprets SAST, DAST, and SCA scan results; deduplicates findings |
| L4 | Detection | Credential exposure analysis: 15 secret types, entropy scoring, blast radius, attacker timeline |
| L3 | DevSecOps | Secure software development lifecycle: security requirements, design review, code review guidance |
| L2 | Architecture | Security architecture review: zero trust assessment, control coverage gaps, architecture risk |
| L2 | Training | Security awareness program assessment: phishing simulation results, training effectiveness |
| L2 | Governance | Security policy adequacy review: gap analysis against frameworks, control effectiveness |
| L3 | Research | Vulnerability research and responsible disclosure guidance |
| L3 | Risk | SBOM analysis, malicious package detection (5 categories), SLSA build integrity assessment |
| L3 | Risk | Simulates supply chain attack scenarios to test detection and response capabilities |
| L3 | Detection | Assesses telemetry data quality, dedup confidence, normalization errors, data source health |
| L2 | Risk | Third-party and vendor risk assessment: security questionnaires, contract risk, SLA gaps |
| L3 | Detection | Hypothesis-driven, IOC-driven, and anomaly-driven threat hunting with 4 built-in playbooks |
| L3 | Intelligence | Threat intelligence enrichment: IOC analysis, actor attribution, TTP mapping |
| L4 | Operations | Mediates tool execution requests from agents: scope validation, approval gating, execution logging |
| L3 | Vulnerability | Full vulnerability lifecycle: CVSS v3.1 + EPSS scoring, SLA-based prioritization, remediation tracking |
| L3 | Response | Zero-day compensating controls: exposure scoring, 5 control options, vendor timeline tracking |
| L2 | Governance | Board/executive coordination for zero-day events: communication matrix, regulatory deadlines |
| L4 | Cloud | Container and serverless runtime security: anomaly detection, escape detection, CWPP gap analysis |
| L4 | AppSec | Security-focused static code analysis: OWASP Top 10, logic flaws, dependency audits |
| L3 | Governance | Cross-domain security posture scoring: aggregates findings into an executive scorecard |
| L4 | Detection | Deception technology strategy: honeypot placement, canary token deployment, lateral movement traps |
| L4 | DevOps | CI/CD pipeline security scanning: secrets in env vars, SAST integration, artifact signing check |
| L2 | Executive | Generates CISO-level security briefs: risk posture summaries, board-ready narratives |
| L2 | Governance | Builds investment-prioritized 12-month security program roadmaps from posture, risk, and compliance data |
| L3 | Governance | Tracks and analyzes aging security findings, computes SLA breach counts, and classifies debt accumulation rate |
| L3 | AppSec | Proactive analysis of PRDs, architecture docs, and requirements specs to extract security gaps before alerts fire |
| L4 | System Security | OS configuration assessment against CIS Benchmarks, DISA STIGs, and NSA guides with prioritized remediation |
| L4 | Pentest | OWASP Top 10 web/API penetration testing with CVSS and MITRE mapping; authorization required |
| L2 | Pentest | Compiles pentest findings into executive and technical reports with CVSS risk ratings and patch SLAs |
| L3 | Red Team | Credential attack reasoning: spray vs brute-force decisions, wordlist selection, hydra result interpretation, lockout risk |
| L3 | Red Team | Active web content discovery: path brute-force result reasoning, endpoint prioritization, high-value target identification |
| L3 | Webapp | First-pass webapp finding triage: OWASP category mapping, severity scoring, blast radius scoping, downstream skill routing |
| L3 | Webapp | OWASP Top 10 2025 classification with confidence scoring from a finding description or CWE |
| L3 | Webapp | API surface posture scoring against OWASP API Security Top 10 (BOLA, auth, rate limit, mass assignment, audit) |
| L3 | AppSec | STRIDE + DREAD threat modeling from a target spec; entry point of the AppSec chain |
| L3 | AppSec | Threat-model-scoped static analysis: hardcoded creds, SQL string concat, public IaC, weak crypto |
| L3 | AppSec | Verify, dedupe, rank vuln-scan output; emit TRIAGE.md hit list |
| L4 | AppSec | Generate minimal candidate patches (unified diffs) for confirmed findings — never auto-applies |
| L3 | AppSec | Three-forcing-question walkthrough to adapt the AppSec chain to a new language / vulnerability class |
Paste any SKILL.md into your LLM as the system prompt, then send a security event as the user message.
# View a SKILL.md
cat secrets-exposure/SKILL.md
# Minimal user message structure
{
"event_type": "secret_exposure",
"severity": "critical",
"raw_payload": {
"file_path": "config/prod.env",
"matched_pattern": "aws_access_key",
"branch": "main"
}
}The LLM returns a structured JSON recommendation with action, rationale, intent_type, confidence, key_findings, evidence_references, and timestamp_utc.
This repo is the default skills/ submodule in the USAP platform.
# Clone USAP with all public skills
git clone --recurse-submodules https://github.com/jaskaranhundal/usap.git
# To add private bug bounty skills alongside:
git submodule add https://github.com/jaskaranhundal/usap-bugbounty skills-bb
echo "USAP_SKILLS_PATHS=./skills,./skills-bb" >> .env
python3 -m usap.cli validate-agents # 79 skills + 12 cs-* agents valid<slug>/
SKILL.md # LLM system prompt + YAML frontmatter
README.md # This file — what the agent does
references/
workflow.md # Step-by-step analyst workflow
*.md # Domain-specific reference documents
assets/
templates/
output-template.json # Output schema template
expected_outputs/
sample_output.json # Representative output example
scripts/
<slug>_tool.py # CLI tool
pre_analysis.py # Optional: deterministic pre-analysisshared/scripts/ contains tools used across multiple skill packages:
Script | Description |
| CVSS v3.1 base score calculator — no dependencies |
| Bug bounty scope enforcement — validates targets against scope file |
| Interactive Gemini CLI — loads a USAP kit as system prompt, starts a chat session |
See shared/README.md for usage.
To add a new agent, open a PR against this repo. See CONTRIBUTING.md for the full authoring guide including frontmatter requirements, SKILL.md body structure, and quality bar.
Apache 2.0 — see LICENSE.
This plugin does not collect, store, or transmit any user data. All processing happens locally within your Claude Code session. No telemetry, no analytics, no external API calls are made by the plugin itself.
Contact: jaskaranhundal0001@gmail.com
Phase 3 explicit dispatch. After route_payload returned an approval_required decision and the calling client surfaced the prompt to the user, the client calls this to actually invoke the downstream capability. Writes approval_granted + dispatch audit lines so the chain is recoverable end-to-end.
| Name | Required | Description | Default |
|---|---|---|---|
| mcp_id | Yes | The MCP id from the prior route decision. | |
| arguments | No | Arguments passed to the capability. | |
| capability_id | Yes | The capability id to invoke. | |
| approval_token | No | Audit token for the approval. Phase 4 will require this to be USAP-signed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals that the tool writes 'approval_granted' and dispatch audit lines for recoverability, and mentions future USAP-signing requirements for the approval token. This adds meaningful behavioral context beyond mere invocation.
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 with three sentences, no unnecessary words. It front-loads the key info ('Phase 3 explicit dispatch') and efficiently conveys workflow, behavior, and audit impact.
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 4 parameters (2 required), no output schema, and nested objects, the description provides sufficient workflow context (phase, prior step, future requirement). It could elaborate on the return value or error handling, but overall it's complete enough for an agent to use correctly within the workflow.
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 baseline is 3. The description adds extra meaning for 'approval_token' (audit token, future signing requirement) and contextualizes 'mcp_id' and 'capability_id' from the prior route decision, enhancing parameter understanding.
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's 'Phase 3 explicit dispatch' after an approval decision. It specifies it invokes the downstream capability and writes audit lines. This distinguishes it from siblings like 'route_payload' (which returns approval_required) and 'validate_payload', making its purpose unambiguous.
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 when to use: after 'route_payload' returned 'approval_required' and the client surfaced the prompt. It provides clear contextual conditions. It does not mention when not to use, but the workflow context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full agent definition for one cs-* orchestrator agent. Use this to activate the agent persona in the client's LLM.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The agent slug, e.g. 'cs-security-analyst' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes a read operation (return definition) and implies no side effects, but the phrase 'activate the agent persona' could be misinterpreted as a state change. Does not detail whether retrieval is idempotent or if auth is needed.
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?
Two sentences with no wasted words. First sentence states what it does, second gives usage. Front-loaded and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers purpose and usage adequately. However, it omits details about the output structure (what constitutes a 'full agent definition'), which could be helpful given the lack of output schema.
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 one parameter (slug). Description adds an example ('e.g. 'cs-security-analyst'') which is helpful but minimal. Does not elaborate on slug format or validation 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 it returns the full agent definition for a cs-* orchestrator agent, and specifies the use case of activating the agent persona. Distinguishes from sibling tools like list_agents and get_skill.
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 'Use this to activate the agent persona in the client's LLM', providing clear context. Does not mention when not to use it or list alternatives, but the sibling tools offer implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full SKILL.md content for one skill. Use this to load a skill as a system prompt in the client's LLM context.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The skill slug, e.g. 'vuln-scan' or 'threat-hunting' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details such as error handling, permissions, or what happens for invalid slugs, leaving the agent with incomplete information for a safe invocation.
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 with two sentences that front-load the core action and usage context, containing zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the key purpose and use case. It lacks detail on return format or error states but is generally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the one parameter's description is clear. However, the description adds no additional meaning beyond the schema, so it meets the baseline but doesn't enhance understanding.
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 returns the full SKILL.md content for one skill and specifies its use case for loading as a system prompt, effectively distinguishing from sibling tools like list_skills.
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 explicit guidance on when to use the tool ('to load a skill as a system prompt'), but does not mention when not to use it or alternatives beyond implication from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 12 cs-* USAP orchestrator agents.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions it lists agents. It fails to disclose critical behavioral aspects like authentication requirements, pagination, or output format.
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, efficient sentence that communicates the core action and its scope with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse. It does not specify what fields are returned (e.g., agent IDs, descriptions), leaving the agent with incomplete information.
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?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds no parameter information, but none is needed.
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 (the 12 cs-* USAP orchestrator agents), distinguishing it from siblings like get_agent and list_skills.
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 such as get_agent for a single agent or list_skills for skills. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all specialist MCPs the router knows about, with their enabled/disabled status, declared capabilities, and which intent_type values route to them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool's output (status, capabilities, intent_type routes) but does not mention any side effects, permissions, or read-only nature. With no annotations, the description carries the full burden; however, for a listing tool, the provided behavioral details are adequate but not comprehensive.
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 efficiently conveys the tool's purpose and output details without any redundant words. It is front-loaded with the action and resource, and every part of the sentence is 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 no parameters and no output schema, the description adequately covers the return values (status, capabilities, intent_type routes). It lacks mention of ordering, pagination, or whether the list is complete, but for a simple listing tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed as the schema is already fully covered. There is no missing semantic value.
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 the resource 'all specialist MCPs', and specifies the returned information: enabled/disabled status, capabilities, and intent_type routes. It effectively distinguishes from sibling tools like list_agents and list_skills by focusing on MCPs.
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 explicit when-to-use or when-not-to-use guidance, nor does it reference sibling tools. While the tool's purpose is straightforward (listing MCPs), the lack of differentiation from similar listing tools like list_agents or list_skills limits its helpfulness for an agent deciding which tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List USAP skills with one-line descriptions. Optionally filter by domain (one of: appsec-devsecops, cloud-infra, detection, governance, identity-access, pentest, platform-ai, red-team, response, risk-compliance, system-security, webapp-security).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Optional domain filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool lists skills with descriptions and supports filtering, but lacks details on pagination, data format, rate limits, or whether the operation is read-only. For a simple list, this is minimal.
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 with no wasted words. It conveys the purpose and optional filtering in a compact form, 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?
For a simple listing tool with one optional parameter and no output schema, the description is largely complete. It could state that the output is a list of objects, but that is implied. It covers the essential information needed for 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?
The input schema only describes 'domain' as 'Optional domain filter.' The description adds significant value by enumerating all valid domain values, which helps the agent correctly select and invoke the filter. Schema coverage is 100%, but description goes beyond.
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 'List USAP skills with one-line descriptions,' specifying the verb, resource, and output format. It distinguishes from sibling tools like 'get_skill' (which likely retrieves a single skill) and 'list_agents' (different resource).
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 mentions the optional domain filter and lists all valid domain values, providing clear context for usage. However, it does not include guidance on when not to use this tool (e.g., to get a single skill) or mention alternatives like 'get_skill'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Phase 2 routing. Take an 11-field USAP payload and look up which specialist MCP would handle it (Splunk / CrowdStrike / FortiGate / Okta / Slack / GitHub / AWS Security Hub, etc.) per the registry at registry/usap-mcp-registry.yaml. If the payload or the matched capability sets human_approval_required: true, returns an approval prompt instead of dispatching. Phase 3 will actually invoke the adapter; Phase 2 confirms routing logic + approval gate. Every decision is written to ~/.usap/audit/YYYY-MM-DD.jsonl.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | The 11-field USAP payload from a skill or agent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: Phase 2 vs Phase 3, approval prompt on human_approval_required, and audit logging. However, it omits details like what happens on no match 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 concise (around 100 words), front-loads the purpose, and each sentence adds value without redundancy.
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 covers the routing flow, approval gate, and audit trail, which is fairly complete for a Phase 2 routing tool. Missing edge cases like unmatched payloads, but overall adequate given no output schema.
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 single parameter 'payload' has minimal schema description. The tool description adds context about the 11-field structure and its role in routing, but does not detail the fields, so it adds some but not substantial meaning 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's Phase 2 routing for 11-field USAP payloads, lists example target MCPs, and distinguishes its role from sibling tools like validate_payload and dispatch_after_approval.
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 explains the routing logic and approval gate, but does not explicitly state when not to use this tool or compare to alternatives like validate_payload.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a JSON payload against the USAP 11-field output contract (agent_slug, intent_type, action, rationale, confidence, severity, key_findings, evidence_references, next_agents, human_approval_required, timestamp_utc). Returns 'PASS' or a list of violations.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | The payload to validate against the contract |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return type (PASS or violations) but doesn't specify side effects, whether it modifies state, or the format of violations. Adequate but not thorough.
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 sentence that immediately conveys the action, target, and expected result. No extraneous information; every word earns 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?
For a simple validation tool with one parameter and no output schema, the description covers the purpose, contract fields, and return type. It lacks details on violation format or error cases, but overall is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a generic description for the payload parameter. The tool description adds the exact contract fields, significantly enriching the meaning beyond the schema. Since schema coverage is 100%, baseline is 3, but the added list justifies a 4.
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 validates a JSON payload against a specific 11-field contract, listing all fields and indicating the return value ('PASS' or violations). This is specific and distinct from siblings which are unrelated actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or when to choose alternatives. No prerequisites or context provided, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
dispatch_after_approvalget_agentget_skilllist_agentslist_mcpslist_skillsroute_payloadvalidate_payloadEach tool targets a distinct function: listing vs. retrieval, routing vs. validation vs. dispatch. Even the three listing tools for agents, MCPs, and skills are clearly separated by entity type, and the two-phase routing tools (route_payload and dispatch_after_approval) have distinct roles.
All tools use a consistent verb_noun pattern in snake_case (e.g., list_agents, get_skill, route_payload, validate_payload). The naming is predictable and self-explanatory, with no mixed conventions.
With 8 tools, the surface is well-scoped for an orchestration server. Each tool earns its place, covering discovery, retrieval, routing, validation, and dispatch without unnecessary redundancy.
The tool set covers the core workflow: discover entities, validate payloads, route them, and dispatch after approval. A minor gap is the lack of tools for managing routing history or handling approval rejections, but the audit trail is handled externally.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Governed AI agent skills — one library, distributed to devs and exposed to remote agents over MCP.
Cited, standards-aware compliance overlay for AI assistants (ISO, NIST, FedRAMP, IRAP), over MCP.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jaskaranhundal/usap-skills'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
