Loading ToolBench
MCP server that gives coding agents accurate, version-to-version breaking-change briefings for any npm package — so migrations stop being hallucinated.
Three well-named, verb-prefixed tools with strong descriptions (194 - 250 chars, well above baseline 194 avg). All parameters have type definitions and descriptions. Input schemas use Zod with clear constraints. Error handling includes recovery guidance ('Use list_versions to see valid versions'). Main gaps: no output schema documentation, no pagination support for list_versions, no tool annotations (readOnlyHint), and error responses could be more structured. Tools are READ_ONLY and idempotent, which is good for agent safety.
Get an accurate, source-grounded list of BREAKING CHANGES for an npm package between two versions. Reach for this BEFORE writing or reviewing any dependency upgrade / migration — it defeats the model's stale, hallucinated migration knowledge by reading the real GitHub release notes (and CHANGELOG as fallback) for every version in the range. Returns breaking notes grouped per version, newest first.
Return the complete release notes (not just breaking lines) for every version of an npm package between `from` (exclusive) and `to` (inclusive), newest first. Use when you need full context — new features, fixes, deprecations — not only breaking changes, or when breaking_changes_between reports the maintainer wrote breaking notes prose-style.
List published versions of an npm package with their release dates, newest first. Use this to discover valid `from`/`to` values before calling breaking_changes_between, or to see how far behind an installed version is.
No output schema documentation. Tool descriptions state what is returned (e.g., 'breaking notes grouped per version, newest first') but the actual response structure is not formally documented. LLMs cannot plan downstream operations without knowing field names and types.
list_versions lacks pagination parameters. No 'offset', 'page', or 'cursor' support; no 'total_count' in response. If a package has 1000+ versions, the tool returns only 40 (default limit) with no way to fetch the rest. Large result sets risk context window exhaustion.
No tool annotations. All three tools are READ_ONLY and idempotent, but the server does not declare readOnlyHint or idempotentHint in tool definitions. This forces LLMs to infer safety properties, increasing hallucination risk.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Error responses are text-only. When a tool fails (e.g., 'Could not load package from npm'), the response is a plain string. No structured error code, category (retryable/user-fixable/fatal), or machine-parseable recovery hint. LLMs must parse prose to decide next steps.
Parameter descriptions lack format/constraint details. E.g., 'from' and 'to' accept semver strings but do not specify the exact format (e.g., 'Must be a valid semver version: X.Y.Z or X.Y.Z-prerelease'). LLMs may pass invalid versions like '1.0' or 'latest'.