Skip to main content
Glama
CPersona

CPersona

Official
by Cloto-dev

reconstruct

Read-only

The recommended way to answer a question from memory. Returns up to count ITEMS (10 by default): units of memory, each quoting verbatim its most relevant record.

Instructions

The recommended way to answer a question from memory. Returns up to count ITEMS (10 by default): units of memory, each quoting verbatim its most relevant record. content is the parts of that record that matched the query; pass head_ref, or an item's expand as it is, to get_contents to read more. No model is called and nothing is summarised; stored rows are never modified. COUNT IS A CEILING, not a fill target or a search depth: fewer items is a normal result and carries shortfall_reason, and nothing is padded. reserved_count held items (block, cue, far, mode seats) may trail the window. Breadth is set apart from count: raise top_k when items are missing evidence; max_hops and max_evidence bound the declared-relation walk and the rows kept per item. BUDGET bounds the characters of quoted text (content plus excerpts), where count bounds items: excerpts are omitted before items, and raising the budget never removes an item or an excerpt. Omit it for the server default. mode (lite / pro) caps the tokens returned (see it). READ FURTHER IN STEPS, smallest first: an item's expand, then the neighbours of a quote's node or block index ({ref, node: [i-1, i+1]}, or block), and the bare ref, the whole record, last. ITEM: claims lists the retained rows newest first (ref, as_of, why, hops, roles); excerpts quote the other claims. roles[].role names what the REFERENCED row is to this claim (supports / supersedes / corrects / qualifies / contradicts / temporal_predecessor); ignore a role you do not know. conflicts appears only when two rows cannot be ordered. A response adds fields only when the server did something other than asked (count_policy, budget_policy, bounds, gate_fallback); their absence does not say the items suffice or that the whole store was searched. trace=true returns the full audit. Declared associations widen the lexical search and add walked evidence inside items, never items. Full contract: docs/RELIABLE_RECALL_2_6.md section 7.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "agent_id": "<agent_id>",
      "query": "<query>"
    },
    "name": "reconstruct"
  }
}

Input Schema

NameRequiredDescriptionDefault
deepNoDeep recall for the candidate stage -- same semantics as in `recall`.
liteNoThe same as `mode: "lite"`, which is the name to use; kept so that older callers keep working. Not together with `mode`. Default false.
modeNoA named answer size whose returned JSON is at most `cap` cl100k_base tokens, counted as sent (`used_tokens`). "lite" (cap 3,000) is for a question one or two records can answer: up to 2,800 characters unless `budget` is given, short records whole first, then the best-ranked passages of longer ones. "pro" (cap 5,000) reads 15 items by default and quotes as much as the cap holds. Both leave out `ranges`, `bounds` and the budget fields; an item whose only claim is its head carries that claim's `as_of` instead of `claims`. A larger cap never removes an item or an excerpt. Omit it for the default response, which has no cap. `trace=true` returns every field and is not held to the cap.
countNoCeiling on recall items returned -- not a fill target, not a search depth. Declare per call; omit to take the server default (10 unless configured). An operator-forced value overrides both. Requesting 5 with only 2 valid items returns 2; neither setting requires filling the window. Clamped to the server maximum, and the clamp is reported in count_policy rather than applied silently.
queryYesSearch query (empty returns recent memories)
top_kNoCandidate depth: how many rows the retrieval hands to bundling. This is the breadth knob; it is independent of `count` and is what to raise when items are missing evidence.
traceNoInclude candidate refs and cluster membership for local diagnosis, and the trace of the recall it made as trace.recall; no full text is added.
budgetNoPayload budget: characters of quoted text (item `content` plus `excerpts`) the response may carry. Bounds depth, where `count` bounds breadth, and breadth wins: excerpts are omitted before any item is. Omit for the server default, which is never less than one quote per item of the window; an operator-forced value overrides both; clamped to the server maximum and raised to one head quote, and budget_policy says which.
channelNoMemory channel filter
agent_idYesAgent identifier
max_hopsNoRelation hops the walk may follow from an item's candidates through declared entity -> entity relations. 0, or any mode, adds no walked evidence. A relation left unfollowed at the bound is named in bounds.omitted. At most 5, as for traverse: a larger value is lowered to it, and bounds.max_hops then states the value applied.
time_cueNo2.6: when the answer was stored, as far as you remember — the same object recall takes (see recall's time_cue), applied to the candidate recall this reconstruction reads. The response carries time_cue when one was applied.
source_idNoPer-user source filter -- same semantics as in `recall`.
project_idNoγ filter -- same semantics as in `recall`, including the '@auto' sentinel, which resolves this agent's default from the server's operating context and echoes the resolution as resolved_project_id. With no configured operating context the sentinel is NOT resolved: it is filtered as the literal project_id '@auto'. Read resolved_project_id before relying on the resolution.
session_keyNoOpaque session identity you declare: a partition hint, not authentication and not a data filter. Forwarded to the candidate recall.
max_evidenceNoMaximum retained rows per item, bounding its claims and role targets. A cut is named in bounds.omitted and counted in the item's claims_omitted. At most 100, as traverse's limit: a larger value is lowered to it, and bounds.max_evidence then states the value applied.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.6.12
    • changedInput schema / properties / max_evidence / description
      Previous value: -"Maximum retained rows per item, bounding its claims and role targets. A cut is named in bounds.omitted and counted in the item's claims_omitted."New value: +"Maximum retained rows per item, bounding its claims and role targets. A cut is named in bounds.omitted and counted in the item's claims_omitted. At most 100, as traverse's limit: a larger value is lowered to it, and bounds.max_evidence then states the value applied."
    • addedInput schema / properties / max_evidence / maximum
      Added value: +100
    • changedInput schema / properties / max_hops / description
      Previous value: -"Relation hops the walk may follow from an item's candidates through declared entity -> entity relations. 0 adds no walked evidence. A relation left unfollowed at the bound is named in bounds.omitted. At most 5, as for traverse: a larger value is lowered to it, and bounds.max_hops then states the value applied."New value: +"Relation hops the walk may follow from an item's candidates through declared entity -> entity relations. 0, or any mode, adds no walked evidence. A relation left unfollowed at the bound is named in bounds.omitted. At most 5, as for traverse: a larger value is lowered to it, and bounds.max_hops then states the value applied."
    • changedInput schema / properties / mode / description
      Previous value: -"A named answer size whose returned JSON is at most `cap` cl100k_base tokens, counted as sent (`used_tokens` says how many). \"lite\" (cap 3,000) is for a question one or two records can answer: up to 2,800 characters unless `budget` is given, short records whole first, then the best-ranked passages of longer ones. \"pro\" (cap 5,000) reads 15 items by default and quotes as much as the cap holds. Both leave out `ranges`, `bounds` and the budget fields; an item whose only claim is its head carries that claim's `as_of` instead of `claims`. A larger cap never removes an item or an excerpt. Omit it for the default response, which has no cap. `trace=true` returns every field and is not held to the cap."New value: +"A named answer size whose returned JSON is at most `cap` cl100k_base tokens, counted as sent (`used_tokens`). \"lite\" (cap 3,000) is for a question one or two records can answer: up to 2,800 characters unless `budget` is given, short records whole first, then the best-ranked passages of longer ones. \"pro\" (cap 5,000) reads 15 items by default and quotes as much as the cap holds. Both leave out `ranges`, `bounds` and the budget fields; an item whose only claim is its head carries that claim's `as_of` instead of `claims`. A larger cap never removes an item or an excerpt. Omit it for the default response, which has no cap. `trace=true` returns every field and is not held to the cap."
  2. Changed2 schema fields changedv2.6.10
    • changedInput schema / properties / lite / description
      Previous value: -"A smaller, cheaper response, for a question one or two records can answer. Quotes at most 2,800 characters unless `budget` is given, short records whole first and then the best-ranked passages of longer ones. Leaves out `ranges`, `bounds` and the budget fields; an item whose only claim is its head carries that claim's `as_of` instead of `claims`. The response says `lite: true`. It can miss evidence the default finds: use the default when the question needs several records or a lite answer was incomplete. `trace=true` returns every field. Default false."New value: +"The same as `mode: \"lite\"`, which is the name to use; kept so that older callers keep working. Not together with `mode`. Default false."
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "A named answer size whose returned JSON is at most `cap` cl100k_base tokens, counted as sent (`used_tokens` says how many). \"lite\" (cap 3,000) is for a question one or two records can answer: up to 2,800 characters unless `budget` is given, short records whole first, then the best-ranked passages of longer ones. \"pro\" (cap 5,000) reads 15 items by default and quotes as much as the cap holds. Both leave out `ranges`, `bounds` and the budget fields; an item whose only claim is its head carries that claim's `as_of` instead of `claims`. A larger cap never removes an item or an excerpt. Omit it for the default response, which has no cap. `trace=true` returns every field and is not held to the cap.",
      +  "enum": [
      +    "lite",
      +    "pro"
      +  ],
      +  "type": "string"
      +}
  3. Changed1 schema field changedv2.6.5
    • addedInput schema / properties / lite
      Added value: +{
      +  "description": "A smaller, cheaper response, for a question one or two records can answer. Quotes at most 2,800 characters unless `budget` is given, short records whole first and then the best-ranked passages of longer ones. Leaves out `ranges`, `bounds` and the budget fields; an item whose only claim is its head carries that claim's `as_of` instead of `claims`. The response says `lite: true`. It can miss evidence the default finds: use the default when the question needs several records or a lite answer was incomplete. `trace=true` returns every field. Default false.",
      +  "type": "boolean"
      +}
  4. Changed7 schema fields changedv2.6.1
    • changedInput schema / properties / budget / description
      Previous value: -"Payload budget: characters of quoted text (item `content` plus `excerpts`) the response may carry. Bounds depth, where `count` bounds breadth, and breadth wins: excerpts are omitted before any item is. Omit for the server default, which is never less than one quote per item of the window; an operator-forced value overrides both; clamped to the server maximum and raised to one preview-tier excerpt, and budget_policy says which."New value: +"Payload budget: characters of quoted text (item `content` plus `excerpts`) the response may carry. Bounds depth, where `count` bounds breadth, and breadth wins: excerpts are omitted before any item is. Omit for the server default, which is never less than one quote per item of the window; an operator-forced value overrides both; clamped to the server maximum and raised to one head quote, and budget_policy says which."
    • changedInput schema / properties / count / description
      Previous value: -"Ceiling on recall items returned -- not a fill target, not a search depth. Declare per call; omit to take the server default (1 unless configured). An operator-forced value overrides both. Requesting 5 with only 2 valid items returns 2; neither setting requires filling the window. Clamped to the server maximum, and the clamp is reported in count_policy rather than applied silently."New value: +"Ceiling on recall items returned -- not a fill target, not a search depth. Declare per call; omit to take the server default (10 unless configured). An operator-forced value overrides both. Requesting 5 with only 2 valid items returns 2; neither setting requires filling the window. Clamped to the server maximum, and the clamp is reported in count_policy rather than applied silently."
    • changedInput schema / properties / max_hops / description
      Previous value: -"Relation hops the walk may follow from an item's candidates through declared entity -> entity relations. 0 adds no walked evidence. A relation left unfollowed at the bound is named in bounds.omitted."New value: +"Relation hops the walk may follow from an item's candidates through declared entity -> entity relations. 0 adds no walked evidence. A relation left unfollowed at the bound is named in bounds.omitted. At most 5, as for traverse: a larger value is lowered to it, and bounds.max_hops then states the value applied."
    • addedInput schema / properties / max_hops / maximum
      Added value: +5
    • addedInput schema / properties / session_key / maxLength
      Added value: +256
    • addedInput schema / properties / time_cue
      Added value: +{
      +  "description": "2.6: when the answer was stored, as far as you remember — the same object recall takes (see recall's time_cue), applied to the candidate recall this reconstruction reads. The response carries time_cue when one was applied.",
      +  "type": "object"
      +}
    • changedInput schema / properties / trace / description
      Previous value: -"Include candidate refs and cluster membership for local diagnosis; no full text is added."New value: +"Include candidate refs and cluster membership for local diagnosis, and the trace of the recall it made as trace.recall; no full text is added."
  5. Addedv2.5.12

TDQS

A3.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, yet the description adds substantial non-obvious behavior: no model is called, nothing is summarised, stored rows are never modified, count is a ceiling rather than a fill target with `shortfall_reason` on shortfall, `reserved_count` items may trail the window, `budget` omits excerpts before items, and response fields like `count_policy`/`bounds` appear only when the server deviated from the request. This is exactly the kind of context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

It is front-loaded sensibly — purpose first, then count/budget semantics, then reading workflow — and with no output schema the return-shape detail is load-bearing. But the prose is dense and jargon-heavy (ALL-CAPS emphasis, 'reserved_count held items (block, cue, far, mode seats) may trail the window'), and several return-field sentences (`claims`, `roles[].role`, `conflicts`) could be tightened without loss.

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 16-parameter tool with only a readOnlyHint annotation and no output schema, the description supplies what an agent actually needs: what an item contains, how to expand incrementally, how count differs from budget and top_k, when policy fields appear, and what `trace=true` does. Nothing material about calling it correctly is missing.

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% and the per-parameter schema text already spells out count-as-ceiling, the budget/excerpt precedence, max_hops clamping and mode caps, so the description largely restates the schema. It does add the framing that 'count bounds items, budget bounds characters' and that `top_k` is the breadth knob separate from count, but that distinction is also present in the schema descriptions. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence pins a specific verb and resource — 'answer a question from memory' returning 'up to `count` ITEMS ... each quoting verbatim its most relevant record' — which is far more concrete than a tautology. However, it never distinguishes itself from the sibling tools it repeatedly defers to ('same semantics as in `recall`', 'as for traverse'); an agent choosing between `recall`, `recall_with_context` and `reconstruct` gets no differentiation from the description body.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is genuine operational guidance: 'READ FURTHER IN STEPS, smallest first: an item's `expand`, then the neighbours ... and the bare ref, the whole record, last' and 'raise `top_k` when items are missing evidence'. But this is guidance for using the result, not guidance on when to pick this tool versus `recall`/`recall_with_context`; tool selection is left entirely to inference.

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