Provides CNPC JavaDoc API lookups using JavaDoc hosted on GitHub Pages for CustomNPCs forks (CustomNPC+, Goodbird, BetaZavr).
Click on "Install 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., "@CNPC JavaDoc MCP Server search for ICustomNpc class in 1.12.2"
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 that provides CustomNPCs (CNPC) JavaDoc API lookups. Lets AI coding agents search CNPC class methods, fields, and inheritance hierarchies across multiple Minecraft versions and forks.
CustomNPCs is a Minecraft mod with a rich Java scripting API spanning 10+ Minecraft versions and 3 forks. This MCP server lets your AI agent:
Search CNPC JavaDoc for methods and fields with boolean expressions, column modifiers, and scoring
View class hierarchies — inheritance chains and direct subclasses
Auto-build caches on first use — fetches and parses JavaDoc HTML from kodevelopment.nl and GitHub Pages
Full interoperability with AI-MCP-NativeMinecraftAccess — identical search syntax
Scenario | How This Helps |
CNPC script development | Look up method signatures, parameters, and return types |
Class hierarchy exploration | Find parent interfaces and classes for API types |
Cross-version porting | Compare API surfaces between MC versions |
Fork development | Query CustomNPC+ or Goodbird fork APIs |
Tool | Description |
| Search CNPC JavaDoc methods/fields with boolean expressions |
| Display class inheritance chain and direct subclasses |
Related MCP server: EmbeDocs-MCP
Node.js ≥ 18
git clone https://github.com/SaltfishSheep/AI-MCP-CNPCAPIAccess.git
cd AI-MCP-CNPCAPIAccess
npm install
npm run buildClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"cnpc-javadoc": {
"command": "node",
"args": ["/absolute/path/to/AI-MCP-CNPCAPIAccess/dist/index.js"]
}
}
}OpenCode (opencode.json):
{
"mcp": {
"cnpc-javadoc": {
"type": "local",
"command": ["node", "/absolute/path/to/AI-MCP-CNPCAPIAccess/dist/index.js"],
"enabled": true
}
}
}Cursor (.cursor/mcp.json):
{
"mcpServers": {
"cnpc-javadoc": {
"command": "node",
"args": ["/absolute/path/to/AI-MCP-CNPCAPIAccess/dist/index.js"]
}
}
}Replace
/absolute/path/to/with the actual path where you cloned the repo.
search(mc_version="1.12.2", expression="ICustomNpc")
search(mc_version="1.12.2", expression="say:method")
search(mc_version="1.12.2", expression="health:field")Example queries:
Query | Description |
| All entries mentioning ICustomNpc |
| Methods with "say" in name |
| Fields with "health" in name |
| Class name exactly "ICustomNpc" |
| All entries under entity package |
| Methods returning boolean |
| Static methods containing "get" |
| Dialog or quest entries with "get" |
| Deduplicated class list |
Expression syntax:
Syntax | Meaning | Example |
| Case-insensitive substring match |
|
| Restrict to specific columns |
|
| Strong modifier — exact match |
|
| Dot notation → |
|
| AND (higher precedence) |
|
| OR |
|
| Grouping |
|
Modifiers:
Modifier | Searches | Description |
| class, name, desc, access, is_static | Default (excludes sideonly) |
| class | Full class path |
| class name after last | Class name only |
| package before last | Package only |
| name | Method/field names |
| name, type=method only | Methods only |
| name, type=field only | Fields only |
| desc | JVM descriptors |
| access, is_static | Access/static status |
| sideonly | Always "common" for CNPC |
show-hierarchy(mc_version="1.12.2", class="noppes/npcs/api/entity/ICustomNpc")Example output:
Hierarchy: ICustomNpc -> IEntityLiving -> IEntityLivingBase -> IEntity -> Object
Subs:
ICustomNpcThe tool returns two sections:
Hierarchy: inheritance chain from the class up to root (-> separated)
Subs: direct subclasses (if any)
Dot notation is also accepted: "noppes.npcs.api.entity.ICustomNpc".
Source | Versions | Parser Profile |
kodevelopment.nl | 1.7.10 | kodevelopment-legacy |
kodevelopment.nl | 1.8.9, 1.9.4 | kodevelopment-old |
kodevelopment.nl | 1.10.2, 1.11.2 | kodevelopment-mid |
kodevelopment.nl | 1.12.2 | kodevelopment-modern |
kodevelopment.nl | 1.16.5, 1.18.2 | kodevelopment-latest |
CustomNPC+ (Kamkeel) | cnpc+:1.7.10 | kodevelopment-legacy |
Goodbird | 1.20.1 | goodbird |
BetaZavr | BetaZavr:1.12.2 | kodevelopment-modern |
BetaZavr | BetaZavr:1.20.1 | goodbird |
Note: CNPC has no official releases for MC 1.8–1.8.8, 1.9–1.9.3, 1.11, or 1.13–1.15.2.
Standard: "1.12.2", "1.7.10", "1.20.1"
Fork: "cnpc+:1.7.10" (CustomNPC+), "BetaZavr:1.12.2", "BetaZavr:1.20.1"
On first search for a given CNPC version, the server fetches JavaDoc HTML from kodevelopment.nl or GitHub Pages
It parses class pages using version-specific HTML parsers (6 profile names routing to 3 parser implementations)
Methods and fields are extracted with JVM descriptors and stored as CSV cache
Class hierarchy is extracted and stored as JSON cache
Subsequent searches use the cached data (validated against package.json version)
AI-MCP-CNPCAPIAccess/
├── package.json
├── tsconfig.json
├── src/
│ ├── index.ts # MCP server entry point (search + show-hierarchy)
│ ├── types.ts # TypeScript type definitions
│ ├── util.ts # Shared utilities (CSV parsing, package version)
│ ├── version-table.ts # CNPC version → doc URL + parser profile mapping
│ ├── builder/
│ │ ├── index.ts # buildJavadocCache entry point
│ │ ├── download.ts # HTTP fetch with retry
│ │ ├── javadoc-parser.ts # 3-implementation JavaDoc HTML parser (6 profiles)
│ │ ├── descriptor.ts # Java type → JVM descriptor converter
│ │ └── cache.ts # CSV + hierarchy JSON cache writer
│ └── search/
│ ├── index.ts # Re-exports
│ ├── expression.ts # Boolean expression parser (AND/OR/braces)
│ └── csv-reader.ts # CSV reader + search
├── dist/ # Built JavaScript (entry: dist/index.js)
└── .javadoc-caches/ # Generated cache files (gitignored)MIT License — see LICENSE.
kodevelopment.nl — Official CustomNPCs JavaDoc (1.7.10–1.18.2)
Kamkeel GitHub Pages — CustomNPC+ fork JavaDoc (1.7.10)
Goodbird GitHub Pages — Unofficial CNPC port JavaDoc (1.20.1)
Search CustomNPCs (CNPC) JavaDoc API — methods and fields across versions and forks.
expression syntax: term — case-insensitive substring term:modifier — substring match in column; term::modifier — exact match in column a&b (AND) | a|b (OR) | {expr} (grouping). & has higher precedence than |. "noppes.npcs.api.entity.ICustomNpc" auto-expands to "/" and "$" paths.
Modifiers: all (default) — all columns class — class (full path) classname — class name after last '/' package — package before last '/' name — name (methods+fields) method — same column, methods only field — same column, fields only desc — desc (JVM descriptor) modifier — access, is_static side — sideonly (always common for CNPC)
Scoring: exact case hit = 1.0, case-insensitive = 0.5, then by mismatch (less unmatched chars ranks higher).
Common patterns: "ICustomNpc::classname" → exact class name only "Script:classname" → all classes containing "Script" "noppes/npcs/api/entity:package" → all classes under a package "health:field" → fields only, no methods "()Z:desc" → methods returning boolean "get:method&static::modifier" → static methods containing "get" output="%class%" → deduplicated class list
Version format: "1.12.2" for standard, "cnpc+:1.7.10" for CustomNPC+ fork.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-indexed). Default: 1 | |
| limit | No | Number of results per page (default: 20, max: 100) | |
| output | No | Output format template using %variable% syntax (case-insensitive). Variables: %type%, %class% (full class path), %name% (method/field name), %desc% (JVM descriptor), %access%, %is_static% (static/non-static), %sideonly%, %match%, %mismatch%. Consecutive spaces collapsed. Identical outputs deduplicated. | [%type%] %class%/%name% %desc% %access% %is_static% %sideonly% |
| expression | Yes | Boolean search expression (case-insensitive, exact case match scores higher). Syntax: term, term:modifier (substring match in column), term::modifier (exact match in column), a&b (AND), a|b (OR), {expr} (grouping with braces). Modifiers: all, class, classname, package, name, method, field, desc, modifier, side. & has higher precedence than |. Examples: "Entity::classname", "walk:method&static::modifier", "noppes/npcs/api/entity:package" | |
| mc_version | Yes | Minecraft version to search (e.g. "1.12.2", "1.20.1"). Supported: 1.10.2, 1.11.2, 1.12.2, 1.16.5, 1.18.2, 1.20.1, 1.7.10, 1.8.9, 1.9.4, BetaZavr:1.12.2, BetaZavr:1.20.1, cnpc+:1.7.10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only, open-world, idempotent, non-destructive. The description adds behavioral details like scoring, output deduplication, and format templates, enhancing transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for syntax, modifiers, scoring, patterns, and version format. Every sentence serves a purpose, and it is appropriately sized for the complexity.
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?
Given 5 parameters, no output schema, and complex query syntax, the description covers all necessary details: syntax, modifiers, scoring, common patterns, version format, and output template. No gaps.
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?
With 100% schema coverage, the description still adds substantial value by explaining expression syntax in depth, listing modifiers, providing examples, and detailing output variables, far exceeding baseline.
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 clearly states the tool searches the CNPC JavaDoc API for methods and fields across versions and forks, distinguishing it from the sibling 'show-hierarchy' which likely displays hierarchy instead of searching.
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?
The description provides extensive usage guidelines with syntax, modifiers, scoring, and common patterns. It lacks explicit when-not-to-use compared to the sibling, but the detail effectively guides correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display the class inheritance hierarchy for a CustomNPCs (CNPC) class.
Returns two sections:
Hierarchy: inheritance chain from the class up to root (-> separated)
Subs: direct subclasses (if any)
Example output for BlockEvent: Hierarchy: BlockEvent -> CustomNPCsEvent -> Event -> Object Subs: BlockEvent$BreakEvent BlockEvent$ClickedEvent ...
| Name | Required | Description | Default |
|---|---|---|---|
| class | Yes | Fully-qualified class path using '/' separator (e.g. "noppes/npcs/api/entity/ICustomNpc"). Dot notation is also accepted (e.g. "noppes.npcs.api.entity.ICustomNpc"). | |
| mc_version | Yes | CNPC version to query (e.g. "1.12.2", "cnpc+:1.7.10", "1.20.1"). Supported: 1.10.2, 1.11.2, 1.12.2, 1.16.5, 1.18.2, 1.20.1, 1.7.10, 1.8.9, 1.9.4, BetaZavr:1.12.2, BetaZavr:1.20.1, cnpc+:1.7.10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, so the tool's safety profile is clear. The description adds behavioral context by explaining the two return sections and providing an example output, going beyond what annotations offer.
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?
The description is concise, front-loads the purpose, and includes an example. It is efficiently structured, though it could be slightly tighter.
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 read-only tool with two well-documented parameters, the description covers the purpose, return structure, and provides an example. With no output schema, the description adequately compensates.
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 the schema already documents both parameters. The description mentions dot notation and lists supported versions, but these add little beyond the schema. The baseline of 3 is appropriate.
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 clearly states it displays a class inheritance hierarchy for CNPC, and distinguishes itself from the sibling tool 'search' by its specific function. It explicitly mentions the two output sections (Hierarchy and Subs) and provides an example.
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?
The description implies usage when needing class hierarchy, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it.
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. Dates show when Glama detected each change.
v1.1.0searchshow-hierarchyThe two tools have clearly distinct purposes: 'search' handles querying the JavaDoc database with a powerful search syntax, while 'show-hierarchy' displays class inheritance. There is no overlap in functionality.
Both tool names follow a consistent verb pattern (imperative), with 'search' being a single verb and 'show-hierarchy' using a verb_noun format with hyphenation. The style is uniform and predictable.
With only two tools, the server feels somewhat thin for a JavaDoc browsing domain. While the search tool is powerful, additional tools like 'get_class_details' or 'list_versions' would enhance the coverage. The count is borderline acceptable but not optimal.
The tool set covers search and hierarchy but misses direct access to detailed documentation for specific methods or fields. Users relying solely on these tools may face dead ends when needing comprehensive class or method info, indicating notable gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Versioned documentation registry and semantic search for AI tools and coding assistants.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SaltfishSheep/AI-MCP-CNPCAPIAccess'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
