Personal memory layer: files, notes, messages, tasks and email, semantically indexed.
Scored across 11 tools
Several tools overlap in purpose: `memory` and `remember` both write to CortexPlus memory (one auto-classifies note/task/reminder, the other stores a note), and `search` vs `recall` both retrieve from memory. Descriptions do provide guidance ('prefer recall over search'), which keeps these from being truly indistinguishable, but the boundaries require careful reading.
Naming mixes verbs (connect, fetch, recall, remember, resume, search, signup) with bare nouns (memory, context_packs, tasks), so there is no single predictable pattern. Most names are snake_case single tokens with only `context_packs` and `save_context` using underscores, so it is still readable but not uniform.
At 11 tools, the surface is well-scoped for a personal memory/knowledge-base server. Each tool maps to a recognizable operation (auth, write, retrieve, handoff, tasks) without padding.
The lifecycle is largely covered: signup/connect for auth, memory/remember/save_context for writes, search/recall/fetch for retrieval, and context_packs/resume plus tasks for surfacing stored work. Minor gaps exist — no explicit update or delete of memory items or context packs, which agents cannot work around.
Complete the CortexPlus connection with the 6-digit code the user received by email after signup. Ask the user for the code, then call this tool with the same email used in signup; never guess or invent the code. The response includes an API key that the AI platform should save in its CortexPlus connector configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The 6-digit code from the CortexPlus email. | |
| Yes | The email address used in signup. | ||
| client | No | The name of the AI platform you are running on, e.g. ChatGPT, Claude, Cursor. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| Yes | ||
| apiKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, open-world, non-destructive operation, and the description adds value beyond that: the response contains an API key that must be persisted in the connector configuration, and the code must come from the user rather than being fabricated. It doesn't cover failure modes such as an expired or already-used code, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each doing work: what the tool does, the procedure with the user, and what to do with the returned key. The critical constraint (never invent the code) and the post-call action are both front-loaded and unambiguous.
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?
Since an output schema exists, return values needn't be enumerated, and the description still flags the API key as the important output and what to do with it. The only gaps are error/retry behavior and the unmentioned optional `client` parameter, which are minor for this flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's guidance on the email ('same email used in signup') largely restates the schema, and the optional `client` parameter is not mentioned at all, so it adds little semantic meaning beyond the structured fields.
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 outcome: completing the CortexPlus connection using the 6-digit signup code. It clearly distinguishes this tool from the sibling `signup` by framing itself as the post-signup completion step, so an agent can route between them without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (after the user receives the email code), an operational precondition (call with the same email used in signup), and a negative instruction (never guess or invent the code). It also tells the agent to ask the user for the code first, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved CortexPlus context packs, optionally filtered by AI platform.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| platform | No | Platform filter, e.g. chatgpt or claude. |
| Name | Required | Description |
|---|---|---|
| packs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only that packs are 'saved' and the filter is optional; it says nothing about pagination behavior or result ordering relative to the limit parameter.
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?
A single front-loaded sentence with no wasted words. The core action and the optional filter are both stated immediately.
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?
With an output schema present, return values need no explanation, and annotations cover safety. However, for a list tool with a bounded limit parameter, the description says nothing about default page size or how to retrieve more than 20 items, leaving a gap 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 only 50%: platform is already documented in the schema, and the description merely restates that filter without adding format or semantics. The limit parameter (default 20, max 50) is never mentioned in the description, so the gap in the other half of parameters is not compensated.
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 ('List') and resource ('saved CortexPlus context packs') with a clear optional filter. An agent can tell this is a read/list tool, though the description does not contrast it with siblings like search, recall, or save_context that also touch context data.
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?
'Optionally filtered by AI platform' implies the main use case (browse packs, narrow by platform), but there is no explicit guidance on when to choose this over search or recall. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full content of one CortexPlus memory item by id, as returned by search. Health data (saude tag) is only included when the user has enabled sharing it with AI assistants in CortexPlus settings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Item id from a search result. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds a genuinely non-obvious behavioral rule: `saude`-tagged health data is only returned when the user has enabled AI sharing in settings, which explains why content may be missing. No mention of truncation or pagination, but that is minor for a by-id fetch.
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, zero filler, with the core action stated first and the privacy caveat second. Every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is unnecessary. For a one-parameter read tool with full annotation coverage, the description supplies everything an agent needs: what it returns, where the id comes from, and the one condition under which content may be withheld.
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 the single parameter is documented as 'Item id from a search result.' The description's 'by id, as returned by search' conveys the same provenance already stated in the schema, so it adds no new semantic detail. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Retrieve the full content of one CortexPlus memory item') plus the lookup key ('by id'). The phrase 'as returned by search' cleanly separates it from the sibling search tool, which lists items rather than returning full 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 establishes the workflow context: this tool is used on an id that came from a search result, implying it follows a search call. It gives no explicit when-not or alternative-tool guidance, but the usage condition is unambiguous for a single-item reader.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a memory in CortexPlus. CortexPlus decides whether it is a note, task, or reminder and extracts the client.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| text | Yes | Text to classify and save. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| type | Yes | |
| title | Yes | |
| client | Yes | |
| memory | Yes | |
| review | Yes | |
| status | Yes | |
| resolved | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=false and destructiveHint=false. The description adds useful behavior beyond that: the system decides whether the input becomes a note, task, or reminder and extracts the client. There is no contradiction between 'save' and 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 short sentences with the core action front-loaded. Every phrase adds meaning, and there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and safety annotations present, the description does not need to cover return values. It covers the core save-and-classify behavior, but the undocumented tags parameter and lack of sibling differentiation keep it from being fully 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 schema already explains 'text' as text to classify and save, and the description reinforces the classification behavior. However, the optional 'tags' parameter is never mentioned, and schema coverage is only 50%, leaving the meaning of tags unclear.
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?
Verb 'save' plus resource 'memory' states the operation clearly, and the second sentence adds the auto-classification behavior. It does not explicitly differentiate from related siblings such as 'remember' or 'tasks', so it stops short of a 5.
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?
No guidance is given about when to use this tool instead of a sibling. Among the sibling tools are 'remember' and 'tasks', which could plausibly compete, but the description gives no selection rule or exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a context block from the user's CortexPlus memory: the passages that answer a question plus their graph neighbours, already formatted as text. Prefer this over search when you intend to answer from the user's memory. Health data (saude tag) is only included when the user has enabled sharing it with AI assistants in CortexPlus settings.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| limit | No | ||
| query | Yes | ||
| maxChars | No |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), so the bar is lower, and the description still adds real context: results arrive pre-formatted as text, include graph neighbours, and health-tagged data is privacy-gated behind a user setting. It does not disclose truncation behaviour tied to maxChars or what happens when no passages match, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each doing distinct work: what is built, when to prefer it over a sibling, and the privacy caveat. The purpose statement is front-loaded and nothing is repeated from the annotations or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the privacy gating plus the search-vs-recall routing are covered. The gap is the four undocumented tuning parameters — for a memory-retrieval tool, the agent has no guidance on how `depth`, `limit`, and `maxChars` should be set, which is a real usability hole.
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 0% across four parameters, so the description carries the full burden and largely fails: `depth`, `limit`, and `maxChars` are never mentioned, leaving the agent to guess at graph traversal depth, result count, and output size trade-offs. Only `query` is obliquely implied by 'a question'.
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?
Specific verb and resource: 'Build a context block from the user's CortexPlus memory', with the content spelled out as 'the passages that answer a question plus their graph neighbours, already formatted as text'. It also implicitly separates itself from the sibling `search` tool by describing a different output shape (a ready-to-use text block vs. raw search hits).
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 names the alternative: 'Prefer this over search when you intend to answer from the user's memory', giving both the preferred tool and the selecting condition. It also documents a conditional exclusion (health/`saude` data only when the user has enabled AI sharing), so the agent knows when content will be missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a note in the user's CortexPlus memory so future conversations can recall it.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| type | No | Node type, e.g. note or meeting-note. | note |
| title | No | ||
| content | Yes | ||
| parentId | No | Optional id of an existing memory to nest this one under. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| title | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose the write profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false) and that the call is not idempotent. The description adds a little lifecycle context (the note is retained for future conversations) but never warns that repeat calls with identical content create duplicate nodes, nor whether writes require auth or are permanent.
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?
One front-loaded sentence with a clear verb, resource, and purpose clause. Nothing is padded or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, and annotations cover the safety profile. However, for a 5-parameter mutation tool at 40% schema coverage, the description is too thin: it omits duplicate/idempotency behavior and gives no help on the undocumented content/tag/title parameters.
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 only 40% — type and parentId are documented, while content, tag, and title are bare. The description adds no parameter meaning whatsoever (no tag semantics, no nesting behavior, no note-type guidance), so it fails to compensate for the coverage gap.
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 ("Store") and resource ("a note in the user's CortexPlus memory"), plus the downstream benefit (recall in future conversations). It implicitly contrasts with retrieval siblings like recall/search, but never names them, so an agent must infer the distinction.
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?
There is no explicit when-to-use guidance and no mention of alternatives such as recall, save_context, or memory. Only the phrase "so future conversations can recall it" hints at intent, leaving the agent to infer when this beats the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a previously saved CortexPlus context pack to resume work started in another AI conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Pack id, as returned by context_packs. | |
| query | No | Topic to find the pack by, in natural language. | |
| maxChars | No |
| Name | Required | Description |
|---|---|---|
| pack | Yes | |
| text | Yes | |
| matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds useful context that the pack was "previously saved" and originates from "another AI conversation," but says nothing about what loading actually does to state (e.g., whether it injects context, overwrites anything, or how the pack is selected among matches).
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?
A single well-formed sentence that front-loads the verb and resource. Every word earns its place; there is 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?
An output schema exists and annotations cover the safety profile, so return values and side-effect risk need not be re-explained. What is missing is guidance on the id-vs-query resolution path and the role of maxChars, which is the main thing an agent needs to call this 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?
The description says nothing about parameters. Crucially, the tool accepts two different lookup modes (id vs. query) and the description never explains the id/query duality or that either is optional, leaving the agent to infer the selection strategy from the schema alone. With only 67% schema coverage, the description does not compensate for the gap.
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 ("Load") and resource ("previously saved CortexPlus context pack") with the intended outcome ("resume work started in another AI conversation"). It distinguishes itself implicitly from read/list siblings like context_packs, but never explicitly names an alternative tool, so it falls short of a 5.
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 phrase "to resume work started in another AI conversation" implies the usage context (re-entering a prior session), which is more than nothing. However, it never states when to prefer this over recall, context_packs, or connect, and gives no prerequisites or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a handoff summary of this conversation to the user's CortexPlus memory so it can be resumed later in another AI platform. Write the summary yourself, in Markdown, covering: objective, decisions taken, current state, artifacts, next steps and constraints. Do not paste the raw transcript. Never include passwords, API keys or tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Short stable slug for the topic, e.g. context-pack-design. Sending the same key again updates the pack instead of creating another. | |
| tags | No | ||
| model | No | ||
| title | No | ||
| content | Yes | Handoff summary in Markdown. | |
| platform | Yes | The AI platform you are running on, e.g. ChatGPT, Claude, Gemini, Cursor. | |
| messageCount | No |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| title | Yes | |
| created | Yes | |
| redactions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations carry destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation profile is already declared. The description adds genuinely new behavioral constraints the annotations cannot express: write the summary yourself, do not paste the raw transcript, and never include credentials. It stops short of explaining the overwrite-on-same-key behavior, which lives in the schema instead.
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 tight sentences, front-loaded with the action and its payoff before the content rules. The section list is dense but each item earns its place as a content requirement rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the description fully specifies what to put in the required content field. Gaps remain around the update-in-place semantics and the platform/model/tags parameters, but the core write path is adequately specified.
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 only 43%, so the description must compensate. It does clarify the content parameter (a self-authored Markdown handoff covering objective, decisions, state, artifacts, next steps, constraints), which is real added meaning, but tags, model, title, and messageCount remain undocumented anywhere.
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?
Specific verb (save) plus resource (handoff summary to CortexPlus memory) and an explicit downstream purpose (resume in another AI platform). An agent can distinguish this from siblings like remember, memory, recall, and resume without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the context of use ('so it can be resumed later in another AI platform') and gives content rules, but never names or contrasts the neighboring tools (remember, memory, resume) that an agent might confuse this with. Clear context, no explicit alternatives.
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 CortexPlus memory and return ranked matches. Use this to find what the user has stored before answering from memory. Health data (saude tag) is only included when the user has enabled sharing it with AI assistants in CortexPlus settings.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | What to look for, in natural language. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing that results are ranked and that `saude`-tagged health data is filtered out unless the user opted into AI sharing in settings, a privacy constraint not visible anywhere else. It does not describe result volume/pagination behavior.
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 compact sentences with the core purpose front-loaded; no filler. The health-data sentence is longer but carries non-obvious behavioral information, so it earns its place rather than padding the text.
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?
With an output schema present, return values need not be explained, and the description covers purpose, invocation context, and a privacy caveat. The one meaningful omission is routing guidance against the overlapping recall/fetch siblings, which matters for a search-style tool in this toolset.
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 50%: `query` is documented in the schema while `limit` has only a default and min/max bounds. The description adds nothing about either parameter (no guidance on query phrasing or when to raise limit), so it neither compensates for the coverage gap nor extends the documented field. 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?
States a specific verb and resource ('Search the user's CortexPlus memory') and the return shape ('ranked matches'), which is more than a restatement of the name. However, it never distinguishes itself from plausible siblings such as recall, fetch, or memory, so an agent cannot tell them apart from the text alone.
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?
'Use this to find what the user has stored before answering from memory' gives a clear triggering context, which is genuinely helpful. It stops short of the 5 level: no when-not conditions and no named alternatives among the overlapping siblings (recall, fetch, context_packs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a CortexPlus account, or begin signing in to an existing one, so this conversation can use CortexPlus as the user's long-term memory and knowledge base. Ask the user for their email address, and for their name if you do not already have it, then call this tool. CortexPlus sends them a 6-digit code by email; ask the user for that code and call connect with it and the same email. Never guess or invent the email address.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The user's name, if it is not already known. | |
| Yes | The user's email address. Ask the user; never guess or invent it. | ||
| client | No | The name of the AI platform you are running on, e.g. ChatGPT, Claude, Cursor. |
| Name | Required | Description |
|---|---|---|
| sent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare only readOnly=false, destructive=false, openWorld=true, but the description goes further: it discloses the email verification flow, that a 6-digit code is emailed, and that the session continues via 'connect'. It also surfaces the key behavioral risk ('never guess or invent the email address'). This is meaningful disclosure beyond the structured hints.
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?
Four sentences, front-loaded with the purpose before the operational steps. Every sentence carries actionable content, though the workflow instructions make it longer than the minimum needed for pure identification.
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 multi-step account/sign-in entry point, it covers purpose, user interaction, the hand-off to 'connect', and the anti-fabrication rule. An output schema exists, so return values need no explanation in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents email, name, and client, giving a baseline of 3. The description adds real value by constraining how values should be sourced ('ask the user', 'never guess or invent it' for email) and when name is needed, though it says nothing about the client parameter.
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 ('Create a CortexPlus account, or begin signing in to an existing one') plus the downstream purpose (long-term memory / knowledge base). It clearly distinguishes itself from the sibling 'connect', which is positioned as the follow-up step rather than the same 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?
Explicitly prescribes when to call it, what to ask the user for (email, and name if unknown), and what to do next ('ask the user for that code and call connect with it and the same email'). It names the alternative tool and the condition that selects it, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open CortexPlus tasks and reminders, optionally filtered by client.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| client | No | ||
| status | No | open |
| Name | Required | Description |
|---|---|---|
| tasks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results are limited to open items and may include reminders, which is useful context, but says nothing about pagination, ordering, or the effect of the limit parameter.
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?
A single front-loaded sentence with no filler or redundancy. It is appropriately sized, though the 'CortexPlus' branding is not load-bearing for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and annotations cover the safety profile. However, with three undocumented parameters at 0% schema coverage, the description leaves meaningful gaps around limit and status semantics.
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 0%, so the description must carry parameter meaning. It explains 'client' filtering and implies the default status via 'open', but never mentions 'limit' (or its 1-50 range) and does not clarify what other status values are accepted.
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?
Specific verb ('List') and resource ('CortexPlus tasks and reminders') with a stated scope ('open'). No sibling tool overlaps with task listing, so differentiation is effectively automatic, but the description does not explicitly rule anything out.
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?
Only 'optionally filtered by client' hints at usage; there is no guidance on when to use this vs. other retrieval tools, no exclusions, and no mention of prerequisites or alternate paths.
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.
connect3 fields changedInput schema / properties / emailAdded value: +{
+ "description": "The email address used in signup.",
+ "type": "string"
+}Input schema / properties / key / descriptionPrevious value: -"The authentication key pasted by the user from their CortexPlus email."New value: +"The 6-digit code from the CortexPlus email."Input schema / requiredPrevious value: -[
- "key"
-]New value: +[
+ "email",
+ "key"
+]remember1 field changedInput schema / properties / parentIdAdded value: +{
+ "description": "Optional id of an existing memory to nest this one under.",
+ "type": "string"
+}context_packsresumesave_contextconnectfetchmemoryrecallremembersearchsignuptasksA self-improving memory layer. Your memory, notes, tasks and goals, remembered everywhere.
Personal wiki and memory layer for AI assistants. Persistent, structured memory across sessions.
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Add one secure layer between your agents and this server.
