Skip to main content
Glama

Yinyang Masters

Habit Stack Planner

build_habit_stack
Read-onlyIdempotent

Build a structured 30-day habit plan from a proven habit framework that fits the daily time budget (habits longer than the remaining minutes are left out and listed), phased in week by week with check-in days. Optionally aligns each week with the numerology personal month if a birth date is given.

Input Schema

NameRequiredDescriptionDefault
goalYesdiscipline, energy, character, consistency or focus
birth_dateNoOptional date of birth YYYY-MM-DD to add the numerology personal month theme
start_dateNoStart date YYYY-MM-DD; defaults to today (UTC) if the user did not name a date
minutes_per_dayNoTime available per day in minutes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior — habits exceeding the remaining minutes are omitted but explicitly listed, phasing is weekly with check-in days — yet says nothing about the return shape, whether plans vary by goal, or how numerology themes are injected.

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 deliverable, then the constraints and the optional enhancement. No filler or restated title, and the parenthetical about omitted habits is placed exactly where it matters.

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 four-parameter, read-only generator with full schema coverage and no output schema, the description covers scope, constraints and optional enrichment well enough to call correctly. The remaining gap is the result format — the agent cannot say what the plan object looks like — which matters slightly more given no output schema exists.

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?

Schema coverage is 100% and the schema already explains each parameter including the enum values and the 5-240 minute bounds, so the baseline is met. The description still adds meaning by tying minutes_per_day to the exclusion-and-listing behavior and birth_date to the personal-month alignment, clarifying what those inputs actually change.

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?

States a specific verb and artifact ('Build a structured 30-day habit plan') plus the inputs that shape it (time budget, week-by-week phasing, optional numerology alignment). It is clearly distinguishable from sibling build_productivity_plan and from calculate_numerology/plan_my_personal_year, which it only optionally draws on.

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?

The description implies when to use it (a user wants a 30-day habit plan within a daily time budget) and names the optional birth-date condition, but it never states when to prefer this over build_productivity_plan or the numerology siblings, nor any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.