Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nyyon-planner Plan my day with the carry-over ritual"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local MCP server for day planning. Your AI assistant runs the planning conversation; this tool gives it memory and a method: saved day plans, weekly objectives, an honest carry-over ritual, and a rendered day card you can pin anywhere. No network, no model, nothing leaves the machine — every plan is a plain JSON file you can grep, diff, and sync however you like.
Extracted from the Daily Planner inside the Nyyon Command Center, where it plans real days.
Ground first — one plan_day call returns today's plan, the week's objectives, and what's still open from recent days.
The carry-over ritual — unfinished items from past days surface first, and each gets a decision: done, carry over, or drop. Nothing silently disappears.
Four questions, one at a time — what do you want done today? any constraints? how many Focus Sessions fit? aligned with the week?
Focus Sessions are the backbone — ~2-hour deep-work blocks, each with one concrete deliverable (what will exist when it's done). Everything else is supporting blocks and to-dos.
Strategic or wing-it — a day either serves the week's 2-4 objectives or it deliberately doesn't. Both are legitimate; the plan says which.
The full brief ships in the server (plan_day returns it), so any MCP-capable assistant picks up the method with zero setup.
Related MCP server: AgentOS
open_panel starts a tiny loopback-only web page — the day in the same aesthetic, but every control is real: tap a block or a to-do and it writes to the plan store; type a note ("replan the afternoon, I'm drained") and it's recorded. Each interaction becomes a signal, and the next plan_day call delivers all of them to the assistant exactly once as panel_activity — so the conversation always opens already knowing what you did with your hands. No fake buttons, no push magic: an honest pull on the next turn.
Loopback only, token-guarded URL, dies with the MCP process; the state is in the files either way.
Because every day is one JSON file with done-flags, review is just a read. review_period computes any range (defaults to the last 7 days):
completion rates — focus sessions, blocks, to-dos, and the starred few, planned vs done
the slippage list — items that appeared on multiple days before resolving, and the ones still stuck (the honest follow-up feed)
strategic vs wing-it ratio, and every touched week's objectives with their hit rate
a review_brief telling the assistant how to narrate the retro: lead with what shipped, read rates as patterns not grades, close by drafting next week's objectives
"Do my week in review" or "how did this month actually go" becomes one tool call plus an honest conversation.
render_plan draws any day as a clean 1080×1350 PNG — Focus Sessions accented, done items struck, the week's objectives at the foot:
tool | what it does |
| Start here. The planning brief + today's plan + the week + the carry-over feed, in one call. |
| Write the day: schedule blocks ( |
| Edit during the day — pass only the keys that change. |
| One day's plan, with its still-open items computed. |
| Recent past days with their open items — the carry-over feed. |
| Full-text search across every saved day. |
| The strategic layer: this week's 2-4 objectives. |
| Week/month analytics: completion rates, the slippage list, objectives hit rate + a retro narration brief. |
| The day as a shareable PNG day card. |
| The LIVE local page: real checkboxes + a note box; interactions surface as |
| Data dir, work week, theme — all env-overridable. |
npm install{
"mcpServers": {
"nyyon-planner": { "command": "node", "args": ["/ABSOLUTE/PATH/nyyon-planner/src/index.js"] }
}
}Or with the CLI: claude mcp add nyyon-planner -- node /ABSOLUTE/PATH/nyyon-planner/src/index.js
Everything is env-overridable (NYYON_PLANNER_*):
NYYON_PLANNER_DIR — where plans live (default ~/.nyyon-planner; plain JSON, one file per day)
NYYON_PLANNER_WORK_DAYS — comma list, 0=Sun..6=Sat (default 1,2,3,4,5; an Israeli work week is 0,1,2,3,4)
NYYON_PLANNER_WEEK_START — the week's anchor day (default: first work day). Weekend days roll forward to the coming week.
NYYON_PLANNER_TZ — the "today" boundary timezone (default: system)
NYYON_PLANNER_PAPER / INK / MUTE / LINE / ACCENT / ACCENT_WASH — day-card colors (hex)
NYYON_PLANNER_FONT_SANS / FONT_MONO / FONT_FILES — day-card fonts (IBM Plex bundled)
NYYON_PLANNER_BRAND — the footer mark on the card
NYYON_PLANNER_OUT — where rendered cards are written (default <data dir>/cards)
npm test # store roundtrip, week anchoring, card render — in a temp dirBuilt like nyyon-figures: a local, offline MCP server where the calling assistant does the thinking and the tool does the persistence and the drawing. MIT.
The active configuration: data directory, work week (days, anchor, timezone), and day-card theme. All overridable via NYYON_PLANNER_* env vars.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It mentions the tool reads configuration and lists what is included, but does not explicitly state that it is read-only with no side effects. For a simple getter, the behavior is implied but not explicitly 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?
Single sentence with no wasted words. Information is front-loaded and precisely conveys the tool's output.
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 zero parameters and no output schema, the description lists exactly what the tool returns. It is sufficient for understanding the tool's purpose, though mentioning output format (e.g., JSON) could add clarity.
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?
There are no parameters, and schema coverage is trivially 100%. The description correctly implies no input is needed. No additional parameter details are necessary.
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?
Description clearly states that the tool shows active configuration including data directory, work week details, and day-card theme. It uses a specific verb ('show') and resource ('settings'), and the content is distinct from sibling tools which deal with plans and weeks.
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 usage guidance is provided. There is no mention of when to use this tool versus alternatives, or any prerequisites or context. While siblings are about different resources (plans, weeks), explicit guidance would improve selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most recent PAST day plans with their open (unfinished) items — the carry-over feed. Surface these at the start of planning and ask: done, carry over, or drop?
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | default 3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states it returns recent past plans with open items, but does not disclose whether it's read-only, what happens if no plans exist, scope limitations beyond the 'days' parameter, or any side effects. Lacks sufficient detail for a tool with zero annotation support.
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 that are front-loaded with the core purpose and include actionable guidance. No redundant or extraneous information. Highly 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 simple tool with one optional parameter and no output schema, the description covers the main use case but lacks details on output format (e.g., list of plans and items) and edge cases (e.g., no past plans, all completed). Could be more explicit to avoid ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'days' parameter, with a description of 'default 3'. The tool description adds no additional semantics or usage guidance beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'most recent PAST day plans with their open (unfinished) items', explicitly distinguishing it from siblings like read_plan (single plan) or search_plans (generic). The use-case as a 'carry-over feed' is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'Surface these at the start of planning and ask: done, carry over, or drop?' This tells when to use it and how to act on results. However, it does not explicitly list alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a local web panel for the day (loopback-only, token-guarded URL): REAL checkboxes for blocks, to-dos and objectives, plus a note box. Every interaction writes to the plan store and is reported back as panel_activity on the next plan_day call. Give the user the returned URL to open (or open it for them).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD; default today |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the panel is loopback-only, token-guarded, and that interactions write to the plan store and report as panel_activity on the next 'plan_day' call. This sufficiently informs the agent of side effects and security constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that fronts key information (local panel, token-guarded, features, side effects). While efficient, it could be broken into two sentences for clarity, but overall no wasted words.
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 one parameter, no output schema, and no annotations, the description covers purpose, behavior, usage, and return value (URL) adequately. It mentions interaction side effects with 'plan_day', providing sufficient context.
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?
Only one parameter (date) with 100% schema coverage. The description adds context that the default is today, but the schema already provides the format. No additional semantic nuance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a local web panel for the day, with specific features (checkboxes, to-dos, objectives, note box). It distinguishes itself from siblings like 'plan_day' and 'read_plan' by emphasizing interactive panel behavior.
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 advises giving the returned URL to the user or opening it for them, providing clear usage context. It does not explicitly state when not to use, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START HERE. One call returns: the planning brief (how to run the conversation), today's date, any existing plan for the day, this week's objectives, and the open items from recent days (the carry-over feed). Follow the brief, then save_plan.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD; default today |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns a planning brief, date, existing plan, objectives, and carry-over feed. No mention of side effects, but for a read-like operation this is sufficient; could be improved by noting any authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, efficient and front-loaded with 'START HERE'. Every sentence adds value, though the enumeration of returned items could be formatted more concisely.
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 no output schema, the description fully explains what the tool returns. The single optional parameter is well-documented. The tool is straightforward and the description covers all necessary context 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?
Only one optional parameter 'date' with schema description 'YYYY-MM-DD; default today'. Schema coverage is 100%, so baseline 3. Tool description does not add additional meaning beyond the schema; however, the context of date is implied by the tool's purpose.
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?
Clearly states it is the starting point for planning a day and enumerates the returned information (brief, date, plan, objectives, carry-over). Differentiates among siblings by indicating 'START HERE' and naming 'save_plan' as the next step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'START HERE' to indicate when to use, and directs 'Follow the brief, then save_plan' for subsequent action. Implicitly excludes other siblings by positioning itself as the entry point, though does not explicitly list when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one day's saved plan (schedule + to-dos + what's still open). date default today.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses read-only nature (Read), returned components, and default date, but does not cover error conditions, rate limits, or auth needs.
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?
Single 18-word sentence, front-loaded with purpose and parameter info. No superfluous words.
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?
Adequate for a simple read tool with one parameter and no output schema. Covers purpose, parameter default, and returned components. Minor gap: no parameter format or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds crucial default behavior ('date default today') that schema alone does not convey. Lacks format specification (e.g., YYYY-MM-DD).
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?
Clearly states verb (Read), resource (one day's saved plan), and scope (schedule, to-dos, what's still open). Distinguishes from siblings like read_week (week) and search_plans (search) by specifying single day.
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?
Implies usage for reading a daily plan, but no explicit when-to-use, when-not, or alternatives mentioned. Sibling names provide context but description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The strategic layer: this week's 2-4 objectives (or a given week anchor date). Strategic days align to these.
| Name | Required | Description | Default |
|---|---|---|---|
| week_start | No | week anchor YYYY-MM-DD; default the current week |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It describes a read operation (retrieving objectives) but lacks details on side effects, permissions, or results format. The name implies read-only, yet no explicit confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core function without extraneous words. It is front-loaded and efficient, earning 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 no output schema and simple input, the description should explain what 'objectives' are or what the tool returns. It lacks detail about return format or how results relate to other tools like read_plan, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the week_start parameter has a description noting format and default. The description adds 'or a given week anchor date' but does not substantially enhance meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates it reads weekly objectives (2-4 items) for a given week or current week. It uses 'strategic layer' to hint at its role but does not explicitly differentiate from sibling tools like read_plan or plan_day, though the context provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for high-level weekly objectives, but it does not state when not to use it (e.g., for daily details) or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a day's plan as a clean 1080x1350 PNG (Focus Sessions accented, done items struck, the week's objectives at the foot). Returns the file path — show the image inline. Great for sharing the day or pinning it somewhere visible.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| out_path | No | filename under the output dir; default <date>-card.png |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description is the sole source. It states the output is a PNG file and includes rendering details, but lacks information on side effects, required permissions, or potential costs.
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 dense sentences with no wasted words. Every detail serves a purpose: output format, dimensions, visual features, return value, and usage advice.
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 rendering tool with two optional parameters and no output schema, the description explains the output and purpose well. Minor omission: default date behavior if omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only out_path described). The description adds context about the image dimensions and content, but does not clarify the date format or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a day's plan as a 1080x1350 PNG with specific visual features. It distinguishes from siblings like read_plan (text) or plan_day (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests use cases: sharing or pinning the image. It mentions returning a file path to be shown inline, but does not explicitly note when to avoid or contrast with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Follow-up analytics across saved plans: per-day rollups, completion rates (focus sessions, blocks, to-dos, starred), the SLIPPAGE list (items that appeared on multiple days before resolving — and the ones still stuck), and every touched week's objectives. Defaults to the last 7 days; pass from/to for a month or any range. The result includes a review_brief telling you how to narrate it — follow it.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD; default today | |
| from | No | YYYY-MM-DD; default 6 days before `to` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key output components including a 'review_brief' for narration, but does not explicitly state that the tool is read-only or discuss any side effects. Without annotations, more explicit behavioral details would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences packed with information—lists outputs, defaults, and range option—without unnecessary words. Efficient and well-structured.
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?
Covers what the tool returns (per-day data, rates, slippage, objectives, review_brief) and how to use it. Without an output schema, this description is adequate for an agent to understand the tool's purpose and output.
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 already covers both parameters with descriptions. The description reinforces the default 7-day range and adds context for using from/to for arbitrary ranges, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Follow-up analytics across saved plans' and enumerates specific outputs (per-day rollups, completion rates, slippage list, objectives), making it distinct from sibling tools like read_plan or read_week.
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?
States default range (last 7 days) and how to specify a custom range ('pass from/to for a month or any range'), providing clear usage context. No explicit exclusions or alternatives, but the context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write (or replace) a day's plan. schedule = time blocks; mark each ~2h Focus Session focus:true with ONE concrete deliverable. todos with star:true for the critical few. mode "strategic" (aligned to the week — set weekly_ref to the week anchor) or "wing_it".
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD; default today | |
| mode | No | ||
| todos | No | ||
| summary | No | one line: what this day is about | |
| schedule | Yes | ||
| weekly_ref | No | the aligned week's anchor date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the write/replace behavior and structural hints, but lacks details on permissions, rate limits, overwrite vs merge behavior, or side effects, leaving gaps for a mutation tool.
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 but dense, with a run-on second sentence. It front-loads the core action but could be better structured (e.g., bullet points) for readability. Every sentence adds value, though.
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 6 parameters, no output schema, and moderate complexity, the description provides enough to understand the key constructs (focus, star, mode). However, it omits details on default date, summary usage, and id fields, and doesn't explain return behavior, making it somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, and the description adds meaningful context for key fields like schedule (time blocks), focus (with deliverable), star (critical few), and mode (strategic vs wing_it). However, it does not describe all parameters (e.g., date, summary, id) or compensate fully for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Write (or replace) a day's plan' identifying the verb and resource. While it distinguishes from siblings like update_plan by implying upsert behavior, it doesn't explicitly differentiate from plan_day, leaving some 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?
Provides contextual usage tips (e.g., mark focus sessions with deliverables, use star for critical todos, mode alignment). However, it doesn't explicitly state when to use this tool versus alternatives like update_plan or plan_day, relying on implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all saved day plans (summaries, blocks, to-dos). Empty query = most recent.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the search scope and empty query behavior, but omits details like search scope (user-owned vs. all), pagination, or rate limits. Adequate but not thorough.
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, front-loaded sentences with no redundancy. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 2 params and no output schema, the description covers core function and an edge case. However, it lacks details about return format or ordering, which would help completeness.
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 description must compensate. It only adds meaning for 'query' (optional, empty returns recent), but 'limit' is unexplained. The description adds marginal value beyond the schema's bare types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs full-text search across saved day plans, specifying the content areas (summaries, blocks, to-dos) and the behavior for empty query. This distinguishes it from siblings like list_recent_plans (listing) and read_plan (single read).
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 (searching across plans) and notes the empty query fallback, but does not explicitly state when not to use or name alternatives. Guidance is present but limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the week's 2-4 strategic objectives (short outcome statements, or {text, done}). week_start default = the current week's anchor.
| Name | Required | Description | Default |
|---|---|---|---|
| objectives | Yes | ||
| week_start | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Discloses default behavior for week_start but does not state whether the tool overwrites existing objectives, if it is destructive, or any side effects. Lacks information on execution behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise at one sentence plus a default note. Information is front-loaded but could be more structured with explicit formatting.
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?
Provided context is adequate for a simple setter tool: identifies number of objectives and default. However, lacks information about success/failure responses, prerequisites, or how it interacts with sibling tools like 'save_plan'.
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%; description adds meaning by explaining objectives should be short outcome statements or objects with {text, done}, and week_start defaults to current week anchor. However, does not fully describe the format of week_start or the anyOf structure in objectives.
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?
Clearly describes the action 'Set' and the resource 'week's strategic objectives', specifying a count of 2-4. Distinguishes from sibling tools like 'read_week' (read vs set) and 'plan_day' (week vs day).
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 explicit guidance on when to use this tool versus alternatives such as 'read_week', 'update_plan', or 'plan_day'. Only mentions a default for week_start, but does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit a plan during the day — mark blocks/to-dos done, add items, reshuffle. Pass ONLY the keys you are changing; everything else is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| mode | No | ||
| todos | No | ||
| summary | No | ||
| schedule | No | ||
| weekly_ref | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It indicates a mutating operation (edit, mark done, add, reshuffle) and partial update behavior. However, it does not mention idempotency, authorization needs, or what happens on failure. Basic transparency but not comprehensive.
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 long, front-loading the action verbs and then providing the critical partial-update instruction. Every sentence adds value with no fluff.
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 6 parameters, no schema descriptions, no output schema, and a complex nested structure (todos, schedule), this description is too minimal. It omits parameter semantics, return format, and error conditions, leaving significant gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters. The description hints at `todos` and `schedule` via 'mark blocks/to-dos done, add items, reshuffle' but does not explain `date`, `mode`, `summary`, or `weekly_ref`. The agent gains little parameter meaning beyond the schema structure.
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 that the tool edits an existing day plan, with specific actions like marking items done, adding, and reshuffling. The title reinforces 'Update part of a day plan', and the verbs distinguish it from creating or reading plans.
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 key usage guidance by instructing to 'Pass ONLY the keys you are changing; everything else is kept.' However, it does not mention when to use this tool versus alternatives like plan_day or save_plan, nor does it give context about prerequisites or restrictions.
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.
v0.3.0get_settingslist_recent_plansopen_panelplan_dayread_planread_weekrender_planreview_periodsave_plansearch_plansset_weekupdate_planScored across 12 tools
Each tool has a distinct purpose: configuration, daily planning (start/read/save/update/list/search), weekly objectives (read/set), visualization (render/interactive panel), and review (analytics). No two tools overlap in function; descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern with underscores (e.g., get_settings, plan_day, save_plan, update_plan, list_recent_plans, read_week, set_week, open_panel, review_period). No mixing of conventions.
12 tools is well within the ideal range (3-15) for a planner domain. Each tool covers a necessary operation without being excessive or sparse.
The tool surface covers the core CRUD-like operations for plans and weeks, plus search, visualization, and analytics. Minor gap: no explicit delete tool, but overwriting (save_plan) serves as replacement. Overall, the set is nearly complete for its purpose.
MIND MCP Server — 31 tools. Persistent AI memory: knowledge graph, LIFE tasks, CRM, 50+ models.
Persistent, verbatim, searchable memory for AI assistants — one memory across every MCP client.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Work management where AI agents are first-class members: tasks, projects, memory over hosted MCP
