neoforge-docs
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NEOFORGE_DOCS_DB | No | Overrides the SQLite FTS5 index location. Defaults to the server's `data/` index output. | |
| NEOFORGE_DOCS_ROOT | No | Overrides the NeoForge documentation directory. Defaults to the repository's `neoforge-docs` directory. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_docsA | Search NeoForge docs and return ranked section snippets with URLs. Args: query: English keywords, e.g. "register item", "data components", "screen rendering". version: "current" (26.1), an exact version such as "1.21.1" / "1.20.4", or "all". section: optional filter: "docs", "toolchain", "user", "modpack". limit: number of hits, 1-12 (default 6). mode: "text" for normal search, "api" to restrict matching to code identifiers. |
| get_sectionA | Return one section (heading + body) of a documentation page. Cheaper and more focused than get_doc. The heading argument accepts an anchor ("creating-an-item"), a heading title ("Creating an Item"), or any distinctive part of the heading path. Args: doc_id: doc_id from search_docs, or a path such as "items/index.md" / "items". heading: anchor, heading text, or heading-path fragment. version: version key; only used when doc_id is a path rather than a full doc_id. |
| get_docA | Return a whole documentation page as markdown, plus its heading outline. Prefer get_section unless the whole page is genuinely needed: pages reach 15k+ chars. Args: doc_id: doc_id from search_docs, or a path such as "items/index.md" / "items". version: version key ("current", "1.21.1", ...) when doc_id is a path. |
| find_symbolA | Find where a Java/NeoForge API name is used or explained. Exact match first, then substring. Good for "Item.Properties#of", "DeferredRegister", "DataComponents", "BlockEntity#saveAdditional". Args: symbol: the API identifier to look up. limit: max hits (1-20, default 10). |
| list_docsA | List every page of a documentation version with title, group and URL. Useful for browsing or checking whether a page exists before searching. Args: version: version key ("current", "1.21.1", ...). section: optional filter: "docs", "toolchain", "user", "modpack". |
| compare_versionsA | Diff one documentation page between two versions (migration helper). Args: doc: page path or doc_id, e.g. "items/index.md". from_version: older version key, e.g. "1.21.1". to_version: newer version key, e.g. "current". |
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 are clearly distinct: get_section vs get_doc is explicitly delineated (partial vs whole page) and list_docs/compare_versions have unique roles. The main overlap is search_docs with mode='api' restricting matches to code identifiers, which duplicating find_symbol's purpose; find_symbol adds exact-then-substring behavior, but the boundary is soft.
All six tools follow a clean snake_case verb_noun pattern (search_docs, get_section, get_doc, find_symbol, list_docs, compare_versions). Verbs are distinct and predictable, with no mixed conventions.
Six tools is well-scoped for a documentation server: search, browse, section/page retrieval, symbol lookup, and version diffing. Each tool earns its place with no redundant bulk.
The read-only docs surface is thorough: full-text and symbol search, page listing, granular section retrieval, whole-page retrieval, and cross-version diffing cover the realistic lifecycle of doc lookup. No obvious dead ends for the stated purpose.