Skip to main content
Glama

Configure Memory

configure_profile_read

Read-only

Read the current user's approved profile. Use the no-argument overview only when the user explicitly asks to review their profile or get a profile overview. For personalized help or a specific fact, use configure_profile_search with a concrete query about the current task; no overview is needed first. Read a known category or project box when the user asks to review it or resume that project. Three ways in. (1) No arguments: the profile overview. Returns composed context, not raw files: identity, the synthesized narrative and preference docs, key facts each tagged with their box like "[work] …", changesSince (memories newer than the synthesized summary), and a table of contents of boxes. Category boxes ("work", "preferences-and-taste", …) hold Configure's settled facts; source boxes ("agents/atlas", "imports/chatgpt") hold one agent's or import's own notes; project boxes ("projects/") are shared tags across agents. The overview is budget-bounded; when something is cut it sets truncated and names the box ids holding the rest — open those instead of re-reading. (2) sections: strict pages of the composed document, and ONLY those pages — sections: ["imports"] is the imports overview (each provider's summary and count), ["soul"] is the full soul document (voice and personality) and ["context"] the full context document (current focus), each the untruncated version of what the overview cut, ["agents"] is the connected-agent map. Use a section when you want one page cheaply. (3) box: open one shelf of STORED memories by id from the table of contents; unknown or empty boxes return a clean empty result naming the boxes that exist. A box open returns ONE PAGE: the response carries total, and when total is larger than the notes you received, call read again with page: 2, then 3, until you have them all — answering from page 1 alone silently drops the rest. For point lookups (one fact, date ranges, source attribution) or filtering by author, use configure_profile_search. An authorization challenge means the user is not signed in; configure_connect supplies the sign-in link that resolves it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
boxNoOptional box id from a previous read's table of contents. A category name like "work" opens the settled facts in that category, ranked by value, across all sources. "agents/<name>" or "imports/<provider>" opens the notes that source saved. "projects/<slug>" opens a shared project tag: notes any agent filed under that box when saving, collected across sources — the pattern for cross-agent handoffs (write with that box, read it back here). Unknown or empty boxes return an empty result listing the boxes that exist; never an error.
pageNoOptional 1-based page for a box open. Each box open returns page_size facts and a total; pass page: 2 to continue a long box (project threads, big namespaces). Ignored without box.
sinceNoOptional delta cursor for a box open ("YYYY-MM-DD" or an ISO timestamp): return only notes newer than this. Every box open returns latest (the newest note timestamp); store it and pass it back as since on the next open to read just what changed. Ignored without box.
detailNoOptional box-open verbosity. Default compact truncates long notes and marks them truncated: true; pass "full" to read whole notes. Ignored without box.
sectionsNoStrict page filter on the composed profile document: the response contains exactly the pages named here, nothing else. Omit for the profile overview (facts, boxes, sources, docs), only on an explicit profile review request. Pages: identity, preferences (interaction rules), integrations, imports, agents (connected agents), summary, soul (voice and personality), context (current focus). Pages of the composed document, not storage: to open stored memories use box; to filter by author use search with source.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
boxesNoTable of contents: category, source and project boxes.
linkedNoFalse when no Configure user is resolved for this session.
sourcesNo
identityNo
top_factsNoHighest-value facts, each prefixed with its category id in brackets, and the source that saved it.
truncatedNo
connectionsNo
changesSinceNoMemories written after the synthesized summary was generated, so a stale summary is paired with what changed.
integrationsNo
truncated_boxesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint the description discloses real behavioral traits: the overview is budget-bounded and sets 'truncated' naming the box ids to open, sections are strict pages, box opens return ONE PAGE with a total requiring repeated calls with page: 2, 3, and unknown boxes return a clean empty result rather than an error. These are non-obvious operational facts the annotations do not carry.

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 purpose then cleanly organized into three numbered modes, and every mode carries actionable detail. It is long (~350 words) and slightly redundant, mentioning configure_profile_search for lookups twice and re-describing return fields the output schema already covers, which costs a point.

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 5-parameter, multi-mode read tool with an output schema, the description covers mode selection, pagination, truncation, empty-box handling, and auth failure. Nothing an agent needs to call it 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 description coverage is 100%, so the per-parameter semantics already live in the schema and a 3 baseline applies. The description nonetheless adds interaction semantics the schema does not (how box/page/since form a pagination loop, that sections are exclusive of box, that detail defaults to compact with truncated marking), so it exceeds the baseline.

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?

The opening sentence states a specific verb and resource ('Read the current user's approved profile') and the body enumerates three concrete access modes (no-arg overview, sections, box). It repeatedly and explicitly distinguishes itself from configure_profile_search and configure_connect, so an agent can route without opening the schema.

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 when/when-not guidance: the no-arg overview is gated on an explicit review request, personalized help routes to configure_profile_search with a concrete query, and point lookups/filtering route to search. It even names the fallback (configure_connect) for the auth-challenge case, leaving nothing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources