Skip to main content
Glama

Sweeppea MCP

by com.sweeppea.mcp

create_calendar_event

Create a new calendar event with title, dates, and optional details like location, time, and notifications. DATE RULE: The API server uses UTC. Today's date may be rejected as "past" depending on the user's local timezone. To be safe, always use tomorrow's date or later when creating events. NEVER use today's date — it will fail with "Cannot Create Events In The Past". If the user asks to create an event for today, explain this limitation and suggest tomorrow instead.

create_calendar_event

When to use

Create a new calendar event with title, dates, and optional details like location, time, and notifications. DATE RULE: The API server uses UTC. Today's date may be rejected as "past" depending on the user's local timezone. To be safe, always use tomorrow's date or later when creating events. NEVER use today's date — it will fail with "Cannot Create Events In The Past". If the user asks to create an event for today, explain this limitation and suggest tomorrow instead.

Parameters to validate before calling

  • title (string, required) — Event title (required)

  • start_date (string, required) — Start date in ISO 8601 format, e.g., 2026-01-20 (required)

  • end_date (string, required) — End date in ISO 8601 format, e.g., 2026-01-20 (required)

  • description (string, optional) — Event description (optional)

  • location (string, optional) — Event location (optional)

  • start_time (string, optional) — Start time in HH:MM format, e.g., 09:00 (optional)

  • end_time (string, optional) — End time in HH:MM format, e.g., 17:00 (optional)

  • color (string, optional) — Event color in hex format, e.g., #FF5733 (optional)

  • all_day (boolean, optional) — Whether this is an all-day event (optional, default: false)

  • status (string, optional) — Event status (optional)

  • private_event (boolean, optional) — Whether this is a private event (optional, default: false)

  • sms_notification (boolean, optional) — Enable SMS notifications (optional, default: false)

  • completed (boolean, optional) — Mark event as completed (optional, default: false)

  • latitude (number, optional) — Location latitude coordinate (optional)

  • longitude (number, optional) — Location longitude coordinate (optional)

  • event_url (string, optional) — URL associated with the event (optional)

  • people_involved (string, optional) — People involved in the event (optional)

  • repeat_this_event (string, optional) — Repeat configuration for recurring events (optional)

  • notification (string, optional) — Notification settings (optional)

Notes

  • Calendar API uses UTC — today's date may be rejected as past depending on the user's timezone

  • Always use tomorrow or later when creating events

  • If the user asks for today, explain the UTC limitation

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorNoEvent color in hex format, e.g., #FF5733 (optional)
titleYesEvent title (required)
statusNoEvent status (optional)
all_dayNoWhether this is an all-day event (optional, default: false)
end_dateYesEnd date in ISO 8601 format, e.g., 2026-01-20 (required)
end_timeNoEnd time in HH:MM format, e.g., 17:00 (optional)
latitudeNoLocation latitude coordinate (optional)
locationNoEvent location (optional)
completedNoMark event as completed (optional, default: false)
event_urlNoURL associated with the event (optional)
longitudeNoLocation longitude coordinate (optional)
start_dateYesStart date in ISO 8601 format, e.g., 2026-01-20 (required)
start_timeNoStart time in HH:MM format, e.g., 09:00 (optional)
descriptionNoEvent description (optional)
notificationNoNotification settings (optional)
private_eventNoWhether this is a private event (optional, default: false)
people_involvedNoPeople involved in the event (optional)
sms_notificationNoEnable SMS notifications (optional, default: false)
repeat_this_eventNoRepeat configuration for recurring events (optional)

TDQS

A4.3/5.0
Behavior5/5

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

The description discloses critical behavioral details beyond annotations: the API server uses UTC, today's date may be rejected as past, the exact error message 'Cannot Create Events In The Past', and a directive to always use tomorrow or later. This is actionable and not present in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The description is highly redundant—the same UTC date rule appears multiple times, and the parameter list duplicates the input schema almost verbatim. While organized under headings, the excessive repetition makes it bloated and harder to parse.

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 tool with 19 parameters and no output schema, the description thoroughly covers the purpose, all parameter details, the required fields, and the primary usage pitfall (UTC date validation). However, it omits any description of the return value or response format, which would help an agent confirm success.

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?

Although the input schema covers all 19 parameters (100% coverage), the description adds a crucial semantic constraint for start_date and end_date: they must be in the future due to the UTC rule. This goes beyond the schema's generic format descriptions.

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 clearly states 'Create a new calendar event' with a specific verb and resource, and lists key fields (title, dates, location, time, notifications). This distinguishes it from sibling tools like update_calendar_event, delete_calendar_event, and fetch_calendar_events.

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 provides clear context for when to use the tool (creating new events) and explicitly warns against using today's date, advising to suggest tomorrow instead. However, it does not mention alternative tools or when to prefer update_calendar_event.

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

All Sweeppea MCP toolsInspect
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.6/5.0
Disambiguation4/5

Most tools follow a clear resource+action pattern (fetch_* for lists, get_* for single items, create/update/delete for writes), making them distinguishable. A few near-overlaps exist (fetch_billing_transactions vs fetch_wallet_transactions, draw_winners vs schedule_drawing) but the descriptions clarify the boundaries.

Naming Consistency4/5

Tool names consistently use snake_case verb_noun, with fetch_ for list operations and get_ for single-item retrieval. Some verb variation (add_participant, count_participants, draw_winners, schedule_drawing) deviates from the dominant create/fetch/update/delete pattern but remains predictable and readable.

Tool Count1/5

With 83 tools, this is far beyond a well-scoped server (typically 3-15, with 25+ considered too many). Even though the platform has broad functionality, the sheer number of tools creates significant agent confusion and selection overhead.

Completeness4/5

The sweepstakes domain is thoroughly covered: lifecycle management, participants, groups, rules, drawings, winners, calendar, notes, todos, tickets, surveys, invoices, billing, files, and entry settings. A few minor gaps exist (e.g., no general participant field update, no archive action) but the surface is remarkably complete for its scope.

Resources