Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server has significant structural and definition quality gaps. All 7 tools are defined only in src/agent/prompts.py as static dictionaries without explicit MCP server registration code visible. No MCP server initialization, tool_list response, or call_tool handler implementation is shown in the provided source. Tool definitions appear to be inferred from a hardcoded list rather than formally registered via an MCP server framework. Descriptions are present but minimal (20-50 chars), falling below the production baseline of 194 chars. Parameter descriptions are present but terse. No input schemas are visibly declared in JSON Schema format, only parameter names and descriptions are noted. No output schemas are documented. Error handling and recovery guidance are absent. The tool catalog builder (tool_catalog.py) and tool generator (tool_generator.py) show code to wrap tools, but there is no evidence of actual MCP server transport implementation, request/response handling, or protocol-compliant tool listing. This appears to be a proof-of-concept that generates tool wrappers for internal use rather than a production-grade MCP server.
Tools (7)
get_dependency_inforead only32/100
Get dependency information from deps.dev
get_exploit_probabilityread only30/100
Get EPSS exploit probability score for a CVE
get_package_metadataread only37/100
Retrieve package metadata including latest version and GitHub repository
get_release_notesread only33/100
Get release notes for a package between two versions
get_security_scorecardread only32/100
Get OpenSSF security scorecard for a repository
query_vulnerabilityread only33/100
Query OSV database for vulnerabilities affecting a package version
search_cvesread only33/100
Search for CVEs affecting a specific package version
No input schemas visible in source code. Tools reference parameter names ('package', 'version', 'owner', 'repo', etc.) but no JSON Schema type definitions, constraints, required fields, or format specifications are provided.
Tool descriptions are extremely terse (20-50 characters). Baseline production average is 194 chars. Descriptions lack context about when to use each tool, what distinguishes it from similar tools, and prerequisites. E.g., 'Search for CVEs affecting a specific package version' does not explain when to call this vs query_vulnerability, or whether it requires network access.
Add explicit JSON Schema input_schema to every tool definition. Include 'type', 'properties', 'required', and per-parameter 'type' + 'description'. Example: search_cves should have {"type": "object", "properties": {"package": {"type": "string", "description": "Python package name (e.g., requests, django). Case-sensitive."}, "version": {"type": "string", "description": "Semantic version (e.g., 2.28.1). Use * for all versions."}, "required": ["package", "version"]}.
Expand tool descriptions to 100 - 300 characters, following production baseline. Include (1) what the tool does, (2) when to use it vs. similar tools, (3) prerequisites (does it require internet?), (4) typical response structure. Example: 'Search for publicly disclosed CVEs affecting a specific Python package version. Use this for initial threat assessment before query_vulnerability (which checks OSV database). Returns list of CVE IDs, CVSS scores, and affected versions. Requires internet access.'
Document output schemas for each tool. State the return type (object, array, string, number), per-field types, and example structure. Example: search_cves returns {"cves": [{"id": "CVE-2024-1234", "cvss_score": 7.5, "affected_versions": ["1.0.0", "1.1.0"], "description": "..."}], "total_count": 15}.
Add error handling and recovery guidance. State what can go wrong (network timeout, invalid package name, rate limit) and what the LLM should do next. Example: 'If package not found, try search_packages() first. If rate-limited, wait 60 seconds and retry. If network timeout after 2 retries, inform the user and skip CVE check.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No output schemas documented. LLMs cannot plan downstream operations or extract fields if they do not know what each tool returns. Missing return type declarations for all tools.
No MCP server registration or initialization code visible. Tool definitions appear to be static dictionaries in prompts.py. No evidence of MCP::initialize handler, tools/list response, or tools/call handler. The server may be a tool wrapper generator rather than a functional MCP server.
No error handling or recovery guidance. None of the tools document what happens on failure (network timeout, invalid CVE ID, rate limit, etc.) or what the LLM should do next.
Parameter constraints are missing. 'package' and 'version' are unbounded strings. 'from_version' and 'to_version' have no format hints (semver? date?). 'owner' and 'repo' have no length constraints. Constraints must be stated in descriptions or as JSON Schema properties (enum, pattern, minLength, maxLength).
Clarify parameter semantics. 'package' should accept PyPI package names; state case sensitivity and whether it accepts aliases. 'version' should specify if it accepts semver, wildcard patterns, or pre-release versions.
Ensure tools are mutually exclusive or complementary. search_cves and query_vulnerability appear to serve similar purposes, the descriptions should clarify: does search_cves query NVD/Mitre while query_vulnerability queries OSV? When should an LLM use one vs. the other?
Implement the actual MCP server handler code. The current source shows tool wrapper generation but not MCP protocol compliance. Add an MCP server class that implements initialize, tools/list, and tools/call handlers per the current MCP spec (2026-07-28). Use an official MCP SDK (e.g., mcp Python SDK) to ensure protocol compliance.
Add pagination support if tools return lists (e.g., search_cves with many results). Include 'limit' and 'offset' or 'next_cursor' parameters, and document the maximum result size.
For tools that call external APIs (NIST NVD, GitHub, deps.dev), set explicit timeouts (e.g., 10s) and document retry logic. Return clear timeout errors: 'Request to NVD API timed out after 10 seconds. Retry in 60 seconds.'
Mark tools as read-only in their definitions (via annotation or description). All 7 tools have Risk: READ_ONLY, but this should be explicit in the MCP tool annotation (readOnlyHint: true in the spec).