Skip to main content
Glama
alopez3006

snipara-mcp

by alopez3006

snipara_recall

Read-onlyIdempotent

Retrieve past decisions, learnings, and preferences from project memory. Ask a question to get ranked relevant memories within a specified owner boundary.

Instructions

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.

Input Schema

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

Install Server

Other Tools

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