Forge Neo MCP
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| capabilitiesA | Report what this Forge instance offers: routes, counts, and which metadata sources are available. Call this first in a session. |
| model_profileA | Describe the currently loaded checkpoint: architecture preset, whether it behaves as a turbo/distilled model, the sampling parameters that actually worked before, the expected prompt dialect, and whether its VAE and text encoder modules exist. Call before writing a prompt for an unfamiliar model. |
| prompt_dialectA | How the loaded checkpoint expects to be prompted, with its quality tags. Returns the dialect (pony / illustrious / animagine / anima / sd15 / sdxl_base / natural), the quality prefix and negative baseline it needs, and where that conclusion came from. Quality tags are not decoration: an Illustrious prompt without them degrades, and a Flux prompt with them degrades too. When the dialect comes back unknown — |
| lorasA | Search available LoRAs by name, title, tags, trigger words or description. Only call this when the request actually calls for one (a named style,
character, or concept) — most generations need no LoRA at all. |
| lora_infoA | Full detail for one LoRA, including description, tags, past usage and a ready-to-paste prompt fragment with its trigger words. |
| modelsA | List or load checkpoints. action: "list" | "load" | "refresh". Loading swaps the model for the whole instance, including any human using
the web UI at the same time, and takes several seconds — only do it when the
operator asked for that model. When the target belongs to a different
architecture, its preset, VAE and text encoder are switched with it, since
Forge would otherwise load it against whatever modules are selected now. The
architecture is inferred from two signals and only acted on when they agree;
pass |
| module_checkA | Check the VAE and text encoders loaded for an architecture against what it actually needs, and list installed files that could fill any gap. Defaults to the active preset. Worth calling after switching architecture or when output looks wrong for no obvious reason: Forge records the last selection made under a preset, so loading a checkpoint while another preset was active can leave the wrong modules attached. Where the reference does not state a VAE, it says so instead of guessing — a wrong VAE degrades output without raising an error. |
| module_downloadA | Find, and optionally fetch, a VAE or text encoder the architecture needs. Called with no arguments it lists what the active preset is missing and
where each file comes from, downloading nothing. Downloading requires both a
Links come from the Forge Classic wiki's Download Models page. Where several builds exist — bf16, fp8_scaled, gguf — they are all offered, because which to take depends on the operator's hardware, not on a default worth hiding. |
| generateA | Generate an image from an already-written prompt. The prompt is sent verbatim: include any Pass |
| progressB | Check or stop the current generation. action: "status" | "interrupt" | "skip". |
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 10 tools
Tools are mostly distinct by resource and action—LoRA search vs detail, module check vs download, generation vs progress—but model_profile and prompt_dialect overlap on prompt dialect, and models/model_profile could be confused at a glance. The detailed descriptions mitigate most ambiguity.
Names consistently use lowercase snake_case and a readable resource-oriented style (loras, lora_info, models, module_check). Not all are verb_noun—generate is a bare verb and progress is ambiguous—so it is not a perfect 5, but there is no chaotic convention mixing.
Ten tools is well within the ideal 3–15 range and matches the server's scope: discovery, model/prompt/LoRA/module setup, generation, and progress control. No tool feels redundant or superfluous.
The surface covers the full generation workflow—model loading, profiling, prompt dialect, LoRA lookup, module diagnostics/download, generate, and progress monitoring. Minor gaps exist (no LoRA download/management, no explicit output/history listing), but they are not required for the core purpose.