Bring saved project decisions, preferences and goals into your next AI task. Configure keeps user-chosen context in a persistent, searchable profile with OAuth, explicit saves and user-provided imports.
Scored across 9 tools
The memory-write cluster (configure_profile_remember, remember_many, import, commit) all persist memories and their boundaries require lengthy prose to distinguish, which is itself a sign of overlap. The read/search pair is cleaner but still needs explicit 'use X instead' guidance to keep agents from misselecting.
Every tool uses lowercase snake_case with a consistent configure_ prefix and clear verb (connect, commit, forget, import, read, remember, search, share). The pattern is highly predictable across the whole set.
Nine tools is well within the reasonable range for a profile/memory server. It is slightly heavy on write paths (four tools that all persist memories) that could arguably be consolidated, but nothing feels redundant enough to be a problem.
Coverage spans auth (connect), read/search, single and bulk writes, import, delete (forget), and project sharing — a fairly complete lifecycle. The main gap is an explicit update/edit-memory operation, though delete-plus-recreate can work around it.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | Optional app to connect or reconnect for an already signed-in user. This is for third-party apps only; it does not bring memories in from other assistants (that is not a connect action — see configure_profile_import). | |
| client | No | Legacy fallback handle for an unauthenticated headless client whose transport supplies no identity. Never overrides an authenticated agent. | |
| purpose | No | Optional one-line reason shown to the user on the permission page, such as "so I can send the follow-ups you approve". Used with capability. | |
| capability | No | Optional specific permission to request when the user has an app connected but not this capability (the profile read's integrations map shows which capabilities each connector has). For example, when Gmail is connected read-only and you need to send, pass capability "gmail:send". Returns status permission_needed with a link that asks the user for exactly that permission and why. Prefer this over app when only a capability (like send) is missing. | |
| client_name | No | Legacy display hint for an unauthenticated headless client. Never overrides registered agent metadata. |
| Name | Required | Description |
|---|---|---|
| app | No | |
| status | Yes | connect_app, authorization_required, session_probe_required, or permission_needed. |
| connected | No | |
| capability | No | |
| connect_url | No | Server-minted link where the user acts. Minted per session: only this exact URL works; a retyped or shortened one fails. |
| instructions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that retrying returns the same result until sign-in completes, that links exist only as this tool mints them (hand-built links fail), and that minting a second link when a result already carries one creates a competing session. It also explains how the requester identity is derived (agent/MCP metadata, with client as legacy fallback).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose and the two triggering situations before the edge cases. It is dense and reads as a single long paragraph, but nearly every sentence carries routing or behavioral content rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter tool with an output schema, the description supplies what the schema and annotations cannot: when to call it, when not to, the status values to expect (connect_app, permission_needed), and identity-derivation behavior. Nothing needed 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage the baseline is 3, but the description adds real routing meaning: omit app unless the user names a specific app, prefer capability over app when only one permission is missing, and that client/client_name are legacy fallbacks that never override authenticated metadata. It reinforces rather than merely restates the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Mints the Configure link that fixes access") and immediately scopes it to three concrete outcomes: sign-in, app connect, or permission grant. It explicitly differentiates from siblings, naming configure_profile_read (first call) and configure_profile_commit (fix for -32009) as the tools this is NOT.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit triggering conditions: a Configure tool result saying authorization_required, or the user asking to sign in/connect an app. It also states exclusions (not the first call of a conversation, not the fix for error -32009, not for importing memories), and clarifies the signed-in app vs capability branches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| read_id | No | Optional read id returned by a prior configure_profile_read or configure_profile_search obligation; pass it to tie this commit to that specific read. | |
| memories | No | Optional durable memory candidates to save, one clear fact per entry. Only include durable user facts, preferences, or intentions; do not summarize provenance, the conversation, or assistant replies. | |
| messages | No | Optional minimal evidence to clear read-backed commit obligations: at most the one or two user statements that directly support each saved memory. Never send conversation history or any messages beyond those supporting statements. | |
| toolResults | No | Optional bounded tool result evidence, each with toolName and content, used as evidence to clear read-backed commit obligations. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| memories | No | |
| committed | No | |
| obligations | No | Read obligations this commit cleared. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: additive-only semantics, never deletes or overwrites, never emails/posts/publishes, and describes the return payload (obligations cleared, memories written with id/source/marker). These traits are consistent with destructiveHint=false and readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and error-resolution rule, and most sentences earn their place, but the evidence-minimality rule is stated twice (once in prose, once per-parameter) and the parameter guidance slightly duplicates the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be detailed, yet the description still summarizes them. It covers obligations, the error path, evidence bounds, and additive semantics — everything needed to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description reinforces the constraints on each parameter: read_id ties the commit to a specific read obligation, memories must be durable facts not provenance, and evidence is limited to supporting user statements plus toolResults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Close out a Configure-profile-backed turn by submitting bounded turn evidence and, optionally, durable memories') and distinguishes itself from siblings by naming configure_connect and configure_profile_remember with the conditions that select each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly covers when to call (turn end, even with nothing learned, because reads/searches create obligations), when not to (only when the host requires manual write-back; the runtime usually handles it), the -32009 resolution path, and the alternative (configure_profile_remember for a single stated fact).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | One memory to delete, by the id returned when it was saved (format "mem_...", also shown on entries in your own source box). Use exactly one selector: id, import_id, or scope. | |
| date | No | Optional. The memory's date ("YYYY-MM-DD") if known, from the saved path or entry; providing it makes the delete a direct lookup instead of a namespace scan. | |
| match | No | Selector. Words a memory contains, e.g. "nursing" or "coffee". Finds YOUR OWN matching memories and deletes them, so you do not need a separate search to get ids first. A match WITHOUT confirm:true returns a count and preview and deletes nothing; call again with confirm:true to delete. Reach for this the moment a user says "delete the X stuff" and you do not already hold ids. | |
| scope | No | Delete everything of yours in one call, instead of one id at a time. "imports": every memory you brought in through configure_profile_import, including older imports that predate import ids. "saved": everything you saved with remember or commit. "all": both. Only your own writes are ever touched, so this can never reach another assistant's memories or the profile's settled facts. | |
| reason | No | Optional, default "correction". Use "user_request" ONLY when the user explicitly asked you to remove this and not bring it back (for example "delete that" or "never call me that again") — it additionally suppresses the same content from every source and blocks it from being re-saved or re-imported. Use "correction" (or omit) when you are fixing your own mistake or retracting something stale. | |
| confirm | No | Only with match. Omit or false to preview (count + the memories that match, deletes nothing). Set true to delete the matched memories. Preview first unless the user was unambiguous. | |
| import_id | No | Optional, and used instead of id. The import_id returned by configure_profile_import: retracts every memory that import created, in one call, instead of one delete per memory. Only entries from an import you performed are touched. |
| Name | Required | Description |
|---|---|---|
| id | No | The id of the deleted memory — the confirmation the caller acts on. |
| error | No | Present when the id was malformed or not found in your namespace. |
| match | No | The match words this call used, echoed back. |
| deleted | Yes | Whether anything was removed by this call. False on previews and no-matches. |
| matched | No | For match-based forgets: how many memories matched. |
| message | No | |
| preview | No | Memories a match would delete; nothing is deleted until confirm is true. |
| deleted_ids | No | Ids of the memories a confirmed match deleted. |
| deleted_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, readOnlyHint=false and idempotentHint=false, but the description goes well beyond them: reach is limited to your own writes (never another agent's memories, a user-run import, or settled profile facts), match deletes nothing until confirm:true, user_request suppresses re-saving/re-importing, and an out-of-reach id returns a clean not-found rather than an error. These are material behavioral facts not encoded in structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the purpose and then organized around WHICH/HOW selectors, so structure is strong and most sentences carry operative detail. It is dense and longer than strictly needed (some selector semantics repeat what the schema states), keeping it just below the top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, seven-parameter tool with an output schema present, the description covers the risky decision points — reach, preview/confirm, suppression, selector exclusivity — without redundantly explaining return values. An agent has everything needed to invoke it safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 each parameter, giving a baseline of 3. The description adds genuine extra meaning — the one-selector exclusivity rule, the confirm-gated preview semantics of match, the re-save suppression of user_request, and the reach boundary on import_id — so it exceeds the baseline rather than merely restating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb (Delete) and a precisely scoped resource (the user's memories that YOU saved or imported), immediately bounding reach. This cleanly separates it from siblings like configure_profile_remember, configure_profile_import, and configure_profile_search without needing their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit selection logic: use id when you hold one, match when the user names a topic, import_id to retract a whole import, scope to clear everything at once, and 'pass exactly one selector'. It also states when to use reason 'user_request' vs 'correction', and that a match must be previewed and confirmed — the full when/when-not decision tree is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| box | No | Box the note was filed under. |
| error | No | |
| saved | No | |
| memory | No | |
| source | No | |
| distilled | No |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| box | No | Optional 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. | |
| page | No | Optional 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. | |
| since | No | Optional 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. | |
| detail | No | Optional box-open verbosity. Default compact truncates long notes and marks them truncated: true; pass "full" to read whole notes. Ignored without box. | |
| sections | No | Strict 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. |
| Name | Required | Description |
|---|---|---|
| boxes | No | Table of contents: category, source and project boxes. |
| linked | No | False when no Configure user is resolved for this session. |
| sources | No | |
| identity | No | |
| top_facts | No | Highest-value facts, each prefixed with its category id in brackets, and the source that saved it. |
| truncated | No | |
| connections | No | |
| changesSince | No | Memories written after the synthesized summary was generated, so a stale summary is paired with what changed. |
| integrations | No | |
| truncated_boxes | No |
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.
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.
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.
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.
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.
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.
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/" 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.
| Name | Required | Description | Default |
|---|---|---|---|
| box | No | Optional. The namespace box (shelf) to file this under. TWO KINDS. (1) A topic box, for facts about the user: "work", "contacts", "health". (2) "projects/<slug>", the shared handoff shelf, for notes written for OTHER AGENTS rather than about the user — status, handoffs, and what you did on a shared piece of work. Work called "billing-migration" goes to box "projects/billing-migration". Reuse an existing box id from the profile table of contents when one matches; otherwise a short new lowercase name creates that box instantly. Omitted files it under "other". | |
| fact | Yes | Required. The single durable fact to store, phrased as a concise standalone statement about the user (for example "Prefers vegetarian restaurants"). One fact per call; do not batch multiple facts or paste transcript text. | |
| kind | No | What kind of note this is, for "projects/<slug>" notes. Set it whenever you are stuck or need something back from another agent: "blocker" (you cannot proceed) and "question" (you need an answer) are the two that get tracked as OPEN until another note resolves them. A note with no kind is never reported as outstanding, however urgent its text. This is not configure_profile_import's kind, which is a different vocabulary for how a dump is processed; and an unrecognized value here is never fatal, the note is saved unclassified and the result names the value that was ignored. | |
| reply_to | No | Optional. Memory id ("mem_...") of a note in the SAME box this one answers. Ids appear on notes when you open a project box. | |
| resolves | No | Optional. Memory id ("mem_...") of a question or blocker in the SAME box that this note closes, which is what stops it being reported as open. |
| Name | Required | Description |
|---|---|---|
| box | No | Box the note was filed under. |
| error | No | |
| saved | No | |
| memory | No | |
| source | No | |
| distilled | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) by disclosing that identity is resolved from the authenticated session rather than arguments, that the call is purely additive and never deletes or overwrites, that it never emails/posts/publishes, and that it returns the stored memory id and source. These are the exact behavioral facts an agent needs before committing a write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded — purpose, then intent rules, then scope, then routing, then behavior — but bloated at roughly 250 words with visible redundancy: configure_profile_commit is introduced twice for effectively the same turn-level-inference case. The scope-exclusion sentence and the commit sentence could be merged without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter write tool with an output schema and annotations, the description covers everything an agent still needs: single-fact scope, unclear-intent handling, sibling routing, project-box handoff convention, namespace resolution, additive-only guarantee, and return shape. Nothing material is left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds genuine meaning: box filing rules (reuse an existing box id, a short new lowercase name creates one, omission defaults to "other") and the crucial note that no identity argument exists because the namespace is session-resolved. It does largely restate the schema's box/kind semantics, which caps it below 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb (save), resource (one explicit durable fact the user stated about themselves), scope (one fact per call), and the downstream consumer (any Configure-connected agent). It actively distinguishes itself from siblings by naming configure_profile_import for bulk material and configure_profile_commit for turn-level inference, so an agent can route correctly without opening another schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (user asks to remember, or clearly signals a fact is for keeps) and when-not (passing details, bulk pasted material, one-off task context, anything the user didn't say), plus an escalation rule (ask when intent is unclear). It also names the alternatives for adjacent cases: configure_profile_import for bulk, configure_profile_commit for inferred/turn-level memories, and the projects/<slug> box for the agent's own work notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 25 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.
| Name | Required | Description | Default |
|---|---|---|---|
| facts | Yes | Short standalone facts the user asked to save or approved. At most 20,000 fact characters in total. |
| Name | Required | Description |
|---|---|---|
| counts | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=false. The description adds substantial non-obvious behavior: additive semantics ('never changes or deletes existing memories'), batch limits (1-25 facts, 1,000 chars each, 20,000 total), an explicit sensitive-data exclusion list, and a warning that server pattern checks are a backstop rather than a complete filter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the when-to-use condition and then packs constraints and exclusions into dense, purposeful sentences. It is long but nearly every clause carries a distinct constraint; only the return-value recount is slightly redundant given the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with an output schema present, the description covers the approval gate, size limits, exclusion policy, additive behavior, and error-handling guidance ('retry only failed entries, and never say the whole list was saved when some entries were refused or failed'). Nothing an agent needs to invoke or report on this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 'fact' and 'box' including the category and length constraints. The description reinforces intent ('each a short standalone statement about the user', 'box files a fact under a category') but adds little beyond what the structured fields already say, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Saves each entry as a separate memory in the user's Configure profile, in one call') and explicitly distinguishes itself from siblings: configure_profile_remember for a single fact and configure_profile_import for raw material. An agent can route correctly without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit triggering conditions ('user asks to save several facts at once, or approves a list of facts you proposed'), a pre-call approval workflow ('show the list and wait for their approval'), and named alternatives for the single-fact and raw-material cases. When-to-use and when-not are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional inclusive end date filter in YYYY-MM-DD format for date-attributed results. | |
| box | No | Optional category box id from configure_profile_read's table of contents, such as "work". Filters to the settled facts in that box and composes with query; unknown or empty boxes return empty results, never an error. | |
| from | No | Optional inclusive start date filter in YYYY-MM-DD format for date-attributed results. | |
| limit | No | Optional maximum result count. The backend enforces a default and hard cap. | |
| query | No | Optional search query. Omit or use "*" to list bounded permitted attributed profile results, for example with a source filter. | |
| detail | No | Optional result detail. Defaults to compact, which truncates long memory text. Full returns the complete text plus markers. Every result at either detail carries id, source, written_by, and saved_on (a YYYY-MM-DD date that matches the from/to filters). | |
| source | No | Optional explicit source handle filter, such as "tempo", "chatgpt", or "import:chatgpt". Source-box ids from configure_profile_read's table of contents ("agents/<name>", "imports/<provider>") are also accepted and mean the same source. This is not a path or connector and there is no magic self value. |
| Name | Required | Description |
|---|---|---|
| results | Yes | Matching attributed memories, each with id, text and source. |
| guidance | No | What to do next when results are thin: a status, a short explanation, and a suggested next action. |
| visibleSources | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: unknown/empty boxes return empty results rather than errors, the backend enforces a default and hard cap on limit, compact truncates long text while full returns complete text plus markers, and import results carry imported_by_agent/import_id. It stops short of a fully rich operational picture (e.g. ordering, pagination), so 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and then organized by use case, with each sentence carrying actionable routing or parameter guidance. It is dense but not padded; the trailing sentence about configure_profile_forget's import retraction is slightly tangential yet still useful cross-tool context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail needn't be restated, and annotations cover the safety profile. Between the description, 100% schema coverage, and the output schema, an agent has everything needed to call this correctly across the described scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description nonetheless adds non-obvious usage semantics: pass '*' with a source for source-scoped questions, box composes with query, resolve relative dates before passing from/to, and detail 'full' when complete text or metadata matters. It clarifies intent beyond the schema's field definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search or list permitted attributed profile memories/facts for the current user') and immediately scopes it against siblings by referencing configure_profile_read's table of contents and configure_profile_forget's import id. An agent can distinguish this from the other configure_profile_* tools without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly enumerates when to use it: personalized help, targeted retrieval, source-specific questions, exact lookup, listing, and relative-date questions. It also names the alternative (configure_profile_read for the table of contents) and gives concrete call recipes such as query '*' plus source for 'what does <source> know about me?'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
configure_connectconfigure_profile_commitconfigure_profile_forgetconfigure_profile_importconfigure_profile_readconfigure_profile_rememberconfigure_profile_remember_manyconfigure_profile_searchconfigure_project_share
Add one secure layer between your agents and this server.