LocalMCP
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 |
|---|---|
| feedback_prepareA | Prepare a bug report, feature request or help request for al-mighty/localmcp. Use only when the user wants to report a LocalMCP problem or suggestion. No network request or automatic log/file collection. Show the complete preview and ask for approval before publishing. Do not use public issues for vulnerabilities or credentials; use SECURITY.md. |
| feedback_submitA | Publish a feedback_prepare draft under the user's existing gh login. Call only after explicit user approval of that draft's repository, title and body. Never submit automatically after an error or upload private context. Returns the created issue URL. Drafts expire in 15 minutes and belong to this MCP process; do not automatically retry uncertain results. |
| memory_searchA | Hybrid semantic + lexical search over persistent cross-project memory. Call this BEFORE answering questions about past decisions, incidents, infrastructure quirks, or user preferences — it is the source of truth for things not derivable from the current repo. |
| memory_getA | Fetch one memory in full by id. memory_search returns only the matching excerpt; call this when the excerpt is not enough and you need the whole text. |
| memory_writeA | Persist one durable fact. Use for: non-trivial fixes and their root cause (kind=incident), architectural choices and why (decision), stable project facts (fact), how the user wants to be worked with (preference), external URLs/dashboards/tickets (reference), reusable code patterns (snippet). Do NOT store what the repo or git history already records. Near-duplicates are rejected with the existing id — update or supersede that instead. |
| memory_updateA | Amend an existing memory in place. Use for corrections and additions that do not change what the memory is about; use memory_supersede when the belief itself changed. |
| memory_supersedeA | Replace an outdated memory with a new one, keeping the old version queryable so the history of the belief survives. Prefer this over delete whenever a fact changed. |
| memory_listA | Browse memories by project/kind/tags without a query. Use to audit what is stored or to load a project's context at the start of a session. |
| memory_deleteA | Permanently remove a memory. Only for entries that were wrong to record at all (secrets, noise, mistakes). For facts that merely became stale, use memory_supersede. |
| memory_statsA | Counts per project and kind, plus embedder and database health. Use to verify the store is reachable and to see what knowledge exists before searching blindly. |
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
Each tool has a clearly distinct role: memory search/get/list cover retrieval, write/update/supersede/delete cover mutation with explicit guidance on when to use which, and feedback prepare/submit form a clear staged workflow. The descriptions explicitly contrast easily confused operations such as update vs supersede and delete vs supersede.
All tools follow a consistent snake_case resource_action pattern: memory_* for memory operations and feedback_* for feedback operations. The naming is predictable and readable throughout.
Ten tools is well-scoped for a local memory server with a small feedback path. The eight memory tools each cover a distinct lifecycle operation, and the two feedback tools are appropriately minimal.
The memory surface is strong, covering search, retrieval, listing, stats, creation, correction, supersession, and deletion. The feedback path covers preparation and submission but lacks status tracking, listing, or follow-up operations, which is a minor gap for the stated reporting purpose.