polypack-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 |
|---|---|
| memory_storeB | Store durable project memory. Use procedural for preferences, conventions, and decisions; semantic for stable facts; episodic for events or task outcomes; and entity for named people, projects, or objects. Use a stable context for project memory. |
| memory_getA | Fetch one memory by exact ID, including its current state and revision. |
| memory_updateA | Update mutable memory fields without changing its content. Supported fields are context, confidence, provenance, and metadata. Use memory_supersede when the memory content itself needs to change. expected_revision prevents overwriting a concurrent update. |
| memory_list_contextsA | List context namespaces and the number of memories in each. |
| memory_deleteA | Permanently delete one memory and its graph edges. This destructive operation requires confirm=true. Prefer memory_suppress when retaining history is useful. |
| memory_recallA | Search memories by text, context, activation, and confidence. Use this for a targeted question. Use memory_context to assemble working context. Context is soft by default; use strict_context=true for isolation. With include_neighbors=true, bounded graph neighbors are hydrated into the result. Filter relationships with edge_types such as RESPONDS_TO. The neighbor_limit bounds hydrated neighbors; limit remains the total result count. depth is silently clamped to at most 3 hops regardless of the value passed; metadata reports the depth actually applied. Metadata also reports when additional neighbors were available. |
| memory_threadB | Walk the RESPONDS_TO chain from a starting memory ID and return the thread. Retrieves connected memories in both directions along RESPONDS_TO edges, returning them sorted chronologically. |
| memory_contextB | Return a working-memory set selected by activation and estimated-token budget. token_budget is an estimated-token budget. Each returned memory fits wholly within the remaining budget; budgets must be greater than zero. |
| memory_feedbackB | Record whether a retrieved memory helped this task. Call this after using a recalled memory when it was useful or misleading. |
| memory_suppressC | Inhibit a stale or unhelpful memory without deleting it. |
| memory_supersedeA | Replace an outdated fact while retaining its history. |
| memory_consolidateC | Consolidate source memories into one durable higher-level memory. |
| memory_linkA | Connect two memories with an explicit graph relationship. Use RESPONDS_TO when a new handoff, verification, or fix addresses an earlier memory. Use memory_recall(include_neighbors=true) to retrieve linked memories with relationship metadata. |
| memory_store_with_linkA | Store a new memory and link it to an existing memory in one call. Combines memory_store and memory_link for the common case of storing a reply, verification, or fix that responds to an earlier memory. By default the new memory is the link source (new -relationship-> target); set reverse=true to make the new memory the link target instead. |
| memory_unlinkA | Remove graph edges between two memories. If relationship is omitted, all directed edges from source to target are removed. |
| memory_store_batchA | Store multiple durable project memories in a single batch. Each item in the list should be a dict with 'content' and optional 'memory_class', 'context', 'confidence', 'provenance', and 'metadata' keys. |
| memory_link_batchB | Connect multiple pairs of memories with explicit graph relationships in a single batch. Each item in the list should be a dict with 'source_memory_id', 'target_memory_id', and optional 'relationship' (defaults to 'RESPONDS_TO') keys. |
| graph_queryB | Inspect graph neighbors/schema or perform an advanced edge operation. Prefer memory_link for normal memory relationships. Supported operations are neighbors, add_edge, schema, and relationship_diagnostics. RESPONDS_TO graph edges are authoritative; diagnostics identifies legacy provenance-only relationships. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| active_resource | |
| schema_resource | |
| stats_resource | |
| workflow_help_resource |
TDQS
Scored across 18 tools
Each tool has a clearly distinct role: store, link, retrieve, suppress, supersede, consolidate, batch, and graph diagnostics are all explicitly separated. Even near-overlapping pairs like memory_store/memory_store_with_link and memory_link/graph_query are carefully disambiguated in their descriptions.
The memory_* prefix provides a strong, predictable namespace, and most tools follow a clear verb-like pattern: store, update, delete, recall, link, unlink. Minor deviations like memory_context, memory_thread, and memory_feedback are noun-oriented, and graph_query breaks the memory_ prefix pattern, so it is not perfectly uniform.
At 18 tools, the server is above the ideal 3-15 range and feels somewhat heavy. However, the batch variants, store-with-link convenience, and full memory lifecycle tools are mostly justified by the breadth of the domain.
The tool surface covers memory CRUD, batch operations, graph edge management, retrieval modes, lifecycle transitions, feedback, and context assembly. There are no obvious dead ends or missing operations for a project-memory and relationship-graph server.