Agent-first meeting schedule polls for humans and agents. Create polls, vote, find times.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 6 of 6 tools scored.
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.
meetlark_close_pollAInspectClose a poll to stop accepting new votes. Use the admin token from poll creation.
| Name | Required | Description | Default |
|---|---|---|---|
| adminToken | Yes | The adm_xxx token from poll creation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of explaining side effects. It states the core behavior (stop accepting new votes) but does not disclose whether existing votes are preserved, whether closing is reversible (despite the sibling 'reopen_poll'), or what kind of response is returned. This is adequate for a simple action but leaves some behavioral ambiguity.
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 description is extremely concise: one sentence for purpose plus a short usage directive. Every word contributes to understanding, and the key information appears immediately.
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 single-parameter tool with a well-documented schema, the description covers the essentials: what the action does and what input is needed. It doesn't mention return values or error conditions, but the simplicity of the operation makes this a minor gap.
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 schema already fully describes the only parameter (adminToken) with a clear description. The tool description reiterates the token source without adding significant new meaning beyond the schema, so a baseline score of 3 is appropriate.
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 ('Close') and resource ('poll'), and clearly states the effect ('stop accepting new votes'). It is distinct from the sibling 'reopen_poll' tool and immediately conveys the tool's purpose.
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 gives a clear use case and an explicit prerequisite: 'Use the admin token from poll creation.' It doesn't explicitly mention when not to use it, but the purpose is unambiguous enough that context makes the appropriate use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meetlark_create_pollAInspectCreate a scheduling poll to find a time that works for a group. Returns an admin URL (keep private) and a participation URL (share with participants). The creator's email must be verified -- if not yet verified, a verification email is sent automatically. Ask the user to check their inbox and click the link, then retry.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | What is this poll for? | |
| timeSlots | Yes | Available time slots to vote on | |
| creatorName | No | Name of the poll creator | |
| description | No | Additional context for participants | |
| creatorEmail | Yes | Email address of the poll creator |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fully discloses the return values (admin URL, participation URL), a security note (keep admin URL private), and an important prerequisite side effect (verification email sent automatically if creator email is unverified). This is rich, actionable behavioral context beyond what a schema would provide.
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 description is four sentences, each earning its place. It opens with the core purpose, then immediately covers the two return URLs, and closes with the critical email verification behavior. There is zero fluff or repetition, and the most important operational detail (the verification email) is saved for last, which is a logical build-up.
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?
Given the tool's moderate complexity (5 params, 3 required, no output schema), the description explains the crucial return values and the key edge case (verification email). It does not explicitly state the format of timeSlots or error handling, but the schema covers parameter structure, and the description covers the non-obvious workflow. A small gap is that it does not mention what happens if the email is already verified, but this is minor. Overall, it is sufficiently complete.
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 description coverage is 100%, so the baseline is 3. The description does not add any additional parameter semantics beyond the schema; it only mentions 'timeSlots' implicitly via 'a time that works for a group.' Since the schema already fully documents all five parameters, there is no need for the description to compensate, but it also does not add extra value here.
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's function with a specific verb and resource: 'Create a scheduling poll to find a time that works for a group.' It also uniquely identifies the tool by mentioning the admin and participation URLs, distinguishing it from sibling tools like close_poll or get_results. The purpose is unambiguous and specific.
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: when a group needs to find a mutually available time. It also gives a specific usage flow for handling unverified emails ('Ask the user to check their inbox... then retry'). However, it does not explicitly contrast with sibling tools or mention when NOT to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meetlark_get_admin_viewAInspectGet full poll details including all votes and participants. This is the only way to see who voted and how they voted. Returns poll info, time slots, every participant's votes (yes/maybe/no per slot), participant emails, and admin URLs. Use the admin token from poll creation. Use this to check vote status or results.
| Name | Required | Description | Default |
|---|---|---|---|
| adminToken | Yes | The adm_xxx token from poll creation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It does so by enumerating return contents (poll info, time slots, votes, participant emails, admin URLs) and specifying authentication requirements. It does not explicitly state read-only nature or error behavior, but the verb 'Get' implies a non-destructive operation, and the level of detail is adequate for a simple retrieval tool.
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 description is concise, at four sentences, and front-loads the main purpose in the first sentence. It includes essential authentication and usage details without any fluff or redundant information.
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 single-parameter tool with no output schema, the description is fairly complete: it lists what is returned, how to authenticate, and when to use it. It does not cover error scenarios or token validity, but these are not critical for a simple getter, and the description sufficiently informs an agent for 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 input schema already provides a complete description of the single adminToken parameter ('The adm_xxx token from poll creation'). The tool description repeats 'Use the admin token from poll creation' but adds no new semantic detail beyond the schema, so the baseline score of 3 applies.
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 full poll details including all votes and participants, using the specific verb 'Get' and the resource 'full poll details'. It further distinguishes itself from siblings by claiming to be 'the only way to see who voted and how they voted', which makes the purpose specific and non-confusable.
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 when-to-use guidance: 'Use this to check vote status or results' and instructs on required authentication material ('Use the admin token from poll creation'). It also states a clear exclusion: 'only way to see who voted and how they voted', indicating other tools cannot fulfill this need, effectively guiding against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meetlark_get_resultsAInspectGet 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.
meetlark_reopen_pollAInspectReopen a previously closed poll to accept votes again. Use the admin token from poll creation.
| Name | Required | Description | Default |
|---|---|---|---|
| adminToken | Yes | The adm_xxx token from poll creation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the auth requirement ('Use the admin token from poll creation') and the core state change (reopen to accept votes), but lacks details on side effects like whether existing votes are preserved or what the response looks like.
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 concise sentences with no wasted words. The action is stated first, and the auth requirement is a necessary addition. Perfectly sized for a simple one-parameter tool.
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 tool with one parameter and no output schema, the description is largely sufficient. It explains when to use (previously closed poll) and how (use admin token). It could mention that the poll must be closed, but 'previously closed' covers this. Overall, complete enough for the low complexity.
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 description coverage is 100% and the adminToken parameter is already well-documented as 'The adm_xxx token from poll creation.' The description only repeats this information, adding no new semantic meaning beyond the schema.
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's action: 'Reopen a previously closed poll to accept votes again.' It distinguishes this from siblings like close_poll and create_poll by specifying the reopen/accept-votes behavior.
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 implies usage context ('previously closed poll') but does not explicitly mention alternatives or when not to use. It gives clear context for when this tool is appropriate, though no explicit exclusions or sibling references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meetlark_voteAInspectCast a vote on a scheduling poll. Each time slot can be voted yes, maybe, or no. Requires participant name and email. Use the participation token from the poll's participate URL. If the email matches a previous voter on this poll, their response is updated instead of creating a duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name to display in results | |
| Yes | Participant's email address (required). Used to identify returning voters and send confirmation email. | ||
| votes | Yes | Votes for each time slot | |
| participateToken | Yes | The prt_xxx token from the participation URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosing behavior. It explains the voting options (yes/maybe/no), the email-based identification for returning voters, and the update instead of duplicate behavior. It also mentions the required token, giving a complete picture of what to expect.
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 description is three concise sentences with no waste. It front-loads the core action and then adds essential details about requirements and update behavior, making every sentence earn 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?
The tool is a simple action (voting) and the description covers prerequisites and key behavioral nuances. It lacks details about return values or error handling, but the absence of an output schema and the straightforward nature of the action make this acceptable. It is nearly complete for an agent's needs.
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 input schema already provides 100% coverage of all four parameters, so the baseline is 3. The description adds value by explaining that the email is used to identify returning voters and that the participation token comes from the participate URL, going beyond the schema's property descriptions.
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's purpose with a specific verb ("Cast a vote") and resource ("scheduling poll"), effectively distinguishing it from sibling tools like meetlark_create_poll or meetlark_get_results. It also highlights the unique update behavior when the email matches a previous voter.
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 usage context by specifying required inputs (participant name, email, participation token) and the token's source (the poll's participate URL). While it doesn't explicitly state when not to use the tool or name alternatives, the context is sufficient for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
