MCP SERVERPut the CVEs that affect your actual stack into the assistant's context before it writes the code, and generate the IDE rules file that keeps them there.
LABSCO SUMMARY
Two different shapes of the same data, and both are useful: security context injected per task, so the assistant sees the CVEs for the stack it is touching while it writes; and a guardrail file composed once and saved into the project, so the rules apply without any tool call at all. Prioritization is explicit — actively-exploited CVEs from the CISA KEV list outrank raw severity, with EPSS exploit probability behind it — and nothing needs a key because the catalog ships as committed JSON.
A catalog of CVEs and security rules, kept fresh by a daily pipeline over six public threat sources, exposed so an assistant can pull the relevant ones for the file it is editing and turn them into an IDE guardrail file.
No account and no key to consume it. Run it with npx -y @aigently/mcp-server@latest over stdio. The server reads static JSON snapshots committed into the repository, so there is no database to stand up and no network call at query time. The keys listed in the project — an Anthropic API key, a GitHub token, an optional NVD key — are for running the ingest pipeline yourself, not for using the server. The catalog is refreshed by daily CI from NVD, CISA KEV, GHSA, OSV, npm Audit and EPSS.
One command — npx -y @aigently/mcp-server
USE CASES
Detect the stack from the project's files, then generate the rules file in the format your IDE reads and save it.
Pull the security context for that file and intent — the matching rules and the top CVEs come back together.
Search the catalog filtered by stack and severity, then open the one that matters.
Fetch the rule by slug for its full content and which layers it belongs to.
List the supported stacks and read the catalog manifest for its version and counts.
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
compose_guardrailGenerate a complete, IDE-ready security guardrail file for a tech stack. Returns the full guardrail content with the correct filename for the configured IDE (cursor → .cursor/rules/*.mdc, claude-code → CLAUDE.md, windsurf → .windsurfrules, etc.). Save the returned file to your project root and your AI assistant will enforce the rules automatically. If you don't know the stack_slug, call detect_project_stack first.
detect_project_stackDetect the technology stack from project file paths and return a ready-to-use compose_guardrail call. Call this FIRST when setting up security guardrails for a project — pass a list of files/directories from the project root (e.g. package.json, next.config.ts, app/, go.mod). Returns detected stack slugs, suggested protection layers, and the exact compose_guardrail arguments to run next.
get_manifestGet catalog metadata: version, last updated timestamp, and counts of threats, rules, stacks, and guardrails.
get_ruleGet the full security rule content (bodyMdx + AI summary + layer assignments) for a given rule slug.
get_security_contextInject real CVE threat data and security rules into the AI context for the current coding task. Pass the current file path — the tech stack is auto-detected from it (e.g. 'app/api/auth/route.ts' → nextjs). Also pass what the developer is building as intent text. Returns matching security rules (bodyMdx) and the top 5 relevant CVEs to enforce while generating code. Use this whenever the developer is implementing anything security-sensitive: auth, APIs, data handling, deps.
get_threatGet full details for a single CVE including description, affected versions, and AI-generated guardrail patterns.
list_layersList the 15 security protection layers used to organize guardrail rules (e.g. auth_session, input_validation, api_security).
list_stacksList all supported technology stacks with slug, name, ecosystem, and catalog status. Use slugs with compose_guardrail and search_threats.
search_threatsSearch the CVE/advisory catalog with optional filters. Returns threats sorted by severity.
BEFORE YOU INSTALL
9 tools when we connected. get_rule and list_layers are missing from the documentation's table. auth_session, input_validation and api_security are rule categories, not tools.
All 5 documented clients run the server on your machine.
CONTEXT COST
Rated by the size of the 9 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
npx -y @aigently/mcp-server{
"mcpServers": {
"aigently": {
"command": "npx",
"args": [
"-y",
"@aigently/mcp-server@latest"
]
}
}
}MCP servers
apviso
AiAgentKarl
AbdumajidRashidov
SyedAnas01