MCP server for resolving project dependencies and providing local source code paths
Single tool (get_library_sources) with well-structured parameters, comprehensive descriptions, and clear intent. Tool name follows verb_noun pattern. Input schema is complete with types and descriptions. However, output schema is not formally documented (returns string), error handling relies on text responses without actionable recovery guidance, and no tool annotations present. The implementation shows good practices (validation, ecosystem detection, caching) but lacks production-grade error categorization and structured output.
Resolve project dependencies and provide local source code paths for inspection. This tool auto-detects the build system (Maven, Gradle, Poetry, uv) by scanning files in the given project directory, resolves dependencies, and can clone and check out the source code of matching libraries.
Output schema not documented. Tool returns unstructured string responses instead of structured objects. LLMs cannot plan downstream operations or extract specific fields reliably.
Error responses are freetext strings without actionable recovery guidance. Examples: 'Error: project directory does not exist', 'No dependencies matching found'. No indication whether to retry, ask user, or fix input.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The tool has WRITE risk but this is not declared in the schema.
library_name parameter description references examples (e.g. 'hibernate' matches 'org.hibernate:hibernate-core:6.4.1'). LLMs may reuse example values literally rather than adapting to actual context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Large result sets (many dependencies, transitive closure) risk context explosion but tool lacks pagination support. No limit parameter, no cursor/offset, no total count returned.