Evidence-backed follow-through memory for what you owe, await, and need to remember.
Scored across 11 tools
Most tools target distinct actions and resources, but some close pairs exist: create_follow_up vs draft_follow_up could be confused, and get_today vs list_commitments have overlapping attention/listing purposes. The descriptions mostly clarify these boundaries, so overall ambiguity is low.
All tools follow a consistent snake_case verb_noun pattern (capture_note, create_follow_up, get_commitment, search_memory, etc.). The naming style is uniform and predictable across the entire set.
Eleven tools is well within the ideal range and each tool earns its place for the memory, follow-up, and commitment domain. The set feels appropriately scoped without unnecessary bloat.
The core workflow is covered: capture, create follow-ups, list/get commitments, gather evidence, mark resolved, and search memory. Minor gaps exist around updating or cancelling follow-ups and editing/removing notes, but these do not break the primary use case.
Let a user tell Promise something to remember. Safety: Echo what Promise understood and require review when the platform requests it.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | remember | |
| dueAt | No | ||
| title | No | ||
| contactId | No | ||
| requestId | No | ||
| personName | No | ||
| transcript | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only reporting readOnlyHint=false and destructiveHint=false, the description adds a meaningful behavioral requirement: echo back what Promise understood and require review when the platform asks. This is beyond the schema and annotations, though the platform-review trigger remains somewhat underspecified.
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 the purpose front-loaded and a separate safety note; no filler or repeated schema information. Both sentences earn their 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 tool has seven parameters, no output schema, and no documentation of return behavior, and the description is too sparse to support correct invocation of the richer fields. The safety note is useful but does not compensate for missing parameter guidance and sibling differentiation.
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 needed to compensate, but it only implies that the transcript is the content to remember. It does not explain kind, dueAt, title, contactId, requestId, or personName, leaving the 7-parameter input substantially underspecified.
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 core action - letting a user tell Promise something to remember - which aligns with the capture_note name. It is not a tautology, but it does not mention the task/follow_up/remember variants in the schema or distinguish the tool from siblings like create_follow_up or search_memory.
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 guidance about when to use capture_note versus create_follow_up, draft_follow_up, or search_memory. The safety sentence is operational policy rather than usage context, and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a Promise signup URL for users who want agent access to follow-up memory. Safety: Never collects provider credentials in the agent. Send the user to Promise.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Opaque agent state returned unchanged after authorization. | |
| intent | No | Signup intent to preserve in Promise attribution. | |
| scopes | No | ||
| returnUrl | No | HTTPS URL the user can return to after Promise authorization. | |
| clientName | No | Name of the agent or MCP client requesting access. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is established. The description adds value by stating 'Never collects provider credentials in the agent' – a behavioral guarantee not implied by the annotations – and by instructing the agent to redirect the user. This exceeds the baseline for tools 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 short sentences: the first states the primary purpose, the second adds safety and instruction. It is front-loaded with the core function, wastes no words, and every clause contributes essential information.
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 five optional parameters, no output schema, and annotations that already cover read-only and idempotent behavior, the description provides all necessary context: what it does, when to use it, and a critical safety caveat. The instruction to 'Send the user to Promise' clarifies the expected follow-up action. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema documents most parameters. The description does not elaborate on individual parameters (state, intent, scopes, etc.), though it hints at the purpose of scopes via 'agent access to follow-up memory.' It adds minimal meaning beyond the schema, so the 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 a specific verb ('Return') and resource ('a Promise signup URL'), and the purpose is unambiguous: obtaining a signup URL for users seeking agent access to follow-up memory. It is distinct from sibling tools like capture_note or create_follow_up, which are about data capture and follow-up creation, not authorization.
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 clear context for when to use it ('for users who want agent access to follow-up memory') and provides an explicit instruction ('Send the user to Promise'). However, it does not mention alternatives or exclusions relative to sibling tools, 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.
Create a future follow-up from explicit user intent. Safety: Only create follow-ups from explicit user instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| dueAt | No | ||
| title | Yes | ||
| contactId | No | ||
| requestId | No | ||
| personName | No | ||
| transcript | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent mutation, and the description adds the safety constraint that creation must come from explicit user intent. It does not disclose what side effects occur (e.g., scheduling, notification, persistence) or what the response contains, but coarse behavioral traits are covered by 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 tight sentences with no filler. The action is front-loaded and the safety qualifier is the only additional content, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The safety note provides some operational context, but with six undocumented parameters and no output schema, an agent still lacks critical information for confident invocation. A richer description would explain the meaning of title, dueAt, contactId, requestId, personName, and transcript, and what happens after creation.
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% and the description makes no mention of any of the six parameters. Fields such as requestId, transcript, dueAt, and contactId have no explanatory text, leaving an agent unable to determine what values are 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 identifies the operation ('create'), the object ('future follow-up'), and the trigger ('explicit user intent'), making the tool's purpose immediately clear. It does not explicitly differentiate from the sibling draft_follow_up, so there is minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete precondition: create follow-ups only when the user explicitly instructs it, which is a useful go/no-go signal. It does not mention alternatives like draft_follow_up or explain when to prefer them, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft a follow-up message without sending it. Safety: Do not send email in v1. Return a draft and Promise confirmation link.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| context | No | ||
| personName | No | ||
| commitmentId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and give little positive signal, so the description carries the burden of disclosing behavior. It clearly states the tool does not send email and returns a draft plus a Promise confirmation link, which is meaningful non-obvious behavior. It does not say whether the draft is persisted or what the Promise link represents, but the core behavioral traits are disclosed.
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 no filler. The core action, the no-send safety constraint, and the return value are all present and front-loaded. 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?
Given the lack of an output schema and the unhelpful annotations, the description provides the key no-send invariant and a high-level return description, but it omits parameter semantics and does not clarify how this tool relates to create_follow_up. It is adequate for basic selection but leaves clear gaps 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 0%, so the description needed to compensate by explaining goal, context, personName, and commitmentId. It does not mention any parameter or their relationships, leaving the agent to infer meaning from property names alone. The names are somewhat self-explanatory, which prevents a score of 1, but the description adds no semantic value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('draft') and resource ('follow-up message') and immediately scopes the action as 'without sending it,' which distinguishes it from the sibling create_follow_up. The safety line reinforces that this is a non-sending draft tool, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this when you need to produce a follow-up draft rather than send an email. The v1 safety instruction is an explicit when-not boundary. However, it does not name alternatives or give a fuller routing condition such as 'if sending is needed, use create_follow_up instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a structured Promise commitment or waiting-on item. Safety: Prefer structured status, due dates, people, and source links over raw mail.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only, idempotent, and non-destructive, and the description agrees with them. It adds useful behavioral context: the response may include raw mail, and the agent should prefer structured status, due dates, people, and source links, which informs how the output should be consumed.
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 and no filler. The safety instruction is terse and adds distinct value, making this a well-structured, efficient definition.
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 read-only get-by-id tool, the description conveys the return concept and the fields to prioritize, and annotations cover the safety profile. However, without an output schema it leaves implicit the exact return shape, the source of the required id, and behavior when no commitment is found.
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 input schema exposes only 'id' (uuid, required) with no description, and the tool description never explains what this id refers to or where it can be obtained. With 0% schema description coverage, the description should compensate for the parameter but does not.
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 ('Retrieve') and names the resource as a 'structured Promise commitment or waiting-on item', improving on the bare tool name. It does not explicitly contrast with sibling tools like get_commitment_evidence or list_commitments, so full differentiation is left to inference.
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 sentence tells the agent when to choose this tool over siblings such as get_commitment_evidence or list_commitments. The 'Safety: Prefer structured status...' note is about interpreting the result rather than selecting the tool, so it does not satisfy the usage-guideline requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show why Promise believes a follow-up or memory exists. Safety: Return source summaries and citations permitted by the platform API.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by noting 'Safety: Return source summaries and citations permitted by the platform API', which hints at platform restrictions and the nature of the output (citations). However, it does not detail what happens if the evidence is unavailable or any rate limits.
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, with the core purpose in the first sentence and a safety note in the second. It is front-loaded and concise. The safety note is relevant and earns its place by alerting the agent to platform constraints.
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 moderate complexity (single parameter, read-only, no output schema), the description is mostly complete. It tells the agent what to expect (source summaries and citations) and conveys the safety constraints. It could mention whether the output includes any caveats, but the lack of an output schema means the description carries more weight, and it does a reasonable job.
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%, but the tool has only one parameter (id, a UUID), and the description does not elaborate on the id beyond what the schema shows. The description's main focus is on the tool's purpose, not the parameter. Since the parameter is simple and self-explanatory, a baseline 3 is appropriate – the description does not add significant meaning, but the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Show') and a resource ('commitment evidence'), and clarifies that it explains why Promise believes a follow-up or memory exists. It does not explicitly differentiate from siblings, but the phrase 'why Promise believes' is distinctive enough to set it apart from generic retrieval tools like get_commitment or search_memory.
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: call it when you need to understand the reasoning behind a follow-up or memory. It does not explicitly state when not to use it or name alternatives, but the context of 'why' suggests it complements but does not replace get_commitment or search_memory. This is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize what matters before the user speaks with someone. Safety: Avoid exposing hidden/private fields unless the platform scopes allow them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Name or email search when contactId is unknown. | |
| contactId | No |
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 covered. The description adds a meaningful behavioral constraint not present in annotations: 'Avoid exposing hidden/private fields unless the platform scopes allow them.' This is valuable context about privacy handling.
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 with no waste: the first states the purpose, the second gives a critical safety note. The main verb and resource are front-loaded, and every word 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 read-only tool with 3 optional parameters and no output schema, the description gives the purpose and a safety caveat but lacks guidance on parameter selection or return value expectations. It is minimally viable but leaves gaps that could cause incorrect usage.
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 33% (only 'query' has a description), and the tool description adds no parameter-level meaning. It does not explain the relationship between contactId and query, nor what 'limit' controls. With low coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Summarize') and resource ('what matters before the user speaks with someone'), giving a specific purpose. It does not explicitly differentiate from siblings like search_memory or get_today, but the 'before the user speaks with someone' context provides enough distinct meaning.
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 when to use it ('before the user speaks with someone') but does not mention alternatives or exclusions. There is no explicit guidance on when to prefer this over sibling tools, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return what currently deserves the user's attention. Safety: Return concise items and links back to Promise for sensitive action.
| Name | Required | Description | Default |
|---|---|---|---|
| horizonDays | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish safety (readOnlyHint, idempotentHint, destructiveHint=false). The description adds valuable behavioral context beyond annotations: results should be concise items/links, and sensitive actions should be deferred to Promise. This is consistent with readOnly semantics and clarifies that the tool does not execute actions.
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 with no filler: the core purpose is front-loaded, and the safety note earns its place by preventing misuse. It is appropriately sized for a simple 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?
For a simple, read-only tool with one optional parameter and no output schema, the description conveys the essential outcome ('items and links') and safety posture. It does not explain return structure or horizonDays semantics, but annotations and schema constraints cover enough for this complexity level.
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%, and the description does not mention horizonDays at all. The parameter name and min/max/default constraints in the schema carry the entire semantic load, and 'currently' only weakly implies a time horizon. The description fails to compensate for the missing parameter documentation.
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 gives a clear verb ('Return') and resource ('what currently deserves the user's attention'), which conveys a daily/current-attention digest rather than a generic search or list. However, it doesn't specify what categories of items are included or differentiate itself from siblings like list_commitments or get_person_context, 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?
There is no guidance about when to prefer this tool over siblings such as list_commitments, get_commitment, or search_memory. The 'Safety' sentence is about output behavior rather than usage context or exclusions, leaving selection entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List what the user owes and what the user is waiting on. Safety: Do not infer more certainty than Promise returns.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scope | No | active | |
| category | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is read-only, idempotent, and non-destructive. The description adds a useful safety instruction about not inferring more certainty than Promise returns, providing extra interpretive context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, followed by a relevant safety note. It avoids fluff and is appropriately sized for a simple list tool, though it could briefly mention parameter usage without losing conciseness.
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 3 parameters and no output schema, the description omits meaning of the filter parameters (scope, category) and does not clarify how results are structured or how this differs from get_commitment. The annotations cover safety, but functional completeness is lacking.
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%, and the description provides no explanation of the limit, scope, or category parameters. With no parameter details in the schema or description, the agent has no guidance on how to filter the list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it lists commitments, specifically what the user owes and is waiting on. This distinguishes it from sibling get_commitment which returns a single entity, though it doesn't explicitly name alternatives.
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 guidance on when to use this tool versus alternatives like get_commitment or get_today, nor any exclusions or prerequisites. The safety note is a behavioral caution rather than usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell Promise that a commitment or waiting-on item is complete. Safety: Confirm destructive or irreversible status changes in the agent UI.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=false, but the description explicitly says 'Confirm destructive or irreversible status changes'—implying the action may be destructive or irreversible. This directly contradicts the annotation. No other behavioral traits (idempotency, effects, reversibility) are disclosed. This is a serious inconsistency.
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 only two sentences, efficient and front-loaded with the core action. The safety note is brief and adds relevant caution. No wasted words, though it could be slightly more structured (e.g., separating usage from safety).
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 a write operation with no output schema, the description should clarify return behavior, side effects, and prerequisites. It does none of that, and the safety line actually contradicts the annotation. The tool has only one parameter, but the description still leaves critical gaps about what happens after calling it.
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 0%, so the description must explain the single 'id' parameter. It only says 'Tell Promise that a commitment or waiting-on item is complete', from which one can infer 'id' refers to that item, but no explicit detail is given (e.g., must be a commitment ID, accepted formats). The parameter meaning is largely left to assumption.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Tell Promise that... is complete') and a clear resource (commitment or waiting-on item). It goes beyond a tautology and is easily distinguishable from siblings like 'get_commitment' or 'capture_note'. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions. The only extra text is a safety instruction about confirming destructive changes, which is not usage guidance. An agent gets no help deciding between marking resolved and, say, creating a follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Promise's derived memory with user authorization. Safety: Search derived Promise memory, not raw provider mailboxes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, and destructiveHint false. The description adds useful behavioral context: 'with user authorization' (an operational requirement) and 'Safety: Search derived Promise memory, not raw provider mailboxes' (data source scoping). No contradiction with annotations; adds value 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?
Two sentences, front-loaded with the action ('Search Promise's derived memory'). The safety note is extra but directly relevant. No fluff; concise. Slightly could be more structured, but it's efficient.
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 search tool with 2 parameters and no output schema, the description provides no parameter guidance, no result format, and no pagination info. Annotations cover safety but not operational details. The description is too minimal for an agent to confidently invoke it correctly with distinct queries and limits.
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%, meaning the description must compensate for parameter meaning. The description does not mention 'query' or 'limit' at all, leaving the agent to infer from parameter names alone. With only 2 parameters, it could easily add semantic detail (e.g., query format, limit purpose) but doesn't.
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 'Search Promise's derived memory' – a specific verb and resource. It adds scope by noting 'with user authorization' and distinguishing from 'raw provider mailboxes'. However, it doesn't name a specific sibling tool to differentiate, so it doesn't fully leverage sibling awareness.
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 when to use (searches on derived memory) and includes an exclusion ('not raw provider mailboxes') but doesn't explicitly mention alternative tools or conditions for selection. The context is clear but lacks concrete 'when to use vs. when not to use' guidance.
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.
capture_noteconnect_promisecreate_follow_updraft_follow_upget_commitmentget_commitment_evidenceget_person_contextget_todaylist_commitmentsmark_resolvedsearch_memoryA self-improving memory layer. Your memory, notes, tasks and goals, remembered everywhere.
Personal memory outside the AI. Due dates, loose ends and old notes come back on their own.
Your personal action-item list — what you owe and what you're owed. AI proposes; you approve.
Turn any goal with a deadline into a private, gamified, evidence-based execution calendar.
Add one secure layer between your agents and this server.
