Configure Memory

configure_profile_import

Import brings memories INTO the profile from outside — it never exports, lists, or shows what is already saved (use configure_profile_read or configure_profile_search for that, even when the user says "export" or "show me"). Two shapes go in here. A structured memory export, the ---SECTION:Name--- format with one dated entry per line that assistants produce when asked to export everything they know about the user, is split into individual profile facts and filed by category, which is how a first-time backfill from another assistant lands. Anything else is treated as one chunk of context: bulk-file it into your namespace when there is too much to save as a single fact — a long note, meeting notes, a multi-topic dump, or the current discussion when the user asks to save it. Configure distills it into a short context note (a stream, kept as-is in your namespace, not promoted to shared profile facts) and files it into a box automatically. Use configure_profile_remember instead for one clear fact the user stated; use configure_profile_commit to close out a turn after a profile read. Reach for import the moment the user provides material and says things like "keep all of this" or "import these notes", and when the user asks to save the current conversation ("save this whole conversation") — that explicit request is both the designation and the consent, so import is the right call, not a refusal. Send only what the user asked to keep, and never import anything on your own initiative. Optionally pass box to force the shelf: reuse an existing box id from the profile table of contents, or a short new lowercase name to create one; omit it to let Configure pick the box. Writes under your own agent namespace (resolved from the authenticated session, not arguments) and returns the chosen box and stored memory id. Additive: it only files context the user asked to keep. It never deletes or overwrites existing memories, and never emails, posts, or publishes anything on the user's behalf. Use configure_profile_remember_many instead when the user has already turned the material into a list of separate facts and approved it.

Input Schema

TableJSON Schema

Name	Required	Description
`box`	No	Optional, and only used for kind "context". The namespace box (shelf) to file the note under: reuse an existing box id from the profile table of contents, or a short new lowercase name to create one. Omit to let Configure choose. Ignored for kind "memories", which files each fact by category rather than into a namespace box.
`kind`	No	Which of the two PROCESSING shapes this text is, because they are stored differently (a different argument from configure_profile_remember's kind, which classifies a single project note). "memories": the user's own durable facts in any format — an export from another assistant, a list of preferences, a compiled summary of what you know about them; each fact is split out and filed by category so it becomes part of the profile, and Configure reformats messy input so exact formatting does not matter. "context": source material to keep as-is — meeting notes, an article, a long document the user provided; condensed into one short note for reference. The test is whether each line should become a standing fact about the user ("memories") or the material itself is what matters ("context"). Omitted, Configure infers it from the text.
`text`	Yes	Required. The content the user explicitly asked to keep — a memory export from another assistant, material they provided, or the discussion they asked to save. Include only what the user asked to import, nothing beyond it; Configure distills it.

Output Schema

TableJSON Schema

Name	Required	Description
`box`	No	Box the note was filed under.
`error`	No
`saved`	No
`memory`	No
`source`	No
`distilled`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false with destructiveHint=false, and the description adds substantial context beyond that: it writes under the agent's own namespace resolved from the session (not arguments), is additive, never deletes/overwrites, and never emails/posts/publishes. It also explains that context is distilled into a stream kept as-is rather than promoted to shared facts, which is behavior not captured by any structured field.

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 the core scoping statement and the negative definition first, then shapes and guidance. It is on the verbose side with repeated safety/routing reminders, but nearly every sentence carries a distinct routing or behavioral instruction, so little is pure padding.

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 an output schema, the return contract is already covered, yet the description still notes it returns the chosen box and stored memory id. Combined with the two-shape processing model, session-derived namespace, and consent framing for conversation saves, nothing an agent needs to invoke this 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 the schema already documents box, kind, and text thoroughly; the description's added value is modest but real, explaining the box 'force the shelf' behavior and that omission lets Configure choose. It reinforces the kind test and inference behavior, slightly exceeding the baseline-3 expectation for fully covered schemas.

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 (import) and resource (profile), explicitly defines scope ('brings memories INTO the profile from outside') and contrasts it with what it does NOT do ('never exports, lists, or shows'). It names the sibling tools an agent should use instead, so the operation is unmistakable even against configure_profile_read/search/remember.

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 conditions and named alternatives: use configure_profile_read or configure_profile_search for reading, configure_profile_remember for a single clear fact, configure_profile_commit to close out a turn after a read, and configure_profile_remember_many for approved fact lists. It even pre-empts the common 'export'/'show me' misrouting and the 'save this whole conversation' case.

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

All Configure Memory tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?