Helps you pick one New Year's resolution you will actually keep, matched to your life now.
Scored across 3 tools
get_resolution (lookup by id/name/area+feeling), pick_resolution (quiz-driven single recommendation), and search_resolutions (browse the bank) have genuinely different jobs. The only friction is that get_resolution and pick_resolution both return a single resolution, so an agent must read the descriptions to know that one is a lookup and the other runs the quiz engine.
All three follow a clean verb_noun snake_case pattern (get_, pick_, search_). The minor deviation is number agreement — get_resolution and pick_resolution are singular while search_resolutions is plural — but the verbs remain predictable and readable.
Three tools is on the thin edge but matches a deliberately narrow domain: browse the bank, run the quiz for one pick, and fetch full detail for one action. Each tool clearly earns its place, though the surface is minimal enough that a fourth (e.g. listing valid quiz choices) would not feel redundant.
The lifecycle is covered: discover via search_resolutions, generate via pick_resolution, expand via get_resolution, with error paths documented. The main gap is that the valid quiz answer choices and the full set of areas/feelings are only surfaced through error messages rather than a dedicated enumeration tool.
Returns the full detail for one action in the bank of 30: its life area and feeling, the first move for week one, the resolution at all three time levels (30 minutes, 2 hours, and 5 hours a week), the guard line for each kind of past failure, and up to 3 similar actions. Accepts an action id or name from pick_resolution or search_resolutions, or an area plus a feeling. When nothing matches, the result says so and gives example ids.
| Name | Required | Description | Default |
|---|---|---|---|
| off | No | Optional, with area: one feeling, e.g. 'drained' or 'stuck'. | |
| area | No | Optional, with off: one life area, e.g. 'health' or 'home'. | |
| resolution_id | No | Action id from pick_resolution or search_resolutions (e.g. 'take-a-short-walk'), or an action name like 'take a short walk'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), and the description adds genuinely new behavior: the finite size of the bank (30), the exact return payload, and the miss behavior ('the result says so and gives example ids') rather than an error. It does not cover ordering or how the 3 similar actions are ranked, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose, then the accepted inputs, then the failure case — a sensible order. The field enumeration in the first sentence is long but each item is substantive for an agent with no output schema; minor redundancy with the schema's own id/name wording keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and all-optional parameters, the description carries the full burden and discharges it: it enumerates return contents, lists valid input modes, and explains the no-match outcome. Nothing an agent needs in order to invoke and interpret this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters, including the area+off pairing and the id/name acceptance. The description restates the same acceptance modes ('an action id or name... or an area plus a feeling') without adding format, precedence, or ambiguity rules (e.g., what happens if both id and area are supplied), so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns the full detail for one action in the bank of 30') and enumerates exactly what that detail includes: life area, feeling, first move, three time-level resolutions, guard lines, and similar actions. An agent can distinguish it from pick_resolution and search_resolutions without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description routes the agent clearly by stating inputs come 'from pick_resolution or search_resolutions, or an area plus a feeling', which implies this is the detail-fetch step after picking or searching. It does not state an explicit when-not-to-use or contrast the siblings' own purposes, so it stops short of full 5-level routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One resolution, not ten: the single pick small enough to still be alive in December, with a first step, a weekly check-in, and a letter to future you. Returns ONE resolution from a fixed bank of 30 actions, computed by the same quiz engine as keeponeresolution.com. The four answers pick the action and size it: the life area and what felt off choose the action, the weekly time sizes the dose (each action has its own dose at each time level, always inside the time they can give), and what made past plans fail picks the guard line. The result carries the resolution, a first move for week one (week one runs at about half the dose, 5-minute floor, and the result states that week-one size plus a stakes line counted from the plan's own weekly sessions), the guard line, a copyable weekly check-in prompt built for that resolution, a short future-you note written for that same plan, share text, and a link to keeponeresolution.com. There are 360 possible answer paths and 90 distinct resolutions. When an answer is missing or not one of the quiz choices, the result says what is needed and lists the valid choices. Example: health, felt drained, 30 minutes a week, forgot last time returns the single pick 'Take a short walk: 10 min, 3x a week.'
| Name | Required | Description | Default |
|---|---|---|---|
| off | Yes | What felt off this year: 'I felt drained a lot.', 'Things piled up on me.', 'I felt stuck in place.', 'I drifted from good habits.', or 'I felt alone a lot.' Plain words work too, e.g. 'drained', 'stuck'. | |
| area | Yes | What part of life needs care: 'Body and health', 'Money', 'Home', 'Work', 'Family and friends', or 'Mind and calm'. Plain words work too, e.g. 'health', 'my job', 'money'. | |
| fail | Yes | What made past plans fail: 'I tried to do too much.', 'I just forgot to do it.', 'Life got busy and loud.', or 'I got bored and quit.' Plain words work too, e.g. 'forgot', 'too busy'. | |
| time | Yes | How much time they can give: '30 minutes a week', '2 hours a week', or '5 hours a week'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and closed-world, so the description earns credit for adding deterministic-engine context: 360 answer paths, 90 distinct resolutions, fixed bank of 30 actions. It also discloses the fallback behavior when an answer is missing or invalid ('the result says what is needed and lists the valid choices'), which is genuinely useful operational detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening is well front-loaded, but the middle collapses into a single very long sentence enumerating every returned field, plus a parenthetical about week-one sizing and stakes lines that is dense and hard to parse. The example at the end earns its place, but the body could be broken into shorter statements without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns and does so thoroughly: resolution, first move, guard line, check-in prompt, future-you note, share text, and site link. It also states the answer-validation behavior and determinism, leaving nothing an agent needs in order to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description goes further by mapping each parameter to its effect on the output: area and 'off' choose the action, time sizes the dose, and 'fail' picks the guard line. That causal mapping is meaning the schema itself does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('pick one resolution') and immediately scopes it as a single result from a fixed bank of 30 actions computed by a quiz engine. The phrase 'One resolution, not ten' implicitly separates it from the plural search_resolutions sibling, though neither sibling is named explicitly.
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?
Usage is implied rather than stated: the agent learns it must supply four quiz-style answers about area, what felt off, weekly time, and past failure. There is no explicit 'use this instead of get_resolution/search_resolutions when...' routing, so the agent must infer the boundary between picking a new resolution and retrieving or searching existing ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the fixed bank of 30 resolution actions by life area, by what felt off, by a keyword, or by a mix of those. Returns up to 30 matches in bank order, each with its area and feeling, plus the total number of matches, including when there are none. Use it to browse what the quiz can pick before running the full quiz with pick_resolution.
| Name | Required | Description | Default |
|---|---|---|---|
| off | No | Optional filter: one feeling: drained, piled up, stuck, drifted, or alone. | |
| area | No | Optional filter: one life area: 'Body and health', 'Money', 'Home', 'Work', 'Family and friends', or 'Mind and calm'. | |
| limit | No | Optional: max results to return, 1 to 30. Default 10. | |
| keyword | No | Optional: a plain word to match against action names, e.g. 'walk', 'meal', 'savings'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, and non-destructive, so safety is covered. The description adds genuinely useful behavior not in annotations: results come back in fixed bank order, capped at 30, each with area and feeling, plus a total match count even when empty. It stops short of saying how filters combine (AND vs OR) or whether keyword matching is case-insensitive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what is searched, then the return contract, then the usage routing. Every sentence carries distinct information and nothing is repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return contract itself and does so adequately: result count, per-item fields, ordering, cap, and the empty case. For a zero-required-parameter read-only search over a fixed 30-item bank, an agent has everything needed to invoke and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a 3 is the baseline, but the description adds real meaning by implying the filters can be mixed ('or by a mix of those'), which the schema never states, and by tying the 30-result ceiling to the bank size. It does not clarify matching semantics for keyword or whether 'off' must pair with a valid area.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource plus the exact search axes ('by life area, by what felt off, by a keyword, or by a mix'), and it scopes the data set as a 'fixed bank of 30 resolution actions.' It clearly separates itself from pick_resolution but never mentions get_resolution, so one sibling boundary remains unstated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete when-to-use: browsing what the quiz can pick prior to running the full quiz via pick_resolution. That is a real routing decision, but there is no guidance on when to prefer get_resolution or on what to do when zero matches come back beyond the fact that the count will show it.
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.
get_resolutionpick_resolutionsearch_resolutionsLife-balance task manager that prioritises your tasks to restore balance across your life areas.
AI accountability partner: turn goals into milestones and tasks, and get today's next step.
Mobile-first AI life planner — turn goals into daily, synced tasks from your AI assistant.
Turn any goal with a deadline into a private, gamified, evidence-based execution calendar.
Add one secure layer between your agents and this server.
