Skip to main content
Glama
cotletdev

Partiful MCP Server

by cotletdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Create event

create_event

Creates and publishes a private or public Partiful event page with title, time, location, visibility, and RSVP settings; no guests are invited until you share the link or call invite_guests.

Instructions

New event page. Nobody is invited until you call invite_guests.

Creates and publishes an event page hosted by this account, as Create on partiful.com does, with Partiful's default theme. It is private (only people with the link) unless visibility is public. Nobody is invited or texted; share url or call invite_guests. Times without an offset are read in timezone. Guest Approval and a guest limit exclude each other, so a call with both is refused. Returns the new event.

Input Schema

NameRequiredDescriptionDefault
titleYesEvent title.
end_atNoEnd, ISO 8601. Optional; must be after start_at.
locationNoAddress, place name or link.
start_atYesStart, ISO 8601. Without an offset it is read in the event's time zone.
timezoneNoIANA zone the event is shown in, e.g. America/New_York. Default: the browser's zone.
questionsNoGuest Questionnaire, short-answer questions asked at RSVP. An empty list turns it off.
max_guestsNoGuest limit; RSVPs over it go to the waitlist. null removes the limit.
visibilityNoprivate: only people with the link (default). public: anyone on or off Partiful.
descriptionNoEvent details shown on the page.
rsvp_deadlineNoLast moment guests can RSVP, ISO 8601.
guest_approvalNoGuests ask to join and you approve them (Guest Approval). Clears max_guests.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, it discloses that the event is published immediately, private by default unless visibility is public, uses Partiful's default theme, sends no invitations or texts, and returns the new event. It also states the Guest Approval and guest-limit conflict and the timezone behavior for offsetless times.

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

Conciseness4/5

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

The key scoping statement is front-loaded and the description is appropriately sized for an 11-parameter creation tool. There is some redundancy around 'nobody is invited' and invite_guests, but overall it is efficient.

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?

Given the complexity of the tool, the rich schema, and the absence of an output schema, the description is complete enough for an agent to call it correctly. It covers publishing behavior, privacy, invitation behavior, timezone handling, parameter conflicts, and the return value.

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 100%, so the schema already carries most parameter meaning. The description adds useful semantics by calling out the mutual exclusion between Guest Approval and guest limit and the timezone interpretation for times without offsets.

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 gives a specific verb and resource: it creates and publishes an event page hosted by the account. It also distinguishes the creation step from invitation by explicitly saying nobody is invited until invite_guests is called.

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?

It clearly explains the main usage context and names invite_guests as the alternative for inviting guests, plus the share-url path. It does not explicitly route the agent away from siblings like update_event or duplicate_event, so it stops short of full when-not-to-use guidance.

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

Deploy Server

Other Tools