forgemcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | GitHub personal access token for enhanced code search and metadata. |
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 |
|---|---|
| memory.recallC | Search code memory for patterns, solutions, and insights from past sessions |
| memory.storeC | Save a code pattern, solution, or insight to persistent memory |
| memory.evolveC | Create an improved version of an existing pattern (links to parent) |
| memory.relatedB | Find patterns related to a given pattern (by explicit links) |
| memory.linkC | Create a relationship between two patterns |
| memory.statsA | Show code memory statistics: size, coverage, top patterns |
| memory.forgetA | Remove a pattern from memory (cascades to tags, links, embeddings) |
| code.reachA | Jump to any symbol — returns definition, signature, callers, callees, deps in ONE call. Replaces 5-10 Read/Grep calls. |
| code.mapC | Get instant project architecture map — modules, dependencies, hot paths, entry point. Understands MVC, layered, microservices patterns automatically. |
| code.symbolsB | List all exported symbols (functions, classes, types) in a path scope with signatures |
| code.traceB | Trace a call chain from one function to another. Shows the shortest path through the call graph. |
| code.understandA | Get compressed understanding of a file or directory — purpose, key exports, data flow, dependencies, complexity hotspots. Replaces reading 10+ files. |
| github.search_reposC | Search GitHub repositories by query, language, stars, topics |
| github.search_codeC | Search code across GitHub. Returns file matches with text fragments. |
| github.repo_overviewC | Get comprehensive repo intelligence: stars, health, CI, topics, license |
| github.repo_fileC | Get file content from a GitHub repo |
| github.repo_treeC | Get file tree of a GitHub repo (recursive) |
| genius.find_bestA | Find the best implementations of a concept across GitHub. Returns ranked archetypes with explanations, not raw search results. Example: genius.find_best('rate limiter', language: 'typescript') |
| github.compareC | Compare implementations from different repos side-by-side with quality breakdown |
| import.extractA | Extract a function/module from a GitHub repo with provenance. License-checked, dependency-resolved, style-adapted. Returns ready-to-paste code with attribution. |
| research.archaeologyB | Trace how a concept evolved in a repo over time. Analyzes git commit history and code changes. No external AI required. |
| research.deep_compareC | Deep comparison of implementations across repos. Returns structured metrics and quality signals for the calling LLM to reason about. |
| research.start_chainA | Start a new research chain to track reasoning across multiple steps. Chains persist across sessions for future recall. |
| research.add_stepC | Add a reasoning step to an active research chain. Records: what you searched, what you found, key insight, decision made. |
| research.concludeC | Mark a research chain as completed with final synthesis. |
| research.recall_chainB | Search past research chains by topic. Answer questions like 'why did we choose Orama?' from stored reasoning. |
| genius.huntB | Find the best implementations of a concept across GitHub, grep.app, and searchcode. Returns ranked archetypes (not raw search results) with quality explanations. Example: genius.hunt('rate limiter', language: 'typescript') |
| genius.explainB | Explain why a code result ranked where it did. Full signal breakdown with per-factor scores. |
| forge_discoverA | Search ForgeMCP capabilities by intent. Returns matching tool names with one-line descriptions. Example: forge_discover('find rate limiter code') → genius.hunt, genius.find_best |
| forge_describeA | Get full input schema and usage example for a ForgeMCP tool. Call forge_discover first to find tool names. |
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 30 tools
Multiple tools have overlapping purposes with near-identical descriptions: genius.find_best vs genius.hunt, github.compare vs research.deep_compare, and code.reach vs code.understand are easy to confuse. While some descriptions contain differentiating details, several boundaries remain unclear enough that an agent could misselect.
Most tools use dot-namespaced names (memory.recall, github.search_code, code.reach), but the pattern is broken by forge_discover/forge_describe and subcommands mix single words, verbs, and snake_case (e.g., research.archaeology vs research.deep_compare). Readable but not fully consistent.
With 30 tools, this exceeds the 25+ threshold for 'too many'. Several tools are redundant variations (e.g., two 'find best implementations' tools, two comparison tools), suggesting the surface could be consolidated rather than each tool earning its place.
The surface covers code memory CRUD (store, recall, evolve, forget, link, related, stats), research chain lifecycle, GitHub search/retrieval, local code understanding, and implementation discovery. Minor gaps like local full-text code search or exact-ID memory retrieval are workable, but not fatal.