Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pumpkin API MCP Server Search the Pumpkin API for the PlayerJoinEvent and show its documentation."
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.
An MCP (Model Context Protocol) server designed to help LLMs (like Claude, Cursor, Windsurf) understand, navigate, and develop plugins for the Pumpkin Minecraft Server.
This MCP server provides intelligent tools to search the Pumpkin Plugin API, read WebAssembly Interface Types (WIT) definitions, and even scaffold new Wasm plugins instantly.
Read API & WIT Files: Safely explore the crates/pumpkin-plugin-api and crates/pumpkin-plugin-wit directories.
Smart Search: Regex-enabled search across the entire API and WIT codebase.
Code Block Extraction: Extract specific line ranges to prevent LLM context bloat.
Auto-Documentation Extraction: Instantly extract doc comments (///) and public signatures from Rust/WIT files to get a quick overview of any module.
Plugin Scaffolding: Generate a fully configured wasm32-wasip1 boilerplate project with a single command.
Related MCP server: MCP Docs Server
Clone the repository (if you haven't already): Ensure you have pulled the submodules, as the WIT definitions are stored in one.
git clone --recurse-submodules https://github.com/YOUR_USERNAME/Pumpkin-MCP.git
cd Pumpkin-MCPInstall Dependencies: Make sure you have Node.js installed.
npm installBuild the Server: Compile the TypeScript code to JavaScript.
npm run buildTo use this MCP server, you need to configure your LLM client to point to the built dist/index.js file.
Go to Settings > Features > MCP.
Click + Add new MCP server.
Set the type to command.
Set the name to pumpkin-api.
Set the command to:
node /absolute/path/to/Pumpkin-MCP/dist/index.js(Make sure to replace /absolute/path/to/ with the actual path to this repository on your computer).
Edit your claude_desktop_config.json file to include:
{
"mcpServers": {
"pumpkin-api-mcp": {
"command": "node",
"args": [
"/absolute/path/to/Pumpkin-MCP/dist/index.js"
]
}
}
}Once configured, your LLM will automatically have access to these tools:
list_api_files: Lists all files in the API and WIT directories.
read_api_file: Reads the full content of an API or WIT file.
search_api_code: Searches for keywords, structs, or traits using Regex.
read_code_block: Extracts specific line ranges from a file.
get_module_docs: Extracts only the documentation comments and public exports from a file.
scaffold_plugin: Generates a standard Pumpkin plugin boilerplate configured for WebAssembly.
This repository includes a GitHub Actions workflow (.github/workflows/sync.yml) that runs daily. It automatically syncs the crates/pumpkin-plugin-api and crates/pumpkin-plugin-wit folders directly from the upstream Pumpkin repository to ensure your LLM always has the latest context.
Extracts documentation comments (///) and the signatures immediately following them from a Rust or WIT file
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the file relative to the API or WIT root, e.g. 'src/item.rs' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the return content (doc comments and immediately following signatures). However, it omits that this is a read-only, side-effect-free operation, how missing files or unsupported file types are handled, and any output format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tightly-worded sentence with the action and scope front-loaded and no filler. Nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description conveys enough: what it extracts and from which file types. It would be stronger if it noted the read-only nature and error behavior, but the core invocation is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (filePath) exists and schema description coverage is 100%, including the relative-path convention and an example. The description adds no parameter detail, so baseline 3 applies since the schema already does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Extracts') and resource ('documentation comments (///) and the signatures immediately following them') scoped to Rust or WIT files. It is clear on its own, but it does not distinguish itself from similar siblings like read_api_file or read_code_block, which also read file content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this over alternatives such as read_api_file or read_code_block, nor any mention of prerequisites or supported contexts beyond the Rust/WIT scope. The agent must infer the use case from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all files and directories in the Pumpkin Plugin API and WIT interface
| Name | Required | Description | Default |
|---|---|---|---|
| subdirectory | No | Optional subdirectory to list, e.g. 'src/events' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the scope of what is enumerated (both the Plugin API and the WIT interface), which is real behavioral information, but says nothing about depth/recursion, ordering, or whether limits apply to the listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no waste, front-loading the verb and the resource scope. Nothing is repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter listing tool with no output schema or annotations, the description is minimally sufficient, but it omits any hint of the return shape (tree, flat list, file types) that an agent would benefit from when planning a browse-then-read flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'subdirectory' parameter is documented in the schema with an example ('src/events'). The description adds no additional parameter meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and names the resources ('files and directories in the Pumpkin Plugin API and WIT interface'), which cleanly separates it from read_api_file and search_api_code. It stops short of explicitly contrasting itself with those siblings, but the verb makes the browse-vs-read distinction obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus partners like read_api_file, search_api_code, or get_module_docs. An agent can infer it is a discovery step before reading, but the description supplies no conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the content of a specific file in the Pumpkin Plugin API or WIT interface
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the file relative to the API or WIT root, e.g. 'src/lib.rs' or 'pumpkin-plugin.wit' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses very little beyond the basic read action. It does not say what happens if the path is invalid, whether large files are truncated, what the return shape is, or whether the read is guaranteed non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or redundancy. It is perhaps overly terse for the behavioral gaps it leaves, but nothing in it is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with full schema coverage and no output schema, the description is minimally adequate. However, with zero annotations it should say more about read safety, failure modes, or content size limits to fully equip an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself documents filePath with concrete examples ('src/lib.rs', 'pumpkin-plugin.wit'). The description adds only the framing that paths are relative to the API or WIT root, which is already in the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Reads') and resource ('content of a specific file') with scope ('in the Pumpkin Plugin API or WIT interface'). It is clearly distinguishable from list_api_files and search_api_code in intent, though it does not explicitly name those siblings to reinforce the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings like search_api_code (find content) or read_code_block, nor any note about prerequisites such as the file needing to exist. Usage is only implied by the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a specific range of lines from a file in the Pumpkin API or WIT interface
| Name | Required | Description | Default |
|---|---|---|---|
| endLine | Yes | The ending line number (1-indexed, inclusive) | |
| filePath | Yes | Path to the file relative to the API or WIT root, e.g. 'src/lib.rs' | |
| startLine | Yes | The starting line number (1-indexed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While 'Reads' implies a non-mutating operation, it says nothing about error behavior (e.g. out-of-range lines, missing file), size limits, or encoding, all of which matter for a line-range reader. This is a notable gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with the action front-loaded. The trailing 'in the Pumpkin API or WIT interface' is useful scoping rather than filler, though the sentence could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and its three required parameters are fully documented in the schema, so little is needed. However, with no output schema the description does not indicate what is returned (raw lines, line-numbered, etc.), which would help an agent use the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the schema already documents filePath, startLine (1-indexed), and endLine (inclusive). The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Reads) and resource (a range of lines from a file), with a scope constraint (Pumpkin API or WIT interface). It is clear what the tool does, but it never names the obvious alternative read_api_file, so the boundary between reading a range and reading a whole file is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this instead of read_api_file or search_api_code. The 'range of lines' phrasing implies a targeted-read use case, but no explicit condition or exclusion is stated, leaving the agent to infer the distinction from the siblings' names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a standard boilerplate project for a Pumpkin plugin, configured for wasm32-wasip1.
| Name | Required | Description | Default |
|---|---|---|---|
| pluginName | Yes | The name of the plugin (e.g. 'my-cool-plugin') | |
| destinationDir | Yes | The absolute path where the plugin project should be created |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the target platform (wasm32-wasip1) but says nothing about side effects: whether files are written to disk, whether it overwrites/fails on an existing directory, or whether it runs install/build steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; the key action and platform target come first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A mutating, filesystem-writing tool with no annotations and no output schema should describe what artifacts get created and how it behaves on an existing destination. Those obligations are unmet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already fully documented in the schema (pluginName, destinationDir with absolute-path note). The description adds nothing beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Generates') and resource ('boilerplate project for a Pumpkin plugin') plus a configuration detail (wasm32-wasip1). This clearly separates it from the read-only sibling tools (list_api_files, read_api_file, etc.), though it never explicitly distinguishes itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to scaffold vs. read existing API code, no prerequisites, and no note about what happens if the destination already contains a project. The agent must infer appropriate usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for a string or regex pattern in the Pumpkin Plugin API and WIT codebase
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search term or regex pattern | |
| isRegex | No | Whether the query is a regular expression |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and only conveys the search scope. It omits case sensitivity, match limits or pagination, how results are returned, and whether the operation is purely read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that states the action and scope with zero filler. Nothing could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should ideally hint at result shape and limits, and with no annotations it should at least confirm the read-only nature. The scope statement covers the essentials but leaves meaningful gaps for an agent deciding how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both query and isRegex are already documented inline. The description's mention of "string or regex pattern" loosely reinforces isRegex but adds no syntax, format, or default information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Searches") and resource (a string or regex pattern) scoped to the Pumpkin Plugin API and WIT codebase. It is clearly distinguishable from read/list siblings, though it never explicitly contrasts itself with read_api_file or list_api_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to search versus reading files directly, nor any mention of prerequisites or exclusions. The agent must infer from the verb alone that this is the discovery tool and the read_* tools are for retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_module_docslist_api_filesread_api_fileread_code_blockscaffold_pluginsearch_api_codeScored across 6 tools
Most tools have distinct purposes, but read_api_file (full file) and read_code_block (line range) overlap in function, and get_module_docs also reads file content albeit for a specific extraction. Descriptions help clarify boundaries, but an agent could still confuse these read-oriented tools.
All tools use snake_case with a verb_noun pattern, which is consistent. However, the first three tools include an 'api' prefix (list_api_files, read_api_file, search_api_code) while the remaining three do not, creating a minor inconsistency in naming convention.
Six tools is well-scoped for an API exploration and plugin scaffolding server. Each tool covers a distinct operation without redundancy, and the set feels complete without being bloated.
The tool surface covers reading, searching, extracting documentation, and scaffolding a plugin, which are core workflows. Minor gaps exist, such as no tool to validate or build a scaffolded plugin, but these are outside the primary API exploration focus.
Securely search and manage workspace context files for AI agents and teams.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
An MCP server that gives your AI access to the source code and docs of all public github repos
Provide detailed Pokémon data and information through a standardized MCP interface. Enable LLMs an…
