Skip to main content
Glama
soil-dev
by soil-dev

update_poll

DestructiveIdempotent

Modify an open poll by id or key: update title, details, closing time, or settings, and add options without removing existing ones.

Instructions

Edit an OPEN poll by id_or_key: 1 call (2 with options). Pass only what changes: title, details (REPLACES the text), closing_at (future; opening a draft announces unless notify_on_open is false), options (names to ADD: merged with the current list, so it never removes an option it saw; not atomic), settings. Cannot change poll_type, anonymous, group or tags; a closed poll answers 403.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo
detailsNo
optionsNoNames to ADD (+1 call): merged with the stored names, so it never removes an option it saw. Not atomic.
id_or_keyYesPoll id or short key.
max_scoreNoscore: max per option (default 5); meeting: 2.
min_scoreNoscore: min per option (default 0).
stv_seatsNostv: seats to fill.
closing_atNoISO-8601, future; omitted = unchanged. To end voting soon pass the next full hour.
hide_resultsNoCannot leave 'until_closed' once set.
reason_promptNoPrompt above the reason box.
details_formatNoDefault 'md'; 'html' when `details` is HTML.
notify_on_openNoAnnounce (`poll_announced`) on opening; Loomio's default is TRUE.
dots_per_personNodot_vote: points per voter (default 8).
shuffle_optionsNoRandomise option order per voter.
meeting_durationNomeeting: slot minutes. No default through the API.
recipient_emailsNoEmails to invite; non-members become guests.
can_respond_maybeNomeeting: allow 'maybe'. API default is false.
notify_recipientsNoEmail/push the named recipients; SEPARATE from notify_on_open.
recipient_messageNoText for the notification.
recipient_audienceNo'group' = every member (needs announce permission).
recipient_user_idsNoUser ids to invite / notify.
specified_voters_onlyNoOnly the named recipients may vote.
maximum_stance_choicesNoMax options per voter (poll: 1; raise for multi-choice).
minimum_stance_choicesNoMin options per voter (ranked_choice: ranks, default 3).
notify_on_closing_soonNo24h closing reminder; API default is 'nobody'.
show_none_of_the_aboveNoOffer 'none of the above' (poll, ranked_choice).
stance_reason_requiredNoDefault 'optional'; anonymous polls force 'disabled'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.0.13

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that details REPLACES existing text, options are ADD-only and merged (never removes), the merge is not atomic, opening a draft announces a poll, and a closed poll returns 403. These are exactly the destructive/stateful traits an agent needs and the annotations alone (destructiveHint, idempotentHint) do not convey.

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?

A single dense paragraph that is front-loaded with the action and the call-count note, then lists the mutability contract and exclusions. Every sentence carries information; only the count of packed clauses keeps it from being maximally clean.

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 27-parameter tool with high schema coverage, a safety profile in annotations, and no output schema, the description supplies the missing behavioral context (overwrite, merge, non-atomicity, 403, announce-on-open). Return values needn't be described since no output schema exists.

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?

With 93% schema coverage the baseline is 3, but the description adds real semantic value: 'Pass only what changes', details overwrite behavior, option merge semantics, and future-only closing_at. It clarifies the update-patch contract that the schema type constraints alone don't express.

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 (Edit) and resource (an OPEN poll) with the identifying parameter (id_or_key), and the constraint that it must be open immediately differentiates it from create_poll/delete_poll siblings. An agent can identify the operation without opening the schema.

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?

Gives clear when-to-use conditions (only open polls; closed returns 403) and explicit when-not boundaries (cannot change poll_type, anonymous, group, tags). It doesn't name a sibling alternative by name, but the create/delete/update triad is unambiguous from context.

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