Which integrations are available for this server?

Supports library discovery by searching GitHub topics to suggest relevant third-party libraries for Minestom projects. Analyzes Gradle build configurations, including modules, dependencies, plugins, and version catalogs, to interpret Minestom project environments. Detects and inspects Kotlin source code layouts and language signals within Minestom server projects. Parses Gradle version catalogs in TOML format to extract and analyze project dependency and property information. Parses Maven pom.xml files to interpret dependencies, plugins, and build properties for Minestom project builds.

How do I use Minestom MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Minestom MCP Server Explain the event system and look up the GlobalEventHandler API." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Minestom MCP Server

by RonaldBunk

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Minestom MCP Server

A stdio MCP server for Minestom, implemented with the Model Context Protocol SDK and TanStack AI tool definitions.

NPM Version

Install

Preferred package invocation:

npx -y minestom-mcp

Often a file like .mcp.json at your project root will be picked up by agents:

{
  "mcpServers": {
    "minestom-mcp": {
      "command": "npx",
      "args": ["-y", "minestom-mcp"]
    }
  }
}

Installed command aliases:

minestom-mcp-server
minestom-mcp

Why this shape:

minestom-mcp-server is the npm package name and the safest npx entrypoint.
minestom-mcp is the shorter command alias after install.
npm npx resolves the matching bin when one of the bin entries matches the package name, so publishing the package as minestom-mcp-server with a minestom-mcp-server bin keeps npx -y minestom-mcp-server reliable. Source: npm npx docs

The tool surface is grounded in:

the official Minestom docs at minestom.net/docs
the Minestom javadocs at javadoc.minestom.net
the Minestom ecosystem directory at minestom.net/libraries

Detailed tool documentation lives in docs/tools.md.

The repository also ships a publish-ready static docs site in docs/ plus a GitHub Pages workflow in /.github/workflows/deploy-docs.yml.

Community and contribution docs live in CONTRIBUTING.md, CODE_OF_CONDUCT.md, and SECURITY.md.

Related MCP server: Minecraft Plugin Documentation MCP Server

Tools

ping: verifies that the MCP server is reachable.
get_server_info: returns package metadata, runtime details, tool inventory, and knowledge-catalog coverage.
inspect_minestom_environment: inspects the current workspace or repoRoot, including subdirectories, Gradle/Maven build signals, JVM source layouts, detected patterns, entrypoints, existing libraries, and any detected run/ folders.
inspect_minestom_build: interprets Gradle or Maven modules, including dependencies, plugins, wrapper commands, variables/properties, and Gradle version catalogs.
explain_minestom_pattern: explains Minestom patterns for bootstrap, instances, events, commands, schedulers, and thread ownership.
lookup_minestom_api: returns curated API matches with package names, related APIs, and javadoc links.
plan_minestom_feature: produces a grounded implementation outline for Minestom feature types.
review_minestom_design: reviews design notes against Minestom’s manager, event, instance, scheduler, and threading patterns.
suggest_minestom_libraries: returns curated library suggestions, can optionally add live GitHub topic results, and now uses repository signals when available.

Notes

API lookup is curated around the most important Minestom symbols and patterns; it is not a full javadoc crawler.
Library discovery is hybrid: curated results are always returned first, live GitHub topic:minestom-library search is optional, and repo-aware ranking can inspect the target project.
Environment-aware tools default to the current working directory and inspect subdirectories as part of that workspace. You can pass repoRoot to inspect a different Minestom workspace, and run/ is treated as a strong development signal rather than an assumed server root.
Because Minestom is JVM-based, the environment scan explicitly looks for Gradle/Maven build files, common wrapper scripts, JVM source roots, and Java/Kotlin signals before treating a workspace as a likely Minestom server project.
Build-aware inspection understands common Gradle dependency/plugin declarations in build.gradle or build.gradle.kts, reads gradle/libs.versions.toml, and parses Maven pom.xml dependencies, plugins, and properties.

Development

pnpm install
pnpm dev
pnpm lint:fix
pnpm check

Husky installs local hooks during pnpm install. Commits run lint-staged, and pushes run the full pnpm check verification flow.

Publish

The package is set up for npm publishing with:

executable bins for minestom-mcp-server and minestom-mcp
a shebang-included bundled entrypoint in dist/server.js
files whitelisting for the publish tarball
prepack and prepublishOnly verification hooks
GitHub Actions publishing from .github/workflows/npm-publish.yml via pnpm install/check steps and npm trusted publishing
publishConfig.access = public

Recommended release flow:

pnpm check
npm pack --dry-run
npm publish

For npm trusted publishing, configure npm to trust the workflow filename npm-publish.yml in .github/workflows/. The workflow now uses pnpm for dependency installation and verification, then publishes with npm publish through GitHub Actions OIDC instead of a long-lived NPM_TOKEN.

Available Tools

9 tools

explain_minestom_patternA

Read-onlyIdempotent

Use this when you want a docs-backed explanation of how Minestom typically models bootstrap, instances, events, commands, schedulers, or thread ownership.

ParametersJSON Schema

Name	Required	Description	Default
`goal`	No	Optional goal or problem statement to tailor the pattern explanation.
`topic`	Yes	The Minestom subsystem or design topic to explain.

Output Schema

ParametersJSON Schema

Name	Required	Description
`commonPitfalls`	Yes
`explanation`	Yes
`goalAdjustment`	No
`keyApis`	Yes
`lifecycleNotes`	Yes
`officialLinks`	Yes
`summary`	Yes
`title`	Yes
`topic`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral context by stating that the explanation is 'docs-backed' and covers 'how Minestom typically models' various aspects. This goes beyond the annotations (readOnlyHint=true, idempotentHint=true) which indicate safe, repeatable behavior. No contradictions are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that conveys all necessary information without any wasted words. It is front-loaded with the tool's purpose and immediately actionable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (so return values are documented elsewhere), the description adequately covers the tool's purpose and the range of topics it can explain. No gaps are evident for a pattern explanation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides full coverage (100%) with descriptions and enums for both parameters. The description does not add additional semantic value beyond what the schema offers, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to provide a docs-backed explanation of Minestom patterns across specific subsystems. It uses specific verbs ('explain') and resources ('Minestom pattern'), and the listed topics distinguish it from sibling tools like 'inspect_minestom_build' or 'lookup_minestom_api'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this when you want...', providing clear usage context. It does not explicitly state when not to use it, but the context of sibling tools implies it is for pattern explanations. This is adequate but could be improved by specifying exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_server_infoA

Read-onlyIdempotent

Use this when you need package metadata, runtime details, tool inventory, or knowledge-catalog coverage for this Minestom MCP server.

ParametersJSON Schema

Name	Required	Description	Default
`includeDependencies`	No	Whether to include runtime dependency versions in the response.

Output Schema

ParametersJSON Schema

Name	Required	Description
`availableTools`	Yes
`dependencies`	No
`description`	Yes
`knowledgeCatalog`	Yes
`name`	Yes
`officialSources`	Yes
`runtime`	Yes
`toolCount`	Yes
`version`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by specifying the types of data returned but does not disclose additional behavioral traits beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, well-structured sentence that directly states the tool's purpose with no unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and the description covers the main use cases, it is sufficiently complete for an information-retrieval tool, though it could mention the response structure or defaults.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single boolean parameter is well-described in the schema; the description adds no further parameter information beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly lists the specific types of information the tool provides (package metadata, runtime details, etc.), distinguishing it from sibling tools that focus on specific Minestom aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly starts with 'Use this when you need...', providing clear guidance on when to invoke the tool, though it does not explicitly mention when not to use it or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_minestom_buildA

Read-onlyIdempotent

Use this when you want Gradle or Maven specific interpretation for a Minestom workspace, including dependencies, plugins, wrapper commands, and variables from build files or version catalogs.

ParametersJSON Schema

Name	Required	Description	Default
`repoRoot`	No	Absolute or relative path to the Minestom workspace to inspect. Defaults to the current working directory.

Output Schema

ParametersJSON Schema

Name	Required	Description
`modules`	Yes
`notes`	Yes
`primaryModuleRoot`	No
`repoRoot`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds specific context about what the tool inspects (dependencies, plugins, etc.) and that it provides 'interpretation' beyond raw file reading, which is valuable supplementary information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the usage guidance. It is concise, with no redundant words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of a comprehensive input schema, annotations, and an output schema (as indicated by context signals), the description adequately covers the tool's purpose, inputs, and outputs. It specifies the scope of inspection (Gradle/Maven, dependencies, plugins, etc.), making it complete for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter repoRoot has a clear description in the schema ('path to the Minestom workspace'). The overall description does not add additional parameter-specific semantics, so with 100% schema coverage, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides 'Gradle or Maven specific interpretation' for a Minestom workspace, listing specific outputs like dependencies, plugins, wrapper commands, and variables. This distinguishes it from sibling tools like inspect_minestom_environment or lookup_minestom_api.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly starts with 'Use this when you want...' providing clear context for when to invoke. It does not mention when not to use or explicitly name alternatives, but the sibling tools serve as implicit alternatives for other tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_minestom_environmentA

Read-onlyIdempotent

Use this when you want a Minestom workspace scan rooted at the current directory or repoRoot, including build files, source patterns, entrypoints, existing libraries, and any detected run/ subdirectories.

ParametersJSON Schema

Name	Required	Description	Default
`repoRoot`	No	Absolute or relative path to the Minestom repository to inspect. Defaults to the current working directory.

Output Schema

ParametersJSON Schema

Name	Required	Description
`buildFiles`	Yes
`buildTool`	Yes
`detectedApiSymbols`	Yes
`detectedTopics`	Yes
`entrypointFiles`	Yes
`existingLibraries`	Yes
`jvmProject`	Yes
`languages`	Yes
`notes`	Yes
`packageNamespaces`	Yes
`projectRoots`	Yes
`repoRoot`	Yes
`runDirectory`	Yes
`runDirectories`	Yes
`sourceRoots`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing what the scan includes (build files, source patterns, etc.) and that it roots at repoRoot or current directory, which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that quickly states the tool's purpose. It is front-loaded with usage guidance and avoids unnecessary words, though it is slightly long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (so return format is documented elsewhere) and one optional parameter, the description adequately covers the tool's capabilities and scope (build files, source patterns, etc.). It is complete enough for an agent to understand what the tool provides.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for repoRoot. The tool description does not add extra semantic meaning beyond the schema's field description, which already explains the default and path nature. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a Minestom workspace scan, listing specific components (build files, source patterns, entrypoints, libraries, run/ subdirectories). It distinguishes from siblings like inspect_minestom_build or lookup_minestom_api.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description begins with 'Use this when you want...', providing explicit guidance on when to use the tool. However, it does not explicitly state when not to use it or suggest alternative sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_minestom_apiA

Read-onlyIdempotent

Use this when you need curated Minestom API matches with package names, why they matter, related APIs, and javadoc links.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Class, interface, or API symbol to look up, such as EventNode or SchedulerManager.
`topic`	No	Optional topic filter to keep the lookup scoped to one Minestom subsystem.

Output Schema

ParametersJSON Schema

Name	Required	Description
`bestMatches`	Yes
`query`	Yes
`topicFilter`	No
`warning`	No

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as read-only and idempotent. The description adds value by detailing what the output contains (package names, explanations, related APIs, javadoc links), going beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single focused sentence beginning with a usage directive. Every word is necessary and no redundancy. It is optimally concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, 1 enum, read-only, output schema exists), the description sufficiently covers what the tool does and returns. No critical gaps are apparent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for symbol and topic. The description does not explicitly reference parameters but the context of 'API matches' implies the symbol parameter. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the tool's purpose as providing curated Minestom API matches with package names, reasons, related APIs, and links. While it is clear, it lacks a strong verb like 'look up' but the context implies lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly starts with 'Use this when you need curated Minestom API matches,' providing clear usage context. It does not mention when not to use or name alternatives, but the sibling tools are available for comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pingA

Read-onlyIdempotent

Use this when you want to verify that the Minestom MCP server is reachable.

ParametersJSON Schema

Name	Required	Description	Default
`message`	No	Optional text to echo back in the response.

Output Schema

ParametersJSON Schema

Name	Required	Description
`echoedMessage`	Yes
`ok`	Yes
`timestamp`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the specific behavior of verifying reachability and echoing an optional message, which is consistent and adds context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise and front-loaded with the purpose. Every word is necessary and there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple nature of the tool, the presence of an output schema (indicated by context), and comprehensive annotations, the description provides complete context for an AI agent to understand when and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for the single optional parameter 'message', so the baseline is 3. The tool description does not add any new information about the parameter beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'verify' and the resource 'Minestom MCP server reachability', making it distinct from sibling tools like 'get_server_info' or 'inspect_minestom_build'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use the tool ('verify that the Minestom MCP server is reachable'), but does not provide explicit when-not-to-use or alternatives. However, the context is clear and sufficient for basic guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

plan_minestom_featureA

Read-onlyIdempotent

Use this when you want a Minestom feature plan grounded in official patterns for bootstrap, commands, events, instances, schedulers, and threading.

ParametersJSON Schema

Name	Required	Description	Default
`featureType`	Yes	The kind of Minestom feature you want to plan.
`language`	No	The target JVM language for the implementation.	java
`packageName`	No	Base package name for the generated outline.	dev.example.minestom
`targetName`	Yes	A short feature name such as SpawnCommand or LobbyJoinListener.
`useCases`	No	Optional behavior notes or acceptance criteria to fold into the plan.

Output Schema

ParametersJSON Schema

Name	Required	Description
`featureType`	Yes
`files`	Yes
`implementationSteps`	Yes
`keyApis`	Yes
`primaryTopic`	Yes
`summary`	Yes
`supportingTopics`	Yes
`threadSafetyNotes`	Yes
`verificationSteps`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety and idempotency. The description adds context about 'official patterns' but does not elaborate on behavior beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the use case. Every word is necessary and there is no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (5 parameters, output schema present), the description is short but sufficient to understand when to invoke. The output schema likely covers return values, so the description does not need to explain them. Slight deduction for not mentioning plan structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already describes all parameters. The description does not add parameter-level detail but is not required to; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('plan') and resource ('Minestom feature plan') and specifies it is grounded in official patterns. It distinguishes from sibling tools like 'explain_minestom_pattern' (plan vs explain) and 'inspect_*' (plan vs inspect).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description starts with 'Use this when you want...' providing clear use context. It implicitly differentiates from siblings but does not explicitly list exclusions or alternatives. It could benefit from mentioning when not to use or suggesting 'explain_minestom_pattern' for understanding existing patterns.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

review_minestom_designA

Read-onlyIdempotent

Use this when you want Minestom-specific design feedback that checks whether a proposed feature aligns with the platform’s manager, instance, event, scheduler, and threading patterns.

ParametersJSON Schema

Name	Required	Description	Default
`designNotes`	Yes	Free-form design notes or a proposed implementation approach to review.
`featureType`	Yes	The kind of Minestom feature the notes describe.

Output Schema

ParametersJSON Schema

Name	Required	Description
`featureType`	Yes
`fitAssessment`	Yes
`gaps`	Yes
`recommendedApis`	Yes
`recommendedTopics`	Yes
`riskyAssumptions`	Yes
`strengths`	Yes
`threadTickConcerns`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds no further behavioral context. It confirms the tool checks design patterns but does not expand on safety or side effects beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with usage context. No wasted words. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two simple parameters, 100% schema coverage, and presence of output schema, the description is complete. It explains the tool's purpose and when to use it without missing critical details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters have clear descriptions. Description does not add any additional meaning or constraints beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'review' and the resource 'Minestom-specific design feedback', specifying alignment with platform patterns. It effectively distinguishes from sibling tools like 'plan_minestom_feature' (planning) and 'explain_minestom_pattern' (explanation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use this when you want Minestom-specific design feedback...' Provides context but lacks explicit exclusions or naming of alternative tools. Still clear enough for agent decision.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

suggest_minestom_librariesA

Read-onlyIdempotent

Use this when you want Minestom ecosystem suggestions grounded in the official libraries directory, with optional live GitHub topic lookups.

ParametersJSON Schema

Name	Required	Description
`category`	No	Optional curated category filter to narrow the ecosystem suggestions.
`includeLiveResults`	No	When true, also search live GitHub repositories tagged with the Minestom library topic.
`repoRoot`	No	Absolute or relative path to the target Minestom repository. Defaults to the current working directory for environment-aware suggestions.
`useCase`	Yes	Describe the problem space, such as command framework, world persistence, debug rendering, or Kotlin coroutines.

Output Schema

ParametersJSON Schema

Name	Required	Description
`categoryFilter`	No
`curatedResults`	Yes
`environment`	No
`liveResults`	Yes
`matchedCategories`	Yes
`mergedResults`	Yes
`query`	Yes
`warning`	No

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context about being 'grounded in the official libraries directory' and 'optional live GitHub topic lookups', which clarifies what the tool does without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that is front-loaded with the usage guidance. It is concise and every part earns its place without extraneous detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has a complete input schema (100% coverage) and an output schema, the description adequately covers the purpose and high-level behavior. The context signals confirm it is a read-only suggestion tool, and the description aligns with that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; it paraphrases the includeLiveResults and repoRoot functionality but does not clarify constraints or formats beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'suggest Minestom ecosystem suggestions' with a clear verb and resource, and distinguishes from sibling tools like 'explain_minestom_pattern' by focusing on library suggestions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description starts with 'Use this when you want ...' providing direct usage context. It mentions the data source and optional live lookups, but does not explicitly state when not to use it or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv1.0.0Mar 29, 2026
- First observedexplain_minestom_pattern
- First observedget_server_info
- First observedinspect_minestom_build
- First observedinspect_minestom_environment
- First observedlookup_minestom_api
- First observedping
- First observedplan_minestom_feature
- First observedreview_minestom_design
- First observedsuggest_minestom_libraries

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored 2026-05-03 14:50 across 9 tools

Disambiguation5/5

Each tool targets a distinct aspect of Minestom development: explanation, inspection, planning, review, API lookup, library suggestions, server info, and a health check. No two tools have overlapping purposes.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., explain_minestom_pattern, inspect_minestom_build). The ping tool is a single verb but is a standard health check. Overall consistent and readable.

Tool Count5/5

9 tools is well-scoped for a server focused on Minestom development support. Each tool serves a clear role without redundancy.

Completeness4/5

The set covers the core needs for Minestom development: pattern explanation, environment/build inspection, API lookup, planning, design review, and library suggestions. Minor gaps exist (e.g., no direct troubleshooting or runtime control), but it aligns with its advisory purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
developer
io.github.doc2mcp
MCP server for developer documentation, generated by doc2mcp.
Documentation Access Developer Tools
24
docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2
dev
io.github.doc2mcp
MCP server for dev documentation, generated by doc2mcp.
Documentation Access Developer Tools
12

Related MCP Servers

MCP Documentation Server
Documentation Access Developer Tools Search
glassBead-tc
A
license
B
quality
D
maintenance
Provides comprehensive access to MCP documentation through structured guides, full-text search, and interactive development workflows for building servers and clients.
Updated a year ago (2025-09-19 13:06 UTC)
3
8
MIT
Minecraft Plugin Documentation
Developer Tools Documentation Access Code Analysis
ValentinTarnovsky
F
license
A
quality
B
maintenance
This MCP server assists Minecraft Java plugin developers by providing dependency documentation lookups, version checking, and automated scanning for Gradle and Maven projects. It supports popular APIs such as Paper, Spigot, and LuckPerms to streamline plugin development and workspace analysis.
Updated 2 months ago (2026-07-23 17:03 UTC)
4
2
-
mcp-registry
Developer Tools Search
daedalus
A
license
A
quality
C
maintenance
An MCP server designed for interacting with the Model Context Protocol Registry API to discover and retrieve information about available MCP servers. It provides tools to search, list, and view detailed configurations and version history for servers within the registry.
Updated 5 months ago (2026-04-21 19:28 UTC)
4
MIT
Endstone MCP Server
Developer Tools Code Analysis
Mcayear
A
license
Not graded
quality
D
maintenance
An MCP server for EndstoneMC development, enabling module information queries, code search, plugin template generation, event handling guidance, and development tutorials through natural language.
Updated a year ago (2025-06-15 00:06 UTC)
2
MIT