Skip to main content
Glama
smaramwbc

Statewave

by smaramwbc
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

@statewavedev/mcp-server

Statewave MCP server — exposes Statewave memory to MCP-compatible clients (coding assistants, agent frameworks, IDE extensions).

Part of the Statewave Connectors ecosystem. Vendor-neutral by design — no IDE, model provider, or hosted dependency assumptions.

What's here

  • STATEWAVE_MCP_TOOLS — the canonical tool surface (5 tools, JSON Schema input)

  • StatewaveClient — thin HTTP client for the Statewave v1 API (auth, tenant, typed errors)

  • dispatchTool — input-validating dispatcher that maps a tool call to a StatewaveClient method

  • startMcpServer — minimal stdio JSON-RPC 2.0 transport, plus a --list-tools mode

Related MCP server: MemHeaven

Tools

Tool

Purpose

statewave_ingest_episode

Ingest a single normalized episode (deduped on idempotency_key).

statewave_search_memories

Search compiled memories by free-text query within a subject.

statewave_get_context

Retrieve compact, ranked context for a subject — the default tool to use inside a prompt.

statewave_get_timeline

Chronological episodes for a subject; filterable by kinds, since, until.

statewave_compile_subject

Trigger compilation of a subject so newly ingested episodes become recallable.

Usage

# As a CLI subcommand (via @statewavedev/connectors-cli)
statewave-connectors mcp start --list-tools     # print the JSON Schema surface and exit
statewave-connectors mcp start                  # stdio JSON-RPC 2.0 server (requires STATEWAVE_URL)

# Or programmatically inside an existing MCP runtime
import { StatewaveClient, dispatchTool } from "@statewavedev/mcp-server";
const client = new StatewaveClient({ url: process.env.STATEWAVE_URL!, apiKey: process.env.STATEWAVE_API_KEY });
const { result } = await dispatchTool(client, "statewave_get_context", {
  subject: "repo:owner/name",
  query: "repo conventions and recent changes",
});

Status

v0.1.0 preview — minimal stdio transport included. See RELEASE_NOTES.md.

Available Tools

6 tools
statewave_compile_subjectA

Compile a subject's accumulated raw episodes into durable, retrievable memories. This is the step that makes ingested episodes searchable: statewave_ingest_episode stores raw episodes, and this distils them into the compiled memory that statewave_get_context and statewave_search_memories read. Triggers a compile job on the server and returns its summary (subject and status). By default it is a no-op when there are no new episodes since the last compile; set force to recompile anyway. Call it right after ingesting episodes you want to become retrievable.

ParametersJSON Schema
NameRequiredDescriptionDefault
forceNoRecompile even when no new episodes have been ingested since the last compile (default false). Use to refresh stale memory or after changing compilation settings.
subjectYesSubject to compile. Format `scope:identifier`, e.g. `repo:owner.name` or `customer:acme`.

TDQS

A4.7/5.0
Behavior5/5

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

Despite no annotations, the description fully discloses behavior: triggers a compile job, returns a summary, is a no-op by default, and the effect of the force parameter. It covers all important behavioral aspects.

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

Conciseness5/5

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

The description is three sentences, each essential: first defines the tool, second distinguishes from siblings, third explains behavior and usage. It is front-loaded with the core purpose.

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

Completeness5/5

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

Given the two parameters, no output schema, and no annotations, the description is fully complete. It explains the return value (summary with subject and status) and provides all necessary context for correct invocation.

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

Parameters4/5

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

The schema already provides 100% coverage with descriptions for both parameters. The description adds value by explaining the default no-op behavior for the force parameter and the subject format, going beyond the schema.

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 description clearly states the tool compiles raw episodes into durable, retrievable memories, and distinguishes it from siblings like statewave_ingest_episode (stores raw) and statewave_search_memories (reads compiled). It uses specific verbs and resource terms.

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

Usage Guidelines4/5

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

The description explicitly advises calling it right after ingesting episodes to make them retrievable. It also explains the default no-op behavior and when to use the force parameter. It lacks explicit when-not-to-use instructions but provides clear context.

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

statewave_get_contextA

Assemble a compact, ranked context bundle for a subject, tailored to the task described in query. Read-only. Designed to be injected into an agent/LLM prompt in place of stuffing raw chat history or whole files: it returns only the most relevant distilled facts and procedures, fit to a token budget. Returns a context bundle with assembled_context (ready-to-prompt text), structured facts and procedures arrays, and a token estimate. Prefer this over statewave_search_memories when you want prompt-ready context rather than a raw ranked list of memories.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe task being performed or question being answered. Used to rank and select which facts and procedures to include in the bundle.
subjectYesSubject to retrieve context for. Format `scope:identifier`, e.g. `repo:owner.name` or `customer:acme`.
max_tokensNoApproximate token budget for the assembled context (100–32000, default 2000). Lower it for tight prompts; raise it for richer context.

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It declares read-only behavior and describes the output structure (assembled_context, facts, procedures, token estimate). It does not cover auth needs or error handling but provides sufficient behavioral context for an agent.

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

Conciseness4/5

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

The description is a single paragraph but is concise and front-loaded with purpose. Every sentence serves a purpose, though it could be broken into shorter sentences for clarity.

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 tool's complexity (3 params, no output schema, no annotations), the description explains purpose, usage, output, and parameter details adequately. It lacks edge-case or error information but is generally complete.

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

Parameters4/5

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

Schema coverage is 100%, and the description adds meaning beyond the schema: it explains query's ranking role, subject's format with examples, and max_tokens usage advice. This adds substantial value.

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 description clearly states the tool assembles a compact, ranked context bundle for a subject tailored to the query. It uses specific verbs ('assemble', 'injected') and distinguishes itself from statewave_search_memories, making the purpose unambiguous.

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

Usage Guidelines4/5

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

The description explicitly recommends preferring this tool over statewave_search_memories when prompt-ready context is needed, providing a clear when-to-use scenario. However, it does not address when to use other siblings like statewave_compile_subject or statewave_get_timeline.

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

statewave_get_timelineA

Retrieve a subject's raw episodes in chronological order (oldest to newest). Read-only. Unlike statewave_search_memories (ranked, compiled memories), this returns the underlying event log unmodified — use it for audit trails, change-logs, debugging what was ingested, or replaying history. Optionally bound the window with since/until and filter to specific event kinds. Returns an array of episode records (id, kind, text, occurred_at, source), capped by limit; an empty array means no episodes matched the filters.

ParametersJSON Schema
NameRequiredDescriptionDefault
kindsNoOptional list of event kinds to include (e.g. `["github.issue.opened", "chat.note"]`). When omitted, all kinds are returned.
limitNoMaximum number of episodes to return (1–500, default 100).
sinceNoOptional inclusive lower time bound: only episodes with occurred_at at or after this ISO 8601 timestamp are returned, e.g. `2026-06-01T00:00:00Z`.
untilNoOptional exclusive upper time bound: only episodes with occurred_at strictly before this ISO 8601 timestamp are returned.
subjectYesSubject whose episodes to list. Format `scope:identifier`, e.g. `repo:owner.name` or `customer:acme`.

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Declares read-only, returns unmodified chronological log, capped by limit, and describes return structure. Does not discuss pagination or error handling, but adequately covers core behavior for a read operation.

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

Conciseness5/5

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

Single paragraph of five sentences, front-loaded with purpose, then details. No wasted words. Clearly structured with contrasting sibling and enumeration of parameters.

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 no output schema, description explains return array with fields and behavior when empty. Covers key aspects for agent decision (read-only, filters, limit). Missing error conditions or existence checks, but adequate for typical usage.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. Description adds value by contextualizing parameters (e.g., 'bound the window with since/until', 'filter to specific event kinds'), providing format examples for kinds and subject, and explaining limit cap. Reinforces schema descriptions with usage context.

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?

Clearly states the verb 'retrieve', the resource 'subject's raw episodes', and ordering 'chronological order'. Distinguishes from sibling statewave_search_memories by contrasting raw vs compiled, and lists specific use cases (audit trails, change-logs, debugging, replaying history).

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

Usage Guidelines4/5

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

Explicitly states when to use (audit trails, debugging, etc.) and contrasts with statewave_search_memories (ranked, compiled). Mentions optional filters but doesn't explicitly say when not to use. Provides enough context for an agent to choose based on need for raw vs compiled data.

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

statewave_ingest_episodeA

Write a single normalized event ('episode') into Statewave's raw memory log for a subject. This is a write: the episode is stored immediately but is NOT yet retrievable as durable memory — call statewave_compile_subject afterward to distil episodes into the compiled memories that statewave_get_context and statewave_search_memories read. Idempotent: re-ingesting an idempotency_key already seen for the subject does not create a duplicate. Returns the stored episode id, its idempotency_key, and a duplicate boolean indicating whether an existing episode was matched. Use it to capture a durable fact, decision, message, or system event you want remembered.

ParametersJSON Schema
NameRequiredDescriptionDefault
kindYesEvent type in dotted lowercase namespace form, used to group and filter episodes. Examples: `github.issue.opened`, `chat.note`, `deploy.succeeded`.
textYesHuman-readable content of the event — the fact, note, or message to remember. This is the primary text distilled into compiled memory.
sourceYesProvenance of the episode — where it originated.
subjectYesMemory subject the episode belongs to, as `scope:identifier` using only letters, digits, and the characters . _ - : (no slashes). Examples: `repo:owner.name`, `customer:acme`, `workspace:team`.
metadataNoOptional free-form key/value object for structured attributes (labels, ids, scores) carried alongside the episode.
occurred_atYesWhen the event actually occurred, as an ISO 8601 / RFC 3339 timestamp, e.g. `2026-06-30T15:00:00Z`.
idempotency_keyYesCaller-supplied unique key for this episode. Re-ingesting the same key for the same subject is a no-op (deduplicated), so retries are safe.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: it is a write operation, immediately stored but not retrievable until compilation, idempotent with idempotency_key, and returns the stored episode id, idempotency_key, and a duplicate boolean. No contradictions.

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

Conciseness4/5

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

The description is relatively concise at three sentences, but the second sentence is quite long and packs many details. While all information is relevant, the structure could be slightly more streamlined. Overall, it is well front-loaded with the core action.

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

Completeness5/5

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

Despite no output schema, the description specifies what is returned (stored episode id, idempotency_key, duplicate boolean). It covers the complete workflow: write, compile later, idempotent behavior. It accounts for all required parameters with examples and distinguishes from sibling tools. No gaps.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds meaningful context beyond the schema: for 'kind' it gives dotted lowercase naming conventions and examples; for 'text' it notes it is the primary text distilled into memory; for 'source' it explains provenance; for 'subject' it provides pattern and examples; 'metadata' is optional free-form; 'occurred_at' and 'idempotency_key' are clearly explained with usage details.

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 description clearly states it writes a single normalized event into Statewave's raw memory log, specifying the subject, kind, and other fields. It distinguishes from siblings by explaining that compiled memories are accessed via statewave_get_context and statewave_search_memories, and that statewave_compile_subject must be called afterward.

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 explicitly states when to use this tool (to capture durable facts, decisions, messages, or system events) and when not to rely on it for retrieval until compilation. It provides clear guidance that the episode is not immediately retrievable and requires statewave_compile_subject. It also mentions idempotency for safe retries.

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

statewave_list_subjectsA

List the memory subjects this Statewave instance knows about, with per-subject episode and memory counts. Read-only. Use it to discover which subject id to pass to the other tools (e.g. repo:owner.name) — especially in chat clients that have no repository context. Returns a paginated array of subjects (subject id, episode_count, memory_count) plus a total count; page through larger instances with limit/offset.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of subjects to return (1–200, default 50).
offsetNoNumber of subjects to skip from the start of the list, for pagination (default 0).

TDQS

A4.5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It explicitly states 'Read-only,' describes pagination with limit/offset, and details the return structure (paginated array with per-subject counts and total count). This fully discloses behavior beyond what the schema provides.

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

Conciseness5/5

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

The description is a single, well-structured paragraph. It front-loads the purpose and read-only nature, then adds usage guidance, and finally return details. Every sentence adds value with no redundancy.

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

Completeness5/5

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

For a simple list tool with only two parameters and no output schema, the description is complete. It explains why to use it, how to use it (pagination), and what it returns (subject id, episode_count, memory_count, total count). Nothing missing given the complexity.

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 description coverage is 100%, so baseline is 3. The description mentions pagination with limit/offset but does not add new meaning beyond the schema's descriptions. It reinforces the intended use but does not enhance semantics.

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 description clearly states it lists memory subjects with counts, and is read-only. It distinguishes from sibling tools by explicitly mentioning its role in discovering subject IDs for other tools like `repo:owner.name`. This makes the purpose precise and unique.

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

Usage Guidelines4/5

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

The description explicitly says 'Use it to discover which subject id to pass to the other tools' and gives context for chat clients. While it doesn't explicitly state when not to use it, the guidance is clear and actionable for agents. No alternatives are named, but the sibling list is separate.

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

statewave_search_memoriesA

Search a subject's compiled, durable memories by free-text query and return the most relevant ones, ranked by relevance. Read-only. This searches distilled memories, NOT raw episodes — newly ingested episodes only appear here after statewave_compile_subject has run. Returns an array of memory records (id, subject, kind, content) ordered most-relevant first; an empty array means nothing matched. Use it to look up specific remembered facts; prefer statewave_get_context when you instead want prompt-ready context assembled to a token budget.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of ranked memories to return (1–50, default 10).
queryYesFree-text search query — keywords, a question, or a topic to match against the subject's compiled memories.
subjectYesSubject to scope the search to (required by the server). Format `scope:identifier`, e.g. `repo:owner.name` or `customer:acme`.

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are provided, so the description must disclose all behavioral traits. It correctly states 'Read-only' and explains that it searches only compiled memories (not raw episodes), returns results ordered by relevance, and returns an empty array for no match. The description covers the key behaviors, but could mention whether the search is expensive or if there are any rate limits. Still, it is thorough enough for an agent to understand the tool's side effects and data dependencies.

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

Conciseness5/5

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

The description is three sentences long, front-loaded with the primary purpose and read-only nature. The second sentence adds a critical constraint, and the third sentence covers return format and usage guidance. Every sentence is essential and there is no redundant or unnecessary text.

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 that there are no annotations and no output schema, the description covers the necessary aspects: purpose, when to use, key constraint (compilation), return format, and an example of empty results. It is complete enough for an agent to use the tool correctly, though it could elaborate on what 'compiled, durable memories' means beyond referencing statewave_compile_subject.

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

Parameters4/5

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

Schema coverage is 100%, but the description adds significant value beyond the schema. It explains that the search operates on 'distilled memories' and that newly ingested episodes require prior compilation, which clarifies the meaning of the search results. It also provides formatting guidance for the 'subject' parameter. This extra context elevates the score above the baseline of 3.

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 description clearly states the action ('Search'), the resource ('compiled, durable memories'), the method ('free-text query'), and the outcome ('most relevant ones, ranked by relevance'). It explicitly differentiates from sibling tools like statewave_get_context which assembles prompt-ready context. The purpose is unambiguous and specific.

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 explicitly says when to use this tool ('look up specific remembered facts') and when to prefer an alternative ('prefer statewave_get_context when you instead want prompt-ready context assembled to a token budget'). It also provides a critical constraint: newly ingested episodes only appear after statewave_compile_subject has run, guiding the agent on prerequisite actions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 6 tool updatesv1.0.1
    • Changedstatewave_compile_subject3 fields changed
      • changedInput schema / properties / force / description
        Previous value: -"Recompile even if no new episodes"New value: +"Recompile even when no new episodes have been ingested since the last compile (default false). Use to refresh stale memory or after changing compilation settings."
      • addedInput schema / properties / subject / description
        Added value: +"Subject to compile. Format `scope:identifier`, e.g. `repo:owner.name` or `customer:acme`."
      • addedInput schema / properties / subject / pattern
        Added value: +"^[A-Za-z0-9_.:-]+$"
    • Changedstatewave_get_context4 fields changed
      • addedInput schema / properties / max_tokens / description
        Added value: +"Approximate token budget for the assembled context (100–32000, default 2000). Lower it for tight prompts; raise it for richer context."
      • changedInput schema / properties / query / description
        Previous value: -"The task being performed — used to rank facts and procedures"New value: +"The task being performed or question being answered. Used to rank and select which facts and procedures to include in the bundle."
      • addedInput schema / properties / subject / description
        Added value: +"Subject to retrieve context for. Format `scope:identifier`, e.g. `repo:owner.name` or `customer:acme`."
      • addedInput schema / properties / subject / pattern
        Added value: +"^[A-Za-z0-9_.:-]+$"
    • Changedstatewave_get_timeline9 fields changed
      • addedInput schema / properties / kinds / description
        Added value: +"Optional list of event kinds to include (e.g. `[\"github.issue.opened\", \"chat.note\"]`). When omitted, all kinds are returned."
      • addedInput schema / properties / kinds / items / description
        Added value: +"An event kind to include in the results."
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of episodes to return (1–500, default 100)."
      • changedInput schema / properties / since / description
        Previous value: -"ISO 8601 timestamp"New value: +"Optional inclusive lower time bound: only episodes with occurred_at at or after this ISO 8601 timestamp are returned, e.g. `2026-06-01T00:00:00Z`."
      • addedInput schema / properties / since / format
        Added value: +"date-time"
      • addedInput schema / properties / subject / description
        Added value: +"Subject whose episodes to list. Format `scope:identifier`, e.g. `repo:owner.name` or `customer:acme`."
      • addedInput schema / properties / subject / pattern
        Added value: +"^[A-Za-z0-9_.:-]+$"
      • changedInput schema / properties / until / description
        Previous value: -"ISO 8601 timestamp"New value: +"Optional exclusive upper time bound: only episodes with occurred_at strictly before this ISO 8601 timestamp are returned."
      • addedInput schema / properties / until / format
        Added value: +"date-time"
    • Changedstatewave_ingest_episode12 fields changed
      • addedInput schema / properties / idempotency_key / description
        Added value: +"Caller-supplied unique key for this episode. Re-ingesting the same key for the same subject is a no-op (deduplicated), so retries are safe."
      • changedInput schema / properties / kind / description
        Previous value: -"Event kind (e.g. github.issue.opened)"New value: +"Event type in dotted lowercase namespace form, used to group and filter episodes. Examples: `github.issue.opened`, `chat.note`, `deploy.succeeded`."
      • addedInput schema / properties / metadata / description
        Added value: +"Optional free-form key/value object for structured attributes (labels, ids, scores) carried alongside the episode."
      • changedInput schema / properties / occurred_at / description
        Previous value: -"ISO 8601 timestamp"New value: +"When the event actually occurred, as an ISO 8601 / RFC 3339 timestamp, e.g. `2026-06-30T15:00:00Z`."
      • addedInput schema / properties / occurred_at / format
        Added value: +"date-time"
      • addedInput schema / properties / source / description
        Added value: +"Provenance of the episode — where it originated."
      • addedInput schema / properties / source / properties / id / description
        Added value: +"Stable identifier of the item within the source system, e.g. an issue number, message id, or URL slug."
      • addedInput schema / properties / source / properties / type / description
        Added value: +"Source system or channel, e.g. `github`, `slack`, `chat`, `web`."
      • addedInput schema / properties / source / properties / url / description
        Added value: +"Optional canonical link back to the source item."
      • changedInput schema / properties / subject / description
        Previous value: -"Memory subject (e.g. repo:owner/name, customer:acme)"New value: +"Memory subject the episode belongs to, as `scope:identifier` using only letters, digits, and the characters . _ - : (no slashes). Examples: `repo:owner.name`, `customer:acme`, `workspace:team`."
      • addedInput schema / properties / subject / pattern
        Added value: +"^[A-Za-z0-9_.:-]+$"
      • addedInput schema / properties / text / description
        Added value: +"Human-readable content of the event — the fact, note, or message to remember. This is the primary text distilled into compiled memory."
    • Changedstatewave_list_subjects9 fields changed
      • addedInput schema / properties / limit / default
        Added value: +50
      • changedInput schema / properties / limit / description
        Previous value: -"Max subjects to return (default 50, max 200)"New value: +"Maximum number of subjects to return (1–200, default 50)."
      • addedInput schema / properties / limit / maximum
        Added value: +200
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • changedInput schema / properties / limit / type
        Previous value: -"number"New value: +"integer"
      • addedInput schema / properties / offset / default
        Added value: +0
      • changedInput schema / properties / offset / description
        Previous value: -"Pagination offset"New value: +"Number of subjects to skip from the start of the list, for pagination (default 0)."
      • addedInput schema / properties / offset / minimum
        Added value: +0
      • changedInput schema / properties / offset / type
        Previous value: -"number"New value: +"integer"
    • Changedstatewave_search_memories4 fields changed
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of ranked memories to return (1–50, default 10)."
      • addedInput schema / properties / query / description
        Added value: +"Free-text search query — keywords, a question, or a topic to match against the subject's compiled memories."
      • changedInput schema / properties / subject / description
        Previous value: -"Subject the search is scoped to — the Statewave server requires it"New value: +"Subject to scope the search to (required by the server). Format `scope:identifier`, e.g. `repo:owner.name` or `customer:acme`."
      • addedInput schema / properties / subject / pattern
        Added value: +"^[A-Za-z0-9_.:-]+$"
  2. 6 tool updatesv1.0.0
    • First observedstatewave_compile_subject
    • First observedstatewave_get_context
    • First observedstatewave_get_timeline
    • First observedstatewave_ingest_episode
    • First observedstatewave_list_subjects
    • First observedstatewave_search_memories
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation5/5

Each tool targets a unique operation: ingestion, compilation, context retrieval, timeline viewing, memory search, and subject listing. Descriptions explicitly distinguish when to use each, leaving no ambiguity.

Naming Consistency5/5

All tools follow the consistent pattern `statewave_verb_noun` (e.g., `statewave_ingest_episode`, `statewave_get_context`), making the set predictable and easy to navigate.

Tool Count5/5

Six tools cover the essential operations for a memory management system—ingest, compile, retrieve, search, and list—without redundancy or bloat.

Completeness4/5

The tools provide a complete workflow: write, compile, read (context/timeline/search), and discover. Minor gaps such as missing update/delete operations exist, but the core lifecycle is well-supported.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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/smaramwbc/statewave-connectors'

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