Skip to main content
Glama
Sign In
signupgenius-mcp

signupgenius-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

signupgenius_rsvp

Destructive

Submit a Yes/No/Maybe RSVP to a SignUpGenius sign-up sheet, confirming before the organizer sees it. Not for slot-based sign-ups.

Instructions

RSVP to a SignUpGenius sign-up (the Yes/No/Maybe-style sheets, including invitations from family/friends). WRITES DATA the organizer sees, so it asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call sends nothing and returns the preview (sheet, response, head counts, identity) and a confirmToken, and only a repeat call with the same arguments plus that token submits — show the preview to the user and get their approval first (MCP_CONFIRM_MODE). Responds as the signed-in account by default: omit firstname/lastname/email unless the user is responding for someone else. A supplied identity that differs from the account is allowed but flagged in the preview (identityDiffersFromAccount) — point it out to the user. Refuses when the signed-in member already has a response on the sheet (it can only ADD a response, so a second one would double-count) — change an existing answer in the SignUpGenius web UI. Slot-based sign-ups (e.g. "claim the 3pm slot") are NOT handled here — use signupgenius_claim_slot for those.

Input Schema

NameRequiredDescriptionDefault
urlYesSignUpGenius sign-up URL (https://www.signupgenius.com/go/<slug>) or just the slug.
emailNoOptional. Defaults to the signed-in account's email.
adultsNoAdult guest count. Defaults to 1 for yes/maybe, 0 for no.
commentNoOptional comment shown to the sign-up owner.
childrenNoChild guest count. Defaults to 0.
lastnameNoOptional. Defaults to the signed-in account's last name.
responseYesRSVP response. Maps to the wizard's Yes / No / Maybe buttons.
firstnameNoOptional. Defaults to the signed-in account's first name. Supply it only to respond for someone else (e.g. a family member); the preview then flags identityDiffersFromAccount.
confirmTokenNoONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.1.11
    • addedInput schema / properties / email / description
      Added value: +"Optional. Defaults to the signed-in account's email."
    • addedInput schema / properties / firstname / description
      Added value: +"Optional. Defaults to the signed-in account's first name. Supply it only to respond for someone else (e.g. a family member); the preview then flags identityDiffersFromAccount."
    • addedInput schema / properties / lastname / description
      Added value: +"Optional. Defaults to the signed-in account's last name."
    • changedInput schema / required
      Previous value: -[
-  "url",
-  "response",
-  "firstname",
-  "lastname",
-  "email"
-]New value: +[
+  "url",
+  "response"
+]
  2. Changed2 schema fields changedv2.1.4
    • removedInput schema / properties / confirm
      Removed value: -{
-  "description": "Must be true to actually submit. Omit (or false) to get a dry-run preview of the sign-up, response, head counts and identity — nothing is sent to the organizer.",
-  "type": "boolean"
-}
    • addedInput schema / properties / confirmToken
      Added value: +{
+  "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+  "type": "string"
+}
  3. Changed1 schema field changedv2.1.3
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Must be true to actually submit. Omit (or false) to get a dry-run preview of the sign-up, response, head counts and identity — nothing is sent to the organizer.",
+  "type": "boolean"
+}
  4. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  5. Changed1 schema field changedv1.8.1
    • changedInput schema / properties / email / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  6. First observedv1.3.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare destructive=true, idempotent=false, openWorld=true, and the description goes well beyond them: it discloses that data is written and visible to the organizer, the elicitation vs. two-step confirmToken fallback, the refusal on duplicate responses, and the identityDiffersFromAccount flag. The main remaining gap is that it does not state what a successful submission returns beyond the phase-1 preview, though no output schema exists to cover it.

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 purpose and write-semantics are front-loaded, and the dense sentences carry distinct constraints rather than repeating themselves. It is long, but nearly every clause adds a routing or safety fact; a little more white space around the two-step fallback would aid scanning.

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?

With no output schema, the description compensates by enumerating the preview contents (sheet, response, head counts, identity, confirmToken) and the exact two-phase call sequence. Combined with the annotations, an agent has everything needed to invoke this correctly, including the confirmation requirement.

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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains that firstname/lastname/email default to the signed-in account and should be omitted unless responding for someone else, and it details the confirmToken's exact lifecycle (same arguments, only after approval, never invented or reused). This goes beyond the schema text.

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?

States a specific verb (RSVP) and resource (SignUpGenius sign-up) and immediately scopes it to the Yes/No/Maybe-style sheets rather than slot claims. It names the sibling it is not (signupgenius_claim_slot), so an agent can route between them without opening a 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?

Gives explicit when-to-use (RSVP sheets), when-not-to-use (slot-based sign-ups → signupgenius_claim_slot), a refusal condition (existing response → edit in web UI), and the confirmation protocol. Alternatives and exclusions are all named.

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