Skip to main content
Glama

suggest_minestom_libraries

Read-onlyIdempotent

Suggests Minestom ecosystem libraries by searching the official directory and optionally live GitHub topics for your use case.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryNoOptional curated category filter to narrow the ecosystem suggestions.
includeLiveResultsNoWhen true, also search live GitHub repositories tagged with the Minestom library topic.
repoRootNoAbsolute or relative path to the target Minestom repository. Defaults to the current working directory for environment-aware suggestions.
useCaseYesDescribe the problem space, such as command framework, world persistence, debug rendering, or Kotlin coroutines.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryFilterNo
curatedResultsYes
environmentNo
liveResultsYes
matchedCategoriesYes
mergedResultsYes
queryYes
warningNo

Implementation Reference

  • The main handler function for the suggest_minestom_libraries tool. Parses input (category, includeLiveResults, repoRoot, useCase), inspects the Minestom environment, selects curated libraries by scoring them against the use case, optionally fetches live GitHub results, merges and deduplicates results, and returns the output.
    export const suggestMinestomLibrariesTool: TanStackServerTool = toolDefinition({
    	description:
    		"Use this when you want Minestom ecosystem suggestions grounded in the official libraries directory, with optional live GitHub topic lookups.",
    	inputSchema: suggestMinestomLibrariesInputSchema,
    	name: "suggest_minestom_libraries",
    	outputSchema: suggestMinestomLibrariesOutputSchema,
    }).server(async (args) => {
    	const { category, includeLiveResults, repoRoot, useCase } =
    		suggestMinestomLibrariesInputSchema.parse(args);
    	const environment = await inspectMinestomEnvironment(repoRoot).catch(
    		() => undefined,
    	);
    	const curated = selectCuratedLibraries(useCase, category, environment);
    	const live = includeLiveResults
    		? await fetchLiveLibraries(useCase, category)
    		: { results: [], warning: undefined };
    
    	const mergedResults = uniqueBy(
    		[...curated.results, ...live.results].filter(
    			(entry) =>
    				!environment?.existingLibraries.some(
    					(library) =>
    						library.repoUrl.toLowerCase() === entry.repoUrl.toLowerCase(),
    				),
    		),
    		(entry) => entry.repoUrl.toLowerCase(),
    	);
    
    	return suggestMinestomLibrariesOutputSchema.parse({
    		categoryFilter: category,
    		curatedResults: curated.results,
    		environment,
    		liveResults: live.results,
    		matchedCategories: uniqueBy(
    			[
    				...curated.inferredCategories.filter(
    					(value): value is z.infer<typeof libraryCategorySchema> => {
    						return (libraryCategorySchema.options as string[]).includes(value);
    					},
    				),
    				...curated.results.map((entry) => entry.category),
    				...live.results.map((entry) => entry.category),
    			],
    			(value) => value,
    		),
    		mergedResults,
    		query: useCase,
    		warning:
    			live.warning ??
    			(environment &&
    			(!environment.jvmProject.isLikelyJvmProject ||
    				environment.detectedTopics.length === 0)
    				? "No strong JVM-backed Minestom repository signals were detected in the inspected environment; suggestions are primarily use-case driven."
    				: undefined),
    	});
    });
  • Input schema defining the tool's parameters: category (optional filter), includeLiveResults (boolean, defaults false), repoRoot (optional path), and useCase (required text describing the problem space).
    const suggestMinestomLibrariesInputSchema = z.object({
    	category: libraryCategorySchema
    		.optional()
    		.describe(
    			"Optional curated category filter to narrow the ecosystem suggestions.",
    		),
    	includeLiveResults: z
    		.boolean()
    		.default(false)
    		.describe(
    			"When true, also search live GitHub repositories tagged with the Minestom library topic.",
    		),
    	repoRoot: z
    		.string()
    		.optional()
    		.describe(
    			"Absolute or relative path to the target Minestom repository. Defaults to the current working directory for environment-aware suggestions.",
    		),
    	useCase: z
    		.string()
    		.describe(
    			"Describe the problem space, such as command framework, world persistence, debug rendering, or Kotlin coroutines.",
    		),
    });
  • Output schema defining the tool's response: categoryFilter, curatedResults, environment, liveResults, matchedCategories, mergedResults, query, and optional warning.
    const suggestMinestomLibrariesOutputSchema = z.object({
    	categoryFilter: libraryCategorySchema.optional(),
    	curatedResults: z.array(librarySuggestionSchema),
    	environment: environmentSummarySchema.optional(),
    	liveResults: z.array(librarySuggestionSchema),
    	matchedCategories: z.array(libraryCategorySchema),
    	mergedResults: z.array(librarySuggestionSchema),
    	query: z.string(),
    	warning: z.string().optional(),
    });
  • src/tools.ts:18-28 (registration)
    Registration of the suggestMinestomLibrariesTool in the tools array. The tool is imported from ./minestom/libraries.js and pushed into the server's tool collection.
    tools.push(
    	pingTool,
    	createGetServerInfoTool(toolNames),
    	inspectMinestomEnvironmentTool,
    	inspectMinestomBuildTool,
    	explainMinestomPatternTool,
    	lookupMinestomApiTool,
    	planMinestomFeatureTool,
    	reviewMinestomDesignTool,
    	suggestMinestomLibrariesTool,
    );
  • Helper that infers a library category from a live GitHub repository's description and name, falling back to 'gameplay' if no match.
    function inferCategoryForLiveRepo(
    	useCase: string,
    	description: string,
    	name: string,
    ): z.infer<typeof libraryCategorySchema> {
    	const inferred = inferCategoriesFromUseCase(
    		`${useCase} ${description} ${name}`,
    	)[0];
    
    	switch (inferred) {
    		case "commands":
    		case "concurrency":
    		case "world-storage":
    		case "models-and-ui":
    		case "gameplay":
    		case "debugging":
    			return inferred;
    		default:
    			return "gameplay";
    	}
    }
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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Azoraqua/minestom-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server