A Minestom MCP server with repository-aware JVM tooling.
The server provides 9 tools with consistent verb-noun naming and non-empty descriptions. However, there are significant gaps in schema completeness, parameter descriptions, and output schema documentation. Tools are well-intentioned but fall short of production-grade quality. Most tools lack comprehensive input validation guidance and output schema definitions. The custom TanStack registration layer properly applies tool annotations (readOnlyHint=true for all), but parameter documentation is inconsistent across tools.
Use this when you want a docs-backed explanation of how Minestom typically models bootstrap, instances, events, commands, schedulers, or thread ownership.
Use this when you need package metadata, runtime details, tool inventory, or knowledge-catalog coverage for this Minestom MCP server.
Deep-dive inspection of a Minestom project's build configuration, plugins, dependencies, and Gradle/Maven structure.
Scan a Minestom project repository to detect build system, JVM languages, source roots, and architectural patterns.
Use this when you need curated Minestom API matches with package names, why they matter, related APIs, and javadoc links.
Use this when you want to verify that the Minestom MCP server is reachable.
Missing output schemas for all tools, LLMs cannot infer response structure and must guess which fields are returned, breaking downstream tool chaining
Code inspection tools (review_minestom_design, plan_minestom_feature) accept unbounded string input with no size limits, validation guidance, or error recovery, agents could pass massive code blocks or malformed input
Parameter descriptions lack actionable format constraints, 'repoRoot' says 'Absolute or relative path' but doesn't specify format, existence checks, or validation behavior on missing path
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2025-06-18+ | v2 |
Use this when you want a structured implementation plan for a new Minestom feature with design checks, file templates, and verification steps.
Use this when you want a structured design review against Minestom best practices, thread safety, and architectural patterns.
Use this when you want Minestom ecosystem suggestions grounded in the official libraries directory, with optional live GitHub topic lookups.
No error handling guidance in descriptions, tools don't state what errors are recoverable, what to do when symbol lookup fails, or how to handle live GitHub search rate limits (includeLiveResults)
Tool pair explain_minestom_pattern and lookup_minestom_api have overlapping responsibility, both provide Minestom API knowledge but lack clear distinction on WHEN to use each (pattern explanation vs symbol lookup)
inspect_minestom_build description states 'Deep-dive inspection of build configuration' but doesn't explain output structure (what fields? what schema? modules vs dependencies vs plugins?), forcing LLM to guess