Skip to main content
Glama

vectr_distill

Idempotent

Review pending failure-to-success arcs and dismiss those not worth distilling, providing reasons to prevent cluttering working memory with covered or transient lessons.

Instructions

Review pending arcs — discovered failure->success moments captured automatically from your own tool calls (e.g. a command that failed twice, then succeeded after an edit) — and turn the ones worth keeping into working-memory notes. Call with no arguments to render pending arcs for review, oldest and most-confident first, token-bounded. For each arc worth keeping, call vectr_remember(..., distilled_from=[arc_id]) to persist the lesson as a note (see vectr_remember's own parameters for kind/priority/triggers). For arcs not worth keeping, call vectr_distill(dismiss=[arc_id, ...], reason='...'). Distiller rules: (1) recall-first dedupe — vectr_recall(query=) before writing; if an existing note already covers it, dismiss the arc (reason: covered by note #N) — if the arc proves an existing note wrong or outdated, use contradicts=/supersedes= on that note instead of writing a duplicate. (2) Generalize — store the lesson (what class of command fails, why, what fixed it), not the transcript; keep concrete commands/paths only when they ARE the lesson. (3) Kind mapping — an env/process/build fact -> kind='operational' (add triggers=[{'event': 'prompt-submit', 'semantic': True}, {'command': ''}] when the lesson is tied to a command family); tied to specific files -> kind='gotcha' with those files as anchors; a standing user rule -> kind='directive' (rare from arcs). (4) Low-confidence arcs are dismissed unless the same lesson recurs across >= 2 arcs. (5) Priority defaults to medium; high only when acting on the stale belief is costly (e.g. false-pass verification traps). (6) Batch cap — distill at most ~5 notes per sitting; leave the rest pending.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoRequired together with dismiss= — why these arcs are not worth distilling (e.g. 'covered by note #12', 'transient network flake').
dismissNoArc ids (from this tool's own render or GET /v1/arcs) to dismiss without distilling into a note. Pass together with reason.
Behavior5/5

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

Description discloses extensive behavioral details: token-bounded rendering, oldest-first ordering, batch cap, deduplication rules, and kind mapping. No contradiction with annotations (idempotentHint=true is consistent with idempotent dismiss).

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?

Description is verbose but well-structured with front-loaded purpose and numbered rules. Every sentence adds value, though could be slightly more concise.

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 tool complexity (multiple modes, rules, and integration with other tools), the description is remarkably complete. Covers all states: render, dismiss, and distiller rules. No output schema, but return value (rendered arcs) is implied.

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 covers 100% of parameters with descriptions, but the description adds essential semantics: explains that dismiss and reason must be used together, provides examples, and clarifies behavior with no arguments.

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 clearly states the tool reviews pending arcs (failure->success moments) and distills them into working-memory notes. It distinguishes from sibling 'vectr_remember' by positioning itself as the review/dismiss 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?

Provides explicit guidance: call with no arguments to render arcs, call with dismiss+reason to reject, and detailed rules for when to keep vs dismiss. References alternatives like vectr_remember and vectr_recall for deduplication.

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/swapnanil/vectr'

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