Configure Memory

Mints the Configure link that fixes access for the current user — sign-in, app connect, or permission grant. This is the tool for two situations: a Configure tool result says authorization_required (the user is not signed in), or the user asks to sign in or connect an app. The user's data exists behind sign-in, so "I have nothing on you" would be inaccurate in that state; what serves the user is knowing sign-in is the blocker and having the returned link, on its own line where it is easy to click. Retrying the failed call returns the same result until the user has signed in. Links exist only as this tool mints them — a hand-built link fails — and when a tool result already carries a link, that link is the one the user needs (minting another creates a second, competing session). Not the first call of a conversation (that is configure_profile_read), and not the fix for error -32009 (that is configure_profile_commit). For a signed-in user: app (gmail, calendar, drive, notion, sheets) connects or reconnects that app — returns status connect_app, a link, and whether it is already connected — and capability (like gmail:send) covers a single missing permission (status permission_needed). Bringing memories in from another assistant is NOT a connect action: this tool does not do it, and a bare "connect Configure" from a signed-in user needs no argument at all — omit app unless the user names a specific app to connect. Configure derives the requester from authenticated agent metadata or MCP transport metadata; the client field is a legacy fallback hint for an unauthenticated headless client only.

Close out a Configure-profile-backed turn by submitting bounded turn evidence and, optionally, durable memories worth keeping. Error -32009 (commit_required) from any configure tool is resolved ONLY by this call: commit, then retry the blocked call — never configure_connect, which is for sign-in. Call it at turn end even when you learned nothing durable: reads and searches created obligations regardless, and an empty commit with a one-line summary clears them. The runtime usually calls this for you after a profile read; call it yourself only when your host requires manual write-back. Prefer configure_profile_remember for a single fact the user explicitly stated; use commit to clear the obligation created by a configure_profile_read or configure_profile_search and to save memories drawn from the whole turn. Evidence is minimal: at most the specific user statements that support each memory, plus toolResults — never conversation history; memories are durable user facts, preferences, or intentions rather than provenance or assistant replies. Returns the obligations it cleared and any memories written (id, source, marker). Additive: it only records what this turn learned. It never deletes or overwrites existing memories, and never emails, posts, or publishes anything on the user's behalf.

Delete the user's memories that YOU saved or imported. WHICH to delete: if you hold an id, pass id ("mem_..."); if you do NOT have an id and the user names a topic, pass match with a word the memory contains (match: "nursing") and forget finds and deletes your matching memories itself, no search first. HOW: pass reason "user_request" whenever the user wants it gone for good or says never mention it again (this suppresses the content from re-saving and re-importing); use the default correction only for fixing your own mistake. A match previews first: it returns a count and the matching memories and deletes NOTHING until you call again with confirm: true, so review and confirm only what the user meant. import_id (from configure_profile_import) retracts one whole import; scope ("imports", "saved", "all") clears everything of yours at once. Pass exactly one selector. Reach is your own writes only: never another agent's memories, never an import the user ran themselves, never the profile's settled facts, and this deletes memories only, never the Configure account. An id outside your reach returns a clean not-found, not an error. Deletion is permanent for your copy. Returns the deleted memory id and which source it lived under.

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 b…

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/<slug>") 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.…

Save one explicit, durable fact the user stated about themselves so any Configure-connected agent the user allows can use it in future conversations. Use it when the user asks you to remember something or clearly signals a fact is for keeps (a stable preference stated for future use, an ongoing goal); a detail mentioned in passing is not a request to persist it — when intent is unclear, ask before saving. Save one clear fact per call. Its scope is one stated fact: bulk pasted material, message arrays, one-off task context, and anything the user did not actually say fall outside it — configure_profile_import handles bulk context and configure_profile_commit handles turn-level inference. To save memories inferred from a whole turn rather than a single stated fact, use configure_profile_commit instead. Your own work is not a fact about the user: what you built, shipped, debugged, or are tracking belongs on the shared project shelf, so file it with box "projects/<slug>" for the next agent to read back, or leave it out. Optionally file the fact into a box (a shelf within your namespace) with the box argument: reuse an existing box id from the profile table of contents when one fits, otherwise pass a short new lowercase name and it is created on the spot. Writes under your own server-resolved agent namespace (identity is resolved from the authenticated session rather than from arguments) and returns the stored memory id and source. Additive: it only saves what 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 this when the user asks to save several facts at once, or approves a list of facts you proposed. Saves each entry as a separate memory in the user's Configure profile, in one call. Send only facts the user asked to save or approved, each a short standalone statement about the user. If the user asks to review first, show the list and wait for their approval before calling. Use configure_profile_remember for a single fact. Accepts 1 to 100 facts per call, up to 1,000 characters each and 20,000 in total; send a longer approved list as several calls. It is not for passwords, keys, payment or health details, government identifiers, identity documents, sensitive personal attributes (race, religion, politics, sexuality, biometrics or genetics), or other people's personal data; the server's pattern checks are a backstop, not a complete filter, so these are left out before calling. Optional box files a fact under a category. Additive: it never changes or deletes existing memories. Returns a result for each entry and counts of saved, already_saved, refused and failed. Report those counts accurately, retry only failed entries, and never say the whole list was saved when some entries were refused or failed. Use configure_profile_import instead when the user supplies raw material rather than a list of facts: a note, a document, or an export from another assistant.

Search or list permitted attributed profile memories/facts for the current user. Use this for personalized help, targeted retrieval, source-specific questions, or exact memory/fact lookup. For personalized help, pass a concrete query about the current task and relevant filters when known; no overview is needed first. Omit query or pass "*" only when the user asks to list saved memories, narrowing by the requested source, category or date when specified. For "what does <source> know about me?", pass query "*" plus source, e.g. "tempo" or "chatgpt". To search inside one category from configure_profile_read's table of contents, pass box with that box id, e.g. "work"; box narrows to the settled category facts and composes with query. For relative-date questions, resolve dates first and pass from/to; compact results may include snippets. Pass detail "full" when complete result text or inspectable metadata matters. Results from an import also carry imported_by_agent and import_id, which is what configure_profile_forget takes to retract that whole import.

Share one Configure project without making a copy. Four modes with different stakes — action "list" only inspects (grants and open counts, changes nothing); every other mode changes access outside this conversation and needs the user's explicit go-ahead for that specific change. action "share" grants a named person (email or phone) read access, write only when the user explicitly grants it; "share" with mode "link" mints a public read-only link — confirm the user wants it public; "revoke" with grant_id removes one grant, and "revoke" WITHOUT grant_id unshares the whole project — confirm which of the two the user means before calling. Link tokens are shown once and never appear in grant listings.