Garita MCP

Verificar vulnerabilidades conocidas de un paquete

check_known_vulnerabilities

Revisa si un paquete de software (de npm, PyPI, Go, crates.io, Maven, RubyGems, y otros ecosistemas soportados por OSV.dev) tiene vulnerabilidades ya conocidas y publicadas (CVEs y equivalentes), consultando la base de datos abierta OSV.dev (agrega GitHub Advisory Database, PyPA, Go, npm, RustSec, entre otras). Devuelve cada vulnerabilidad encontrada con su identificador, CVE oficial si existe, severidad, fecha de publicación y un link. Úsalo antes de confiar en un paquete del que depende un servidor MCP o cualquier otro componente — un paquete puede pasar la auditoría del manifiesto y la detección de descripciones envenenadas y aun así tener una falla de seguridad ya conocida en su propio código. Requiere una llave de acceso válida (usos gratis o créditos) — ver POST /crear-llave.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ecosistema": "<ecosistema>",
      "nombre": "<nombre>"
    },
    "name": "check_known_vulnerabilities"
  }
}

Input Schema

Name	Required	Description
`nombre`	Yes	Nombre exacto del paquete tal como aparece en su registro (ej. "left-pad" en npm).
`version`	No	Versión exacta a revisar. Si se omite, busca vulnerabilidades conocidas en cualquier versión del paquete.
`ecosistema`	Yes	Ecosistema del paquete. Comunes: npm, PyPI, Go, crates.io, Maven, NuGet, RubyGems, Packagist, Hex, Pub. Se envía tal cual a OSV.dev.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.1/5.0

Behavior4/5

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 backend (OSV.dev and aggregated feeds), what each result contains (ID, CVE, severity, publication date, link), and an auth requirement (valid access key with free uses or credits). It does not discuss rate limits or error behavior, but covers the critical operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and return shape, then usage and auth requirements. It is somewhat lengthy but every sentence contributes; the repeated ecosystem listing is minor.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must explain return values, which it does with fields and links. It also covers auth and usage context. A mutation-free lookup tool does not need much more, though error conditions are omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the three parameters are already documented. The description names supported ecosystems and reiterates the package-name concept but adds no syntax or version-specific guidance beyond the schema; the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Revisa') and resource ('vulnerabilidades conocidas... de un paquete'), and scopes it to OSV.dev ecosystems. It distinguishes itself from sibling checks by noting packages can pass manifest audit and poisoned-description detection yet still carry a known CVE.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use it before trusting a package that an MCP server or other component depends on, and contrasts it with manifest auditing and poisoned-description detection. It stops short of explicit when-not-to-use or a named alternative, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Garita MCP tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?