Server defines 3 tools with adequate naming (verb_noun pattern) and reasonable descriptions. However, output schemas are entirely absent, no documentation of what these tools return, which is a critical gap for LLM planning. Parameter descriptions are present but minimal (under 50 chars typically). Error handling is not visible in the source. The tools themselves are straightforward READ_ONLY operations, but lack the depth of documentation expected for production use. Average tool score: 58.

• Document the complete output schema for each tool. Specify what fields are returned, their types, and whether they are always present or conditional. Example: 'Returns: {manifests: [{name: string, type: 'image'|'workload', vulnerabilityCount: number}], total: number}'
• Expand parameter descriptions to 50-100 characters. For namespace: 'Kubernetes namespace name (e.g., "default", "kube-system"). Omit to search all namespaces.' For level: 'Type of vulnerability analysis: "image" (container images), "workload" (Kubernetes workloads), or "both" (both types).'
• Add error guidance to tool descriptions. E.g. 'Returns error if manifest not found. Use list_vulnerability_manifests to discover available manifests.' This guides LLM recovery.
• Implement pagination for list tools. Add parameters: limit (1-100, default 20), offset (default 0). Return: {items: [...], total: number, hasMore: boolean}.
• Document the relationship between tools in their descriptions. E.g. 'list_vulnerabilities_in_manifest: First call list_vulnerability_manifests to get valid manifest_name values.'
• Add example manifest_name formats to improve LLM guidance without embedding literal values. E.g. 'manifest_name: string (e.g., format: "deployment-nginx" for workload, "gcr.io/project/image:v1" for image)'.