team-memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TEAM_MEMORY_USER | No | Optional username for ownership of written experiences. Used as fallback when TEAM_MEMORY_API_KEY is not set (default: anonymous). | |
| TEAM_MEMORY_DB_URL | Yes | PostgreSQL connection string, e.g. postgresql+asyncpg://user:pass@host:5432/team_memory. Required unless provided by a config file. | |
| TEAM_MEMORY_API_KEY | No | API key that maps the MCP session to a Web user. Recommended; if not set, falls back to TEAM_MEMORY_USER. | |
| TEAM_MEMORY_PROJECT | No | Optional project name to scope experiences. If absent, the server infers the project from .tm.toml, git repo name, or directory name. | |
| TEAM_MEMORY_CONFIG_PATH | No | Path to a server configuration file. If set, it takes precedence and can supply database URL and other settings. |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| memory_saveA | Save valuable knowledge: solutions, decisions, patterns, pitfalls. Call this when you: fix an unexpected error (title=error summary, problem=what failed, solution=what fixed it); choose between alternatives (title=decision, problem=context, solution=chosen option + why); receive user correction on your approach (title=feedback, problem=what you did wrong, solution=correct approach); learn access info like credentials or config (title=reference, problem=what you needed, solution=how to access it). Use scope='personal' for preferences, 'project' for team knowledge. For session archiving, use the /archive skill (not this tool). |
| memory_recallA | Search team knowledge base before solving problems. Call this BEFORE you: debug an error or exception; implement a feature in an unfamiliar area; make a design or architecture decision; work with code you haven't seen before. Provide 'problem' for focused solutions, 'query' for exploratory search, or just 'file_path' for context-based suggestions. With include_archives=True, results may include type=archive (previews only); call memory_get_archive(archive_id) for full L2 text. |
| memory_contextB | Get your profile and relevant team knowledge for current work. Call this when: starting a new task or conversation; switching to a different part of the codebase; wanting to understand team conventions for a file or module. |
| memory_get_archiveA | Load full archive body (L2) by id: solution_doc, overview, conversation_summary, attachments (with content_snapshot), document_tree_nodes. Use when memory_recall returned type=archive. |
| memory_archive_upsertA | Create or update an archive (title + project dedup), same contract as POST /api/v1/archives. Use for L0/L1/L2 text fields only; large files via HTTP POST /api/v1/archives/{archive_id}/attachments/upload or python -m team_memory.cli upload (after you have archive_id). Does not embed file bytes. |
| memory_feedbackA | Rate a knowledge result after using it (1=not helpful, 5=very helpful). Call this when a memory_recall result helped you solve a problem. |
| memory_draft_saveB | Pipeline-only: save a draft memory. source is always 'pipeline', exp_status is always 'draft'. |
| memory_draft_publishA | Pipeline-only: promote a draft to published. Only works on experiences with source='pipeline' and exp_status='draft'. |
| memory_submit_responseA | Submit your response text after using memory_recall results. This enables faithfulness evaluation — measuring whether your response was based on the retrieved knowledge. Call this AFTER you've used memory_recall results to answer a question. |
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 9 tools
Most tools have clearly distinct purposes: recall searches, save writes, get_archive fetches full archives, draft_save/publish manage pipeline drafts. The only ambiguous pair is memory_recall and memory_context, which both retrieve relevant knowledge but differ in trigger scenario, so an agent might occasionally choose the wrong one.
All tools share a consistent memory_ prefix and most use a verb_noun pattern (get_archive, save, recall, archive_upsert, draft_publish, submit_response). memory_context breaks the pattern by using only a noun, and memory_save is a bit vague without an object, but the overall convention is predictable.
Nine tools is well-scoped for a team memory server covering search, save, archives, drafts, feedback, context, and response submission. Each tool serves a distinct part of the memory lifecycle without excessive granularity or missing core operations.
The tool surface covers the main workflows: saving, recalling, retrieving full archives, managing archive upserts, pipeline draft handling, feedback, and context. Minor gaps exist—there is no explicit delete or update operation for saved knowledge experiences, and no direct get-by-id for non-archive entries—but agents can work around these via recall and archive upsert.