Muninn
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_hybridA | Semantic + fulltext hybrid search over indexed repos. Supply 'repo' (absolute checkout/directory path) or 'cwd' (a directory inside it); 'repo' takes precedence. Git worktrees resolve through Git and registered families; directory roots through database registration. A first search can register and index a new linked worktree when its family already permits indexing. Subsequent searches use that checkout's last completed index; incomplete Git operations retain it. |
| search_fulltextA | Tokenized full-text keyword search, not literal substring or regex matching. Supply 'repo' (absolute checkout/directory path) or 'cwd' (a directory inside it); 'repo' takes precedence. Git worktrees resolve through Git and registered families; directory roots through database registration. A first search can register and index a new linked worktree when its family already permits indexing. Subsequent searches use that checkout's last completed index; incomplete Git operations retain it. |
| search_semanticA | Vector similarity search. Supply 'repo' (absolute checkout/directory path) or 'cwd' (a directory inside it); 'repo' takes precedence. Git worktrees resolve through Git and registered families; directory roots through database registration. A first search can register and index a new linked worktree when its family already permits indexing. Subsequent searches use that checkout's last completed index; incomplete Git operations retain it. |
| search_structuralA | Find name-based related-symbol candidates, not compiler-verified bindings. For Git checkouts, call resolution prefers matches in the caller file, keeping ties; otherwise it keeps checkout-wide matches. Verify paths and source. Supply 'repo' (absolute checkout/directory path) or 'cwd' (a directory inside it); 'repo' takes precedence. Git worktrees resolve through Git and registered families; directory roots through database registration. A first search can register and index a new linked worktree when its family already permits indexing. Subsequent searches use that checkout's last completed index; incomplete Git operations retain it. |
| record_knowledgeA | Store a curated knowledge item under an exact repository-path key (no worktree/family resolution). Items are embedded and searchable via search_knowledge. Provide 'id' to update an existing item. |
| search_knowledgeA | Hybrid semantic + fulltext search over curated notes under an exact repository-path key; no worktree/family resolution. Use the established main-checkout key for shared notes. |
| delete_knowledgeC | Delete a knowledge item by its UUID. |
| list_knowledgeB | List knowledge for an exact repository-path key, ordered by most recently updated. Worktrees do not automatically share this key. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
This server cannot be deployed
TDQS
Scored across 8 tools
The four search_* tools map to distinct modalities (hybrid, fulltext, semantic, structural), and the knowledge tools (record/search/delete/list) are clearly separated. However, the search tools share nearly identical boilerplate about repo/cwd resolution, making the first-purpose distinction easy to gloss over, and search_knowledge sits conceptually close to the search_* family.
Consistent snake_case with search_<modality> for retrieval and <verb>_knowledge for note management. The minor inconsistency is that search_knowledge uses the verb_noun form while the other searches use object-noun (modality) naming, but the pattern remains readable.
Eight tools is well-scoped for a code-search server: four search modalities plus a complete knowledge-item lifecycle. Each tool earns its place with no obvious redundancy.
Knowledge items have full lifecycle coverage (record/create+update, list/read, search, delete) and retrieval spans four modalities. The gap is index management: no explicit re-index, index-status, or delete-index tool, though searches auto-register/index to mitigate.