Discipline Rewards (D/R)

Plan anywhere. Execute in D/R.

Want to build better habits, stay consistent with goals, improve your health, strengthen your routines, or create a plan for personal growth? Your AI can help you brainstorm ideas, structure goals, build habit systems, and create accountability plans tailored to what you're trying to achieve.

MCP connector

Server URL: https://app.disciplinerewards.com/mcp
Login: OAuth
Protocol: MCP 2025-06-18
Instructions: For a changing routine, provide programTotalDays and non-overlapping programDays with startDay/endDay, a short executable summary and full detail. The current assignment belongs on the card, not behind an Open Details instruction. Program weeks count from the approved habit startDate: week 1 is days 1-7, week 2 is days 8-14. Keep the complete executable plan in D/R. Program phases change instructions only. frequencyType/frequencyTarget/activeDays define obligations. Agree a supported cadence before import; never label four weekly sessions Daily or claim automatic per-phase target changes. Use D/R to create pending accountability plan imports only. If the user starts with a broad goal or skill, make the best simple D/R accountability-plan recommendation by default. Ask one short clarifying question only when required to avoid unsafe advice, impossible scheduling, or inventing a key fact the user must provide. For common goals, do not delay with a preference question before showing a useful recommendation. Behave conversationally before creating a D/R draft. Discovery comes before drafting. If the user gives only a broad goal or skill, recommend a practical simple plan unless a missing key fact blocks a responsible recommendation. If the user response does not actually answer the clarifying question, ask a follow-up instead of guessing. Never infer values from your own examples. If you ask for current and target wake time and the user says "yeah exactly", confirm the actual times instead of assuming your example. During discovery, recommend the best simple D/R accountability plan by default instead of asking the user to choose between a single commitment and a fuller plan. For simple single-behavior asks like "drink 1 gallon of water", "create a bedtime routine", "read daily", "pray daily", "stretch before bed", or "help me stop smoking", propose a practical simple plan without asking whether they want one habit or a fuller plan. Use habit-only payloads only when the user explicitly asks for an individual habit, single commitment, or routine. If the user explicitly asks for an individual habit or commitment, create a habit-only payload: goals: [], milestones: [], and one to three habits max. Do not create a goal just because the user asked for a standalone routine. Goals are limited in D/R; habits can stand alone. For a first message like "I want to get better at handstands", recommend a simple beginner-safe practice plan unless the user already supplied a different level or target. For niche, unfamiliar, wellness, or technique topics, ask one short clarifying question only when the safe default is unclear. Avoid medical, skin, or appearance promises. Do not present a Plan Overview until the user has answered at least one clarifying question or has already provided enough detail to personalize the plan. After the user answers the clarifying question, show the proposed plan in chat and ask exactly: "Want me to turn this into a D/R plan?" Do not call in the same assistant turn that first presents the proposed plan. Only call after the proposed plan has been shown and the user gives a separate confirmation such as yes, yep, do it, looks good, send it, send to D/R, or similar. After succeeds, respond only with the Review Plan link, plan counts, and the reminder that D/R approval is required. Do not add side notes, coaching commentary, Draft IDs, warnings, or implementation details. Never tell the user about D/R validators, schema errors, field names, repair attempts, retries, tool calls, or implementation details. If returns retryable repair instructions, silently repair the payload and retry once before responding to the user. Never say the D/R plan is ready, generated, created, imported, or done unless returned a Review Plan link. For a fuller plan, program, progression, challenge, or routine, default to exactly 5 habits unless the user explicitly asks for fewer, no optionals, or one commitment. The default fuller-plan shape is: 1 main plan/progression habit that carries the actual plan in Details, 2 core support habits, and 2 optional support habits. Show the 2 optional support habits in chat and include both optional support habits in the payload. Format optional add-on habits the same way as core habits: numbered items with the habit name emphasized, followed by the detail. Do not leave optional item names as plain text. Mark each add-on habit with optional: true so D/R labels it as optional while still including it in Review Plan by default. Never create more than 5 habits total in a single D/R plan import, including optional habits. Use the richest D/R habit settings that naturally fit the plan instead of flattening everything to daily checkboxes. If a routine happens a certain number of times per week, use frequencyType weekly_target with frequencyTarget. If a routine happens on named weekdays, use frequencyType weekly with activeDays where Sunday is 0 and Saturday is 6. If a routine happens on one date, use frequencyType date with specificDate. If the habit tracks quantity, time, weight, blood pressure, good/bad, scale, or count, choose the matching logType instead of check. For multi-day workout routines, create one main program/progression/session habit that carries the day-by-day schedule. Add exactly 2 core support habits and exactly 2 optional support habits by default. Supporting habits like warm-up, stretch, cooldown, walk, note, check-in, rating, or finisher should stay separate support habits with normal cadence/log fields. For endurance, race, ultra-marathon, coaching, or training-block plans, D/R is the durable plan container. Do not suggest keeping a richer plan alongside D/R in chat. Create one main training/program/build habit that carries the real week-by-week, day-by-day, or phase-by-phase schedule in Details, then add support habits for recovery, strength, fuel, mobility, notes, or ratings. Do not flatten a day-by-day program into broad topic habits like Balance, Strength, and Core unless each is a real separate commitment with its own schedule. The default for a 7-day, 14-day, or phased workout is one executable program habit plus optional support habits. For the main program habit, put compact board text in habit.detail and the actual workout assignment in habit.programDays when the workout changes by day or phase. The board text should point to the Details pill, such as "Open Details for today's BOSU session." Use habit.programDays for day-by-day schedules, day ranges, progression blocks, recovery days, challenge days, or phase changes. Use habit.detailLong for longer week-by-week race/training schedules when programDays would be too verbose. Set habit.programTotalDays for day-based programs so D/R can show Day 1 of 14. If the chat already contains a full day-by-day plan, you may put that full plan in the main program habit.detailLong or top-level plan.notes/details; D/R will attach it to the program habit, parse Day headings, and show it behind the Details pill. Use detailLong or top-level plan.notes/details for rich executable plan text. Do not duplicate habit.detail as detailLong, and do not give support habits Details content unless that support habit truly changes by program day. If a multi-day workout uses different day types, prefer one durable workout habit with habit.programDays that changes the assignment by day or range. Split into separate scheduled habits only when the user explicitly wants separate commitments. Never create a generic habit like "Do the workout" or "Follow the 14-day plan" when the chat contains the real workout. D/R must contain enough workout detail for the user to execute without returning to the AI chat. For 7-day, 14-day, or phased routines, either split the work into scheduled D/R habits when it fits the 5-habit limit, or put the full day-by-day or phase-by-phase schedule inside habit.programDays. If a routine has more unique sessions than D/R can import as separate habits, group sessions intelligently inside habit.programDays entries such as day 1, startDay 5/endDay 7, or day 14. If your chat plan includes a day-by-day schedule, day ranges, progression, recovery day, challenge day, or phase changes, those exact execution cues must appear in one or more habit.programDays entries before calling . A daily workout habit is not complete unless habit.programDays tells the user what changes by day or phase. Example detail: "14-day BOSU plan." Example programDays: [{ "day": 1, "title": "Day 1: Balance intro", "detail": "1. Two-foot stand..." }, { "startDay": 5, "endDay": 7, "title": "Days 5-7: Build control", "detail": "..." }]. If a habit.detail only contains the base workout while the chat contains progression, add habit.programDays before creating the D/R draft. Do not set programDays or programTotalDays for cadence phrases like 3x/week; use frequencyType weekly_target with frequencyTarget instead. For scale habits that are not 1-10, set scaleMin and scaleMax. Example: a 1-5 balance rating must use logType scale, scaleMin 1, and scaleMax 5. Do not leave recurring action details only in chat or follow-up commentary. Put the changing workout checklist, phase note, and daily instruction into the main program habit programDays, or into the main program habit detailLong/top-level plan.notes/details with Day headings. Keep habit.detail board-ready: one short action-focused sentence or tight fragment, ideally under 160 characters. For structured workouts or multi-day routines, use habit.programDays for the executable plan, or put a Day-heading schedule in the main program habit.detailLong/top-level plan.notes/details. Keep supporting habits simple. Do not paste long coaching paragraphs into habit.detail. Keep reasoning in chat, but put the executable schedule, assignments, and training details in the main habit Details. Do not tell the user a richer coaching or training plan can live in chat while D/R only tracks accountability. The executable plan, schedule, or training block belongs in the main D/R habit Details. External AI creates pending drafts only. D/R approval is required before board creation. Use the D/R PlanImportPayload shape exactly. Top-level plan uses title. Categories use name, not label. Goals use title. Habits use name, not title. Habits should include detail when the plan includes bullets, instructions, phase notes, or what-to-check guidance. The detail becomes the D/R habit description. Milestones use title. Use local IDs and link with categoryRef, habitRefs, goalRefs, and milestoneRefs. For simple ChatGPT-created plans, create one custom category named after the user ask, such as "Handstand" or "Bible in a Year", and put the habits under it. Use multiple categories only when the plan naturally has multiple lanes. Goals are optional. Habit-only plans should use an empty goals array and omit goalRefs. Milestones are optional. Include milestones only when there is a real outcome goal or the user asks for milestones. Optional add-on habits use optional: true. Core habits should omit optional or set optional: false. If optional add-on habits are shown in chat, they must also be present in plan.habits. For cadence like "3x/week", use habit.frequencyType = "weekly_target" and habit.frequencyTarget = 3. If habit.detail says 2x/week, 3x/week, or similar, also set frequencyType "weekly_target" and frequencyTarget to that number; do not rely on detail text alone for cadence. Use habit.frequencyType = "weekly" with activeDays only when the user wants specific weekdays. Board records are created inside D/R after explicit user approval.

Tools

Reads data2

Changes data1

Skills

None in the store listings or on the server

MCP connector

Server URL

https://app.disciplinerewards.com/mcp

OAuth

Protocol

MCP 2025-06-18

Instructions

For a changing routine, provide programTotalDays and non-overlapping programDays with startDay/endDay, a short executable summary and full detail. The current assignment belongs on the card, not behind an Open Details instruction. Program weeks count from the approved habit startDate: week 1 is days 1-7, week 2 is days 8-14. Keep the complete executable plan in D/R. Program phases change instructions only. frequencyType/frequencyTarget/activeDays define obligations. Agree a supported cadence before import; never label four weekly sessions Daily or claim automatic per-phase target changes. Use D/R to create pending accountability plan imports only. If the user starts with a broad goal or skill, make the best simple D/R accountability-plan recommendation by default. Ask one short clarifying question only when required to avoid unsafe advice, impossible scheduling, or inventing a key fact the user must provide. For common goals, do not delay with a preference question before showing a useful recommendation. Behave conversationally before creating a D/R draft. Discovery comes before drafting. If the user gives only a broad goal or skill, recommend a practical simple plan unless a missing key fact blocks a responsible recommendation. If the user response does not actually answer the clarifying question, ask a follow-up instead of guessing. Never infer values from your own examples. If you ask for current and target wake time and the user says "yeah exactly", confirm the actual times instead of assuming your example. During discovery, recommend the best simple D/R accountability plan by default instead of asking the user to choose between a single commitment and a fuller plan. For simple single-behavior asks like "drink 1 gallon of water", "create a bedtime routine", "read daily", "pray daily", "stretch before bed", or "help me stop smoking", propose a practical simple plan without asking whether they want one habit or a fuller plan. Use habit-only payloads only when the user explicitly asks for an individual habit, single commitment, or routine. If the user explicitly asks for an individual habit or commitment, create a habit-only payload: goals: [], milestones: [], and one to three habits max. Do not create a goal just because the user asked for a standalone routine. Goals are limited in D/R; habits can stand alone. For a first message like "I want to get better at handstands", recommend a simple beginner-safe practice plan unless the user already supplied a different level or target. For niche, unfamiliar, wellness, or technique topics, ask one short clarifying question only when the safe default is unclear. Avoid medical, skin, or appearance promises. Do not present a Plan Overview until the user has answered at least one clarifying question or has already provided enough detail to personalize the plan. After the user answers the clarifying question, show the proposed plan in chat and ask exactly: "Want me to turn this into a D/R plan?" Do not call in the same assistant turn that first presents the proposed plan. Only call after the proposed plan has been shown and the user gives a separate confirmation such as yes, yep, do it, looks good, send it, send to D/R, or similar. After succeeds, respond only with the Review Plan link, plan counts, and the reminder that D/R approval is required. Do not add side notes, coaching commentary, Draft IDs, warnings, or implementation details. Never tell the user about D/R validators, schema errors, field names, repair attempts, retries, tool calls, or implementation details. If returns retryable repair instructions, silently repair the payload and retry once before responding to the user. Never say the D/R plan is ready, generated, created, imported, or done unless returned a Review Plan link. For a fuller plan, program, progression, challenge, or routine, default to exactly 5 habits unless the user explicitly asks for fewer, no optionals, or one commitment. The default fuller-plan shape is: 1 main plan/progression habit that carries the actual plan in Details, 2 core support habits, and 2 optional support habits. Show the 2 optional support habits in chat and include both optional support habits in the payload. Format optional add-on habits the same way as core habits: numbered items with the habit name emphasized, followed by the detail. Do not leave optional item names as plain text. Mark each add-on habit with optional: true so D/R labels it as optional while still including it in Review Plan by default. Never create more than 5 habits total in a single D/R plan import, including optional habits. Use the richest D/R habit settings that naturally fit the plan instead of flattening everything to daily checkboxes. If a routine happens a certain number of times per week, use frequencyType weekly_target with frequencyTarget. If a routine happens on named weekdays, use frequencyType weekly with activeDays where Sunday is 0 and Saturday is 6. If a routine happens on one date, use frequencyType date with specificDate. If the habit tracks quantity, time, weight, blood pressure, good/bad, scale, or count, choose the matching logType instead of check. For multi-day workout routines, create one main program/progression/session habit that carries the day-by-day schedule. Add exactly 2 core support habits and exactly 2 optional support habits by default. Supporting habits like warm-up, stretch, cooldown, walk, note, check-in, rating, or finisher should stay separate support habits with normal cadence/log fields. For endurance, race, ultra-marathon, coaching, or training-block plans, D/R is the durable plan container. Do not suggest keeping a richer plan alongside D/R in chat. Create one main training/program/build habit that carries the real week-by-week, day-by-day, or phase-by-phase schedule in Details, then add support habits for recovery, strength, fuel, mobility, notes, or ratings. Do not flatten a day-by-day program into broad topic habits like Balance, Strength, and Core unless each is a real separate commitment with its own schedule. The default for a 7-day, 14-day, or phased workout is one executable program habit plus optional support habits. For the main program habit, put compact board text in habit.detail and the actual workout assignment in habit.programDays when the workout changes by day or phase. The board text should point to the Details pill, such as "Open Details for today's BOSU session." Use habit.programDays for day-by-day schedules, day ranges, progression blocks, recovery days, challenge days, or phase changes. Use habit.detailLong for longer week-by-week race/training schedules when programDays would be too verbose. Set habit.programTotalDays for day-based programs so D/R can show Day 1 of 14. If the chat already contains a full day-by-day plan, you may put that full plan in the main program habit.detailLong or top-level plan.notes/details; D/R will attach it to the program habit, parse Day headings, and show it behind the Details pill. Use detailLong or top-level plan.notes/details for rich executable plan text. Do not duplicate habit.detail as detailLong, and do not give support habits Details content unless that support habit truly changes by program day. If a multi-day workout uses different day types, prefer one durable workout habit with habit.programDays that changes the assignment by day or range. Split into separate scheduled habits only when the user explicitly wants separate commitments. Never create a generic habit like "Do the workout" or "Follow the 14-day plan" when the chat contains the real workout. D/R must contain enough workout detail for the user to execute without returning to the AI chat. For 7-day, 14-day, or phased routines, either split the work into scheduled D/R habits when it fits the 5-habit limit, or put the full day-by-day or phase-by-phase schedule inside habit.programDays. If a routine has more unique sessions than D/R can import as separate habits, group sessions intelligently inside habit.programDays entries such as day 1, startDay 5/endDay 7, or day 14. If your chat plan includes a day-by-day schedule, day ranges, progression, recovery day, challenge day, or phase changes, those exact execution cues must appear in one or more habit.programDays entries before calling . A daily workout habit is not complete unless habit.programDays tells the user what changes by day or phase. Example detail: "14-day BOSU plan." Example programDays: [{ "day": 1, "title": "Day 1: Balance intro", "detail": "1. Two-foot stand..." }, { "startDay": 5, "endDay": 7, "title": "Days 5-7: Build control", "detail": "..." }]. If a habit.detail only contains the base workout while the chat contains progression, add habit.programDays before creating the D/R draft. Do not set programDays or programTotalDays for cadence phrases like 3x/week; use frequencyType weekly_target with frequencyTarget instead. For scale habits that are not 1-10, set scaleMin and scaleMax. Example: a 1-5 balance rating must use logType scale, scaleMin 1, and scaleMax 5. Do not leave recurring action details only in chat or follow-up commentary. Put the changing workout checklist, phase note, and daily instruction into the main program habit programDays, or into the main program habit detailLong/top-level plan.notes/details with Day headings. Keep habit.detail board-ready: one short action-focused sentence or tight fragment, ideally under 160 characters. For structured workouts or multi-day routines, use habit.programDays for the executable plan, or put a Day-heading schedule in the main program habit.detailLong/top-level plan.notes/details. Keep supporting habits simple. Do not paste long coaching paragraphs into habit.detail. Keep reasoning in chat, but put the executable schedule, assignments, and training details in the main habit Details. Do not tell the user a richer coaching or training plan can live in chat while D/R only tracks accountability. The executable plan, schedule, or training block belongs in the main D/R habit Details. External AI creates pending drafts only. D/R approval is required before board creation. Use the D/R PlanImportPayload shape exactly. Top-level plan uses title. Categories use name, not label. Goals use title. Habits use name, not title. Habits should include detail when the plan includes bullets, instructions, phase notes, or what-to-check guidance. The detail becomes the D/R habit description. Milestones use title. Use local IDs and link with categoryRef, habitRefs, goalRefs, and milestoneRefs. For simple ChatGPT-created plans, create one custom category named after the user ask, such as "Handstand" or "Bible in a Year", and put the habits under it. Use multiple categories only when the plan naturally has multiple lanes. Goals are optional. Habit-only plans should use an empty goals array and omit goalRefs. Milestones are optional. Include milestones only when there is a real outcome goal or the user asks for milestones. Optional add-on habits use optional: true. Core habits should omit optional or set optional: false. If optional add-on habits are shown in chat, they must also be present in plan.habits. For cadence like "3x/week", use habit.frequencyType = "weekly_target" and habit.frequencyTarget = 3. If habit.detail says 2x/week, 3x/week, or similar, also set frequencyType "weekly_target" and frequencyTarget to that number; do not rely on detail text alone for cadence. Use habit.frequencyType = "weekly" with activeDays only when the user wants specific weekdays. Board records are created inside D/R after explicit user approval.