dependency-compat-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_compatibilityA | Does one exact release work with another exact release, and on what evidence? Call this once both sides are pinned: a PyPI or npm package release, or a Python or Node runtime release. Do not call it with a version range or file contents; resolving ranges and reading a codebase are out of scope. Argument order is meaning. Under the pypi -> pypi requires_dist and npm -> npm dependencies rules, order fixes the declaring side, so swapping arguments asks a different question. For pypi with runtime:python and npm with runtime:node the declaring side follows from the kind of target, so either order reads the same; relation.direction reports which way the server read it. A verdict of unknown is a normal result meaning the claim cannot be proven from current evidence. It is not an error and not a reason to retry: limitations and sources_checked carry the next thing to check. |
| get_compatibility_contextA | What does one exact release declare and state about compatibility, so you can compare it with code you already hold? Call this when a single target is pinned and you want its declared constraints and reviewed changes. Do not call it with a version range, a repository path, or source text; the server is never given a codebase and compares nothing for you. This tool takes one target, so it has no argument order to get wrong; ordering matters only in check_compatibility, where input order fixes the declaring side for the pypi -> pypi and npm -> npm rules while the kind of target fixes it for the runtime rules, and relation.direction reports how the pair was read. An availability of unknown is a normal result meaning current evidence proves nothing here, not an error and not a reason to retry: limitations and sources_checked carry the next thing to check. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: check_compatibility compares two exact releases, while get_compatibility_context retrieves declarations for a single release. There is no overlap in functionality, and the verbose descriptions reinforce the boundaries.
Both tool names follow the consistent verb_noun pattern (check_compatibility, get_compatibility_context). The naming style is uniform and predictable.
With only 2 tools, the server is on the low end of the typical range. The narrow focus on compatibility checking makes this borderline, but it feels slightly thin for a general-purpose dependency tool.
The core domain operations are covered: checking compatibility between two releases and retrieving compatibility context for one release. Minor gaps exist, such as no tool to list available versions or resolve ranges, but these are explicitly out of scope and agents can work around them.