Familia

Create plan

familia_create_plan

Destructive

Use this when the user asks to create a Familia plan item for an event, trip, holiday, school, activity, care coverage, travel, chore block, or other scheduled family plan. If the same plan repeats across several days, weeks, or months, provide rrule and create one recurring plan instead of multiple one-time plans. If the user gives multiple dated or timed actions that clearly belong to the plan, such as flights, leaving for the airport, pickup, packing, check-in, or return travel, put the main event/trip in the plan and create each dated action as a relatedTasks entry instead of stuffing them all into notes. Do not use for standalone responsibility-style task reminders; use familia_create_task or familia_batch_write instead. Related tasks assigned to another household member can queue push notifications; schedules can trigger reminders, and delivered notifications cannot be recalled.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	No	Plan category. Use event when no more specific category fits.
`endAt`	No	Optional ISO datetime.
`notes`	No	Optional plan notes or context. Do not use notes as the only place for separate dated actions; use relatedTasks for each distinct action with its own date or time.
`rrule`	No	Optional RFC 5545 RRULE, e.g. FREQ=DAILY;INTERVAL=2 or FREQ=WEEKLY;BYDAY=MO,WE. Use this when the user says the same task or plan repeats across days, weeks, or months; create one recurring schedule instead of multiple one-time items unless each occurrence has different content. Requires the first dueAt/startAt as the anchor.
`title`	Yes	Short plan title, e.g. "School concert" or "Long weekend trip".
`allDay`	No	Whether the plan is all-day.
`startAt`	No	Optional ISO datetime.
`location`	No	Optional location, venue, or address.
`timezone`	No	IANA timezone for startAt/endAt, e.g. Europe/Prague.
`householdId`	Yes	Familia household id where the plan should be created.
`agreementIds`	No	Optional existing related task ids to link to the plan.
`relatedTasks`	No	Optional new tasks to create and link to this plan. Use one related task per distinct dated or timed action, such as leaving for an airport, outbound flight, return flight, pickup, packing, or check-in.
`idempotencyKey`	No
`recurrenceEndDate`	No	Optional YYYY-MM-DD end date for a recurring schedule. Use this for bounded repeats such as "this week", "for three days", or "until Sunday".
`participantUserIds`	No	Optional Familia user ids participating in the plan.
`requiresConfirmation`	No	Whether participants should confirm coverage or attendance.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`link`	Yes
`schedule`	No
`planItemId`	Yes
`relatedTasks`	No
`occurrenceIds`	Yes
`relatedTaskIds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 6, 2026

TDQS

A4.7/5.0

Behavior4/5

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

The description goes beyond the annotations by disclosing side effects: related tasks assigned to another household member can queue push notifications, schedules can trigger reminders, and delivered notifications cannot be recalled. It does not contradict the annotations; destructiveHint=true is somewhat surprising for a create tool, but the description does not conflict with it.

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 front-loaded with the primary use case, then provides recurrence guidance, related-task decomposition, exclusions, and side-effect warnings. Each sentence earns its place and no space is wasted repeating schema definitions.

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?

For a tool with 16 parameters and several optional relationships, the description covers creation scenarios, exclusions, recurrence handling, related-task decomposition, and notification caveats. Since an output schema exists and schema descriptions cover 94% of parameters, there are no significant gaps an agent needs to call it correctly.

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 94%, so the schema already documents most parameters. The description adds valuable semantics by clarifying that rrule should be used for recurring plans and that each distinct dated action should become a relatedTasks entry rather than being buried in notes, resolving a plausible ambiguity.

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 directive: create a Familia plan item, and enumerates concrete categories such as event, trip, holiday, school, activity, care coverage, and chore block. It also explicitly contrasts itself with familia_create_task and familia_batch_write, making the resource and scope unmistakable.

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 gives explicit when-to-use guidance and equally explicit when-not-to-use guidance: 'Do not use for standalone responsibility-style task reminders; use familia_create_task or familia_batch_write instead.' It also provides decision rules for recurring plans via rrule and relatedTasks, which is exactly the selection guidance an agent needs.

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

All Familia tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?