Mitosis agent-memory platform: pricing, docs search, platform status, agent skills. No auth.
Scored across 17 tools
cortex_ask, search, and cortex_recall all retrieve from the same private memory, making them hard to distinguish in practice; search and cortex_ask are especially close. fetch and cortex_manifest add further retrieval boundaries that overlap with the search cluster. The remaining tools are mostly distinct, but the redundant search surface creates real selection ambiguity.
The cortex_* tools are consistently snake_case verb_noun, but the overall set mixes conventions: plain fetch/search, get_platform_status/get_pricing, search_docs, and list_skills. Three different verbs for the same core action (ask/search/recall) and the adjective-style cortex_connectable_sources further reduce predictability.
At 17 tools, the set is slightly heavy for what is essentially a personal-memory API with some product-info helpers bolted on. Several tools in the retrieval family could be consolidated, though most individual tools have a defensible purpose and the count is not extreme.
The surface covers ingestion, search, retrieval, remembering facts, and enrichment choices, but there is no delete/forget or disconnect operation for memories or sources, and updates are only implicit via re-ingestion. Product status, pricing, docs, and skills coverage is fine but belongs to a separate concern that is only partially developed.
Searches the user's real, private memory — the email, calendar, files, contacts and notes they have connected, plus facts agents have saved — fusing vector, full-text and graph retrieval with provenance. This is their current data on their work, schedule, contacts, projects, documents, decisions and history, which training data and session context do not contain. Results include citations (universal ids), freshness, and cited_graph_url, a deep link showing the cited nodes highlighted in the user's own graph. A later cortex_remember links to what was retrieved here. Retrieval returns nearest matches rather than a thresholded set, so a question whose answer lives in an unconnected source comes back with the closest thing in the memory instead of with nothing. A source_gap object in the result names that case: the memory holds data, but the source that would answer this question is not connected. It lists those sources, what each answers, and one connect link, on cta. A possible_source_gap object is the conditional form — results exist but may be near-misses rather than an answer. A result carrying neither means the answer is genuinely absent from the memory rather than merely unretrieved.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10). | |
| since | No | RFC3339 lower bound on item time. | |
| until | No | RFC3339 upper bound on item time. | |
| question | Yes | Natural-language question or search query. | |
| source_table | No | Restrict to one source table, e.g. gmail_messages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining that retrieval returns 'nearest matches rather than a thresholded set,' and detailing the 'source_gap' and 'possible_source_gap' objects, including what each means and the presence of a 'cta' link. It also clarifies the meaning of a result carrying neither gap. These behavioral traits are not captured by the readOnlyHint or idempotentHint annotations.
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?
The description is lengthy but information-dense; every sentence contributes unique value, such as explaining citations, freshness, and the source_gap mechanism. It is front-loaded with the core purpose and then details edge cases. Some redundancy exists (e.g., the private memory concept is repeated), but overall it is well-structured for a complex tool.
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 the tool's complexity and lack of an output schema, the description is remarkably complete. It covers the retrieval behavior, result contents (citations, freshness, cited_graph_url), the meaning of source_gap and possible_source_gap, and even the semantics of a result without them. No significant gaps remain for an agent to decide when and how to invoke the tool.
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 descriptions cover 100% of the parameters, so per the rubric the baseline is 3. The tool description does not elaborate on individual parameters (e.g., it doesn't explain how 'limit' or 'source_table' affect results beyond what the schema already states). It adds no parameter-specific semantics, but the baseline is acceptable given the high schema coverage.
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 description begins with 'Searches the user's real, private memory' and enumerates specific sources (email, calendar, files, contacts, notes) and retrieval methods (vector, full-text, graph). This clearly identifies the tool's specific verb and resource, and its focus on private memory with provenance distinguishes it from general search tools like 'search' or 'search_docs', even without naming them.
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?
The description provides clear context: this tool accesses the user's connected private data, 'which training data and session context do not contain.' It implies when to use it (when the answer lies in the user's memory) but does not explicitly name alternatives or exclusion criteria, such as 'for general web search use search instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record what the user wants Mitosis to pull out of a data source. A newly saved source WAITS: it is stored and searchable, but nothing is extracted from it until the user answers. When any save/ingest result carries choice.choice_required: true, ask the user its question and present EXACTLY two options: "Standard" (Mitosis extracts the people, companies, projects, topics, dates, and how they connect) or "Describe your goal" (the user says what they want extracted). Then call this tool with their answer. Never choose for the user and never infer an answer from silence. After cortex_list_goals, pass goal_ids to run those saved recipes on this source now. A brand-new goal is enough: Cortex writes the extract contract and starts extracting. Call it without choice to read the current state.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | A new goal, in the user's words. Required with describe_goal unless goal_ids is set. | |
| choice | No | "standard", or "describe_goal" together with `goal` and/or `goal_ids`. Omit to read the current state. | |
| feed_key | Yes | The source, from `choice.feed_key` in the save/ingest result. | |
| goal_ids | No | Saved goals from cortex_list_goals to run on this source. | |
| idempotency_key | No | Optional retry key; the same key never records twice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=true, and the description adds meaningful behavioral context: the source 'WAITS' until the user answers, extraction does not happen automatically, and the idempotency key behavior is implied via schema. The description also clarifies the two modes (standard/describe_goal) and the non-inference rule, which goes beyond the annotations.
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?
The description is long but every sentence carries necessary operational detail. It is front-loaded with the core purpose, then explains the trigger, options, and alternatives. While slightly dense, it avoids redundancy and is well-organized for an agent to parse.
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 the tool's complexity (5 params, two modes, integration with cortex_list_goals), the description covers the main decision points: when to call, what to pass, and the read-only state. It does not describe the output format, but no output schema exists and the focus is on recording intent. The description adequately prepares an agent to use the tool 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 the baseline is 3. The description adds context beyond the schema by explaining how parameters interact: `choice` determines mode, `goal`/`goal_ids` are used with describe_goal, and `feed_key` comes from the save/ingest result. This clarifies the conditional relationships that the schema alone does not convey.
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 description states a specific verb ('record') and resource ('what the user wants Mitosis to pull out of a data source'), and clearly distinguishes its role from siblings like cortex_list_goals and cortex_ingest. The flow for when to call it is explicit, making its purpose unambiguous.
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?
Provides explicit when-to-use guidance: triggered by choice_required=true in save/ingest results, and instructs to present exactly two options. Also explains the alternative for running saved goals (cortex_list_goals) and the read-only mode when called without `choice`. It even states behavioral rules ('Never choose for the user'). This is comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which sources this memory could connect but hasn't yet — each with what it would make answerable, routing tags, and a connect link for the user. This is what explains a cortex_ask result that came back empty or off-topic: the source holding that answer is listed here rather than connected. Data connected into this memory stays searchable, cited, and available across every agent and session the user works in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this read-only, idempotent, and non-destructive. The description adds context about the output (what each source would make answerable, routing tags, connect links) and the broader behavior that connected data remains searchable and available across sessions. This goes beyond the annotations without contradicting them.
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?
The description is three sentences, each earning its place: what it lists, why it matters (explains cortex_ask results), and the broader data persistence context. No filler or redundancy.
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-parameter read-only tool with no output schema, the description covers the purpose, usage context, and key output fields. It lacks an exact output structure specification, but given the low complexity and clear annotations, it is sufficiently complete.
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?
The tool has zero parameters, so there is nothing to document. Schema description coverage is 100% vacuously, and the description correctly focuses on the tool's output and purpose. A baseline of 4 is appropriate for a parameterless tool.
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 description clearly states the tool lists sources a memory could connect to but hasn't yet, including what each source would make answerable, routing tags, and connect links. It also differentiates from sibling tools like cortex_ask by explaining that it helps diagnose empty or off-topic results.
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?
The description explicitly mentions when to use this tool: when a cortex_ask result comes back empty or off-topic, pointing to this tool as the explanation. This provides concrete usage context, though it does not explicitly state when not to use it or name other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The connect link for one memory source, by id — email and calendar (google-workspace), WhatsApp chats, GitHub, Notion, or file uploads. Returns the canonical mitosislabs.ai dashboard page where the user can connect that source to their memory, as a ready markdown link. Source ids appear in unconnected_sources on cortex_ask results and in cortex_connectable_sources; which source fits a question is the caller's judgment, made from each entry's answers and tags. link_text names, in the user's own words, what connecting answers — it becomes the connect page's title. Connecting itself is an authorization the user performs on that page; this tool only returns the link.
| Name | Required | Description | Default |
|---|---|---|---|
| link_text | No | Link text naming what connecting answers, in the user's words. Becomes the connect page title. Omit for a generic label. | |
| source_id | Yes | Source id exactly as listed, e.g. google-workspace, github, notion. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that connecting is an authorization the user performs on the returned page and that this tool only returns the link, adding nuance beyond the readOnlyHint and idempotentHint annotations. It also clarifies how link_text is used, providing useful behavioral detail.
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?
The description is moderately sized but well-structured, leading with the core purpose and then providing supplemental context about source ids, link_text, and the tool's limited action. Every sentence contributes useful information without unnecessary repetition.
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 the simple nature of the tool and the absence of an output schema, the description adequately explains the return value (a markdown link), the origin of parameters, and the boundary between this tool and the user's authorization step. It is complete enough for an agent to select and invoke it 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?
While the schema already documents both parameters at 100% coverage, the description adds meaning by explaining that source_id must be exactly as listed and appears in specific other tool outputs. It also elaborates that link_text becomes the connect page title, going beyond the schema's description.
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 description clearly states the tool returns a ready markdown link for a memory source by id, listing supported source types. It distinguishes itself from sibling tools by emphasizing this is a link-returning tool, not the actual connection action.
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?
The description explains that source ids appear in unconnected_sources and cortex_connectable_sources, and that the caller judges which source fits from answers and tags. It clarifies that the tool only returns the link while the user performs authorization separately, providing clear context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push a document into this memory so its text becomes searchable. Pass the file text as content with a filename, or several items in files (each with name and content). Default feed is local_files. The result may carry choice.choice_required: when that is true the source is stored and searchable but waiting for the user to pick Standard or Describe your goal; record that answer with cortex_choose_enrichment. This server cannot read a local filesystem — paths belong on the stdio MCP (mi-cortex-mcp).
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | Feed identity (schema ext_<feed>). Letters, digits, underscore. Default local_files. | |
| files | No | Several documents: [{name, content}, ...]. | |
| title | No | Override title when ingesting a single file. | |
| content | No | Document text. Required with filename. | |
| filename | No | Name for inline content (required with content). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only, not open-world, idempotent, and non-destructive. The description adds important behavioral details: the possibility of choice_required (source stored but waiting for enrichment) and the server limitation (cannot read local filesystem). This goes beyond what annotations provide, though it doesn't mention rate limits or auth.
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?
The description is concise, with the primary action and key parameters front-loaded. The additional details about choice_required and filesystem limitations are relevant and not excessive. It could be slightly more condensed, but it's well-structured.
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 the tool's complexity (5 parameters, two input modes), the description covers the essential usage patterns and explains edge cases. The reference to cortex_choose_enrichment for post-ingestion actions is helpful. However, it doesn't clarify return values (no output schema), and the relationship to siblings could be more explicit.
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?
The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds minimal semantics beyond the schema, only restating the relationship between content/filename and files. No new meaning is added for parameters beyond what the schema already provides.
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 description clearly states the tool's purpose: pushing a document into memory for searchability. It explicitly describes the input modes (content+filename or files array) and the default feed. It doesn't explicitly name siblings to distinguish itself, but given the context, it's clear this is for direct document ingestion as opposed to cortex_ingest_conversation.
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?
The description provides clear guidance on when to use this tool: for pushing documents into memory. It contrasts with cortex_choose_enrichment and the local filesystem limitation, indicating when this tool is not appropriate. However, it doesn't explicitly mention alternatives like cortex_remember or cortex_ingest_conversation, leaving some ambiguity for agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ingest a conversation — the user’s messages and your full answers, verbatim — into the user’s permanent memory, where it becomes searchable and appears in their knowledge graph. Use it after an exchange where you gave a substantive answer: ingest that exchange (the user’s message + your complete reply) from the conversation in front of you. EXCLUDE, always: exchanges where you could NOT answer reliably (cannot-answer / connect-a-source replies — they describe missing data, not knowledge), tool call outputs, hidden reasoning, connect links, and anything resembling credentials or secrets. Re-ingesting the same session_id updates it instead of duplicating. Split very long conversations across calls.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Short human title for the conversation. | |
| turns | Yes | The conversation, in order. User and assistant text only — verbatim. | |
| session_id | No | Stable id for this conversation (e.g. its chat id/uuid). Reuse it when ingesting more of the same conversation so chunks upsert instead of duplicating. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, and the description reinforces this by explaining 'Re-ingesting the same session_id updates it instead of duplicating.' It adds meaningful behavioral context beyond annotations: permanent storage, searchability, knowledge graph appearance, and the requirement to ingest verbatim full answers. The exclusions also disclose exactly what will NOT be stored. No contradiction with annotations.
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?
The description is a single dense paragraph that leads with the core purpose, then covers when to use, exclusions, idempotency, and splitting. Every sentence adds necessary guidance for a tool with many caveats. While it is longer than minimal, it remains efficient and well-organized, just slightly verbose for a 10/10.
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 write-only tool with no output schema, the description fully addresses what the tool does, when to use it, what to exclude, how to handle idempotent updates, and how to manage long conversations. The combination of schema (100% parameter descriptions), annotations (idempotentHint), and description gives an agent everything needed for correct invocation.
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% with clear descriptions for title, turns, and session_id. The description adds value by clarifying 'your full answers, verbatim' (emphasizing the completeness of assistant turns) and by advising to 'Split very long conversations across calls,' which informs the agent how to use the turns/session_id combination effectively. This goes beyond the baseline schema descriptions.
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 description uses a specific verb+resource ('Ingest a conversation ... into the user’s permanent memory') and clearly states what is ingested (user messages and full assistant answers verbatim) and the resulting effects (searchable, knowledge graph). It distinguishes itself from sibling tools like cortex_recall and cortex_remember by focusing on permanent conversation storage and the exclusion of non-knowledge content.
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?
The description gives explicit when-to-use guidance ('Use it after an exchange where you gave a substantive answer') and a thorough when-not-to-use exclusion list (cannot-answer replies, tool outputs, hidden reasoning, connect links, credentials). It does not explicitly name an alternative sibling tool, but the context is strong enough to make appropriate selection clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The saved goals this office already asked Mitosis to pull out of data. Call this before choosing enrichment on a new source so you can offer those goals (the user can pick several) instead of inventing a new one. Last-used goals are first. Then pass the chosen ids as goal_ids to cortex_choose_enrichment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful context: results are ordered by last-used, and the tool is meant to be used before enrichment selection. No contradictions with annotations, and the added ordering information goes beyond what annotations state.
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?
The description is two sentences, front-loaded with the purpose and usage context. It avoids redundancy and clearly conveys the reason for calling the tool and the next step. No fluff or unnecessary details.
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-parameter, read-only list tool with no output schema, the description covers purpose, usage timing, result ordering, and how to use the results (pass ids onward). It hints at the output containing ids and the ability to pick several, which is sufficient for correct invocation.
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?
There are zero parameters, so the schema is trivially 100% covered and the baseline is 4. The description does not need to explain parameters; it adds no parameter-related info, which is appropriate for a parameterless tool.
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 description clearly states the verb 'List' and the resource 'saved goals,' and clarifies these are goals already extracted for this office. It distinguishes from siblings by explicitly positioning it as a prerequisite to cortex_choose_enrichment, making it unambiguous which tool is meant.
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 provides explicit when-to-use guidance: 'Call this before choosing enrichment on a new source so you can offer those goals... instead of inventing a new one.' It also instructs the agent on the follow-up action ('Then pass the chosen ids as goal_ids to cortex_choose_enrichment'), covering the workflow sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A table of contents for this user's memory: which sources are connected (email, calendar, docs, …), how many items each holds, and the top people, topics and projects. It is an index rather than an answer — it contains no message bodies, no dates and no content, so it establishes that a source exists without saying anything about what is in it. The content behind any entry it lists is retrievable with cortex_ask.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds valuable behavioral context: it contains no message bodies, no dates, and no content, only establishes source existence. It also points to cortex_ask for retrieval, setting accurate expectations.
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?
The description is two sentences, both adding value: the first defines the tool's contents and scope, the second clarifies its non-content nature and points to cortex_ask. Every sentence earns its place with no redundancy.
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?
Despite lacking an output schema, the description sufficiently explains what the tool returns (an index of sources, counts, top people/topics/projects) and explicitly lists what it excludes. For a no-parameter tool, this is complete and actionable.
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?
The tool has zero parameters, so the description does not need to explain any. The baseline score of 4 is appropriate, and the description contributes no parameter information because none exist.
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 description defines the tool as 'a table of contents for this user's memory' and enumerates exactly what it contains (connected sources, counts, top people/topics/projects). It explicitly contrasts with cortex_ask by noting content is retrievable there, distinguishing it from siblings.
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?
The description states it 'is an index rather than an answer' and that 'content behind any entry is retrievable with cortex_ask,' providing clear guidance on when to use this tool (overview) vs cortex_ask (actual content).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic-only vector search over the memory, returning source excerpts. Prefer cortex_ask, which also uses full-text and graph expansion; reach for this when you specifically want nearest-neighbour matches on meaning.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10). | |
| query | Yes | Search text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the search is 'semantic-only' and returns 'source excerpts', which are useful behavioral details consistent with annotations.
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?
The description is two sentences, front-loaded with purpose and usage guidance, with no wasted words. Every sentence adds value.
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 tool with only 2 parameters and no output schema, the description fully covers purpose, usage, and return type (source excerpts). It is complete and informative.
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% and both parameters have adequate descriptions in the schema (e.g., 'Search text', 'Max results default 10'). The description does not add further meaning beyond what the schema provides, so baseline 3 is appropriate.
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 description clearly states it is a 'semantic-only vector search over the memory, returning source excerpts'. It distinguishes itself from the sibling tool cortex_ask, which uses full-text and graph expansion.
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 advises to prefer cortex_ask for broader search and to use cortex_recall specifically for nearest-neighbor matches on meaning, providing clear guidance on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a fact, decision or conclusion into the memory, attributed to you. It becomes retrievable via cortex_ask immediately, in this session and every future one, from any agent the user has connected. Provenance: pass source_universal_ids from a previous cortex_ask so the fact links to its evidence. Keep each memory to ONE self-contained fact. Use this whenever the conversation produces a durable conclusion the user would want remembered — a decision, a preference, an outcome, a commitment. If the result carries choice.choice_required: true, the memories source is waiting for the user’s enrichment choice: ask choice.question, offer exactly "Standard" or "Describe your goal", and record the answer with cortex_choose_enrichment.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | e.g. 'decision', 'observation', 'task-outcome'. | |
| text | Yes | The fact or conclusion itself — one self-contained statement. | |
| confidence | No | 0..1, weights the provenance edges. | |
| source_universal_ids | No | Universal ids from a previous cortex_ask that this fact came from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses immediate retrievability ('in this session and every future one, from any agent the user has connected'), the provenance-linking expectation, the one-fact-per-memory constraint, and the conditional `choice.choice_required` follow-up flow with required answer options. This is rich behavioral context an annotation-only view would miss.
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 action, then usage, then the edge-case flow in a logical order. Every sentence carries information, though the final enrichment-handling sentence is dense and slightly extends the length.
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 mutation tool with no output schema but full annotation coverage and 100% schema descriptions, the description compensates by documenting cross-session/cross-agent effects, provenance, and the choice_required return behavior. Nothing critical is left implicit.
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 baseline is 3, but the description adds real meaning: it explains the purpose of source_universal_ids (link the fact to evidence from cortex_ask) and reinforces the 'one self-contained fact' constraint on text. It stops short of clarifying kind/confidence semantics beyond 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 ('Persist a fact, decision or conclusion into the memory') with scope (attributed to you) and distinguishes itself from cortex_ask/cortex_recall by describing persistence semantics. An agent can tell exactly what this does 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?
Gives explicit when-to-use criteria ('whenever the conversation produces a durable conclusion — a decision, a preference, an outcome, a commitment'), names the alternative path for provenance via a previous cortex_ask, and routes the conditional enrichment case to cortex_choose_enrichment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Memory health: per-source ingest and embed counts plus last sync times. Use when you need to know whether the memory is fresh or still ingesting, or when a search came back empty and you need to tell the user whether that means "no data yet" or "nothing matched".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive. The description adds the specific data returned (counts and sync times) and purpose (freshness check), which is helpful but not critical beyond annotations.
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?
Two concise sentences: first defines the output, second gives usage cases. No unnecessary words, front-loaded with key info.
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-parameter, no-output-schema tool, the description fully explains what it returns and when to use it. Nothing 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?
No parameters exist, so schema coverage is 100%. The description doesn't need to add param info. Baseline 4 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?
The description clearly states the tool provides memory health information: 'per-source ingest and embed counts plus last sync times'. It distinguishes itself from sibling tools by focusing on status rather than asking or recalling.
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 tells when to use: 'when you need to know whether the memory is fresh or still ingesting, or when a search came back empty'. This provides clear context and implies when not to use (e.g., for direct queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full contents of a single item from the user’s memory by its id. Ids come from search results. Use this when a search result looks relevant and you need the whole record rather than the excerpt.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id of an item, exactly as returned by `search`. |
| Name | Required | Description |
|---|---|---|
| id | Yes | The id that was requested. |
| url | Yes | Absolute link to this record on the user’s memory graph. |
| text | Yes | The record’s full contents as plain text. May be empty if the record has none. |
| title | Yes | Human-readable name of the record. |
| metadata | Yes | Provenance, where known. Any key may be absent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent hints. The description adds behavioral context about returning full contents versus excerpts, which goes beyond the annotations. No contradiction.
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?
Two sentences, front-loaded with the action, and no wasted words. It communicates purpose and usage guideline efficiently.
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 simple one-parameter read tool with robust annotations and an output schema, the description is complete. It provides enough context for correct invocation without needing to explain return structure.
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% with the id parameter described. The description adds extra meaning by clarifying that ids are exactly as returned by search, reinforcing correct usage.
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 description clearly states the tool retrieves a single item by id, with a specific verb and resource. It also distinguishes from sibling search by noting it returns the full record rather than an excerpt.
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 says when to use it ('when a search result looks relevant and you need the whole record') and points to the alternative search for excerpts. Also notes ids come from search results, giving clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the operational status of the Mitosis website, API, and MCP server. Use before reporting an outage or debugging connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
| service | No | Return only this service. Omit for all services. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and no destructive actions. The description adds context by specifying which services are checked, enhancing transparency without contradicting annotations.
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?
Two concise sentences with no wasted words. Action verb 'Get' front-loads the purpose, and the usage hint is immediately useful.
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 simple tool with one optional enum parameter and no output schema, the description covers purpose and usage adequately. Slight room for describing return format, but not necessary for this low-complexity tool.
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% and includes an enum with clear description. The tool description does not add extra parameter information, so baseline score 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?
The description clearly states the tool retrieves operational status of three specific services (Mitosis website, API, MCP server), distinguishing it from unrelated sibling tools like get_pricing, list_skills, and search_docs.
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?
The description explicitly advises using this tool 'before reporting an outage or debugging connectivity,' providing clear when-to-use guidance. No exclusions or alternatives are given, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current Mitosis plans, prices, credit allowances, metered rates, and add-ons. Use when comparing costs or recommending a plan.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | Return only this plan. Omit for all plans. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that data is 'current', but does not elaborate on caching, rate limits, or freshness. Acceptable but no extra value beyond annotations.
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?
Two concise sentences, front-loaded with the purpose, no redundant information. Every sentence earns its place.
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 simple read-only tool with one optional parameter and no output schema, the description adequately states what is returned and when to use it. No gaps given the low complexity.
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 has 100% coverage for the single parameter 'plan', including enum and description. The description does not add any additional meaning or clarification about the parameter, so baseline of 3 is appropriate.
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 description specifies verb 'Get', resource 'Mitosis pricing', and lists specific data returned (plans, prices, credit allowances, metered rates, add-ons). It clearly distinguishes from sibling tools like get_platform_status and list_skills.
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?
Provides explicit use case ('when comparing costs or recommending a plan'), giving clear context for when to invoke. Does not mention alternatives or when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the agent skills Mitosis publishes (backup create/list/restore/health/diff/schedule/subscribe) with links to each SKILL.md manifest.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter skills by tag (e.g. "backup", "restore", "schedule"). Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that it lists skills with links to manifests, but does not disclose additional behavioral traits beyond what annotations already convey.
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?
The description is a single, well-structured sentence that immediately conveys the purpose, examples, and result. Every word earns its place with no redundancy.
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?
The tool is simple with one optional parameter and no output schema. The description covers the key points: listing skills, including specific examples, and linking to manifests. Slightly incomplete as it doesn't note what happens if the tag filter yields no results, but adequate for a list tool.
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 parameter 'tag' is fully documented. The description does not add meaning beyond listing skill examples; it doesn't elaborate on filtering behavior not already in 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?
The description clearly states the verb 'List' and the resource 'agent skills', with explicit examples of skills and mention of links to manifests. It distinguishes from sibling tools like get_platform_status or search_docs which cover different domains.
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?
The description implies usage for listing Mitosis skills but does not explicitly state when to use versus alternatives. Sibling tools are named in context but no comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the user's own private memory — their email, calendar, documents, contacts, chat history and every fact agents have remembered — and return ranked matches with citation ids and links. This is their current data on their work, schedule, contacts, projects, documents, decisions and history, which training data and session context do not contain. Pass an id from these results to fetch to read the full record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for, in natural language. |
| Name | Required | Description |
|---|---|---|
| results | Yes | Ranked matches from the user’s memory, best first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context beyond that: it explains the scope of data searched, the output includes citations and links, and that full records require a separate fetch call. This transparency about the result shape and data coverage meaningfully supplements the annotations.
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?
The description is two sentences, front-loaded with the tool's core action and scope, and every clause adds information: the data sources, result contents, why this data is unique, and the follow-up action to read full records. There is no fluff or repetition of schema details.
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 low-complexity tool with a single parameter, rich annotations, and an output schema present, the description is largely complete. It explains what data is searched, what results look like, and how to proceed. The only minor gap is not addressing result limits or ranking criteria, but these are likely covered by the output schema or are secondary to the core purpose.
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% with one parameter 'query' described as 'What to look for, in natural language.' The description does not add new parameter-specific syntax or constraints; it merely re-states the purpose at a higher level. Since the schema already fully documents the parameter, the baseline 3 is appropriate.
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 description clearly identifies the tool as a search over the user's private memory, listing specific data sources (email, calendar, documents, contacts, chat history) and noting that it returns ranked matches with citation ids and links. This specific verb+resource scope distinguishes it from siblings like search_docs or cortex_recall, and the mention of 'deep research' in the title reinforces its distinct role.
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?
The description provides a clear usage context: use this tool to access the user's current private data that 'training data and session context do not contain.' It also gives a follow-up workflow ('Pass an id from these results to fetch to read the full record'), which helps the agent know how to proceed. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword-search Mitosis documentation and product pages. Returns ranked results with URLs. Use to answer any "how do I…" question about Mitosis.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5, max 20) | |
| query | Yes | Search terms, e.g. "connect google workspace" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that results are ranked and include URLs, consistent with annotations. No contradictions. Adds useful behavioral detail beyond annotations.
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?
Two sentences: first explains function, second advises usage. No unnecessary words. Efficient and front-loaded.
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 simple search tool with rich annotations, the description covers purpose, behavior, and usage. Missing explicit mention of pagination or error handling, but sufficient for typical use.
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% - both parameters (query, limit) are described. The description's mention of 'keyword-search' and example for query ('connect google workspace') adds marginal value beyond the schema. Baseline of 3 is appropriate.
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 description clearly states 'Keyword-search Mitosis documentation and product pages. Returns ranked results with URLs.' This gives a specific verb, resource, and outcome. It distinguishes from siblings like get_platform_status or get_pricing by noting its use for 'how do I…' questions.
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?
The description explicitly says 'Use to answer any 'how do I…' question about Mitosis,' providing clear guidance on when to use. However, it does not mention when not to use or alternatives, which is acceptable given distinct siblings.
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.
cortex_choose_enrichment3 fields changedInput schema / properties / choice / descriptionPrevious value: -"\"standard\", or \"describe_goal\" together with `goal`. Omit to read the current state."New value: +"\"standard\", or \"describe_goal\" together with `goal` and/or `goal_ids`. Omit to read the current state."Input schema / properties / goal / descriptionPrevious value: -"The user's goal, in their words. Required with describe_goal."New value: +"A new goal, in the user's words. Required with describe_goal unless goal_ids is set."Input schema / properties / goal_idsAdded value: +{
+ "description": "Saved goals from cortex_list_goals to run on this source.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}cortex_ingestcortex_list_goalscortex_choose_enrichmentcortex_connect_linkcortex_ingest_conversationcortex_connectable_sourcesfetch1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "The id that was requested.",
+ "type": "string"
+ },
+ "metadata": {
+ "additionalProperties": false,
+ "description": "Provenance, where known. Any key may be absent.",
+ "properties": {
+ "fetched_at": {
+ "description": "When Mitosis last ingested it.",
+ "type": "string"
+ },
+ "integration": {
+ "description": "Integration that supplied it, e.g. google-workspace.",
+ "type": "string"
+ },
+ "sensitivity": {
+ "description": "Sensitivity label, where the source sets one.",
+ "type": "string"
+ },
+ "source": {
+ "description": "Source table the record came from.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "text": {
+ "description": "The record’s full contents as plain text. May be empty if the record has none.",
+ "type": "string"
+ },
+ "title": {
+ "description": "Human-readable name of the record.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Absolute link to this record on the user’s memory graph.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "text",
+ "url",
+ "metadata"
+ ],
+ "type": "object"
+}search1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "results": {
+ "description": "Ranked matches from the user’s memory, best first.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Opaque record id. Pass it to `fetch` to read the full record.",
+ "type": "string"
+ },
+ "title": {
+ "description": "Human-readable name of the record.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Absolute, user-openable link: the original item where the source exposes one, otherwise a link to the record on the user’s memory graph.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}fetchsearchYour company's brain for AI agents. Cited, permission-aware knowledge across every system.
Shared knowledge base for AI agents. Semantic search across agents, no setup required — just a URL.
Search public agent questions and sourced findings, browse agents, and read the onboarding guide.
One shared brain for your AI coding agents: team memory, agent Q&A, tasks, and file claims.
Add one secure layer between your agents and this server.
