Compatible with CrewAI as an MCP client, allowing CrewAI agent sessions to be monitored and compressed for later retrieval.
Compatible with VS Code Copilot as an MCP client, allowing passive observation and context compression within the Copilot environment.
Compatible with LangChain as an MCP client, enabling integration with LangChain-based agents for session observation and memory.
Omega Stenographer MCP is the passive observation layer of the VERITAS & Sovereign Ecosystem (Omega Universe). Where Omega Brain enforces governance and VERITAS gates evaluate artifact integrity, Stenographer observes: it ingests every conversation turn, extracts decisions and blockers from agent reasoning, builds live running notes, and compresses stale context into searchable briefs before it can be lost to context window eviction. It does not govern — it remembers. In the Omega Universe, Omega Stenographer MCP is the institutional memory: the layer that ensures no decision, no blocker, and no hard-won insight evaporates when the context window scrolls past.
SYSTEM INVARIANT: Stenographer does not interpret. It extracts, indexes, and compresses. Every brief is traceable to its source turns. Every search result cites its provenance. No synthesized narrative substitutes for the original record.
Related MCP server: sswp-mcp
Omega Stenographer MCP is a self-contained Model Context Protocol (MCP) server that runs as a local process alongside any MCP-compatible AI client. It exposes 5 tools and 2 resources covering three observation domains:
Turn ingestion — every user and assistant message is captured with structured metadata (role, session ID, extracted decisions, extracted blockers)
Context compression — when unprocessed turns exceed STENO_TURN_LIMIT, they are compressed into a tiered brief fragment and indexed for later retrieval
Searchable memory — full-text search (FTS5) over all exchanges; semantic similarity search over compressed briefs; live running notes document
One Python file. One pip dependency. Zero external services.
Compatible clients: Claude Desktop, VS Code Copilot, Cursor, Windsurf, AutoGen, LangChain, CrewAI, LlamaIndex, and any MCP-compliant host.
Not a governance layer. Stenographer does not approve, block, or steer agent tool calls. It observes and records.
Not a cloud service. No network egress, no API keys, no telemetry. All data remains on the operator's machine under ~/.omega-stenographer/ (or OMEGA_STENOGRAPHER_DIR).
Not a language model. Stenographer does not generate text. It ingests, extracts, indexes, and compresses agent conversation.
Not a policy authority. Stenographer tags decisions and blockers heuristically; it does not determine correctness or enforce constraints.
Every turn captured — role, content, session ID, timestamp
Automatic decision extraction — regex-based patterns detect decision-like statements (decided, chose, settled on, key finding, →)
Automatic blocker extraction — detects stuck states, errors, crashes, timeouts
FTS5 full-text indexing — every exchange is immediately searchable by content, decisions, and blockers
Configurable turn limit — defaults to 8 turns (STENO_TURN_LIMIT); when exceeded, unprocessed turns are compressed
Tiered briefs — tier-A briefs contain extracted decisions; tier-B briefs preserve raw context excerpts
Traceable provenance — every brief records its source turn IDs; no synthesized narrative replaces the original record
Automatic FTS indexing — compressed briefs are immediately searchable
FTS5 keyword search — stenographer_query_history searches all exchanges by content, decisions, and blockers
Semantic similarity search — stenographer_compact_guard uses TF-IDF cosine similarity to rank compressed briefs against a query
Live running notes — stenographer_get_brief returns a formatted document with milestones, compressed briefs, and recent exchanges
Milestone marking — stenographer_mark_milestone elevates critical exchanges to tier-A priority
Two transports — stdio (default, MCP standard) and SSE (HTTP streaming for web clients)
Docker-ready — single Dockerfile, non-root user, unbuffered I/O
Single dependency — mcp>=1.0.0
Fully local — no cloud, no API keys, no external server required
Venv auto-activation shim — the standalone script re-execs itself with the venv Python if deps are isolated
┌─────────────────────────────────────────────────────────────────┐
│ MCP CLIENT │
│ (Claude Desktop / VS Code Copilot / Cursor / AutoGen / ...) │
└───────────────────────────┬─────────────────────────────────────┘
│ MCP stdio / SSE (JSON-RPC 2.0)
▼
┌─────────────────────────────────────────────────────────────────┐
│ OMEGA STENOGRAPHER MCP SERVER │
│ omega_stenographer_mcp_standalone.py │
│ │
│ ┌──────────────────────────┐ ┌──────────────────────────────┐ │
│ │ INGESTION ENGINE │ │ COMPRESSION ENGINE │ │
│ │ │ │ │ │
│ │ Turn Capture │ │ Turn Counting │ │
│ │ (role, content, SID) │ │ (unprocessed tally) │ │
│ │ │ │ │ │
│ │ Decision Extraction │ │ Fragment Generation │ │
│ │ (regex patterns) │ │ (combined context + │ │
│ │ │ │ decision summary) │ │
│ │ Blocker Extraction │ │ │ │
│ │ (problem detection) │ │ Tier Assignment │ │
│ │ │ │ (A: decisions, B: context) │ │
│ │ FTS5 Indexing │ │ │ │
│ │ (content, decisions, │ │ Source Turn Tracking │ │
│ │ blockers) │ │ (brief → turns mapping) │ │
│ └──────────┬───────────────┘ └────────────────┬─────────────┘ │
│ │ │ │
│ ┌──────────┴───────────────────────────────────┴─────────────┐ │
│ │ SEARCH & RETRIEVAL │ │
│ │ │ │
│ │ FTS5 Search (exchanges) TF-IDF Similarity (briefs) │ │
│ │ Running Notes Builder Milestone Manager │ │
│ └────────────────────────────────────────────────────────────┘ │
└─────────────│───────────────────────────────────────────────────┘
│
▼ SQLite
┌───────────────────────────┐
│ ~/.omega-stenographer/ │
│ steno.db │
│ (exchanges + briefs + │
│ FTS5 indexes) │
└───────────────────────────┘Layer | Component | Role |
Ingestion | Turn Capture | Records every user/assistant message with structured metadata |
Ingestion | Decision Extraction | Regex-based detection of decision-like statements in agent reasoning |
Ingestion | Blocker Extraction | Regex-based detection of stuck states, errors, and problems |
Ingestion | FTS5 Indexing | Full-text search index across content, decisions, and blockers |
Compression | Turn Counting | Tracks unprocessed exchanges; triggers compression at |
Compression | Fragment Generation | Condenses multiple turns into a single brief with decision summaries |
Compression | Tier Assignment | Tier-A for decision-bearing context; tier-B for raw context excerpts |
Compression | Source Tracking | Every brief records its constituent turn IDs for traceability |
Retrieval | FTS5 Search | Keyword search over all exchanges |
Retrieval | TF-IDF Similarity | Cosine similarity ranking of compressed briefs |
Retrieval | Running Notes | Formatted document builder: milestones → briefs → recent exchanges |
🏛️ Protocol Standard: The
omega-stenographer-mcpis the passive observation counterpart to Omega Brain MCP. Where Omega Brain enforces the VERITAS Ω-CODE v2.0 governance gates, Stenographer captures the institutional memory those gates operate on — preserving decisions, blockers, and context that would otherwise be lost to context window pressure.
Requirement | Details |
Python | 3.11 or 3.12 |
Core dependency |
|
OS | Linux, macOS, Windows (WSL2 recommended on Windows) |
Disk | ~5 MB for source + SQLite data dir (default |
No external embedding service required. Stenographer uses built-in TF-IDF n-gram (128-dim) for semantic similarity — no GPU, no model download, always available.
pip install omega-stenographer-mcpgit clone https://github.com/VrtxOmega/omega-stenographer-mcp.git
cd omega-stenographer-mcp
pip install mcpdocker build -t omega-stenographer-mcp .
docker run --rm -i omega-stenographer-mcp # stdio mode (MCP standard)
docker run --rm -p 8056:8056 omega-stenographer-mcp --sse --port 8056 # SSE modepip install pytest pytest-asyncio pytest-cov
PYTHONUTF8=1 OMEGA_STENOGRAPHER_DIR=/tmp/steno-test pytest tests/ -v --tb=shortpython omega_stenographer_mcp_standalone.py --helpThe server reads JSON-RPC 2.0 messages from stdin and writes responses to stdout. MCP clients manage this process automatically via the config below.
python omega_stenographer_mcp_standalone.pypython omega_stenographer_mcp_standalone.py --sse --port 8056
# GET http://localhost:8056/sse — event stream
# POST http://localhost:8056/messages — send tool callsecho '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"stenographer_ingest_exchange","arguments":{"role":"user","content":"Hello, world!"}}}' \
| python omega_stenographer_mcp_standalone.pyEdit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"omega-stenographer": {
"command": "python",
"args": ["/absolute/path/to/omega_stenographer_mcp_standalone.py"],
"env": { "PYTHONUTF8": "1" }
}
}
}Add to .vscode/mcp.json in your workspace (or user settings):
{
"servers": {
"omega-stenographer": {
"type": "stdio",
"command": "python",
"args": ["/absolute/path/to/omega_stenographer_mcp_standalone.py"],
"env": { "PYTHONUTF8": "1" }
}
}
}In Cursor Settings → MCP → Add Server:
{
"mcpServers": {
"omega-stenographer": {
"command": "python",
"args": ["/absolute/path/to/omega_stenographer_mcp_standalone.py"],
"env": { "PYTHONUTF8": "1" }
}
}
}In ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"omega-stenographer": {
"command": "python",
"args": ["/absolute/path/to/omega_stenographer_mcp_standalone.py"],
"env": { "PYTHONUTF8": "1" }
}
}
}{
"mcpServers": {
"omega-stenographer": {
"type": "sse",
"url": "http://localhost:8056/sse"
}
}
}Variable | Default | Description |
|
| Set to |
|
| Override the data directory for the SQLite database |
|
| Number of unprocessed turns before compression triggers |
|
| Number of briefs returned by |
Omega Stenographer MCP integrates with any MCP-compatible client using standard JSON-RPC 2.0 over stdio or SSE. For framework-specific integration patterns (LangChain, CrewAI, AutoGen, LlamaIndex) see INTEGRATIONS.md and the examples/ directory.
For production use, keep one persistent server process across all calls.
import subprocess, json
class StenoClient:
def __init__(self, server_path):
self.proc = subprocess.Popen(
["python", server_path],
stdin=subprocess.PIPE, stdout=subprocess.PIPE,
text=True
)
def call(self, tool_name, args):
msg = {
"jsonrpc": "2.0", "id": 1,
"method": "tools/call",
"params": {"name": tool_name, "arguments": args}
}
self.proc.stdin.write(json.dumps(msg) + "\n")
self.proc.stdin.flush()
return json.loads(self.proc.stdout.readline())
client = StenoClient("/path/to/omega_stenographer_mcp_standalone.py")
# Ingest a turn
client.call("stenographer_ingest_exchange", {
"role": "user",
"content": "Fix the authentication bug",
"session_id": "session-001"
})
# Get running notes
notes = client.call("stenographer_get_brief", {})
# Search history
results = client.call("stenographer_query_history", {"query": "authentication"})
client.close()Goal | Tool | Notes |
Capture a turn |
| Call after every user/assistant message |
View live notes |
| Returns milestones + compressed briefs + recent exchanges |
Context window rescue |
| Returns compressed briefing + top-K relevant briefs |
Flag critical decision |
| Elevates to tier-A |
Keyword search history |
| FTS5 search across all exchanges |
All examples use JSON-RPC 2.0. In practice, your MCP client sends these automatically when you invoke a tool. The shell one-liner form is useful for testing.
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"stenographer_ingest_exchange","arguments":{"role":"assistant","content":"I found the bug in the auth module — the JWT validation was using the wrong secret key. Fix applied to auth.py line 42.","session_id":"debug-session"}}}' \
| python omega_stenographer_mcp_standalone.pyResponse (abbreviated):
{
"result": {
"content": [{
"type": "text",
"text": "Ingested [assistant] #1 (119 chars; decisions: 1; blockers: 0)"
}]
}
}{
"jsonrpc": "2.0", "id": 2,
"method": "tools/call",
"params": {
"name": "stenographer_get_brief",
"arguments": {}
}
}Response:
# Running Session Notes
## 📝 Recent Exchanges
### [1] ASSISTANT (💡 1 decisions)
I found the bug in the auth module — the JWT validation was using the wrong secret key...
### [2] USER
Deploy to staging and monitor for 24 hours.{
"jsonrpc": "2.0", "id": 3,
"method": "tools/call",
"params": {
"name": "stenographer_query_history",
"arguments": {
"query": "JWT OR auth",
"limit": 5
}
}
}{
"jsonrpc": "2.0", "id": 4,
"method": "tools/call",
"params": {
"name": "stenographer_compact_guard",
"arguments": {
"query": "authentication deployment"
}
}
}Response:
# Compaction Guard Briefing
Query: authentication deployment
## 🔴 Live (Uncompressed)
- [assistant] I found the bug in the auth module... [Decisions: JWT validation fix applied]
## 📦 Compressed Briefs (Top-K)
- [A] Batch 1-5: Decisions: Switched to setuptools for build; Fixed JWT secret key rotation{
"jsonrpc": "2.0", "id": 5,
"method": "tools/call",
"params": {
"name": "stenographer_mark_milestone",
"arguments": {
"exchange_id": 1,
"label": "Auth bug root cause identified"
}
}
}Tool | Purpose |
| Capture a conversation turn with role, content, and session ID. Auto-extracts decisions and blockers. |
| Build and return the live running notes document: milestones, compressed briefs, recent exchanges. |
| Get compressed briefing + top-K relevant briefs. Call when context window pressure hits or before compaction. |
| Flag a critical exchange for tier-A priority — survives compression and appears in running notes. |
| FTS5 keyword search over all ingested exchanges by content, decisions, and blockers. |
URI | Description |
| Live running notes document — formatted markdown |
| Auto-compressed briefing + relevant RAG fragments |
Stenographer's compression is designed to solve a specific problem: context window eviction. When an agent session runs long, early turns scroll out of the context window. Those early turns may contain critical decisions, blocker discoveries, or architectural choices that the agent needs later.
Turn counting: Every ingested turn increments the unprocessed counter. Stenographer tracks this via SELECT COUNT(*) FROM exchanges WHERE compressed=0.
Threshold trigger: When unprocessed turns ≥ STENO_TURN_LIMIT (default: 8), compress_unprocessed() fires automatically.
Fragment generation: All unprocessed turns are combined. If decisions were extracted, the brief summarizes them. If no decisions, raw context (first 300 chars) is preserved.
Tier assignment:
Tier A — brief contains extracted decisions (highest signal)
Tier B — brief contains raw context excerpts (medium signal)
Source tracking: Every brief records its source_turns as a JSON array of exchange IDs. No record is lost — the brief is always traceable back to the original turns.
Compaction marking: Source turns are marked compressed=1 so they won't appear in running notes (they're summarized in the brief), but they remain in the database for FTS5 search.
Scenario | STENO_TURN_LIMIT | Rationale |
Short sessions (10-20 turns) | 12 | Less aggressive compression; more detail in running notes |
Long sessions (50+ turns) | 6 | Aggressive compression; prevent context window overflow |
Default | 8 | Balanced — compresses before most context windows evict |
omega-stenographer-mcp/
├── omega_stenographer_mcp_standalone.py # MCP server — Ingestion + Compression + Retrieval (~374 lines)
├── requirements.txt # mcp>=1.0.0
├── pyproject.toml # Package config
├── Dockerfile # Non-root, unbuffered, stdio + SSE
├── INTEGRATIONS.md # LangChain, CrewAI, AutoGen, LlamaIndex guides
├── SECURITY.md # Vulnerability reporting policy
├── CHANGELOG.md # Release history
├── docs/
│ └── integration.md # Detailed integration reference
├── examples/
│ ├── langchain_quickstart.py
│ ├── crewai_quickstart.py
│ ├── autogen_quickstart.py
│ └── llamaindex_quickstart.py
└── tests/
├── test_ingest.py # Turn ingestion + decision/blocker extraction tests
├── test_compression.py # Compression threshold + tier assignment tests
├── test_search.py # FTS5 search + TF-IDF similarity tests
└── test_brief.py # Running notes + milestone testsModuleNotFoundError: mcppip install mcpUnicodeDecodeError on WindowsSet the environment variable before running:
set PYTHONUTF8=1
python omega_stenographer_mcp_standalone.pyOr add "env": { "PYTHONUTF8": "1" } to your MCP client config.
Confirm the path in your client config is absolute (e.g., C:\Users\you\omega-stenographer-mcp\omega_stenographer_mcp_standalone.py), not relative.
Run the server manually in a terminal to see startup errors: python /path/to/omega_stenographer_mcp_standalone.py
Check Python version: python --version must be 3.11+.
Check unprocessed count: the database should show SELECT COUNT(*) FROM exchanges WHERE compressed=0 ≥ STENO_TURN_LIMIT.
Verify STENO_TURN_LIMIT is set (default: 8).
Check stderr for traceback — the compress_unprocessed function logs errors to the server's stderr.
Verify the briefs table exists: sqlite3 ~/.omega-stenographer/steno.db ".tables"
Check that source turns had decisions extracted (non-empty decisions field).
Tier-B briefs preserve raw context; if content is short, the brief will be short.
Delete the data directory and restart to rebuild from scratch (all persisted memory will be lost):
rm -rf ~/.omega-stenographer/
python omega_stenographer_mcp_standalone.pyTo use a separate data directory per project:
OMEGA_STENOGRAPHER_DIR=/path/to/project-steno python omega_stenographer_mcp_standalone.pyConnection refused on port 8056Ensure the server is running with --sse --port 8056 and that the port is not blocked by a firewall. Check with:
curl -N http://localhost:8056/sseAll data is local. The SQLite database is stored in ~/.omega-stenographer/ (or OMEGA_STENOGRAPHER_DIR). No data is transmitted to any external service.
No API keys required. The server requires only a local Python installation and the mcp package.
Passive observation only. Stenographer does not approve, block, or steer agent actions. It cannot modify agent behavior.
Non-root Docker. The provided Dockerfile runs as a non-root steno user.
Sensitive data handling. Do not ingest secrets, credentials, or PII into Stenographer. The database is unencrypted SQLite on disk; protect it with OS-level file permissions.
Venv isolation. The standalone script includes a venv auto-activation shim — if dependencies are in a .venv directory, the script re-execs itself with the venv Python, ensuring no system Python pollution.
For vulnerability reporting, see SECURITY.md.
Threat | Mitigation |
Loss of critical agent decisions to context window eviction | Automatic compression at |
Inability to search past conversation | FTS5 full-text index on all exchanges; persistent across restarts |
Compressed briefs losing provenance | Every brief records source turn IDs; traceable back to original records |
Compression producing synthesized narrative | Briefs preserve verbatim context excerpts; no LLM-generated summary |
Server crash on malformed input | Input validation on role enum + required fields; |
The following threats are not addressed by Omega Stenographer MCP:
Compromised host or operating system — if the process environment is controlled by an adversary, no application-layer protection is sufficient
Unauthorized database access — the database is unencrypted SQLite; OS-level access controls are the operator's responsibility
Malicious administrator — an operator with filesystem access can modify or delete the data directory directly
Supply-chain compromise of mcp or Python itself — dependency integrity verification is the operator's responsibility
Network-level attacks — SSE mode exposes an HTTP endpoint; TLS termination and network access control are the operator's responsibility
Decision extraction accuracy — regex-based extraction is heuristic; false negatives and false positives are expected
[ MCP Client / AI Agent ]
│
│ Trust: MCP client provides truthful turn content.
│ Stenographer does not verify accuracy.
▼
[ Omega Stenographer MCP Server ] ← Observation boundary
│
│ Trust: Local filesystem is operator-controlled.
│ No external services are contacted.
▼
[ ~/.omega-stenographer/steno.db ]Stenographer operates at the observation boundary — it records what it sees. It does not enforce policy, verify claims, or approve actions. If a turn contains false information, Stenographer will faithfully record, index, and compress that false information.
Milestone | Status | Description |
v1.0 — Core observation stack | Released | Turn ingestion, decision/blocker extraction, FTS5 search, compression, milestones |
v1.1 — Enhanced extraction | Planned | LLM-assisted decision extraction for higher recall; configurable extraction patterns |
v1.2 — Embedding upgrades | Planned | Optional |
v1.3 — Multi-session merge | Planned | Cross-session brief merging for long-running projects across multiple sessions |
v2.0 — Omega Brain bridge | Planned | Native Stenographer → Omega Brain ingestion bridge; briefs auto-ingested as RAG fragments |
Community contributions are welcome. See CONTRIBUTING.md for invariants that must not be broken.
Omega Stenographer MCP is the passive observation layer of the VERITAS & Sovereign Ecosystem. The following repositories form the broader Omega Universe:
Repository | Role |
This repo — Passive session observer: turn ingestion, decision extraction, context compression | |
Governance control plane: Cortex gate, VERITAS pipeline, S.E.A.L. ledger | |
Deterministic build attestation protocol | |
Retention substrate — deterministic storage under VERITAS constraints | |
Policy enforcement engine — sovereign access control layer | |
Sovereign desktop media application | |
Local LLM bridge — Ollama integration with Omega governance layer |
📖 Read the master narrative: Why Sovereign AI?
This project is part of the VERITAS Omega Universe — a sovereign AI infrastructure stack.
VERITAS-Omega-CODE — Deterministic verification spec (10-gate pipeline)
Gravity-Omega — Desktop AI operator platform
Omega-Brain-MCP — Governance-first MCP server
Ollama-Omega — Ollama MCP bridge for any IDE
OmegaWallet — Desktop Ethereum wallet (renderer-cannot-sign)
veritas-vault — Local-first AI knowledge engine
sovereign-arcade — 8-game arcade with VERITAS design system
SSWP — Deterministic build attestation protocol
MIT — see LICENSE for full text.
Get compressed briefing + top-k relevant fragments. Call when context window pressure hits.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only vaguely indicates behavior ('compressed briefing'), but does not disclose if read-only, how fragments are selected, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: first states purpose, second gives usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 1 parameter and no output schema, description fails to explain input semantics or return structure. Essential info missing for agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'query' is completely undocumented in description (0% schema coverage). Agent has no guidance on what to supply as query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get compressed briefing + top-k relevant fragments' with a specific verb and resource, distinguishing it from sibling tools like stenographer_get_brief by mentioning compression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Call when context window pressure hits.' However, lacks when-not-to-use or mention of alternatives like stenographer_get_brief.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the live running notes document.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Get', implying a read operation, but does not specify side effects, authentication needs, rate limits, or what 'live' means operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word contributes to the core purpose, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description omits details about the return format, document nature, and whether the 'live' aspect implies real-time updates. The lack of output schema makes this gap more significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema description coverage is 100%. Per guidelines, 0 parameters yields a baseline of 4, as no additional parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'live running notes document', directly conveying the tool's function and distinguishing it from sibling tools focused on compacting, ingesting, marking milestones, or querying history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context on prerequisites, typical use cases, or when to prefer other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ingest a conversation turn. Call after every significant user or assistant message.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | ||
| content | Yes | ||
| session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It only says 'Ingest', implying a write operation, but does not disclose consequences (e.g., whether it overwrites or appends), authentication needs, rate limits, or what happens on failure. More detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no wasted words. The first sentence states the core function, the second gives usage timing. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description is minimal. It lacks details about session_id (optional, possibly for grouping), content length limits, and return behavior. Given that the agent needs to decide when to call and how to set parameters, more completeness is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no explanations for parameters. The schema includes role, content, and session_id, but the description does not clarify their semantics, especially session_id (optional) or content limits. Property names are self-explanatory, but without explanation of session_id's role, the agent may misuse it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Ingest a conversation turn', specifying the verb 'Ingest' and resource 'conversation turn'. It also provides timing context ('after every significant user or assistant message'). This distinguishes it from sibling tools like compact, get brief, mark milestone, query history, which are clearly different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Call after every significant user or assistant message.' It does not explicitly state when not to call or mention alternatives, but the sibling tools serve distinct purposes, so no confusion. Some nuance about non-significant messages could improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flag a critical decision for tier-A priority.
| Name | Required | Description | Default |
|---|---|---|---|
| exchange_id | Yes | ||
| label | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a write operation ('flag') but does not disclose behavioral traits such as whether the action is reversible, requires authorization, or has side effects. The lack of detail leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, which is concise but lacks necessary detail. It front-loads the purpose, but the brevity sacrifices completeness. It could be expanded with parameter context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (2 required parameters, no output schema) and no annotations, the description should explain parameters and behavioral context. It fails to do so, making the tool under-defined for an agent. The description is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention any parameters. The agent receives no help understanding 'exchange_id' or 'label', which are required but undefined. This is a critical gap for proper tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Flag' and the resource 'critical decision', and mentions 'tier-A priority', which gives a specific context. However, the tool name 'mark_milestone' suggests marking a point in time, not necessarily a decision, creating a slight disconnect. It distinguishes from sibling tools by implying a specific priority-level action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, when-not-to-use, or related tools. Only a brief purpose is given, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FTS5 keyword search over all ingested exchanges.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It mentions it's a search but does not disclose whether it's read-only, side effects, rate limits, or return behavior. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no extraneous words. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and no output schema or annotations, the description is severely lacking. It omits return values, pagination, and error handling, making it incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description adds minimal meaning by implying 'query' is a keyword string for FTS5, but it does not explain the 'limit' parameter or any format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as performing an FTS5 keyword search over all ingested exchanges. It distinguishes from siblings like compact_guard or ingest_exchange, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply states the function without context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
stenographer_compact_guardstenographer_get_briefstenographer_ingest_exchangestenographer_mark_milestonestenographer_query_historyThis server cannot be installed
Each tool has a distinct purpose: compacting context, retrieving briefs, ingesting exchanges, marking milestones, and querying history. No overlapping functionality.
All tools follow a consistent 'stenographer_<verb>_<noun>' pattern with snake_case, making it predictable and easy to parse.
Five tools is well-scoped for a stenography server, covering core operations without unnecessary bloat or deficiency.
The set covers recording, retrieval, summarization, milestone marking, and search. Minor gaps like explicit update/delete are mitigated by the append-only nature of the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
MCP-native Trust Infrastructure for AI Agents. Persistent encrypted memory with Trust Quotient.
InfoLang semantic memory MCP — investigate, memorize, and recall compressed agent context.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/VrtxOmega/omega-stenographer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
