haus

update_recurring_calendar_event

Update a recurring calendar event. Changes to title/description/notes patch existing instances. Changes to frequency/dates/time regenerate future instances.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Id of the recurring calendar event (template) to update.
`notes`	No	New freeform notes. Omit to leave unchanged. Patching this alone updates existing generated instances in place rather than regenerating them. Up to 5000 characters.
`title`	No	New event title/summary. Omit to leave unchanged. Patching this alone updates existing generated instances in place rather than regenerating them. Up to 200 characters.
`endDate`	No	PATCH-style date field: omit or send null to leave the stored end date unchanged, send an empty string to clear it (recurrence becomes unbounded by date), or send 'YYYY-MM-DD' to set a new last occurrence date. Changing this deletes and regenerates future instances.
`duration`	No	New length of each instance, in ISO 8601 duration format. Omit to leave unchanged. Changing this deletes and regenerates future instances.
`isAllDay`	No	True if generated instances are all-day events; false for timed instances. Omit to leave unchanged. Changing this deletes and regenerates future instances.
`location`	No	New location, replacing the existing one entirely. Omit to leave unchanged. Patching this alone updates existing generated instances in place rather than regenerating them. Set $type to 'Address' for physical (with line1-3, postalCode, countryCode) or 'OnlineLocation' for virtual (with url, notes).
`timezone`	No	IANA timezone id (e.g. 'Europe/London') that startTime is in. Omit to leave unchanged; null resets to UTC. Changing this regenerates instances.
`startDate`	No	PATCH-style date field: omit or send null to leave the stored start date unchanged, send an empty string to clear it, or send 'YYYY-MM-DD' to set a new anchor date. Changing this deletes and regenerates future instances.
`startTime`	No	New time of day each instance starts, in HH:mm:ss format (local to timezone). Omit to leave unchanged. Changing this deletes and regenerates future instances.
`description`	No	New longer free-text description. Omit to leave unchanged. Patching this alone updates existing generated instances in place rather than regenerating them. Up to 2000 characters.
`cronExpression`	No	New recurrence interval, NOT a cron expression despite the field name. Format is 'N Unit' where N is a positive integer and Unit is one of Day, Week, Month, Year (case-sensitive), e.g. '1 Day', '2 Week', '1 Month', '1 Year'. Omit to leave unchanged. Changing this deletes and regenerates future instances.
`maxOccurrences`	No	New maximum number of instances to generate. Omit to leave unchanged. Changing this deletes and regenerates future instances.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes
`title`	No
`message`	No
`variant`	No

TDQS

A4/5.0

Behavior4/5

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

The description adds substantial behavioral context beyond the annotations: it explains that title/description/notes patch existing instances while frequency/dates/time regenerate future instances. This is crucial and not available from the readOnlyHint/destructiveHint annotations. It does not contradict 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with a clear purpose, followed by a concise summary of the key behavioral distinction. No filler or redundant content.

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?

The description is short but effective for a complex tool with 13 parameters and an output schema. It highlights the most important behavioral distinction (patch vs regenerate) that applies across many parameters, while the schema covers parameter details. It lacks explicit guidance on when to use this tool versus update_calendar_event, preventing a higher score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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. The description provides a general rule about parameter categories (patch vs regenerate) but does not add individual parameter semantics beyond what the schema already states.

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 uses a specific verb+resource: "Update a recurring calendar event." It clearly distinguishes the tool from siblings like update_calendar_event by specifying "recurring" and by describing the patch-vs-regenerate behavior unique to recurring events.

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?

No explicit when-to-use or alternatives are mentioned. The resource type "recurring" implies the intended use case, but the description does not contrast with update_calendar_event or exclude non-recurring events. The focus is on behavior, not usage guidance.

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

All haus 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.

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct resource and action, with clear descriptions separating similar-sounding tools like create_calendar_event vs create_recurring_calendar_event. Shopping list operations (add, buy, remove, update) are clearly delineated.

Naming Consistency5/5

All tools follow a verb_noun snake_case pattern: create_*, list_*, update_*, delete_*, get_*, etc. Even special operations like store_memory, recall_memory, and skip_recommendation fit the pattern.

Tool Count1/5

With 68 tools, this server vastly exceeds a reasonable scope; the instruction manual indicates 50+ tools is an extreme mismatch. The breadth suggests the server should be split into focused sub-servers (tasks, shopping, calendar, etc.) rather than a single monolithic interface.

Completeness5/5

The tool surface covers full CRUD/lifecycle for all major resources: tasks, shopping, calendar, contacts, documents, appliances, vehicles, pets, recipes, meal plans, subscriptions, and memories. Additional features like house review, weather, and profile round out the household management domain.

Resources

Need Help?