Skip to main content
Glama
contextstream

ContextStream MCP Server

Memory

memory
Read-onlyIdempotent

Store and retrieve documentation, decisions, tasks, and events to maintain persistent context across conversations. Use semantic search to find relevant information without filesystem tools.

Instructions

Persistent memory — docs, runbooks, specs, ADRs, decisions, lessons, tasks, and todos live HERE, never on disk: when the user mentions "the doc on X", "our runbook for Y", or "why we decided Z", use action="search" or list_docs/get_doc — NOT filesystem tools. Tasks here are lightweight project-tracking items; for tickets, bugs, incidents, releases, or handoffs use the entity tool instead. Event actions: create_event, get_event, update_event, delete_event (accepts event_id UUID or exact title; delete_all=true bulk-removes exact-title matches), list_events, distill_event, import_batch (bulk import array of events). Node actions: create_node, get_node, update_node, delete_node (accepts node_id UUID or exact title; delete_all=true bulk-removes exact-title matches), list_nodes, supersede_node. Query actions: search, decisions, timeline, summary. Task actions: create_task (create task, optionally linked to plan), get_task, update_task (can link/unlink task to plan via plan_id), delete_task, list_tasks, reorder_tasks. Todo actions: create_todo, list_todos, get_todo, update_todo, delete_todo, complete_todo. Diagram actions: create_diagram, list_diagrams, get_diagram, update_diagram, delete_diagram. Doc actions: create_doc, list_docs, get_doc, update_doc, delete_doc, create_roadmap. Transcript actions: list_transcripts (list saved conversations), get_transcript (get full transcript by ID), search_transcripts (semantic search across conversations), search_archive (hosted archive tier; local npm returns unavailable), delete_transcript. Team actions (team plans only): team_tasks, team_todos, team_diagrams, team_docs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoMode metadata (capture/create filters) and query filter. Matches both structured `mode` and `mode:<value>` tag fallback.
tagsNoTags for event or task categorization
agentNoAgent identity metadata (capture/create filters) and query filter. Matches both structured `agent` and `agent:<name>` tag fallback.
limitNoMaximum number of results to return.
orderNoTask order within plan
queryNoSearch query string.
scopeNoArchive collection scope for search_archive: transcripts, decisions, lessons, docs
titleNoShort descriptive title.
actionYesAction to perform
doc_idNoDoc ID for get_doc/update_doc/delete_doc. For get_doc, accepts UUID or title/query text.
due_atNoDue date (ISO 8601) for todo
eventsNoArray of events for import_batch action
reasonNoFor supersede_node: reason for the supersede
statusNoBackward-compatible alias for task_status in task actions
contentNoFull content/body.
node_idNoNode ID (UUID).
plan_idNoPlan ID (full 36-char UUID): for create_task (link to plan), update_task (set UUID to link, null to unlink), list_tasks (filter by plan)
task_idNoTask ID for get_task/update_task/delete_task (full 36-char UUID)
todo_idNoTodo ID for get_todo/update_todo/delete_todo (full 36-char UUID)
categoryNoInput parameter: category.
doc_typeNoDocument type
event_idNoEvent ID (UUID).
metadataNoInput parameter: metadata.
priorityNoTask priority
task_idsNoTask IDs for reorder_tasks
code_refsNoInput parameter: code refs.
completedNoTodo completion flag for update_todo
node_typeNoInput parameter: node type.
relationsNoInput parameter: relations.
delete_allNoFor delete_node/delete_event with a non-UUID lookup: delete ALL exact-title matches in one call instead of erroring on ambiguity
diagram_idNoDiagram ID for get_diagram/update_diagram/delete_diagram (full 36-char UUID)
event_typeNoInput parameter: event type.
milestonesNoMilestones for create_roadmap action
project_idNoProject ID (UUID).
provenanceNoInput parameter: provenance.
session_idNoSession ID filter for list_transcripts
client_nameNoClient name filter for list_transcripts (e.g., 'claude', 'cursor')
descriptionNoDescription for task
is_personalNoMark as personal (only visible to creator). For create/list actions on todos, diagrams, docs.
new_contentNoFor supersede_node: the new content to replace the node with
task_statusNoTask status
todo_statusNoTodo status filter for list_todos, or status update value for update_todo
diagram_typeNoMermaid diagram type
plan_step_idNoWhich plan step this task implements
workspace_idNoWorkspace ID (UUID).
started_afterNoISO timestamp - filter transcripts started after this time
todo_priorityNoTodo priority
transcript_idNoTranscript ID for get_transcript/delete_transcript (full 36-char UUID)
blocked_reasonNoReason when task is blocked
started_beforeNoISO timestamp - filter transcripts started before this time
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, destructiveHint, etc. The description adds context about the persistence model and mentions deletion behavior (delete_all) and batch operations. It does not contradict annotations and adds value beyond them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely long and enumerates every action in a run-on list. While front-loaded with purpose, the bulk lacks structure and could be more concise. Many sentences are just action lists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity (50 parameters, many actions, no output schema), the description covers a lot: action categories, parameter purposes, and usage hints. However, it lacks guidance on return values and edge cases, which holds it back from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description provides some additional context for parameters like delete_all and plan_id, but mostly it groups actions rather than deeply explaining parameter semantics. No major gaps, but also no significant extra meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence clearly defines the tool as persistent memory for docs, runbooks, specs, etc., and explicitly distinguishes it from filesystem tools. The verb+resource is specific and the scope is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus alternatives, e.g., 'use action=search or list_docs/get_doc — NOT filesystem tools' and 'for tickets, bugs... use the entity tool instead'. This differentiates from sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/contextstream/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server