Skip to main content
Glama

Make a group poll

polls_create

Make a group poll of times free_times_find found for a named meeting, for the people it is for to vote on the times they can make. Each address gets its own link, an address named twice one, handed back in this answer alone - a lost link needs a new poll. Lumman sends them nothing: the person shares the links, or each goes from the person's own mailbox. Whoever opens a link, with no account, ticks the times that address can make, answering again replaces its answer, and sees no one else's. polls_results ranks the times and polls_book books one, in the calendar the person named to receive bookings, which making a poll does not need; a poll closes once booked, or 14 days after it is made, and then holds no address or answer. Naming a circle makes a poll for members of it or, on the person's own circle, for addresses invited that have not joined, meant for those circles_free_times_find names under noCalendar or notJoined: once they answer, the person's own searches for that circle count each by the times they can make, and their page offers to connect a calendar - an address that has not joined joins first, through the letter circles_invite sent it. A member with a calendar is read through it, never from a poll. The page a guest opens names nobody but the meeting, so subject is all a guest reads of whose meeting it is, e.g. Intro call with Sam Lee. An invitee whose time zone is known, as events_create knows a guest's, is answered with that zone and each time in it.

Input Schema

NameRequiredDescriptionDefault
timesYesEach time offered, its start with its offset.
circleNoThe circle's id, as circles_list names it, where the poll is for members of it.
minutesNoMeeting length in minutes; the stored one where omitted.
subjectYesThe meeting's name, as whoever opens the link reads it.
inviteesYesThe address of each person the poll is for.
guestZonesNoA guest's own time zone, only as the person names it - never inferred from an address, a language or a provider.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), it discloses substantial traits: each address gets its own link, Lumman sends no emails, guests vote without an account and can't see others' answers, re-answering replaces, and the poll closes on booking or after 14 days and then retains no address or answer. These are meaningful behavioral and data-retention facts the annotations 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.

Conciseness2/5

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

The content is delivered as a single dense run-on paragraph full of comma-chained clauses, mixing core usage with circle/calendar edge cases. The first sentence is front-loaded, but overall it is overlong and hard to parse, with important facts (link loss, closing/retention) diffused rather than structured.

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 6-parameter mutation tool with no output schema, the description covers link distribution, guest experience, circle semantics, time-zone handling, and lifecycle/retention, which is close to complete. It stops short of a clean return-value or error picture, but the depth of behavioral context largely compensates.

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 real meaning: subject is the only thing a guest reads (with an example), guestZones reflect a zone 'known as events_create knows a guest's,' and circle naming changes what the poll is for. This goes beyond the schema's own text, though some details (minutes, times) merely restate it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource (make a group poll) and ties the input times to free_times_find, so an agent can tell what the tool does and roughly where the times come from. It later names polls_results and polls_book, aiding sibling differentiation, but the purpose statement is buried under a large amount of tangential behavior rather than cleanly front-loaded.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains downstream siblings (polls_results ranks, polls_book books) and notes that making a poll 'does not need' the booking calendar, which implies usage boundaries. However, it never gives an explicit 'use this when / not when' rule or a clean alternative-selection statement; usage must be inferred from the dense prose.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.