Metis

Official

Overview Schema Source Related Servers Discussions Admin

Assemble memory for a task

agent_memory_context

Assemble a task's memory for multi-step tasks by retrieving applicable procedures, facts, past cases, and governed tacit guidance in one call.

Instructions

Assemble a task's memory in one call: the workspace's procedures (SOPs), the facts and past cases that match the context, and the governed tacit guidance that applies. Use it when starting or planning a multi-step task. For a check before a single action, use retrieve_guidance instead; calling both for one step records two decisions. Tacit guidance passes the same condition-aware gate as retrieve_guidance, and task is a label recorded with the query. When required_human_actions lists anything (an escalation, or a use constraint that calls for a person's check), stop and hand the decision to a person. Each call records the query and the gate's decisions on the evidence chain, may open an escalation task, and changes no fragment.

Input Schema

TableJSON Schema

Name	Required	Description
`role`	No	The role you act for, for example operator. A fragment whose conditions name other roles is withheld with reason role_not_authorised. Omit it to skip that check.
`task`	Yes	A short name for the task, recorded with the query.
`context`	Yes	The current work situation, with risk_class.

Output Schema

TableJSON Schema

Name	Required	Description
`task`	Yes	The task the context was assembled for.
`tacit`	Yes	Governed tacit guidance that applies. Empty when none applies.
`episodic`	Yes	Past cases that match the context.
`semantic`	Yes	Facts about the equipment, materials, and process that match the context.
`withheld`	Yes	Fragments about this situation that were withheld, with the reason.
`procedural`	Yes	The workspace's procedures, such as SOPs, all of them.
`governance_notes`	Yes	The rules that shaped this context.
`escalation_task_id`	Yes	The escalation opened for a person, when the gate handed anything over.
`not_yet_authorised`	Yes	How many unreviewed or unauthorised fragments were left out. They stay unnamed until reviewers promote them.
`required_human_actions`	Yes	Actions a person must take before you act: escalations, and use constraints that call for a person's check. When any is listed, stop and hand the decision to a person.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.6Oct 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond annotations: it discloses that each call records the query and the gate's decisions to an evidence chain, may open an escalation task, changes no fragment, that tacit guidance passes a condition-aware gate, and that a populated required_human_actions means stop and hand to a person. This complements readOnlyHint=false/destructiveHint=false by explaining exactly what side effects occur.

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-loads the purpose before routing guidance and behavioral caveats. Every sentence carries information, though the passage is dense and could be trimmed slightly for readability.

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?

Output schema exists so return values need no explanation. For a complex, non-idempotent assembly call, the description still covers the side effects, the human-handoff trigger, and the relationship to the sibling guidance tool, leaving little an agent needs to know beyond this.

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 the schema already documents task, context, and role. The description only restates that task is a label recorded with the query; it adds no matching-syntax or field-usage detail beyond the schema, so the baseline 3 fits.

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?

States a specific verb and resource ('Assemble a task's memory in one call') and enumerates what is assembled: workspace SOPs, matching facts and past cases, and governed tacit guidance. It explicitly distinguishes itself from retrieve_guidance by scope (multi-step task vs single action).

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?

Gives explicit when-to-use ('starting or planning a multi-step task'), names the alternative and its condition ('for a check before a single action, use retrieve_guidance'), and adds a concrete anti-pattern warning that calling both for one step records two decisions.

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

Deploy Server