Familia

Create plan

familia_create_plan

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.

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. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations only state readOnlyHint=false, so the description carries the burden of disclosing creation behavior. It adds useful behavioral context: recurring plans should be created as one schedule, separate dated actions belong in relatedTasks rather than notes, and standalone task reminders belong elsewhere. This goes beyond the mere fact that the tool creates a plan, though it doesn't detail side effects or permission requirements.

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 a single dense paragraph, but every sentence earns its place: primary usage, recurrence handling, relatedTasks handling, and exclusion with alternatives. It is front-loaded with the core purpose and avoids redundant restatement of schema fields.

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 16-parameter create tool with a rich schema and an existing output schema, the description covers the key selection and invocation decisions: what counts as a plan, how to model recurring schedules, how to model associated actions, and which sibling tools to use instead. Nothing critical for correct high-level use is missing.

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 description coverage is 94%, so most parameters are already well documented in the structured schema. The description adds cross-parameter semantics that the schema alone doesn't: how to choose between rrule, relatedTasks, notes, and when to route to create_task or batch_write. This meaningfully supplements the schema without repeating it.

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 an explicit, specific verb and resource: 'create a Familia plan item' for a broad list of plan categories, and it immediately names the sibling tools it is not (familia_create_task, familia_batch_write). This makes the tool's identity unambiguous even before inspecting the schema.

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 direct when-to-use guidance for plans versus standalone tasks, tells the agent to collapse recurring requests into a single rrule-based plan, and instructs how to handle multi-action events with relatedTasks. It also explicitly says 'Do not use for standalone responsibility-style task reminders' and names the alternatives, leaving no ambiguity about routing.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?