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.
Report automatic capture progress and delivery errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Report' implies a read-only status operation, but the description does not explicitly say whether it has side effects, how fresh the status is, or how delivery errors are represented. It adds basic behavioral context but leaves safety and data-source details implicit.
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 terse sentence with no filler. It front-loads the action ('Report') and immediately specifies what is reported, which is ideal for agent scanning.
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 simple no-parameter tool, the description is minimally adequate: it names the output focus (progress and delivery errors). However, with no annotations and no output schema, it does not explain what the returned status looks like, what 'automatic capture' refers to, or when to prefer this over siblings, leaving notable gaps for an 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?
The tool has zero parameters and schema description coverage is 100% vacuously, so there are no parameter semantics for the description to explain. The baseline for a zero-parameter tool is 4, and the description does not need to compensate for missing parameter documentation.
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 states a specific action ('Report') and a clear resource ('automatic capture progress and delivery errors'), so an agent can tell this is a status/health tool. It is distinguishable from siblings like stenographer_query_history and stenographer_ingest_exchange by its focus on current capture status, though it does not explicitly name or contrast those alternatives.
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 given about when to use this tool versus the sibling tools. The description does not state whether this should be called for current status only, whether it should precede other operations, or when an alternative like query_history would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get compressed briefing + task-scoped relevant fragments. Call when context window pressure hits.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only implies a read-only operation through 'Get'. It does not disclose whether context is modified, compressed, or discarded, nor 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?
The description is extremely concise, with two short sentences that deliver the core purpose and usage trigger without unnecessary verbosity.
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?
The description gives a basic idea of the output ('compressed briefing + task-scoped relevant fragments') but lacks parameter details, return format, side effects, and relationship to sibling tools, leaving important context missing.
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 query parameter is not described at all, and session_id is only implied by the schema. With 0% schema description coverage, the agent cannot infer parameter meaning from the description alone.
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 resource ('compressed briefing + task-scoped relevant fragments'), and the trigger condition differentiates it from ordinary retrieval. However, 'task-scoped relevant fragments' is somewhat vague.
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?
It provides an explicit trigger ('Call when context window pressure hits'), which is useful, but does not mention alternatives like get_brief or when not to use this tool.
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 |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects. The verb 'Get' implies a read-only operation, but the description does not explicitly state that there are no side effects, nor does it mention any potential consequences or required permissions. This partial transparency 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, concise sentence with no redundant words or extraneous information. It efficiently conveys the core purpose without verbose elaboration.
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?
The description is minimal and lacks essential context. It does not explain what 'live running notes' means, what the output format or content will be, or any special considerations (e.g., whether the session must be active). Since there is no output schema, the description should have provided more detail about the return value, but it does not.
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 only parameter, session_id, is defined in the schema with type and minLength, providing basic expectations. The description adds no additional meaning or context about how the parameter is used (e.g., whether it refers to a session ID, a document ID, or something else), so it does not enhance the schema.
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 object ('live running notes document'), indicating the tool retrieves a brief for a session. However, 'live running notes' is somewhat ambiguous and does not explicitly distinguish from sibling tools like query_history, though the name and parameter imply session-specific retrieval.
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 provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or comparisons to sibling tools such as stenographer_query_history or stenographer_capture_status, leaving the agent to infer the appropriate use case.
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. Automatically: extracts decisions/blockers via regex, runs NAFE failure-signature scan (heuristic flags do not establish truth), checks for cross-system CLAEG TERMINAL_SHUTDOWN events, and compresses every STENO_TURN_LIMIT turns into session-scoped tiered briefs. Pass trace_id from omega_preload_context to enable cross-system correlation across Omega Brain, SSWP, and Stenographer.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | ||
| content | Yes | ||
| trace_id | No | VERITAS trace ID (VT-YYYYMMDD-xxxxxxxx) from omega_preload_context for cross-system correlation. | |
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses significant automatic behavior: regex extraction, NAFE scan, CLAEG TERMINAL_SHUTDOWN checks, and periodic compression into briefs. It also cautions that heuristic flags do not establish truth. Side effects are partially described but not exhaustively.
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 dense but not wordy; it packs a lot of behavior into a single sentence. Jargon like NAFE, CLAEG, and STENO_TURN_LIMIT is unexplained, but the structure is efficient and free of filler.
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?
It explains when to call and what automatic processes occur, but it does not describe what the tool returns or the outcome of the compression, and key constants are undefined. With no output schema, this leaves some gaps for an 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 low (only trace_id has a description). The description adds useful context for trace_id ('from omega_preload_context to enable cross-system correlation'), but role, content, and session_id rely on their obvious names and types. It partially compensates but does not fully cover the gap.
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 tool ingests a conversation turn and provides the trigger ('after every significant user or assistant message'). It is distinguishable from sibling tools like query_history and get_brief by the ingest action, though it does not explicitly name alternatives.
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?
It gives a clear call condition ('after every significant user or assistant message') but does not explicitly state when not to use it or compare it with sibling tools. The usage context is implied rather than fully specified.
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 priority priority.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | ||
| session_id | Yes | ||
| exchange_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a mutation or state change ('Flag'), but gives no detail about persistence, side effects, return values, or required context such as a valid session.
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 short but not well-formed; the repeated 'priority priority' and unclear wording make it under-specified rather than effectively concise. It is not front-loaded with useful, accurate information.
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?
With three required parameters, no annotations, and no output schema, the description is far too thin. An agent cannot determine correct usage, parameter semantics, side effects, or what constitutes a successful call.
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% and the description does not mention exchange_id, label, or session_id. It fails to explain what these parameters mean, how they relate to the milestone, or what values are valid.
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 uses a specific verb ('Flag') and a resource ('a critical decision'), which gives a rough idea of the operation. However, the phrase 'for priority priority' is garbled and the description never clearly says it marks a milestone, so the purpose remains vague and does not differentiate it from sibling tools.
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 provides no guidance on when to use this tool versus alternatives like stenographer_query_history or stenographer_ingest_exchange. There are no usage conditions, prerequisites, or exclusions.
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 |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| session_id | No | ||
| cross_session | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool performs an FTS5 keyword search over all ingested exchanges, which is useful, but it does not state whether the operation is read-only, how results are ordered or paginated, or how session_id and cross_session affect the search scope.
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 single-sentence description is concise and front-loaded with the main verb and resource. It is not bloated, but it is so terse that it omits important operational details; the structure itself provides no additional guidance.
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 four parameters, no annotations, and no output schema, the description is not complete enough for an agent to call the tool confidently. It lacks expected return format, pagination or limit behavior, session scoping semantics, and any indication of whether results are per-session or cross-session by default.
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 no descriptions for any of the four parameters, and the description does not compensate. It only implies that 'query' is a keyword search string; limit, session_id, and cross_session are left unexplained, so an agent cannot infer their intended values beyond the bare types and defaults in the schema.
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 uses a specific verb ('search') and identifies the resource ('all ingested exchanges'), and it names the mechanism ('FTS5 keyword'). This clearly differentiates it from sibling tools like stenographer_capture_status or stenographer_ingest_exchange, which have obviously 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?
The use case is implied: an agent can infer this tool is for keyword searching ingested exchange data. However, the description provides no explicit when-to-use or when-not-to-use guidance, no mention of alternatives, and no clarification on when session scoping should be applied versus cross-session search.
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.
v2.0.0stenographer_capture_statusstenographer_compact_guard2 fields changedInput schema / properties / session_idAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "session_id"
+]stenographer_get_brief2 fields changedInput schema / properties / session_idAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "session_id"
+]stenographer_ingest_exchange3 fields changedInput schema / properties / session_id / minLengthAdded value: +1Input schema / properties / trace_idAdded value: +{
+ "description": "VERITAS trace ID (VT-YYYYMMDD-xxxxxxxx) from omega_preload_context for cross-system correlation.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "role",
- "content"
-]New value: +[
+ "role",
+ "content",
+ "session_id"
+]stenographer_mark_milestone2 fields changedInput schema / properties / session_idAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "exchange_id",
- "label"
-]New value: +[
+ "exchange_id",
+ "label",
+ "session_id"
+]stenographer_query_history2 fields changedInput schema / properties / cross_sessionAdded value: +{
+ "default": false,
+ "type": "boolean"
+}Input schema / properties / session_idAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}stenographer_compact_guardstenographer_get_briefstenographer_ingest_exchangestenographer_mark_milestonestenographer_query_historyScored across 6 tools
Each tool has a distinct, non-overlapping purpose: querying history, checking status, ingesting exchanges, retrieving briefs, managing compaction, and marking milestones. No ambiguity in tool selection.
All tools share the consistent 'stenographer_' prefix and follow a clear verb_noun pattern (e.g., query_history, capture_status, ingest_exchange), making naming predictable and uniform.
With 6 tools, the set is well-scoped for a stenographer/note-taking domain, covering essential operations without being overly numerous or sparse.
The tool set covers the full lifecycle: ingestion, querying, status monitoring, brief retrieval, compaction, and milestone marking. No obvious missing operations for the stated purpose.
Persistent, verbatim, searchable memory for AI assistants — one memory across every MCP client.
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.
