This server defines 2 tools (searchNpmPackages, checkNpmPackage) with reasonable naming and basic descriptions. However, there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. The tools follow a consistent pattern but lack the rigor expected for production use. Tool names correctly start with action verbs (search_, check_). Descriptions are present but generic (10-20 character range for parameters). Parameter schemas use Zod but descriptions are minimal, 'Search query is required' and 'Maximum number of results to return' lack context about when/why to use them. Output schemas are not explicitly documented; LLMs must infer structure from code. Error handling returns errors but does not guide recovery (e.g., 'Unknown error occurred' gives no actionable next steps).
Check if a package exists in the npm registry and get its latest version
Search for npm packages based on a query
Output schemas not documented. LLMs cannot predict return structure or plan downstream tool calls. searchNpmPackages returns SearchResultItem[] but this is only visible in the TypeScript code, not in the MCP tool definition. checkNpmPackage returns a complex object with conditional fields (exists, error, version), the agent must infer which fields are present.
Parameter descriptions are too brief and lack context. 'Maximum number of results to return' (searchNpmPackages.limit) does not explain WHEN to use limits or what the performance/token cost trade-off is. 'Search query is required' (searchNpmPackages.query) is a constraint, not a description of what the query can contain (package names? keywords? author?). Descriptions should be 50-150 chars and actionable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error handling lacks recovery guidance. When searchNpmPackages catches an error, it returns an empty array with no error context, the agent does not know if the query was invalid, the registry is down, or the network failed. When checkNpmPackage errors, it returns { exists: false, error: '...' }, but 'HTTP error! status: 500' does not tell the agent whether to retry, ask the user, or try a different tool.
No pagination support for searchNpmPackages. The tool hardcodes size=15 in the API call but only returns up to `limit` results (default 5). Large result sets are silently truncated. The tool should document that results are capped at the limit and offer a way to fetch the next page (offset/page parameter) if more results are needed.
checkNpmPackage returns a verbose object including raw API fields (time: Record<string, string>, versions: Record<string, unknown>) that the agent likely doesn't need. According to baseline MCP patterns, responses should strip irrelevant metadata. The agent cares about the package name, latest version, and description, not every version ever published. This wastes tokens.
No tool annotations. Neither searchNpmPackages nor checkNpmPackage declare idempotentHint, readOnlyHint, or destructiveHint. Both are read-only operations and should be marked as such so agents know they are safe to retry without side effects.