Statewave

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
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.
Average 4.6/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 82 commits in the last 12 weeks
- Last stable release on July 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![statewave-connectors MCP server](https://glama.ai/mcp/servers/smaramwbc/statewave-connectors/badges/card.svg)](https://glama.ai/mcp/servers/smaramwbc/statewave-connectors)

Score Badge

Copy to your README.md:

[![statewave-connectors MCP server](https://glama.ai/mcp/servers/smaramwbc/statewave-connectors/badges/score.svg)](https://glama.ai/mcp/servers/smaramwbc/statewave-connectors)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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