remove_participantOrganiser only: remove one participant by name (the oldest row with that name when it repeats), together with their vote. Requires the adminKey from create_event.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact participant name to remove. | |
| slug | Yes | Event slug from the URL, e.g. calm-otter-4821 (sync.day/calm-otter-4821) | |
| adminKey | Yes | Organiser key returned by create_event (the ?key= part of adminUrl). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructive, idempotent), the description discloses specific behavioral details: it removes the participant's vote, and when names repeat it targets the oldest row. It also surfaces the auth requirement (adminKey), which is not carried by annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first front-loads the core action and constraints, the second clarifies the required credential source. There is no redundant phrasing or filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with three well-documented parameters and annotations covering idempotence and destructiveness, the description supplies the essential context: organizer-only access, the adminKey dependency, the exact removal target, and duplicate handling. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the tie-breaking rule for the name parameter ('oldest row') and by specifying that adminKey comes from create_event, enriching the parameter semantics beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('remove'), names the resource ('one participant by name'), and clarifies the scope ('together with their vote'). It also states the organizer-only restriction, which differentiates this from other event-editing siblings like update_event or vote_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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: it is organizer-only and requires the adminKey from create_event. It does not explicitly name alternatives or exclusions, but the prerequisites make the usage context unambiguous and the tool has no direct sibling with a similar function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct operation, and the descriptions clearly separate organizer actions from participant actions. The only mild ambiguity is between decide_time and vote_time, but the descriptions resolve it well.
All tool names consistently follow a snake_case verb_noun pattern: create_event, get_event, update_event, decide_time, vote_time, remove_participant, submit_availability, parse_event_text. There is no mixed casing or inconsistent verb style, making the set predictable.
Eight tools is well-scoped for a scheduling and availability poll server. Each tool covers a meaningful action without redundancy, and the count feels neither thin nor bloated.
The core workflow is covered: create, read, update, availability submission, voting, deciding, participant removal, and natural-language parsing. The main gap is the lack of a delete_event or cancel operation, which is a workaround-level omission rather than a blocking one.