Get poll details and available time slots using a participation token. Returns the poll title, description, status, and time slots -- but NOT votes or participant data. This is the view a participant sees before voting. To see who voted and how, use meetlark_get_admin_view instead.
| Name | Required | Description | Default |
|---|---|---|---|
| participateToken | Yes | The prt_xxx token from the participation URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the transparency burden. It discloses that the tool returns only poll title, description, status, and time slots, explicitly excluding votes and participant data. It also frames the response as the pre-voting participant view, providing context about the data's provenance.
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?
The three-sentence description is concise, with the first sentence immediately stating the action. The second sentence clarifies scope, and the third provides an alternative, all without redundancy.
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 one-parameter tool with no output schema, the description covers the return content, exclusions, usage context, and alternative tool. It is complete for enabling correct invocation.
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?
The single parameter 'participateToken' is fully described in the schema with its format ('prt_xxx token from the participation URL'). The description reinforces this by mentioning 'participation token,' but adds no extra semantic value beyond the schema, which is acceptable given 100% schema coverage.
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 clearly states the tool retrieves poll details and available time slots via a participation token. It explicitly differentiates from meetlark_get_admin_view by noting it excludes votes and participant data, making the purpose unambiguous.
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 explicit guidance: it frames the tool as the participant view before voting and directs users to 'meetlark_get_admin_view' for vote/participant data. This directly addresses the primary sibling ambiguity, though it doesn't discuss all siblings.
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 serves a distinct purpose: create, vote, close, reopen, admin view, and participant results. The admin/view split is clearly explained, and close/reopen are unambiguous opposites.
All tool names follow a consistent verb_noun pattern with lowercase and underscores. The naming clearly indicates the action and target resource.
Six tools is well-scoped for a scheduling poll service, covering the essential lifecycle without redundancy.
The core workflow (create, vote, close, reopen, view results) is covered. Missing update/delete operations for polls are minor gaps that can be worked around, and the admin view provides sufficient oversight.
