Skip to main content
Glama

plur_learn_batch

Batch-create engrams with sequential dedup and per-item decisions. Accepts an array of statements, applies dedup pipeline, and returns aligned ids and failures, enabling efficient bulk knowledge persistence.

Instructions

Create many engrams in one call — the batch form of plur_learn. Accepts an array of engram objects and writes them sequentially through the SAME dedup + policy pipeline as plur_learn (content-hash NOOP → semantic recall → LLM ADD/UPDATE/MERGE decision). Dedup also applies WITHIN the batch: a statement duplicating an earlier item in the same array resolves to NOOP against it. Returns ids aligned 1:1 with the input array (ids[i] is the engram id for input i, or null if input i failed), the per-item decisions (each carrying its input_index), aggregate stats, and any per-item failures (each with its input index) — a single bad item does not abort the batch. Use this when an orchestration fans out and wants to persist consolidated findings without N separate calls. LLM dedup calls are capped (default 50, override with max_llm_calls) to bound bulk-import cost. Note: unlike plur_learn, batch items take the LOCAL learn path — remote-scope auto-routing (learnRouted) is not applied per item, so for shared/remote-store writes prefer plur_learn or pass an explicit local scope. See plur-ai/plur#281.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
engramsYesEngram objects to persist. Each requires `statement`; the other fields mirror plur_learn.
max_llm_callsNoMax LLM dedup calls across the whole batch (default 50). Once spent, remaining items use the cheap hash/cosine path. Pass a large number to opt out.
Behavior5/5

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

The description extensively explains dedup pipeline (content-hash NOOP → semantic recall → LLM decision), within-batch dedup, per-item results, non-abort on failure, and LLM call cap. Annotations (idempotentHint=false, destructiveHint=false) are complemented, not contradicted.

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 front-loaded with purpose and structured well, but slightly lengthy. However, every sentence adds value—no filler. Could be more concise, but given the complexity, it's appropriately detailed.

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?

With 2 parameters, 100% schema coverage, and no output schema, the description covers return values (`ids`, decisions, stats, failures), dedup behavior, failure handling, and usage nuances. It leaves no critical gaps for an agent to invoke correctly.

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% (baseline 3). Description adds value by explaining that `engrams` mirrors `plur_learn` fields and clarifying `max_llm_calls` default and behavior. While schema already describes individual fields, the context of batch operation and the LLM call cap are useful beyond 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?

Description clearly states 'Create many engrams in one call' and explicitly positions itself as 'the batch form of plur_learn.' It distinguishes from the single-item sibling and details the dedup pipeline, providing a specific verb+resource+scope.

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 guidance: 'Use this when an orchestration fans out... without N separate calls.' Also warns against using for remote/shared stores ('for shared/remote-store writes prefer plur_learn or pass an explicit local scope'), and explains the max_llm_calls cap for cost control.

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/plur-ai/plur'

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