Skip to main content
Glama

calendar_add

Schedule a future one-time or recurring event that either re-invokes the agent with a prompt or publishes prepared content through a specified tool when it fires.

Instructions

Schedule a new calendar event that fires once or on a recurrence. Two kinds: 'task' re-invokes the agent with prompt when it fires — write the prompt as a complete, self-contained instruction, since the agent has no memory of this call when it runs. 'post' publishes prepared content through a named tool with no model call in the loop — requires content, channel, and publish_tool. Exactly ONE of at (a one-shot ISO-8601 timestamp, which must be in the future) or rrule (an RFC 5545 recurrence rule) is required — never both, never neither. channel is free text, not a router: it is a hint the tool named in publish_tool reads to decide where to post, so word it the way that tool expects, never a fixed enum. publish_tool must name a tool the caller can actually call right now — a currently-connected tool, never invented or assumed; the event hard-fails at fire time if the named tool is not connected. media is an optional list of local file paths and/or URLs to publish alongside content. timezone is an IANA name (e.g. 'America/New_York') the schedule is interpreted in.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNoOne-shot fire time, ISO-8601 (e.g. '2026-09-01T14:30:00+05:30'). Must be in the future. Exactly one of `at` or `rrule` is required — never both, never neither.
kindYesWhich kind of event this is. 'task' re-invokes the agent with `prompt` when it fires; 'post' publishes `content` via `publish_tool` with no model call in the loop. Determines which other fields are required — see their descriptions.
mediaNoOptional media to publish alongside `content` — a list of local file paths and/or URLs.
rruleNoRecurrence rule, RFC 5545 (e.g. 'FREQ=WEEKLY;BYDAY=MO,WE,FR;BYHOUR=9'), for an event that fires repeatedly. Exactly one of `at` or `rrule` is required — never both, never neither.
titleYesShort human-readable label for the event, shown in calendar listings.
promptNoREQUIRED when kind='task'. The instruction the agent is re-invoked with when the event fires — write it as a complete, self-contained instruction, since the agent has no memory of this call at fire time.
channelNoREQUIRED when kind='post'. Free text naming where to publish (e.g. 'LinkedIn company page', 'Instagram @brand') — a hint the tool named in `publish_tool` reads to decide where to post. This is NOT a routing enum: word it however `publish_tool` expects.
contentNoREQUIRED when kind='post'. The exact prepared text to publish.
timezoneNoIANA timezone name (e.g. 'America/New_York', 'Asia/Kolkata') that `at` or `rrule` is interpreted in.
publish_toolNoREQUIRED when kind='post'. The exact name of a tool the caller can currently call to publish (e.g. 'linkedin_post'). Must be a real, currently-connected tool — never guessed or invented — since the event hard-fails at fire time if the named tool isn't connected.
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it explains that task agents have no memory, post fires with no model call, `channel` is a non-enum hint, and the event hard-fails if `publish_tool` is not connected. These are meaningful execution traits beyond the schema definitions.

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?

Every sentence in the description encodes a real constraint or behavioral fact; there is no filler. The core purpose is front-loaded, and the detailed clauses about kind-specific requirements and constraints are organized naturally given the 10-parameter conditional schema.

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 complex 10-parameter tool with no output schema and no annotations, the description covers parameter requirements, execution behavior, and failure conditions well. It does not describe the success return value or how to later manage the created event, but those are partially covered by sibling tools and are not essential for correct invocation.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds critical semantics: future-only `at` timestamps, IANA timezone names, free-text channel behavior, self-contained prompts, and the requirement that `publish_tool` be a currently-connected real tool. This goes well beyond the field descriptions in the schema.

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 opening sentence names a specific verb and resource: 'Schedule a new calendar event that fires once or on a recurrence.' It immediately distinguishes this creation tool from sibling tools such as calendar_update, calendar_list, and calendar_remove.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states when each mode applies: 'task' for agent re-invocation with prompt, 'post' for publishing content, plus the exact mutually-exclusive `at`/`rrule` requirement. It does not explicitly contrast with calendar_update or calendar_remove, but the creation-focused purpose and sibling names make the intended use clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SupercmoHQ/superCMO-skills'

If you have feedback or need assistance with the MCP directory API, please join our Discord server