Personal memory layer: files, notes, messages, tasks and email, semantically indexed.
Scored across 11 tools
The save-side tools overlap significantly: `memory` (saves note/task/reminder) and `remember` (stores a note) are hard to tell apart, and `save_context` also stores into memory. Similarly `search` vs `recall` vs `fetch` are related enough that selection depends on hints rather than clear boundaries.
Names mix verb style (`connect`, `fetch`, `search`, `remember`, `recall`, `resume`, `save_context`) with plain nouns (`memory`, `tasks`, `context_packs`, `signup`) with no unifying pattern. It is readable but the related concepts (remember/recall/memory) use inconsistent conventions.
11 tools is a healthy, well-scoped size for an auth + memory + context-pack surface. It is slightly inflated by near-duplicate save tools (`memory`/`remember`) that could plausibly be consolidated.
The set covers auth (signup/connect), capture (memory/remember/save_context), retrieval (search/recall/fetch), context packs (list/resume), and tasks. However there is no delete/forget/update operation for memories or context packs, leaving agents unable to correct or remove stored data.
Complete the CortexPlus connection with the short authentication key the user received by email after signup. Ask the user to paste the key, then call this tool; never guess or invent the key. The response includes an API key that the AI platform should save in its CortexPlus connector configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The authentication key pasted by the user from their CortexPlus email. | |
| 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, non-destructive, open-world operation, and the description adds genuinely useful behavior beyond them: the input must come from the user unmodified, and the response yields an API key the platform should persist in its connector configuration. It omits failure/validation behavior, so not 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 tight sentences with the action and its input source front-loaded, followed by the handling rule and the output consequence. No filler and nothing buried.
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, yet the description still flags the important side effect (an API key to save), and it warns against fabricating the key. It is complete enough to call correctly, though it says nothing about the optional 'client' parameter's role or error handling.
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 both 'key' and 'client' are already documented in the schema; baseline 3 applies. The description adds only the nuance that the key is 'short' and user-supplied, which is marginal beyond the schema text.
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: 'Complete the CortexPlus connection' using a short authentication key received by email. It clearly distinguishes itself from the signup sibling by framing this as the post-signup completion step rather than account creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition and sequence: ask the user to paste the key, then call this tool, and 'never guess or invent the key.' It does not name an alternative tool or state when this should NOT be used (e.g., re-connection cases), so it stops 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.
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 short authentication key by email; ask the user for that key and call connect with it. 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 readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the write/external nature is partly covered. The description adds material context beyond them: an email is sent to the user as a side effect, the operation is step one of a two-step auth handshake completed by connect, and it handles both new and existing accounts. It stops short of describing failure modes or what the call returns, so it is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose followed by actionable instructions in a logical order; every sentence drives agent behavior. Slightly longer than strictly necessary, with the rationale clause and the repeated email warning adding mild redundancy, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-step signup tool with annotations and an output schema already present, the description supplies everything an agent needs: the prerequisite user input, the side effect, the follow-up call to connect, and the key prohibition. Return-value details are correctly left to the output schema.
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 all three parameters are already documented, including the 'never guess' constraint on email that the description restates. The description adds no syntax, format, or value guidance for email/name/client beyond what the schema provides, so the baseline of 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 ('Create a CortexPlus account, or begin signing in to an existing one') and immediately names the sibling it hands off to ('call connect with it'). An agent can distinguish this from connect, recall, or remember without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit context for use ('so this conversation can use CortexPlus as the user's long-term memory'), a step-by-step protocol (ask for email/name, then call, then collect the emailed key and call connect), and an explicit prohibition ('Never guess or invent the email address'). The alternative tool and the condition that triggers it are both named.
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.
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.
