Mitosis agent-memory platform: pricing, docs search, platform status, agent skills. No auth.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 13 of 13 tools scored. Lowest: 3.8/5.
There is significant overlap between cortex_ask, cortex_recall, and search, all of which retrieve from the user's memory. cortex_recall explicitly describes itself as a subset of cortex_ask, and search's description is nearly identical to cortex_ask's core function, making it hard for an agent to choose correctly. Other tools are more distinct, but this triple overlap creates real ambiguity.
The naming is inconsistent: memory tools are split between a cortex_* prefix (ask, recall, manifest, status, etc.) and bare fetch/search, with no clear rule for which gets the prefix. Within cortex_*, some are verbs (ask, recall, remember) and some are nouns (manifest, status, connectable_sources), and platform tools use get_/list_/search_ prefixes, resulting in a mixed and unpredictable naming pattern.
13 tools is a reasonable number for a server covering both memory operations and platform information. However, the presence of three overlapping retrieval tools (cortex_ask, cortex_recall, search) slightly inflates the count, suggesting some redundancy rather than each tool earning a unique place.
The server covers core workflows: reading memory (ask, search, recall, fetch, manifest), writing memory (remember, ingest_conversation), checking health (status), and accessing platform info (get_platform_status, get_pricing, list_skills, search_docs). Minor gaps include no explicit update/delete for individual memories and no direct tool to connect new sources (only listings of connectable ones), but these are often user-driven actions.
cortex_askSearch the user’s memoryASearches 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.
cortex_connectable_sourcesSources this memory could connectAWhich 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.
cortex_ingest_conversationSave a conversation into the user’s memoryAIngest 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.
cortex_manifestWhat the user’s memory containsAA 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.
cortex_recallSemantic search of the user’s memoryASemantic-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.
cortex_rememberSave a fact to the user’s memoryAPersist 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.
| 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?
The description adds behavioral context beyond annotations: it states the fact becomes retrievable immediately and persists across sessions and agents, and that it is attributed to the user. Annotations already indicate non-readonly and non-destructive, so coverage is good.
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?
Three sentences with clear purpose, behavior, and usage guidelines. No fluff; front-loaded with the core action. 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?
The description covers the main aspects: what it does, when to use, and key parameter behavior. Without an output schema, it doesn't detail return values, but that is acceptable for a simple mutation tool. Could mention idempotency or limits, but not necessary.
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%, but the description adds value by explaining how to use source_universal_ids for provenance, and that text should be one self-contained fact. This enriches the meaning beyond the schema's basic 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 clearly states the tool's purpose: to persist a fact, decision, or conclusion into the user's memory. It uses specific verbs like 'persist' and 'retrievable', and distinguishes itself from sibling tools like cortex_ask and cortex_recall by being the write operation.
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 guidance on when to use: 'whenever the conversation produces a durable conclusion'. Also advises to keep each memory to one self-contained fact. Could be improved by explicitly mentioning alternatives for retrieval, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cortex_statusMemory freshness and coverageAMemory 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.
fetchRead one item from the user’s memoryARetrieve 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_platform_statusGet platform statusAGet 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_pricingGet Mitosis pricingAGet 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_skillsList agent skillsAList 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.
searchSearch the user’s memory (deep research)ASearch 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.
search_docsSearch Mitosis docsAKeyword-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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
