Pumpkin API MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_api_filesB | Lists all files and directories in the Pumpkin Plugin API and WIT interface |
| read_api_fileC | Reads the content of a specific file in the Pumpkin Plugin API or WIT interface |
| search_api_codeB | Searches for a string or regex pattern in the Pumpkin Plugin API and WIT codebase |
| read_code_blockC | Reads a specific range of lines from a file in the Pumpkin API or WIT interface |
| get_module_docsB | Extracts documentation comments (///) and the signatures immediately following them from a Rust or WIT file |
| scaffold_pluginC | Generates a standard boilerplate project for a Pumpkin plugin, configured for wasm32-wasip1. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.