Skip to main content
Glama
alopez3006

snipara-mcp

by alopez3006
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

snipara-mcp

PyPI version Python 3.10+ License: MIT CI

snipara-mcp is the lightweight stdio MCP connector for the Snipara Project Brain.

Snipara is the Project Brain for AI coding agents.

Use it when an MCP client needs a local stdio process that talks to Snipara's hosted Project Intelligence APIs. Snipara gives Claude Code, Cursor, Codex, and other MCP clients the decisions, active work, code impact, proof, and handoffs they need before they edit. If your client supports streamable HTTP MCP directly, prefer the hosted endpoint and skip the local process.

What Is Snipara?

Snipara is the shared Project Intelligence layer for AI-assisted software work.

It gives Claude Code, Cursor, Codex, OpenAI Agents, and other MCP-compatible clients project context that survives sessions, users, tools, and model switches.

Your agent still uses its own LLM. Snipara gives it the right project context: source-backed docs, reviewed memory, shared guidance, workflow continuity, and code graph structure. In category terms, it is an AI coding agent context, memory, and continuity platform.

Related MCP server: Locus

Why MCP?

MCP is becoming a standard adapter layer for agent tools. snipara-mcp makes Snipara available through that layer without forcing developers into a specific IDE, model, or orchestration framework.

The integration should feel small:

uvx snipara-mcp

The impact is larger: agents can retrieve durable project context instead of starting cold every session.

What It Unlocks

Need

Snipara MCP tool group

Ask project docs a source-backed question

snipara_context_query, snipara_get_chunk

Recall durable decisions and learnings

snipara_recall

Review the team Inbox

snipara_inbox_review_queue, snipara_inbox_review_plan, snipara_inbox_review_apply

Persist reusable memory after a task

snipara_remember_if_novel, snipara_end_of_task_commit

Reuse team standards and shared guidance

snipara_shared_context

Inspect structural code relationships

snipara_code_callers, snipara_code_imports, snipara_code_neighbors

Plan risky code changes

snipara_code_symbol_card, snipara_code_impact within plan capacity

Public MCP clients must use the snipara_* names. The rlm_* compatibility aliases were removed from the distributed contract on 2026-08-16 and remain only as internal handler identifiers. This contract cleanup is staged for the next package release; clients using legacy names must migrate before upgrading.

The stdio server advertises the same compact default agent contract as the hosted MCP endpoint. Set SNIPARA_TOOL_PROFILE=full only for clients that need direct discovery of every specialist compatibility tool; hidden tools remain callable by explicit name and discoverable through snipara_help.

The default discovery surface contains 13 coherent tools: snipara_context_query, snipara_ask, snipara_search, snipara_read, snipara_stats, snipara_help, snipara_get_chunk, snipara_recall, snipara_remember_if_novel, snipara_end_of_task_commit, snipara_inbox_review_queue, snipara_inbox_review_plan, and snipara_inbox_review_apply.

Minimum-safe-change review (2.8.30)

The packaged snipara_context_query and snipara_code_impact contracts now accept minimum_change_mode="review". When enabled, answer packs and impact responses carry a non-blocking, evidence-first receipt covering existing capabilities, stdlib/native options, installed dependencies, the smallest safe diff, and validation-surface preservation. The policy is advisory and remains opt-in until project evidence calibrates stronger enforcement.

Callers may provide bounded minimum_change_evidence with named provenance such as runtime, manifest, lockfile, git_diff, or test_runner. Unverified confirmed claims remain visible as asserted; confirmed is reserved for a versioned, fingerprint-matching adapter receipt. The verified adapters are lockfile_manifest for direct installed dependencies and git_diff for a coherent local smallest-safe-diff check. Responses also include non-blocking preservation guards for validation, errors, auth/security, accessibility, public contracts, and tests.

Semantic rule contract (2.8.27)

The generated snipara_code_symbol_card and snipara_code_impact schemas now forward bounded semantic_rules project overrides to the hosted service. Terms are literal strings rather than executable regular expressions.

MCP transport security floor (2.8.26)

The connector now requires MCP Python SDK 1.28.1 or newer. This incorporates the upstream fixes for authenticated-principal session isolation, experimental task ownership, and WebSocket Host/Origin validation.

Configurable code-impact traversal (2.8.25)

The packaged snipara_code_impact contract now exposes depth (1-6), direction (in, out, or both), and optional edge_kinds. This keeps the connector contract aligned with hosted impact chains and Companion's hybrid local/hosted traversal controls.

Credential-free discovery and compact contract (2.8.24)

MCP clients and directory inspectors can now complete initialize and tools/list before credentials are configured. Every actual tool call still fails closed until authentication and project selection are present. The default tools/list response exposes the same 13-tool core as hosted Snipara, while SNIPARA_TOOL_PROFILE=full retains direct discovery of all specialist compatibility tools. Core tools now include complete selection guidance, behavior annotations, and nested parameter documentation for safer agent use.

Agent-readable tool contracts (2.8.23)

The connector now preserves detailed tool descriptions and MCP behavior annotations from the hosted source of truth. Summary, coordination, state, memory, and code graph tools explain their prerequisites, access rules, side effects, idempotence, alternatives, parameters, outputs, and common failure modes so agents can choose them safely. Native output schemas remain deferred until the transport and structured result format upgrade together.

Unified conversational Inbox review (2.8.22)

Human team admins can list the same memory candidates and ProjectDecision drafts shown by the multi-project Dashboard Inbox, create evidence-backed approve/reject/needs-human recommendations, and atomically apply an explicitly authorized snapshot. The service revalidates the human team-admin identity, project ownership, current candidate states, and immutable item snapshots before recording authority audits. Real credentials remain addressable for rejection but are redacted from MCP output. The earlier ProjectDecision-only tools remain available as specialist compatibility tools.

Conversational decision review (2.8.21)

Agents can list pending ProjectDecision drafts, propose evidence-backed approve/reject/needs-human recommendations, and apply an explicitly authorized snapshot-bound plan. Apply requires a human project admin and fails closed if a draft changed after planning; there is no live wildcard approval.

Structured Why Capture task commits (2.8.20)

snipara_end_of_task_commit now accepts an atomic why block with decision, rationale, alternatives, constraints, and observed_outcome. Structured candidates stay pending until human review, and unknown parameters fail closed instead of being silently ignored.

Retrieval outcome controls (2.8.19)

The stdio connector forwards the hosted server's bounded retrieval-outcome controls for context_query and recall: optional task correlation, shadow or enabled rerank requests, and the strict context attribution window. The hosted server remains authoritative, so a client request can lower or disable the configured mode but cannot escalate it.

Architecture

flowchart LR
    Agents["Claude Code, Cursor, Codex, ChatGPT, OpenAI agents"] --> Stdio["snipara-mcp stdio process"]
    Stdio --> Hosted["Hosted Snipara MCP API"]
    Hosted --> Context["Context engine"]
    Hosted --> Memory["Project memory"]
    Hosted --> Graph["Code graph"]
    Context --> AgentLLM["Agent's own LLM"]
    Memory --> AgentLLM
    Graph --> AgentLLM

Hosted HTTP Or Stdio?

Use the hosted HTTP endpoint when your MCP client supports streamable HTTP:

{
  "mcpServers": {
    "snipara": {
      "type": "http",
      "url": "https://api.snipara.com/mcp/your-project-id-or-slug",
      "headers": {
        "Authorization": "Bearer snp-your-key"
      }
    }
  }
}

Use snipara-mcp when your client expects a local stdio command:

{
  "mcpServers": {
    "snipara": {
      "command": "uvx",
      "args": ["snipara-mcp"],
      "env": {
        "SNIPARA_API_KEY": "snp-your-key",
        "SNIPARA_PROJECT_ID": "your-project-id-or-slug"
      }
    }
  }
}

Decision rule:

  • HTTP MCP first for modern clients

  • snipara-mcp for stdio-only clients or local compatibility

  • create-snipara when you want guided setup across clients and templates

Install

No local install:

uvx snipara-mcp

Python package:

pip install snipara-mcp

With RLM Runtime helper integration:

pip install "snipara-mcp[rlm]"

Quickstart

Sign in through the browser:

pip install snipara-mcp
snipara login

Initialize a project:

snipara init

The initializer detects common project files, writes MCP configuration, and can upload local project docs when you are authenticated.

Useful options:

snipara init --slug my-project
snipara init --dry-run
snipara init --no-upload
snipara init --skip-test

Claude Code

claude mcp add snipara uvx snipara-mcp

Then export credentials in your shell:

export SNIPARA_API_KEY="snp-your-key"
export SNIPARA_PROJECT_ID="your-project-id-or-slug"

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "snipara": {
      "command": "uvx",
      "args": ["snipara-mcp"],
      "env": {
        "SNIPARA_API_KEY": "snp-your-key",
        "SNIPARA_PROJECT_ID": "your-project-id-or-slug"
      }
    }
  }
}

Environment

Variable

Required

Description

SNIPARA_API_KEY

Yes, unless using snipara login

Snipara API key

SNIPARA_PROJECT_ID

Yes, unless using SNIPARA_PROJECT_SLUG

Project identifier

SNIPARA_PROJECT_SLUG

Yes, unless using SNIPARA_PROJECT_ID

Project slug

SNIPARA_API_URL

No

Defaults to https://api.snipara.com

SNIPARA_TOOL_PROFILE

No

core by default; full exposes specialist tool schemas

OAuth tokens created by snipara login are stored in ~/.snipara/tokens.json. If a project id or slug is set, the connector selects the matching token and does not silently fall back to another project.

What You Get

The connector exposes the same compact default MCP contract as the hosted backend. The packaged full compatibility surface is generated from the server source of truth and is available with SNIPARA_TOOL_PROFILE=full.

Common tool groups:

  • retrieval: snipara_context_query, snipara_search, snipara_get_chunk, snipara_load_document

  • durable memory: snipara_recall, snipara_remember, snipara_memory_compact

  • owner-aware bootstrap: snipara_session_memories, snipara_owner_profile_get, snipara_owner_profile_update

  • shared context: snipara_shared_context, collection and template tools

  • document upload: snipara_upload_document, snipara_sync_documents

  • project setup: client, project, and business-context workspace tools

  • operations: snipara_settings, snipara_index_health, snipara_reindex

  • code graph: snipara_code_* tools when code indexes are available

  • coordination: swarm, hierarchical task, and state tools when enabled

Tool availability can vary by plan, hosted deployment, and project index state.

CLI Commands

Command

Description

snipara login

Browser login and token setup

snipara init

Initialize Snipara in the current project

snipara logout

Clear stored tokens

snipara status

Show auth and project status

snipara-mcp

Run the MCP stdio server

Legacy aliases such as snipara-init, snipara-mcp-login, snipara-mcp-logout, and snipara-mcp-status are still supported.

Relationship To Other Repos

Repo

Role

alopez3006/snipara-mcp

Current generated public connector mirror

Snipara/snipara-companion

Local workflow, impact, verification, and handoff CLI

Snipara/snipara-memory

Open memory primitives and schema

snipara-mcp is intentionally thin. It should be easy to install, easy to audit, and boring to operate. The heavy lifting stays in Snipara's hosted context and memory engine.

Development

pip install -e ".[dev]"
pytest
ruff check .

The source of truth for the generated tool contract lives in the Snipara server. When backend tools change, regenerate the packaged contract before publishing this package.

License

MIT. See LICENSE.

Available Tools

12 tools
snipara_askA
Read-onlyIdempotent

Answer one simple question from indexed project documentation with server-side synthesis. This is a read-only VIEWER operation and changes no project state. Use snipara_context_query when citations, answer packs, retrieval controls, or source sections matter; use snipara_search for an exact regex. Returns a concise answer or a bounded no-match/error result.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe question to ask
correlation_contextNoOptional retrieval-correlation context. Reuse session_id across retrieval and outcome calls so telemetry can be joined inside the authenticated project. These identifiers never change authorization or project scope; do not include secrets, tenant IDs, or user data.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by stating it is a VIEWER operation with server-side synthesis and returns a bounded result, though it doesn't detail other behaviors like latency or auth requirements.

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?

Extremely concise: two sentences plus a comparison sentence, front-loaded with purpose and usage, with no superfluous content.

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 simplicity, annotations, and lack of output schema, the description adequately covers purpose, usage, and return type. It could mention limitations on question complexity, but overall it's quite complete.

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

Parameters3/5

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

Schema coverage is 100%, so parameters are already described. The description adds overall context ('simple question') but no per-parameter details beyond the schema, meeting 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 tool answers a simple question from indexed project documentation with server-side synthesis, and distinguishes itself from siblings snipara_context_query and snipara_search, making the purpose very clear.

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?

Explicitly provides when to use this tool (simple question) and when to use alternatives (snipara_context_query for citations/controls, snipara_search for exact regex), offering excellent guidance.

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

snipara_context_queryA
Read-onlyIdempotent

Query project documents, parsed business files, and shared context. Use this first for source truth and narrative documentation. Returns a source-grounded answer_pack plus retrieval_diagnostics and ranked sections within token budget. If a broad query times out, retry once with a narrow 3-8 term query, max_tokens 800-1500, search_mode='keyword', return_references=true, auto_decompose=false, and include_all_tiers=false. For exact text use snipara_search; for structural code context use snipara_code_neighbors, snipara_code_callers, or snipara_code_imports.

ParametersJSON Schema
NameRequiredDescriptionDefault
taskNoOptional task label that scopes the live-join fallback and retrieval correlation; persisted outcome posterior statistics remain project-wide
queryYesDocumentation, business-context, or current-truth question. For timeout recovery, narrow this to the key file, feature, symbol, or 3-8 terms.
max_tokensNoToken budget. Use 800-1500 for fast recovery retries after a timeout.
search_modeNoSearch strategy. Use keyword for fast retry/recovery paths; use hybrid for normal documentation discovery.hybrid
auto_decomposeNoAuto-decompose complex queries into sub-queries (Pro+ only). Complex queries (50+ words, multiple questions, comparisons) are automatically broken down and results merged. Set to False for fast timeout recovery retries.
include_metadataNoInclude document, section, tier, and retrieval metadata with returned context.
prefer_summariesNoPrefer stored summaries when available without excluding authoritative source matches.
include_all_tiersNoInclude all context tiers including COLD and ARCHIVE. By default, searches only HOT and WARM tiers for faster, more relevant results.
return_referencesNoReturn chunk references (IDs + previews) instead of full content. Use snipara_get_chunk to retrieve full content by ID. Reduces hallucination by maintaining clear source attribution and is the preferred fast retry path after a timeout.
correlation_contextNoOptional retrieval-correlation context. Reuse session_id across retrieval and outcome calls so telemetry can be joined inside the authenticated project. These identifiers never change authorization or project scope; do not include secrets, tenant IDs, or user data.
include_answer_packNoInclude a structured answer pack with source facts, caveats, verification checklist, and code/context hints before the ranked context sections.
context_chunk_outcome_rerank_modeNoRequested bounded chunk-outcome rerank mode. This request can disable or lower the server-configured mode but cannot escalate beyond it.disabled
context_chunk_outcome_window_hoursNoStrict attribution window for compatible chunk outcomes.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral details like timeout recovery, token budget behavior, and fallback to job queue. This goes beyond what annotations provide, though some redundancy exists.

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 front-loaded with primary purpose, then flows to usage, recovery, and alternatives. It is appropriately sized for a complex tool with 13 parameters, though some repetition in parameter details could be streamlined.

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 explains return types (answer_pack, diagnostics, ranked sections) and covers timeout behavior, retry logic, token budget, and sibling tools. It addresses the complexity of nested parameters and provides sufficient context for an agent to use the tool effectively.

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. The description adds extra meaning by contextualizing several parameters (query, max_tokens, search_mode, return_references, auto_decompose, include_all_tiers) within the timeout recovery scenario, enhancing their practical use beyond schema descriptions.

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 queries project documents, business files, and shared context for source truth and narrative documentation. It specifies the return type (answer_pack, diagnostics, ranked sections) and distinguishes from siblings by directing exact text searches to snipara_search and code queries to code-specific tools.

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?

Explicit guidelines are provided: 'Use this first for source truth and narrative documentation.' A recovery strategy for timeouts is given in detail (narrow query, max_tokens 800-1500, etc.), and alternatives are named for exact text (snipara_search) and code context (snipara_code_* tools).

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

snipara_end_of_task_commitA

Persist a bounded end-of-task summary, optional structured Why Capture, and selected durable outcomes so another agent can resume the work. This EDITOR operation writes memory and workflow state and is non-idempotent; dry_run validates without writing. Use snipara_remember_if_novel for one reusable memory and document upload tools for source material. Unknown fields fail closed. Returns created or skipped records, review candidates, handoff metadata, and validation warnings.

ParametersJSON Schema
NameRequiredDescriptionDefault
whyNoAtomic Why Capture payload; never split by summary heuristics
taskNoShort task label used as structured Why Capture provenance
dry_runNoValidate extraction and return the proposed receipt without writing memory or workflow state.
outcomeNoFinal task state used to frame the handoff and durable extraction.completed
summaryNoUnstructured task summary used only when why is absent
categoryNoOptional stable category shared by memories produced from this commit.
artifactsNoDurable artifact identifiers or paths produced by the task.
handoff_onlyNoFor final workflow commits, create the Team Sync handoff and skip durable-memory extraction.
files_touchedNoProject-relative files materially changed or inspected during the task.
persist_typesNoMemory categories that may be extracted from the task summary; omit unwanted categories.
external_user_idNoIntegrator client keys only: stable end-user ID for user-owned memories created from task commits.
memory_reconciliation_modeNoFor newly created task memories, find older similar memories. recommend returns candidates only; auto_safe supersedes only high-confidence same-scope/type/category matches.recommend

TDQS

A4.4/5.0
Behavior5/5

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

The description clearly states it is an EDITOR operation that writes memory and workflow state, is non-idempotent, and that unknown fields fail closed. This adds significant behavioral context beyond annotations, which only provide hints about read-only, open-world, idempotent, and destructive nature.

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 concise at four sentences, front-loaded with the primary purpose, and every sentence adds value. No redundant or wasted 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 the complexity of the tool (12 params, nested objects, no output schema), the description provides essential context: it explains return values, validation behavior, and alternative tools. It could be slightly more detailed, but overall it is adequately complete for an experienced agent.

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?

The input schema has 100% description coverage for all 12 parameters, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema, but the schema itself is comprehensive. No deduction needed.

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 persists end-of-task summaries, structured Why Capture, and durable outcomes for agent handoffs. It distinguishes from siblings by naming snipara_remember_if_novel for single reusable memories and document upload tools for source material.

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 mentions when to use snipara_remember_if_novel and document upload tools as alternatives. It also notes dry_run validates without writing, giving guidance on validation usage. However, it does not explicitly state when not to use this tool versus the named alternatives.

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

snipara_get_chunkA
Read-onlyIdempotent

Fetch one complete indexed source chunk by the stable chunk ID returned from a reference-based context query. This is a read-only VIEWER operation and changes no project state. Use snipara_context_query first to discover relevant references; use snipara_read for an exact document line range instead. Returns the chunk text, source identity, position metadata, and a bounded not-found/error result.

ParametersJSON Schema
NameRequiredDescriptionDefault
chunk_idYesThe chunk ID from snipara_context_query results (when return_references=True)
correlation_contextNoOptional retrieval-correlation context. Reuse session_id across retrieval and outcome calls so telemetry can be joined inside the authenticated project. These identifiers never change authorization or project scope; do not include secrets, tenant IDs, or user data.

TDQS

A4.5/5.0
Behavior4/5

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

Description reinforces annotations with 'read-only VIEWER operation and changes no project state.' It also discloses return contents: chunk text, source identity, position metadata, and bounded error result. This adds value beyond annotations by detailing output structure.

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?

Two sentences with no wasted words. First sentence states the core action. Second sentence provides usage guidance and a brief summary of return values. Highly efficient.

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 fully covers what the tool does, when to use it, what it returns, and how it differs from siblings. For a simple fetch-by-ID tool, this is complete.

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

Parameters3/5

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

Schema coverage is 100% with detailed descriptions for both parameters. Description adds minor context for chunk_id (its source) but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.

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?

Description states 'Fetch one complete indexed source chunk by the stable chunk ID returned from a reference-based context query.' It specifies the verb (Fetch), resource (chunk), and source of the ID. It also distinguishes the tool from snipara_read by noting its use for exact document line ranges.

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?

Description explicitly states when to use this tool: after snipara_context_query to fetch a chunk by ID. It also provides an alternative: use snipara_read for exact line ranges. This clearly guides the agent on tool selection.

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

snipara_inbox_review_applyA
Destructive

Atomically apply the exact memory-candidate and decision-draft actions from a prior team Inbox review plan. This destructive ADMIN operation requires explicit user authorization plus a real human team-admin identity, records authority audits, and fails closed if any item or snapshot changed. It is not idempotent and must follow snipara_inbox_review_plan. Returns per-item outcomes and the atomic apply receipt.

ParametersJSON Schema
NameRequiredDescriptionDefault
reasonYesHuman authorization rationale recorded in the authority audit.
actionsYesExact approve/reject action snapshot from the plan; additions or mutations fail closed.
review_plan_idYesExact immutable plan ID returned by snipara_inbox_review_plan after evidence validation.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark destructiveHint=true and idempotentHint=false. The description adds significant behavioral context: atomicity, authorization requirement with human admin identity, audit recording, 'fails closed' behavior, and return of per-item outcomes and a receipt. No contradiction exists.

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 concise, front-loading the core purpose in the first sentence. Each subsequent sentence adds distinct value (authorization, atomicity, failure behavior, return values). No wasted words. Structure is clear and scannable.

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, the description compensates by mentioning return values (per-item outcomes and receipt) and failure behavior (fails closed). It covers prerequisites, atomicity, and audit trails. Lacks detail on error scenarios or partial failure, but overall adequate for a destructive admin tool with rich schema and annotations.

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

Parameters3/5

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

Schema coverage is 100% with descriptive parameter definitions. The description does not add parameter-level meaning beyond what the schema already provides (e.g., review_plan_id, reason, actions). It reinforces overall context but does not enhance parameter understanding. Baseline 3 is appropriate.

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 applies memory-candidate and decision-draft actions from a prior review plan. It explicitly distinguishes from sibling tools like snipara_inbox_review_plan and snipara_inbox_review_queue by mentioning it must follow the plan and is the apply step. The use of 'atomic' and 'destructive ADMIN operation' further sharpens purpose.

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 provides clear prerequisites: must follow snipara_inbox_review_plan, requires explicit user authorization and a real human team-admin identity. It also notes it is not idempotent and fails closed if items changed. However, it does not explicitly state when not to use this tool versus alternatives, though the sibling set offers no other apply tool.

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

snipara_inbox_review_planA
Read-onlyIdempotent

Validate evidence-backed recommendations for team Inbox memory candidates and ProjectDecision drafts without changing authority. This read-only ADMIN operation creates a snapshot-bound review_plan_id; approve/reject items enter the snapshot while needs_human items remain pending. Use snipara_inbox_review_queue first and never call apply without explicit human authorization. Returns the immutable plan, exclusions, and validation findings.

ParametersJSON Schema
NameRequiredDescriptionDefault
recommendationsYesOne evidence-backed recommendation per Inbox item; needs_human items stay outside the apply snapshot.

TDQS

A4.9/5.0
Behavior5/5

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

Confirms read-only nature and non-destructive behavior, aligning with annotations. Adds valuable details about snapshot creation, disposition handling (needs_human items remain pending), and return structure (immutable plan, exclusions, findings). No contradictions with annotations.

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?

Two sentences efficiently cover purpose, constraints, workflow, and output. Every clause earns its place with no fluff. Front-loaded with key action and constraints.

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?

While the description explains the overall workflow and mentions return of 'immutable plan, exclusions, and validation findings', it lacks a precise specification of the return format. However, given the simple input and no output schema, it is mostly complete. A minor gap in fully detailing the return structure.

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?

Input schema has 100% description coverage on all properties. The description adds context on how the recommendations parameter is used, particularly that needs_human items are excluded from the apply snapshot, enhancing understanding 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 validates evidence-backed recommendations and creates a snapshot-bound review plan. It distinguishes from siblings like snipara_inbox_review_queue and snipara_inbox_review_apply by specifying its role as a read-only planning step.

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?

Explicitly instructs to use snipara_inbox_review_queue first and never call apply without human authorization. This provides clear workflow context and when to use this tool vs alternatives.

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

snipara_inbox_review_queueA
Read-onlyIdempotent

List human-reviewable memory candidates and ProjectDecision drafts from the current user's team Dashboard Inbox. This is a read-only ADMIN operation and changes no authority or review state; credential-like material is redacted. Use snipara_inbox_review_plan to validate recommendations before any authorized mutation. Returns stable item IDs, project ownership, evidence, and current review status.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum team Inbox items to return.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds useful behavioral context: it is an ADMIN operation, credential-like material is redacted, and it returns stable IDs, ownership, evidence, and review status. 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.

Conciseness5/5

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

Three sentences, each essential: purpose, behavioral transparency, and usage guidance. No wasted words; 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?

For a tool with one simple parameter and no output schema, the description fully covers what the tool does, what it returns, its security posture, and how it relates to sibling tools. No gaps.

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?

The single 'limit' parameter is already described in the input schema with default, max, min. The description adds no further parameter details. With 100% schema coverage, baseline 3 is appropriate.

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 uses specific verbs ('List'), identifies the resource ('human-reviewable memory candidates and ProjectDecision drafts'), and specifies binding context ('current user's team Dashboard Inbox'). It clearly differentiates from the sibling review_plan tool.

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?

Explicitly states it is a read-only ADMIN operation that changes no state, and directs the agent to use snipara_inbox_review_plan for validating recommendations before any authorized mutation.

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

snipara_readA
Read-onlyIdempotent

Read an exact line range from indexed project documentation. This is a read-only VIEWER operation and changes no project state. Use it after snipara_search or snipara_context_query when exact wording matters; use snipara_get_chunk instead when you already have a cited chunk ID. Returns the resolved range and text, or a validation/not-found error.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_lineNoEnding line number. Defaults to start_line + 50.
file_pathNoIndexed document path. Also accepted by the handler as file, path, or document.
start_lineNoStarting line number. Relative to file_path when provided; otherwise global index line.

TDQS

A4.9/5.0
Behavior5/5

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

Description states it's a 'read-only VIEWER operation and changes no project state', which aligns with and adds context to annotations (readOnlyHint, idempotentHint, destructiveHint). Also specifies return behavior (resolved range and text, or errors).

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?

Three concise sentences with no waste. The first sentence states purpose, the second provides usage context, and the third describes output. Front-loaded and efficient.

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 moderate complexity (3 optional params, no output schema), the description covers purpose, usage context, parameter details, and return behavior (including errors). Annotations cover safety, and the description fills in behavioral details.

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 explaining defaults (end_line defaults to start_line + 50), the relative/global nature of start_line, and accepted aliases for file_path (file, path, document).

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 'Read an exact line range from indexed project documentation', specifying the verb and resource. It distinguishes itself from siblings by mentioning alternatives like snipara_get_chunk and context after snipara_search or snipara_context_query.

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?

Provides explicit guidance: use after snipara_search or snipara_context_query when exact wording matters, and use snipara_get_chunk when you already have a cited chunk ID. This clearly indicates when to and when not to use the tool.

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

snipara_recallA
Read-onlyIdempotent

Semantically recall durable Memory V2 decisions, learnings, preferences, and session carryover within the requested owner boundary. This is a read-only VIEWER operation and changes no memory authority. Use snipara_context_query for source documents and snipara_memories for lifecycle inventory. Returns ranked active memories, optional inactive warnings, authority metadata, and bounded retrieval diagnostics.

ParametersJSON Schema
NameRequiredDescriptionDefault
taskNoOptional task label recorded for retrieval/outcome correlation.
typeNoOptional durable memory type filter applied before semantic ranking.
limitNoMaximum memories to return
queryYesMemory question such as a past decision, preference, or validated learning
scopeNoOwner boundary to search; scope=agent requires agent_id and scope=user may use external_user_id.
agent_idNoRequired when scope=agent; limits recall to one agent namespace
categoryNoFilter by category
min_relevanceNoMinimum relevance score (0-1)
external_user_idNoIntegrator client keys only: stable end-user ID for scope=user recall. Snipara hashes and namespaces it per integrator client.
include_inactiveNoInclude inactive memories in the main result set
warning_thresholdNoMinimum relevance score for inactive-memory warnings
correlation_contextNoOptional retrieval-correlation context. Reuse session_id across retrieval and outcome calls so telemetry can be joined inside the authenticated project. These identifiers never change authorization or project scope; do not include secrets, tenant IDs, or user data.
outcome_rerank_modeNoOptional bounded memory-outcome rerank mode. Omission uses the server configuration; a request cannot escalate beyond it.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it is a 'read-only VIEWER operation' and 'changes no memory authority', and specifies return components (ranked memories, warnings, metadata, diagnostics). 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.

Conciseness5/5

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

The description is two concise sentences. The first sentence states the main purpose and scope. The second clarifies the read-only nature, directs to alternatives, and summarizes return structure. No wasted words.

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

Completeness3/5

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

Despite 13 parameters and a nested object, the description omits details on return value structure and usage of complex parameters like 'correlation_context'. Given no output schema, more clarity on output format would improve completeness, but the description covers core purpose and behavior adequately.

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 does not add significant parameter-level detail beyond the schema; it only mentions return components. However, the schema itself is comprehensive, so additional explanation is not critical.

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 verb 'recall' and the resource 'durable Memory V2 decisions, learnings, preferences, and session carryover', and specifies the 'requested owner boundary'. It distinguishes from siblings by explicitly naming 'snipara_context_query' for source documents and 'snipara_memories' for lifecycle inventory.

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 ('semantically recall durable Memory V2...') and provides alternatives ('Use snipara_context_query for source documents and snipara_memories for lifecycle inventory'), giving clear guidance on 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.

snipara_remember_if_novelA
Idempotent

Store one durable Memory V2 record only when it is sufficiently different from existing reviewed memory. This EDITOR operation may write project, team, user, or agent state; duplicate calls normally skip the write, while auto_safe reconciliation may supersede high-confidence same-owner matches without deleting them. Use snipara_end_of_task_commit for multi-outcome workflow capture and context tools for source documents. Returns whether storage occurred, duplicate evidence, the memory ID, and reconciliation actions.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe memory text to store
typeNoDurable knowledge type used for authority, retention, and later recall filtering.fact
scopeNoMemory owner boundary. scope=agent requires agent_id; scope=user is personal to the authenticated user or integrator external_user_id.project
sourceNoOptional source label for the memory write
agent_idNoRequired when scope=agent; identifies the agent-owned memory namespace
categoryNoOptional stable category used to group and deduplicate related memories.
ttl_daysNoOptional retention period in days; omit only for knowledge that should not expire automatically.
related_toNoExisting memory IDs that provide an explicit relationship, not duplicate candidates.
dedupe_limitNoMaximum nearest existing memories examined before deciding whether this write is novel.
document_refsNoProject-relative source document paths supporting this memory; never place secrets here.
allow_supersedeNoReserved for future conflict handling
external_user_idNoIntegrator client keys only: stable end-user ID for scope=user memory. Snipara hashes and namespaces it per integrator client.
novelty_thresholdNoSimilarity threshold above which a memory is treated as duplicate
memory_reconciliation_modeNoAfter storing, find older similar memories. recommend returns supersede candidates only; auto_safe supersedes only high-confidence same-scope/type/category matches. No physical deletion.recommend

TDQS

A4.7/5.0
Behavior5/5

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

Discloses behavioral traits beyond annotations: conditional storage based on novelty, duplicate skipping, auto_safe reconciliation superseding high-confidence matches without deletion, and potential state writes. Annotations provide idempotent and non-destructive hints, but the description adds nuanced behavior not captured in annotations.

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?

Concise, front-loaded with core purpose, and every sentence adds essential information. No fluff or repetition. Length is appropriate given the tool complexity.

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 14 parameters and no output schema, the description is highly complete: it explains core logic (novelty, deduplication, reconciliation), scope semantics, return fields (storage status, duplicate evidence, memory ID, reconciliation actions), and references sibling tools. Covers all critical aspects for correct invocation.

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 does not significantly add parameter-level meaning beyond the schema. While it provides context like 'never place secrets here' for document_refs, this is also in the schema. No major added 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 'Store one durable Memory V2 record only when it is sufficiently different from existing reviewed memory.' It specifies it is an EDITOR operation, distinguishes from snipara_end_of_task_commit and context tools, and lists return values. The name and description together convey a precise verb-resource-action.

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?

Explicitly advises using snipara_end_of_task_commit for multi-outcome workflow capture and context tools for source documents, indicating when not to use this tool. It also describes duplicate call behavior and reconciliation modes, providing clear guidance on when the tool is appropriate.

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

snipara_statsA
Read-onlyIdempotent

Read compact project documentation and retrieval statistics without changing project state. File samples and database-backed index health are opt-in to keep the response small. Use snipara_index_health for operational diagnosis rather than this overview. Returns counts, token/index summaries, and only the optional sections requested.

ParametersJSON Schema
NameRequiredDescriptionDefault
max_filesNoMaximum file paths to include when include_files=true.
include_filesNoInclude a capped sample of indexed file paths.
include_index_healthNoInclude a compact DB-backed index-health snapshot. For full health, call snipara_index_health.

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description reinforces 'without changing project state' and adds detail about opt-in sections and compactness. This adds value beyond annotations without contradicting them.

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?

Three sentences, each carrying distinct value: read-only purpose, opt-in details, alternative tool. Front-loaded with the core action. No redundant or unnecessary wording.

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 tool with three optional parameters and no output schema, the description adequately explains what it returns (counts, token/index summaries, optional sections) and when to use the sibling tool. No critical gaps.

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 description coverage is 100% with each parameter having a description. The description adds context that file samples and index health are opt-in 'to keep the response small', which enhances understanding of the parameter defaults.

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 states 'Read compact project documentation and retrieval statistics', using a specific verb and resource. It distinguishes this tool from siblings by explicitly referencing snipara_index_health as an alternative for operational diagnosis.

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 'Use snipara_index_health for operational diagnosis rather than this overview', providing clear when-not and alternative. This leaves no ambiguity about when to choose this tool.

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

Tool Schema Changelog

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

  1. 133 tool updatesv2.8.24
    • Removedrlm_agent_profile_get
    • Removedrlm_agent_profile_update
    • Removedrlm_agent_status
    • Removedrlm_broadcast
    • Removedrlm_claim
    • Removedrlm_clear_context
    • Removedrlm_code_callers
    • Removedrlm_code_imports
    • Removedrlm_code_neighbors
    • Removedrlm_code_shortest_path
    • Removedrlm_context
    • Removedrlm_context_query
    • Removedrlm_create_client_project
    • Removedrlm_create_collection
    • Removedrlm_decision_create
    • Removedrlm_decision_query
    • Removedrlm_decision_supersede
    • Removedrlm_decompose
    • Removedrlm_delete_summary
    • Removedrlm_end_of_task_commit
    • Removedrlm_ensure_business_collection
    • Removedrlm_forget
    • Removedrlm_get_chunk
    • Removedrlm_get_collection_documents
    • Removedrlm_get_summaries
    • Removedrlm_get_template
    • Removedrlm_help
    • Removedrlm_htask_audit_trail
    • Removedrlm_htask_block
    • Removedrlm_htask_checkpoint_delta
    • Removedrlm_htask_close
    • Removedrlm_htask_complete
    • Removedrlm_htask_create
    • Removedrlm_htask_create_feature
    • Removedrlm_htask_delete
    • Removedrlm_htask_get
    • Removedrlm_htask_metrics
    • Removedrlm_htask_policy_get
    • Removedrlm_htask_policy_update
    • Removedrlm_htask_recommend_batch
    • Removedrlm_htask_tree
    • Removedrlm_htask_unblock
    • Removedrlm_htask_update
    • Removedrlm_htask_verify_closure
    • Removedrlm_index_health
    • Removedrlm_index_recommendations
    • Removedrlm_inject
    • Removedrlm_journal_append
    • Removedrlm_journal_get
    • Removedrlm_journal_summarize
    • Removedrlm_link_collection
    • Removedrlm_list_business_collections
    • Removedrlm_list_client_projects
    • Removedrlm_list_collections
    • Removedrlm_list_templates
    • Removedrlm_load_document
    • Removedrlm_load_project
    • Removedrlm_memories
    • Removedrlm_memory_attach_source
    • Removedrlm_memory_clean_candidates
    • Removedrlm_memory_compact
    • Removedrlm_memory_daily_brief
    • Removedrlm_memory_duplicate_candidates
    • Removedrlm_memory_health
    • Removedrlm_memory_invalidate
    • Removedrlm_memory_resolve_queue_item
    • Removedrlm_memory_review_queue
    • Removedrlm_memory_supersede
    • Removedrlm_memory_verify
    • Removedrlm_multi_project_query
    • Removedrlm_multi_query
    • Removedrlm_orchestrate
    • Removedrlm_plan
    • Removedrlm_query_trends
    • Removedrlm_read
    • Removedrlm_recall
    • Removedrlm_reindex
    • Removedrlm_release
    • Removedrlm_remember
    • Removedrlm_remember_bulk
    • Removedrlm_remember_if_novel
    • Removedrlm_repl_context
    • Removedrlm_request_access
    • Removedrlm_search
    • Removedrlm_search_analytics
    • Removedrlm_sections
    • Removedrlm_session_bootstrap_status
    • Removedrlm_session_memories
    • Removedrlm_settings
    • Removedrlm_shared_context
    • Removedrlm_state_get
    • Removedrlm_state_poll
    • Removedrlm_state_set
    • Removedrlm_stats
    • Removedrlm_store_summary
    • Removedrlm_svg_bundle_ingest
    • Removedrlm_swarm_create
    • Removedrlm_swarm_events
    • Removedrlm_swarm_join
    • Removedrlm_swarm_leave
    • Removedrlm_swarm_members
    • Removedrlm_swarm_update
    • Removedrlm_sync_documents
    • Removedrlm_task_bulk_create
    • Removedrlm_task_claim
    • Removedrlm_task_complete
    • Removedrlm_task_create
    • Removedrlm_task_delete
    • Removedrlm_task_events
    • Removedrlm_task_list
    • Removedrlm_task_reassign
    • Removedrlm_task_recover
    • Removedrlm_task_stats
    • Removedrlm_task_unclaim
    • Removedrlm_task_update
    • Removedrlm_tenant_profile_create
    • Removedrlm_tenant_profile_get
    • Removedrlm_unlink_collection
    • Removedrlm_upload_business_document
    • Removedrlm_upload_document
    • Removedrlm_upload_shared_document
    • Addedsnipara_ask
    • Addedsnipara_context_query
    • Addedsnipara_end_of_task_commit
    • Addedsnipara_get_chunk
    • Addedsnipara_inbox_review_apply
    • Addedsnipara_inbox_review_plan
    • Addedsnipara_inbox_review_queue
    • Addedsnipara_read
    • Addedsnipara_recall
    • Addedsnipara_remember_if_novel
    • Addedsnipara_search
    • Addedsnipara_stats
  2. 121 tool updatesv2.8.3
    • First observedrlm_agent_profile_get
    • First observedrlm_agent_profile_update
    • First observedrlm_agent_status
    • First observedrlm_broadcast
    • First observedrlm_claim
    • First observedrlm_clear_context
    • First observedrlm_code_callers
    • First observedrlm_code_imports
    • First observedrlm_code_neighbors
    • First observedrlm_code_shortest_path
    • First observedrlm_context
    • First observedrlm_context_query
    • First observedrlm_create_client_project
    • First observedrlm_create_collection
    • First observedrlm_decision_create
    • First observedrlm_decision_query
    • First observedrlm_decision_supersede
    • First observedrlm_decompose
    • First observedrlm_delete_summary
    • First observedrlm_end_of_task_commit
    • First observedrlm_ensure_business_collection
    • First observedrlm_forget
    • First observedrlm_get_chunk
    • First observedrlm_get_collection_documents
    • First observedrlm_get_summaries
    • First observedrlm_get_template
    • First observedrlm_help
    • First observedrlm_htask_audit_trail
    • First observedrlm_htask_block
    • First observedrlm_htask_checkpoint_delta
    • First observedrlm_htask_close
    • First observedrlm_htask_complete
    • First observedrlm_htask_create
    • First observedrlm_htask_create_feature
    • First observedrlm_htask_delete
    • First observedrlm_htask_get
    • First observedrlm_htask_metrics
    • First observedrlm_htask_policy_get
    • First observedrlm_htask_policy_update
    • First observedrlm_htask_recommend_batch
    • First observedrlm_htask_tree
    • First observedrlm_htask_unblock
    • First observedrlm_htask_update
    • First observedrlm_htask_verify_closure
    • First observedrlm_index_health
    • First observedrlm_index_recommendations
    • First observedrlm_inject
    • First observedrlm_journal_append
    • First observedrlm_journal_get
    • First observedrlm_journal_summarize
    • First observedrlm_link_collection
    • First observedrlm_list_business_collections
    • First observedrlm_list_client_projects
    • First observedrlm_list_collections
    • First observedrlm_list_templates
    • First observedrlm_load_document
    • First observedrlm_load_project
    • First observedrlm_memories
    • First observedrlm_memory_attach_source
    • First observedrlm_memory_clean_candidates
    • First observedrlm_memory_compact
    • First observedrlm_memory_daily_brief
    • First observedrlm_memory_duplicate_candidates
    • First observedrlm_memory_health
    • First observedrlm_memory_invalidate
    • First observedrlm_memory_resolve_queue_item
    • First observedrlm_memory_review_queue
    • First observedrlm_memory_supersede
    • First observedrlm_memory_verify
    • First observedrlm_multi_project_query
    • First observedrlm_multi_query
    • First observedrlm_orchestrate
    • First observedrlm_plan
    • First observedrlm_query_trends
    • First observedrlm_read
    • First observedrlm_recall
    • First observedrlm_reindex
    • First observedrlm_release
    • First observedrlm_remember
    • First observedrlm_remember_bulk
    • First observedrlm_remember_if_novel
    • First observedrlm_repl_context
    • First observedrlm_request_access
    • First observedrlm_search
    • First observedrlm_search_analytics
    • First observedrlm_sections
    • First observedrlm_session_bootstrap_status
    • First observedrlm_session_memories
    • First observedrlm_settings
    • First observedrlm_shared_context
    • First observedrlm_state_get
    • First observedrlm_state_poll
    • First observedrlm_state_set
    • First observedrlm_stats
    • First observedrlm_store_summary
    • First observedrlm_svg_bundle_ingest
    • First observedrlm_swarm_create
    • First observedrlm_swarm_events
    • First observedrlm_swarm_join
    • First observedrlm_swarm_leave
    • First observedrlm_swarm_members
    • First observedrlm_swarm_update
    • First observedrlm_sync_documents
    • First observedrlm_task_bulk_create
    • First observedrlm_task_claim
    • First observedrlm_task_complete
    • First observedrlm_task_create
    • First observedrlm_task_delete
    • First observedrlm_task_events
    • First observedrlm_task_list
    • First observedrlm_task_reassign
    • First observedrlm_task_recover
    • First observedrlm_task_stats
    • First observedrlm_task_unclaim
    • First observedrlm_task_update
    • First observedrlm_tenant_profile_create
    • First observedrlm_tenant_profile_get
    • First observedrlm_unlink_collection
    • First observedrlm_upload_business_document
    • First observedrlm_upload_document
    • First observedrlm_upload_shared_document
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: ask, context query, search, read line range, get chunk, recall memory, remember if novel, end-of-task commit, inbox review queue/plan/apply, and stats. No overlapping functionality.

Naming Consistency5/5

All tools follow a consistent 'snipara_' prefix with snake_case descriptive names (e.g., snipara_context_query, snipara_end_of_task_commit). No mixing of conventions or abbreviations.

Tool Count5/5

12 tools is well-scoped for a documentation and memory management server. It covers viewing, searching, querying, memory operations, inbox review workflow, and statistics without being overwhelming or sparse.

Completeness4/5

The tool surface covers core retrieval, memory storage, and inbox review. Minor gaps include the lack of an explicit update or delete for memories, but the server appears focused on append and recall. Overall coverage is strong.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Tages

    ryantlee25-droid
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI coding agents to maintain persistent, cross-session memory of codebase architecture, naming conventions, and decisions through MCP tools. Eliminates repetitive project re-explanation by automatically injecting stored context into every session with local-first SQLite storage and optional team sharing capabilities.
    4
    MIT

  • promem-mcp

    DIP-RO
    A
    license
    B
    quality
    A
    maintenance
    Enables AI coding agents to maintain persistent project context, including rules, decisions, environment intelligence, and Git history, using a local-first MCP server with automatic project detection and token-efficient retrieval.
    13
    MIT

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alopez3006/snipara-mcp'

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