Skip to main content
Glama
wenlan-app

Wenlan

Official
by wenlan-app
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

capture

Destructive

Store durable user preferences, decisions, and facts in the Wenlan wiki memory so agents retain context across sessions. Use proactively when users share lasting personal or project insights.

Instructions

Capture a memory: one durable insight the user's wiki should keep.

STORE PROACTIVELY, without waiting for 'remember this' (a floor, not a trigger): when the user states a preference, makes a decision, corrects you or earlier information, or shares a durable fact about themselves or the people, projects, and tools they care about.

WHEN NOT TO STORE: conversation filler; things the user can trivially re-derive (file paths, recent git history); anything already stored (recall first if unsure); Tool output or command results (file contents, build logs, system prompts); transient task state; general world facts not personal to this user; Your own inferences the user did not express; agent operating rules ('always X' / 'never Y' belong in the agent's own config, not shared memory: store the preference as a fact, never the rule).

CONTENT QUALITY: Specific beats vague ('prefers Rust for CLI tools because of compile-time safety' > 'likes Rust'). Include the WHY, which only you know. Name people, projects, and tools; this powers the knowledge graph. Atomic: one idea per memory. Each call is one atomic idea: 'prefers TDD' and 'uses pytest' are two calls. Declarative, not narrative: 'User prefers X because Y', not 'User said today they prefer X'; memories outlive the conversation.

MEMORY TYPES: omit and trust the backend. By default do NOT set memory_type; the backend auto-classifies into identity / preference / decision / lesson / gotcha / fact with more context than you have, and agents that over-specify pick wrong. Opt in only when sure: 'profile' (about the user: identity / preference), 'knowledge' (about the world: decision / lesson / gotcha / fact), or a precise type when the distinction matters. EXCEPTION: set memory_type="decision" explicitly ONLY when the user articulated the alternatives weighed AND the reasoning; those structured fields power the Decision Log view. A bare 'I'm switching to Cursor' is a preference change, not a decision. NO MODEL: when a capture receipt says enrichment: paused or enrichment: off, nothing classifies memories, so set memory_type yourself on every capture.

Omitting structured_fields beats guessing. If supersedes is supplied for a correction, this call can replace an existing memory in retrieval; use it only when that replacement is intended.

Input Schema

NameRequiredDescriptionDefault
spaceNoTopic scope (e.g. 'rust', 'work', 'health', 'origin'). Auto-detected if omitted.
entityNoPerson, project, or tool name to anchor to (e.g. 'Alice', 'Wenlan', 'PostgreSQL'). Helps build the knowledge graph.
contentYesThe memory content. Write as a complete statement with context and reasoning, not shorthand. One idea per memory.
sessionNoYour AI session as tool:id, e.g. claude-code:<session id>; links what you write back to this conversation.
confidenceNo0.0-1.0. Leave unset for auto-calculation based on type and trust level. Set low (0.3-0.5) for uncertain info, high (0.8-1.0) for user-stated facts.
supersedesNosource_id of a memory this replaces. Use when correcting or updating an existing memory — get the ID from recall first. If the user has set your agent's trust level below full, a capture that sets supersedes is staged for review rather than applied: the response says gated: true, and the memory you meant to replace keeps answering searches until a human accepts your change. Tell the user the correction is waiting for their approval; do not repeat the capture.
memory_typeNo"profile" (about the user) or "knowledge" (about the world) — or precise: "identity", "preference", "decision", "lesson", "gotcha", "fact" — auto-classified if omitted
retrieval_cueNoA question this memory answers, for search matching. Auto-generated by backend; only supply to override.
structured_fieldsNoPre-extracted structured fields as a JSON object. Auto-extracted by backend; only supply if you have high-quality structured data already.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.19.3

TDQS

A4.8/5.0
Behavior5/5

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

Annotations flag a non-idempotent, destructive write; the description goes well beyond that by explaining that `supersedes` replaces an existing memory in retrieval, that such corrections can be staged with `gated: true` when trust is below full, and what to tell the user. It also discloses backend auto-classification and the `enrichment: paused/off` state that changes behavior, which annotations alone cannot convey.

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?

Front-loaded with purpose then policy, organized under clear ALL-CAPS headers that make it scannable. It is nonetheless long, and a few lines restate each other ('Atomic: one idea per memory. Each call is one atomic idea'), which costs it the top score.

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 nine-parameter mutation tool with no output schema, the description covers the decisions an agent actually has to make: whether to store, what quality bar to hit, when to set memory_type, when to use supersedes and what the gated response means. Nothing needed to call it correctly is missing.

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, but the description adds real decision guidance beyond the schema: default to omitting memory_type and why over-specification fails, the 'decision' exception with its alternatives-weighed criterion, and the no-model case where memory_type must be set. Confidence, space, and entity are left to the schema, so it stops short of 5.

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?

Opens with a specific verb and resource plus a scope qualifier: 'Capture a memory: one durable insight the user's wiki should keep.' That immediately separates it from recall, forget, write_page and confirm_memory without needing the schema.

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 when-to-store triggers (preference, decision, correction, durable fact) framed as 'a floor, not a trigger', a dedicated WHEN NOT TO STORE list with concrete exclusions, and an explicit alternative ('recall first if unsure'). This is about as complete a routing policy as a tool description can carry.

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

Deploy Server

Other Tools