F
licenseNot graded
qualityB
maintenanceTracks commitments (promises made in conversations) and provides tools to add, list, mark as fulfilled, and check overdue items.
-
What Matters
Server Details
Your personal action-item list — what you owe and what you're owed. AI proposes; you approve.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 37 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.4/5.0
Scored across 6 tools
Disambiguation5/5
Each tool targets a distinct resource (items, focus, rules, proposals) with clear action verbs, and the descriptions explicitly delineate when to use add_item vs put_proposal and warn against using manage_focus/manage_rule outside conversation, leaving no ambiguity.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (add_item, complete_item, get_document, manage_focus, manage_rule, put_proposal), with verbs conveying the action and nouns the target.
Tool Count5/5
Six tools is well-scoped for this server: core item operations (add, complete, read), auxiliary resource management (focus, rules), and a proposal mechanism. Each tool has a distinct, non-redundant purpose.
Completeness3/5
The surface covers item creation, status changes, and reads, plus focus and rule management, but lacks direct item deletion or content editing; dismissal is mentioned in get_document but no tool performs it, requiring workarounds via proposals.
Available Tools
6 toolsadd_itemAInspect
Add an item immediately, without review. Normally use this ONLY when the user has just asked for it in conversation — they are the human in the loop at that moment, so set initiated: "human". Anything found by scanning on a schedule belongs in put_proposal instead, with ONE exception: something genuinely urgent that cannot wait for review may be added with initiated: "auto" and priority: "high", which immediately notifies the user's phone. That interruption is the point — reserve it for things that truly cannot wait, because routine "urgent" adds teach the user to ignore the one signal that means look now.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| due | No | YYYY-MM-DD. | |
| note | No | Prose context, markdown. A URL belongs in `links`, not here. | |
| links | No | Up to 3 named links — the thread, the document, the ticket. Prefer these over pasting a URL into the note. | |
| title | Yes | The thing to do. | |
| source | No | Who it involves or where it came from — "Dana", "Tuesday's standup". | |
| channel | No | Where it came from, which is what makes an item legible days later. self = the user thought of it themselves, no external trigger. teams = a Teams message or chat. email = an email thread. meeting = raised in or arising from a meeting. other = anywhere else. Describe the ORIGIN, not who added it — an item you add from an email is still email. | |
| flagged | No | True marks the task as urgent — needing the user’s attention now. Set it only when the user asked for the flag, or something genuinely cannot wait; it changes no ordering and no due date. | |
| section | Yes | Which list it belongs in. action = something the user owes someone or themselves. waiting = something owed TO them; they are blocked and the next move is not theirs. note = worth knowing, no action attached. Pick waiting over action whenever the ball is in someone else's court — the distinction is the whole point of the two lists. | |
| priority | No | ||
| initiated | Yes | Who set this add in motion. "human" = the user asked for it in this conversation — whoever is talking to you, not one specific person. "auto" = you are adding it on your own initiative with no direct instruction. Be truthful: "auto" combined with priority "high" interrupts the user's phone. | |
| source_id | No | The stable id of whatever this came from — a Teams message id, an Outlook internetMessageId, a calendar event id. Set it whenever you have one: it is how the app recognises the same thing again, across runs and after rewording. |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well by disclosing the side effect of auto+high (phone notification) and the rationale for reserving it. It does not mention auth, rate limits, or return behavior, but for an add operation, the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused paragraph, front-loaded with the core action, and every sentence adds essential context. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters and no output schema, the description nails the most critical behavioral nuances (human vs. auto, review vs. no review). It does not explain return values, but the primary purpose is clear and the schema covers parameter semantics, so it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 91% of parameters, so baseline is 3. The description adds meaning beyond the schema by explaining the strategic use of initiated and priority together (e.g., 'auto' with 'high' triggers a phone interruption), which is not evident from enum values alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add an item immediately, without review.' It clearly distinguishes this tool from the sibling put_proposal by contrasting immediate addition versus scheduled review, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'ONLY when the user has just asked for it in conversation.' It also gives a clear alternative: 'Anything found by scanning on a schedule belongs in put_proposal instead,' plus an exception for urgent cases. This is precise when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
complete_itemAInspect
Mark an item done, or reopen it. Idempotent.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| done | No | Default true. | |
| item_id | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses idempotency and the reversible nature (reopen), which are key behavioral traits. It does not mention error behavior or return values, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and idempotency. No wasted words, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description is reasonably complete: it states purpose and idempotency. It lacks explicit error/response details, but these are not critical for such a straightforward toggle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the `done` parameter has a description, but `item_id` does not. The description adds meaning to `done` by tying it to 'done or reopen', but does not clarify `item_id` beyond the schema's format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark an item done, or reopen it' uses a specific verb and resource, clearly distinguishing it from siblings like add_item and put_proposal. It directly states the action and the possible reverse action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you want to change the done state of an item. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentAInspect
Read everything: action items, the record of what has already been dismissed, and "focus" — the handful of terms the user says matter most. Always call this before proposing changes: it is the only way to know what was already deleted or rejected, and re-suggesting those is the main failure mode.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| include_rules | No | Include the standing rules. Default true. Read them: the server drops any suggestion an active rule excludes, so proposing one is wasted effort. | |
| include_dismissed | No | Include deleted items and previously rejected suggestions. Default true, and you almost always want it: this is how you avoid proposing something again. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the importance of calling this read tool to avoid failure modes. However, it doesn't explicitly mention side effects or auth, but the read-only nature is clear from 'Read everything' and the guidance to call before changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are direct and front-loaded, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the return contents (action items, dismissed, focus) and the workflow context, making it complete for a read tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with detailed descriptions about include_rules and include_dismissed defaults and implications. The tool description does not add parameter-specific details, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads action items, dismissed records, and focus terms. It uses the verb 'Read' and specifies the resource, distinguishing it from mutation siblings like add_item and put_proposal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call before proposing changes, explains why (to avoid re-suggesting dismissed items), and identifies it as the only way to know what was deleted or rejected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_focusAInspect
Replace the list of things the user says matter most — people, projects, whatever they care about. Send the WHOLE list every time, including the terms you are keeping: this replaces, it does not append, so omitting one deletes it. Read the current list from get_document first. Up to 10 terms of 60 characters; longer lists and longer terms are trimmed rather than refused, and the stored result comes back so you can see what landed. ONLY call this when the user asks you directly, in conversation. A scheduled run must never touch it: focus is the user saying what they care about, so a term they did not choose is worse than no term at all. Never infer one from their list.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| terms | Yes | The complete list, in the order the user wants to see it. An empty array clears it. |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and does it thoroughly. It discloses destructive semantics (omitting a term deletes it), trimming behavior for over-limit inputs, the return of the stored result, and the critical constraint that inferred terms must never be added. This goes well beyond what the raw schema or annotations would convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It front-loads the primary purpose and replacement rule, then systematically covers read-before-write, limits, return value, and usage exclusions. Despite its length, there is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description fully compensates by covering side effects, edge cases (trimming), return behavior, and policy constraints. It is complete enough for an agent to invoke correctly without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes the terms array as 'The complete list, in the order the user wants to see it', the description adds crucial constraints: send the WHOLE list, up to 10 terms of 60 characters, trimming rather than refusing, and the empty-array-clears behavior. These details are not in the schema and materially affect how to set the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Replace the list of things the user says matter most', clearly identifying the resource (the focus list) and the operation (replace). It also distinguishes itself from siblings by emphasizing replacement rather than appending, and by stating 'this replaces, it does not append'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Read the current list from get_document first' names the companion tool to use before this one, and 'ONLY call this when the user asks you directly, in conversation. A scheduled run must never touch it' gives a clear when-to-use and when-not-to-use rule. This strongly differentiates from potential alternative uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_ruleAInspect
Create, change, pause or delete a standing rule, taking effect IMMEDIATELY with no review. Use this only when the user asks you directly — "stop suggesting PTO stuff". A scheduled run must propose rules through put_proposal instead, exactly as it proposes items rather than calling add_item.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rule | No | Required for create. | |
| patch | No | Fields to change, for update. | |
| rule_id | No | Required for update, pause, resume and delete. | |
| operation | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a critical behavioral trait: rules 'tak[e] effect IMMEDIATELY with no review'. While it doesn't detail reversibility or permissions, the most safety-relevant behavior is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and then the usage constraint. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema and no output schema, the description covers the essential selection context and key caveat. The schema handles parameter details and required fields. It could explicitly mention that 'create' requires the rule object, but the schema already implies this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (75%), with rich descriptions for channel, section, and reason. The description adds no parameter-level detail, but the schema already documents the parameters adequately, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Create, change, pause or delete' and identifies the resource as 'standing rule', clearly distinguishing it from siblings like put_proposal and add_item. The scope is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this only when the user asks you directly' and provides an example ('stop suggesting PTO stuff'). It also names the alternative tool for scheduled runs (put_proposal) and explains why, making the usage boundary unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
put_proposalAInspect
Replace the pending set of suggested changes. This is the ONLY write the scheduled run should make — nothing here reaches the list until the user reviews and accepts it. Replaces any previous proposal wholesale, so include everything still worth suggesting, up to 100 deltas.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | Your name as the user knows you — "Claude" — shown as the review headline ("Claude suggests some changes") and in the notification. Just the name: no model version, no "AI". Omit it and the screen says "Your AI agent". | |
| deltas | Yes | The proposed changes — add, complete, remove or update, plus the rule kinds. At most 100: send the ones that matter most and let the rest wait for the next run, because a review too long to finish gets dismissed whole. An empty array clears the proposal. Prefer complete over remove for anything that actually got done. | |
| summary | No | One line on what this pass looked at. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and satisfies it: it discloses that the tool 'Replaces any previous proposal wholesale,' that it is the only write for the scheduled run, and that changes are gated behind user review ('nothing here reaches the list until the user reviews and accepts it'). It also states the 100-delta limit, covering key behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every phrase adds value: the replacement behavior, the exclusive write context, the review gating, and the 100-delta limit. There is zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple delta kinds, rules, parameters) and the absence of annotations or output schema, the description provides essential context: it orients the agent on when to use it, the wholesale replacement semantics, and the critical safety property that nothing reaches the list until user acceptance. The rich schema covers the remaining detail, so the description is complete enough for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself provides exhaustive descriptions for all parameters, including the delta kinds, field meanings, and constraints. The tool description adds only a brief contextual note about the 100-delta cap and wholesale replacement, which is already implied by the schema's description of deltas. Per the rubric, a baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb + resource: 'Replace the pending set of suggested changes.' It clearly distinguishes itself from sibling tools like add_item or complete_item by stating it is 'the ONLY write the scheduled run should make' and that it replaces the entire proposal wholesale, not just a single delta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'This is the ONLY write the scheduled run should make.' It contrasts with alternatives by noting that 'nothing here reaches the list until the user reviews and accepts it,' implying this is for proposing changes rather than direct mutation. It also gives a practical limit: 'up to 100 deltas,' which guides how to prioritize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
add_item1 field changed- added
Input schema / properties / flaggedAdded value: +{ + "description": "True marks the task as urgent — needing the user’s attention now. Set it only when the user asked for the flag, or something genuinely cannot wait; it changes no ordering and no due date.", + "type": "boolean" +}
- Changed
put_proposal1 field changed- changed
Input schema / properties / deltas / items / oneOfPrevious value: -[ - { - "description": "Suggest a new item the user does not have yet.", - "properties": { - "item": { - "properties": { - "channel": { - "default": "self", - "description": "Where it came from, which is what makes an item legible days later. self = the user thought of it themselves, no external trigger. teams = a Teams message or chat. email = an email thread. meeting = raised in or arising from a meeting. other = anywhere else. Describe the ORIGIN, not who added it — an item you add from an email is still email.", - "enum": [ - "self", - "teams", - "email", - "meeting", - "other" - ], - "type": "string" - }, - "due": { - "description": "YYYY-MM-DD. Anything dated today or earlier surfaces in the Today section, so only set this when there is a real deadline — a speculative date drags it to the top.", - "pattern": "^\\d{4}-\\d{2}-\\d{2}$", - "type": "string" - }, - "initiated": { - "description": "Only two values, and only for AI adds. \"human\" = the user asked for this item in conversation just now — any user, whoever is talking to the MCP server, not one specific person. \"auto\" = the AI added it on its own initiative, with no direct instruction. Absent on items the user typed into the app themselves.", - "enum": [ - "human", - "auto" - ], - "type": "string" - }, - "links": { - "default": [], - "description": "Up to 3 named links — the thread, the document, the ticket. Prefer these over pasting a URL into the note: they render as buttons rather than as a wall of text.", - "items": { - "properties": { - "label": { - "description": "What to call it — \"the Teams thread\", \"the signed contract\". Never the raw URL.", - "maxLength": 80, - "minLength": 1, - "type": "string" - }, - "url": { - "description": "The full URL, http or https only. Up to 1000 characters.", - "format": "uri", - "maxLength": 1000, - "type": "string" - } - }, - "required": [ - "label", - "url" - ], - "type": "object" - }, - "maxItems": 3, - "type": "array" - }, - "note": { - "description": "Optional detail or context, markdown. Leave empty unless it genuinely adds something. Up to 2000 characters — a paragraph or two, not a transcript.", - "maxLength": 2000, - "type": "string" - }, - "priority": { - "default": "medium", - "description": "How much this matters: low, medium or high. Defaults to medium — most things are medium, so use high only when someone is blocked or a real deadline is close, and low for things that genuinely can wait. Marking everything high makes the list useless.", - "enum": [ - "low", - "medium", - "high" - ], - "type": "string" - }, - "section": { - "description": "Which list it belongs in. action = something the user owes someone or themselves. waiting = something owed TO them; they are blocked and the next move is not theirs. note = worth knowing, no action attached. Pick waiting over action whenever the ball is in someone else's court — the distinction is the whole point of the two lists.", - "enum": [ - "action", - "waiting", - "note" - ], - "type": "string" - }, - "source": { - "description": "Who it involves or where it came from — \"Dana\", \"You → Dana\", \"Tuesday's standup\". Free text: sometimes a person, sometimes an occasion.", - "maxLength": 200, - "type": "string" - }, - "source_id": { - "description": "The stable id of whatever this came from — a Teams message id, an Outlook internetMessageId, a calendar event id. Set it whenever you have one. It is how the app recognises the same thing again after you have reworded the title, which you are otherwise told to do.", - "maxLength": 500, - "type": "string" - }, - "status": { - "description": "open or done. Leave it out for anything the user still has to act on — which is almost always. Send \"done\" only when adding something that ALREADY happened and is worth keeping as a record.", - "enum": [ - "open", - "done" - ], - "type": "string" - }, - "title": { - "description": "The thing to do, phrased as an action the user can act on. Prefer \"Reply to Dana about the audit dates\" over \"Dana email\". Keep it to one line — 200 characters at most, and anything approaching that belongs in the note instead.", - "maxLength": 200, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "title", - "section" - ], - "type": "object" - }, - "kind": { - "const": "add", - "type": "string" - }, - "reason": { - "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", - "maxLength": 500, - "type": "string" - } - }, - "required": [ - "kind", - "item" - ], - "type": "object" - }, - { - "description": "Suggest an item is already DONE — the meeting happened, the reply was sent. This is almost always what you want when something looks finished. It keeps the record that he completed it; use remove only when the item should never have been there.", - "properties": { - "item_id": { - "description": "The \"id\" of an existing item, exactly as returned by get_document.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - }, - "kind": { - "const": "complete", - "type": "string" - }, - "reason": { - "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", - "maxLength": 500, - "type": "string" - } - }, - "required": [ - "kind", - "item_id" - ], - "type": "object" - }, - { - "description": "Suggest an item should be cleared without being done — a duplicate, or something that stopped being relevant. If it was actually finished, use complete instead.", - "properties": { - "item_id": { - "description": "The \"id\" of an existing item, exactly as returned by get_document.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - }, - "kind": { - "const": "remove", - "type": "string" - }, - "reason": { - "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", - "maxLength": 500, - "type": "string" - } - }, - "required": [ - "kind", - "item_id" - ], - "type": "object" - }, - { - "description": "Suggest changing fields on an existing item — a slipped due date, a better title. Include only the fields that change; anything omitted is left alone.", - "properties": { - "item_id": { - "description": "The \"id\" of an existing item, exactly as returned by get_document.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - }, - "kind": { - "const": "update", - "type": "string" - }, - "patch": { - "properties": { - "channel": { - "description": "Where it came from, which is what makes an item legible days later. self = the user thought of it themselves, no external trigger. teams = a Teams message or chat. email = an email thread. meeting = raised in or arising from a meeting. other = anywhere else. Describe the ORIGIN, not who added it — an item you add from an email is still email.", - "enum": [ - "self", - "teams", - "email", - "meeting", - "other" - ], - "type": "string" - }, - "due": { - "anyOf": [ - { - "pattern": "^\\d{4}-\\d{2}-\\d{2}$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "YYYY-MM-DD. Anything dated today or earlier surfaces at the top, so only set this when there is a real deadline — a speculative date drags it up. Omit to leave the due date alone; null clears it." - }, - "links": { - "description": "Up to 3 named links — the thread, the document, the ticket. PUT URLS HERE, never pasted into the note: they render as buttons rather than a wall of text. Replaces the whole list, so include any existing links you want to keep. Omit to leave them alone.", - "items": { - "properties": { - "label": { - "description": "What to call it — \"the Teams thread\", \"the signed contract\". Never the raw URL.", - "maxLength": 80, - "minLength": 1, - "type": "string" - }, - "url": { - "description": "The full URL, http or https only. Up to 1000 characters.", - "format": "uri", - "maxLength": 1000, - "type": "string" - } - }, - "required": [ - "label", - "url" - ], - "type": "object" - }, - "maxItems": 3, - "type": "array" - }, - "note": { - "anyOf": [ - { - "maxLength": 2000, - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Optional detail or context, markdown. Prose only — a URL belongs in `links`, not here. Up to 2000 characters. Omit to leave the note alone; null clears it." - }, - "priority": { - "description": "How much this matters: low, medium or high. Use high only when someone is blocked or a real deadline is close, and low for things that genuinely can wait. Marking everything high makes the list useless. Omit to leave the current priority alone.", - "enum": [ - "low", - "medium", - "high" - ], - "type": "string" - }, - "section": { - "description": "Which list it belongs in. action = something the user owes someone or themselves. waiting = something owed TO them; they are blocked and the next move is not theirs. note = worth knowing, no action attached. Pick waiting over action whenever the ball is in someone else's court — the distinction is the whole point of the two lists.", - "enum": [ - "action", - "waiting", - "note" - ], - "type": "string" - }, - "source": { - "anyOf": [ - { - "maxLength": 200, - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Who it involves or where it came from — \"Dana\", \"You → Dana\", \"Tuesday's standup\". Omit to leave it alone; null clears it." - }, - "title": { - "description": "The thing to do, phrased as an action the user can act on. Prefer \"Reply to Dana about the audit dates\" over \"Dana email\". Keep it to one line — 200 characters at most, and anything approaching that belongs in the note instead.", - "maxLength": 200, - "minLength": 1, - "type": "string" - } - }, - "type": "object" - }, - "reason": { - "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", - "maxLength": 500, - "type": "string" - } - }, - "required": [ - "kind", - "item_id", - "patch" - ], - "type": "object" - }, - { - "description": "Suggest a standing rule, mined from a pattern in the rejections list. Only when 3 or more rejections share a trait and no active rule already covers it — one rejection is never a pattern. Never auto-applied: it does nothing until the user accepts it.", - "properties": { - "kind": { - "const": "add_rule", - "type": "string" - }, - "reason": { - "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", - "maxLength": 500, - "type": "string" - }, - "rule": { - "properties": { - "action": { - "enum": [ - "exclude", - "recategorize", - "always_keep", - "boost" - ], - "type": "string" - }, - "match": { - "properties": { - "conditions": { - "items": { - "properties": { - "field": { - "enum": [ - "section", - "channel", - "source", - "title", - "priority", - "due_relative" - ], - "type": "string" - }, - "op": { - "enum": [ - "equals", - "not_equals", - "contains" - ], - "type": "string" - }, - "value": { - "items": { - "maxLength": 200, - "type": "string" - }, - "maxItems": 20, - "minItems": 1, - "type": "array" - } - }, - "required": [ - "field", - "op", - "value" - ], - "type": "object" - }, - "maxItems": 10, - "minItems": 1, - "type": "array" - }, - "op": { - "default": "all", - "enum": [ - "all", - "any" - ], - "type": "string" - } - }, - "required": [ - "conditions" - ], - "type": "object" - }, - "origin": { - "properties": { - "count": { - "default": 0, - "maximum": 9007199254740991, - "minimum": 0, - "type": "integer" - }, - "from": { - "enum": [ - "rejections", - "manual" - ], - "type": "string" - }, - "rejection_ids": { - "default": [], - "items": { - "type": "string" - }, - "maxItems": 50, - "type": "array" - } - }, - "required": [ - "from" - ], - "type": "object" - }, - "params": { - "default": {}, - "properties": { - "channel": { - "description": "Where it came from, which is what makes an item legible days later. self = the user thought of it themselves, no external trigger. teams = a Teams message or chat. email = an email thread. meeting = raised in or arising from a meeting. other = anywhere else. Describe the ORIGIN, not who added it — an item you add from an email is still email.", - "enum": [ - "self", - "teams", - "email", - "meeting", - "other" - ], - "type": "string" - }, - "priority": { - "enum": [ - "low", - "medium", - "high" - ], - "type": "string" - }, - "section": { - "description": "Which list it belongs in. action = something the user owes someone or themselves. waiting = something owed TO them; they are blocked and the next move is not theirs. note = worth knowing, no action attached. Pick waiting over action whenever the ball is in someone else's court — the distinction is the whole point of the two lists.", - "enum": [ - "action", - "waiting", - "note" - ], - "type": "string" - } - }, - "type": "object" - }, - "reason": { - "description": "Why this rule exists, in the user's terms. Shown next to it on the rules page.", - "maxLength": 300, - "minLength": 1, - "type": "string" - }, - "status": { - "enum": [ - "active", - "paused" - ], - "type": "string" - } - }, - "required": [ - "action", - "match", - "reason", - "origin" - ], - "type": "object" - } - }, - "required": [ - "kind", - "rule" - ], - "type": "object" - }, - { - "description": "Suggest changing an existing rule — usually to narrow one that is too broad.", - "properties": { - "kind": { - "const": "update_rule", - "type": "string" - }, - "patch": { - "properties": { - "action": { - "enum": [ - "exclude", - "recategorize", - "always_keep", - "boost" - ], - "type": "string" - }, - "match": { - "properties": { - "conditions": { - "items": { - "properties": { - "field": { - "enum": [ - "section", - "channel", - "source", - "title", - "priority", - "due_relative" - ], - "type": "string" - }, - "op": { - "enum": [ - "equals", - "not_equals", - "contains" - ], - "type": "string" - }, - "value": { - "items": { - "maxLength": 200, - "type": "string" - }, - "maxItems": 20, - "minItems": 1, - "type": "array" - } - }, - "required": [ - "field", - "op", - "value" - ], - "type": "object" - }, - "maxItems": 10, - "minItems": 1, - "type": "array" - }, - "op": { - "default": "all", - "enum": [ - "all", - "any" - ], - "type": "string" - } - }, - "required": [ - "conditions" - ], - "type": "object" - }, - "params": { - "properties": { - "channel": { - "description": "Where it came from, which is what makes an item legible days later. self = the user thought of it themselves, no external trigger. teams = a Teams message or chat. email = an email thread. meeting = raised in or arising from a meeting. other = anywhere else. Describe the ORIGIN, not who added it — an item you add from an email is still email.", - "enum": [ - "self", - "teams", - "email", - "meeting", - "other" - ], - "type": "string" - }, - "priority": { - "enum": [ - "low", - "medium", - "high" - ], - "type": "string" - }, - "section": { - "description": "Which list it belongs in. action = something the user owes someone or themselves. waiting = something owed TO them; they are blocked and the next move is not theirs. note = worth knowing, no action attached. Pick waiting over action whenever the ball is in someone else's court — the distinction is the whole point of the two lists.", - "enum": [ - "action", - "waiting", - "note" - ], - "type": "string" - } - }, - "type": "object" - }, - "reason": { - "description": "Why this rule exists, in the user's terms. Shown next to it on the rules page.", - "maxLength": 300, - "minLength": 1, - "type": "string" - }, - "status": { - "enum": [ - "active", - "paused" - ], - "type": "string" - } - }, - "type": "object" - }, - "reason": { - "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", - "maxLength": 500, - "type": "string" - }, - "rule_id": { - "description": "The \"id\" of an existing item, exactly as returned by get_document.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - } - }, - "required": [ - "kind", - "rule_id", - "patch" - ], - "type": "object" - }, - { - "description": "Suggest deleting a rule outright.", - "properties": { - "kind": { - "const": "remove_rule", - "type": "string" - }, - "reason": { - "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", - "maxLength": 500, - "type": "string" - }, - "rule_id": { - "description": "The \"id\" of an existing item, exactly as returned by get_document.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - } - }, - "required": [ - "kind", - "rule_id" - ], - "type": "object" - }, - { - "description": "Suggest pausing a rule, leaving it in the list so it can be resumed.", - "properties": { - "kind": { - "const": "pause_rule", - "type": "string" - }, - "reason": { - "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", - "maxLength": 500, - "type": "string" - }, - "rule_id": { - "description": "The \"id\" of an existing item, exactly as returned by get_document.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - } - }, - "required": [ - "kind", - "rule_id" - ], - "type": "object" - } -]New value: +[ + { + "description": "Suggest a new item the user does not have yet.", + "properties": { + "item": { + "properties": { + "channel": { + "default": "self", + "description": "Where it came from, which is what makes an item legible days later. self = the user thought of it themselves, no external trigger. teams = a Teams message or chat. email = an email thread. meeting = raised in or arising from a meeting. other = anywhere else. Describe the ORIGIN, not who added it — an item you add from an email is still email.", + "enum": [ + "self", + "teams", + "email", + "meeting", + "other" + ], + "type": "string" + }, + "due": { + "description": "YYYY-MM-DD. Anything dated today or earlier surfaces in the Today section, so only set this when there is a real deadline — a speculative date drags it to the top.", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" + }, + "flagged": { + "description": "True marks this task as urgent — needing the user’s attention now. The user toggles it in the app, and the daily briefing offers it on critical findings. It changes no ordering and no due date: a flag is attention, not a deadline. Set it only when something genuinely cannot wait; flag everything and it means nothing. Absent means not flagged.", + "type": "boolean" + }, + "initiated": { + "description": "Only two values, and only for AI adds. \"human\" = the user asked for this item in conversation just now — any user, whoever is talking to the MCP server, not one specific person. \"auto\" = the AI added it on its own initiative, with no direct instruction. Absent on items the user typed into the app themselves.", + "enum": [ + "human", + "auto" + ], + "type": "string" + }, + "links": { + "default": [], + "description": "Up to 3 named links — the thread, the document, the ticket. Prefer these over pasting a URL into the note: they render as buttons rather than as a wall of text.", + "items": { + "properties": { + "label": { + "description": "What to call it — \"the Teams thread\", \"the signed contract\". Never the raw URL.", + "maxLength": 80, + "minLength": 1, + "type": "string" + }, + "url": { + "description": "The full URL, http or https only. Up to 1000 characters.", + "format": "uri", + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "label", + "url" + ], + "type": "object" + }, + "maxItems": 3, + "type": "array" + }, + "note": { + "description": "Optional detail or context, markdown. Leave empty unless it genuinely adds something. Up to 2000 characters — a paragraph or two, not a transcript.", + "maxLength": 2000, + "type": "string" + }, + "priority": { + "default": "medium", + "description": "How much this matters: low, medium or high. Defaults to medium — most things are medium, so use high only when someone is blocked or a real deadline is close, and low for things that genuinely can wait. Marking everything high makes the list useless.", + "enum": [ + "low", + "medium", + "high" + ], + "type": "string" + }, + "section": { + "description": "Which list it belongs in. action = something the user owes someone or themselves. waiting = something owed TO them; they are blocked and the next move is not theirs. note = worth knowing, no action attached. Pick waiting over action whenever the ball is in someone else's court — the distinction is the whole point of the two lists.", + "enum": [ + "action", + "waiting", + "note" + ], + "type": "string" + }, + "source": { + "description": "Who it involves or where it came from — \"Dana\", \"You → Dana\", \"Tuesday's standup\". Free text: sometimes a person, sometimes an occasion.", + "maxLength": 200, + "type": "string" + }, + "source_id": { + "description": "The stable id of whatever this came from — a Teams message id, an Outlook internetMessageId, a calendar event id. Set it whenever you have one. It is how the app recognises the same thing again after you have reworded the title, which you are otherwise told to do.", + "maxLength": 500, + "type": "string" + }, + "status": { + "description": "open or done. Leave it out for anything the user still has to act on — which is almost always. Send \"done\" only when adding something that ALREADY happened and is worth keeping as a record.", + "enum": [ + "open", + "done" + ], + "type": "string" + }, + "title": { + "description": "The thing to do, phrased as an action the user can act on. Prefer \"Reply to Dana about the audit dates\" over \"Dana email\". Keep it to one line — 200 characters at most, and anything approaching that belongs in the note instead.", + "maxLength": 200, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "title", + "section" + ], + "type": "object" + }, + "kind": { + "const": "add", + "type": "string" + }, + "reason": { + "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", + "maxLength": 500, + "type": "string" + } + }, + "required": [ + "kind", + "item" + ], + "type": "object" + }, + { + "description": "Suggest an item is already DONE — the meeting happened, the reply was sent. This is almost always what you want when something looks finished. It keeps the record that he completed it; use remove only when the item should never have been there.", + "properties": { + "item_id": { + "description": "The \"id\" of an existing item, exactly as returned by get_document.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "kind": { + "const": "complete", + "type": "string" + }, + "reason": { + "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", + "maxLength": 500, + "type": "string" + } + }, + "required": [ + "kind", + "item_id" + ], + "type": "object" + }, + { + "description": "Suggest an item should be cleared without being done — a duplicate, or something that stopped being relevant. If it was actually finished, use complete instead.", + "properties": { + "item_id": { + "description": "The \"id\" of an existing item, exactly as returned by get_document.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "kind": { + "const": "remove", + "type": "string" + }, + "reason": { + "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", + "maxLength": 500, + "type": "string" + } + }, + "required": [ + "kind", + "item_id" + ], + "type": "object" + }, + { + "description": "Suggest changing fields on an existing item — a slipped due date, a better title. Include only the fields that change; anything omitted is left alone.", + "properties": { + "item_id": { + "description": "The \"id\" of an existing item, exactly as returned by get_document.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "kind": { + "const": "update", + "type": "string" + }, + "patch": { + "properties": { + "channel": { + "description": "Where it came from, which is what makes an item legible days later. self = the user thought of it themselves, no external trigger. teams = a Teams message or chat. email = an email thread. meeting = raised in or arising from a meeting. other = anywhere else. Describe the ORIGIN, not who added it — an item you add from an email is still email.", + "enum": [ + "self", + "teams", + "email", + "meeting", + "other" + ], + "type": "string" + }, + "due": { + "anyOf": [ + { + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "YYYY-MM-DD. Anything dated today or earlier surfaces at the top, so only set this when there is a real deadline — a speculative date drags it up. Omit to leave the due date alone; null clears it." + }, + "flagged": { + "description": "True marks this task as urgent — needing the user’s attention now; false clears the flag. It changes no ordering and no due date: a flag is attention, not a deadline. Set true only when something genuinely cannot wait. Omit to leave the flag alone.", + "type": "boolean" + }, + "links": { + "description": "Up to 3 named links — the thread, the document, the ticket. PUT URLS HERE, never pasted into the note: they render as buttons rather than a wall of text. Replaces the whole list, so include any existing links you want to keep. Omit to leave them alone.", + "items": { + "properties": { + "label": { + "description": "What to call it — \"the Teams thread\", \"the signed contract\". Never the raw URL.", + "maxLength": 80, + "minLength": 1, + "type": "string" + }, + "url": { + "description": "The full URL, http or https only. Up to 1000 characters.", + "format": "uri", + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "label", + "url" + ], + "type": "object" + }, + "maxItems": 3, + "type": "array" + }, + "note": { + "anyOf": [ + { + "maxLength": 2000, + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Optional detail or context, markdown. Prose only — a URL belongs in `links`, not here. Up to 2000 characters. Omit to leave the note alone; null clears it." + }, + "priority": { + "description": "How much this matters: low, medium or high. Use high only when someone is blocked or a real deadline is close, and low for things that genuinely can wait. Marking everything high makes the list useless. Omit to leave the current priority alone.", + "enum": [ + "low", + "medium", + "high" + ], + "type": "string" + }, + "section": { + "description": "Which list it belongs in. action = something the user owes someone or themselves. waiting = something owed TO them; they are blocked and the next move is not theirs. note = worth knowing, no action attached. Pick waiting over action whenever the ball is in someone else's court — the distinction is the whole point of the two lists.", + "enum": [ + "action", + "waiting", + "note" + ], + "type": "string" + }, + "source": { + "anyOf": [ + { + "maxLength": 200, + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Who it involves or where it came from — \"Dana\", \"You → Dana\", \"Tuesday's standup\". Omit to leave it alone; null clears it." + }, + "title": { + "description": "The thing to do, phrased as an action the user can act on. Prefer \"Reply to Dana about the audit dates\" over \"Dana email\". Keep it to one line — 200 characters at most, and anything approaching that belongs in the note instead.", + "maxLength": 200, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + }, + "reason": { + "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", + "maxLength": 500, + "type": "string" + } + }, + "required": [ + "kind", + "item_id", + "patch" + ], + "type": "object" + }, + { + "description": "Suggest a standing rule, mined from a pattern in the rejections list. Only when 3 or more rejections share a trait and no active rule already covers it — one rejection is never a pattern. Never auto-applied: it does nothing until the user accepts it.", + "properties": { + "kind": { + "const": "add_rule", + "type": "string" + }, + "reason": { + "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", + "maxLength": 500, + "type": "string" + }, + "rule": { + "properties": { + "action": { + "enum": [ + "exclude", + "recategorize", + "always_keep", + "boost" + ], + "type": "string" + }, + "match": { + "properties": { + "conditions": { + "items": { + "properties": { + "field": { + "enum": [ + "section", + "channel", + "source", + "title", + "priority", + "due_relative" + ], + "type": "string" + }, + "op": { + "enum": [ + "equals", + "not_equals", + "contains" + ], + "type": "string" + }, + "value": { + "items": { + "maxLength": 200, + "type": "string" + }, + "maxItems": 20, + "minItems": 1, + "type": "array" + } + }, + "required": [ + "field", + "op", + "value" + ], + "type": "object" + }, + "maxItems": 10, + "minItems": 1, + "type": "array" + }, + "op": { + "default": "all", + "enum": [ + "all", + "any" + ], + "type": "string" + } + }, + "required": [ + "conditions" + ], + "type": "object" + }, + "origin": { + "properties": { + "count": { + "default": 0, + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "from": { + "enum": [ + "rejections", + "manual" + ], + "type": "string" + }, + "rejection_ids": { + "default": [], + "items": { + "type": "string" + }, + "maxItems": 50, + "type": "array" + } + }, + "required": [ + "from" + ], + "type": "object" + }, + "params": { + "default": {}, + "properties": { + "channel": { + "description": "Where it came from, which is what makes an item legible days later. self = the user thought of it themselves, no external trigger. teams = a Teams message or chat. email = an email thread. meeting = raised in or arising from a meeting. other = anywhere else. Describe the ORIGIN, not who added it — an item you add from an email is still email.", + "enum": [ + "self", + "teams", + "email", + "meeting", + "other" + ], + "type": "string" + }, + "priority": { + "enum": [ + "low", + "medium", + "high" + ], + "type": "string" + }, + "section": { + "description": "Which list it belongs in. action = something the user owes someone or themselves. waiting = something owed TO them; they are blocked and the next move is not theirs. note = worth knowing, no action attached. Pick waiting over action whenever the ball is in someone else's court — the distinction is the whole point of the two lists.", + "enum": [ + "action", + "waiting", + "note" + ], + "type": "string" + } + }, + "type": "object" + }, + "reason": { + "description": "Why this rule exists, in the user's terms. Shown next to it on the rules page.", + "maxLength": 300, + "minLength": 1, + "type": "string" + }, + "status": { + "enum": [ + "active", + "paused" + ], + "type": "string" + } + }, + "required": [ + "action", + "match", + "reason", + "origin" + ], + "type": "object" + } + }, + "required": [ + "kind", + "rule" + ], + "type": "object" + }, + { + "description": "Suggest changing an existing rule — usually to narrow one that is too broad.", + "properties": { + "kind": { + "const": "update_rule", + "type": "string" + }, + "patch": { + "properties": { + "action": { + "enum": [ + "exclude", + "recategorize", + "always_keep", + "boost" + ], + "type": "string" + }, + "match": { + "properties": { + "conditions": { + "items": { + "properties": { + "field": { + "enum": [ + "section", + "channel", + "source", + "title", + "priority", + "due_relative" + ], + "type": "string" + }, + "op": { + "enum": [ + "equals", + "not_equals", + "contains" + ], + "type": "string" + }, + "value": { + "items": { + "maxLength": 200, + "type": "string" + }, + "maxItems": 20, + "minItems": 1, + "type": "array" + } + }, + "required": [ + "field", + "op", + "value" + ], + "type": "object" + }, + "maxItems": 10, + "minItems": 1, + "type": "array" + }, + "op": { + "default": "all", + "enum": [ + "all", + "any" + ], + "type": "string" + } + }, + "required": [ + "conditions" + ], + "type": "object" + }, + "params": { + "properties": { + "channel": { + "description": "Where it came from, which is what makes an item legible days later. self = the user thought of it themselves, no external trigger. teams = a Teams message or chat. email = an email thread. meeting = raised in or arising from a meeting. other = anywhere else. Describe the ORIGIN, not who added it — an item you add from an email is still email.", + "enum": [ + "self", + "teams", + "email", + "meeting", + "other" + ], + "type": "string" + }, + "priority": { + "enum": [ + "low", + "medium", + "high" + ], + "type": "string" + }, + "section": { + "description": "Which list it belongs in. action = something the user owes someone or themselves. waiting = something owed TO them; they are blocked and the next move is not theirs. note = worth knowing, no action attached. Pick waiting over action whenever the ball is in someone else's court — the distinction is the whole point of the two lists.", + "enum": [ + "action", + "waiting", + "note" + ], + "type": "string" + } + }, + "type": "object" + }, + "reason": { + "description": "Why this rule exists, in the user's terms. Shown next to it on the rules page.", + "maxLength": 300, + "minLength": 1, + "type": "string" + }, + "status": { + "enum": [ + "active", + "paused" + ], + "type": "string" + } + }, + "type": "object" + }, + "reason": { + "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", + "maxLength": 500, + "type": "string" + }, + "rule_id": { + "description": "The \"id\" of an existing item, exactly as returned by get_document.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + } + }, + "required": [ + "kind", + "rule_id", + "patch" + ], + "type": "object" + }, + { + "description": "Suggest deleting a rule outright.", + "properties": { + "kind": { + "const": "remove_rule", + "type": "string" + }, + "reason": { + "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", + "maxLength": 500, + "type": "string" + }, + "rule_id": { + "description": "The \"id\" of an existing item, exactly as returned by get_document.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + } + }, + "required": [ + "kind", + "rule_id" + ], + "type": "object" + }, + { + "description": "Suggest pausing a rule, leaving it in the list so it can be resumed.", + "properties": { + "kind": { + "const": "pause_rule", + "type": "string" + }, + "reason": { + "description": "Why you are suggesting this, in one line. Shown next to the row when he reviews it, so it is what he judges the suggestion on — \"She has asked twice and the second went unanswered\" beats \"found in email\".", + "maxLength": 500, + "type": "string" + }, + "rule_id": { + "description": "The \"id\" of an existing item, exactly as returned by get_document.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + } + }, + "required": [ + "kind", + "rule_id" + ], + "type": "object" + } +]
6 tool updates
- First observed
add_item - First observed
complete_item - First observed
get_document - First observed
manage_focus - First observed
manage_rule - First observed
put_proposal
Related MCP Connectors
Evidence-backed follow-through memory for what you owe, await, and need to remember.
Shared task queue for humans and AI agents: leases, handoffs, approvals and signed receipts.
- AgentdaOAuthcom.myagentda
Agent-native task management: your AI agent is the interface. Delegate to anyone by email.
Personal finance ledger for AI agents — query spending, track bills, forecast cash flow.
Related MCP Servers
- FlicenseAqualityBmaintenanceTracks meeting commitments, verifies completion via Slack/email/Linear, and sends escalating nudges with manager escalation when deadlines slip.14-
- FlicenseNot gradedqualityFmaintenanceEnables AI-native task and project management through natural language conversation with Claude, eliminating app-switching by letting you add actions, manage projects across multiple areas of focus, and maintain a GTD-style execution system directly in chat.1-
- AlicenseNot gradedqualityCmaintenanceEnables turning conversations into prioritized, trackable actions with dates and natural time hints, while preserving original context as private online notes.MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.