Turn photos or product links into a poll your friends vote on. One link, free, no account needed.
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.2/5 across 3 of 3 tools scored.
Each tool serves a distinct purpose: creating a poll, reading poll metadata, and reading vote results. No overlap or ambiguity between them.
All tools follow a consistent verb_noun pattern: create_photo_poll, get_poll, get_poll_results. Predictable and clearly derived from actions.
Three tools is well-scoped for a focused photo poll server. Each tool covers a fundamental step in the poll lifecycle without unnecessary bloat.
The core create-read-results flow is covered, but tools for updating or deleting polls are missing. The adminUrl hints at management capabilities that aren't exposed, leaving notable gaps.
create_photo_pollCreate a photo pollAInspectCreate a Whichli photo poll so someone can ask friends, family or colleagues which option to pick, and get one shareable voting link back. Use it whenever the user is torn between things they can show a picture of — outfits, furniture, hotel rooms, haircuts, logo drafts, product listings. Voters need no account. Returns voteUrl (share this) and adminUrl (secret, keeps control of the poll).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | duel (default): two photos at a time, winner stays on, one final pick. swipe: like or pass, one photo at a time. | |
| title | Yes | The question voters see, e.g. 'Which sofa for the living room?'. 3-100 characters. | |
| options | Yes | The photos to compare (2-20). | |
| visibility | No | private (default): reachable only through the link. public: may also be listed on the Explore page for 7 days. Only use public when the user asks for it. | |
| creatorName | No | Who is asking. Optional, shown to voters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description must add value. It does by disclosing that the tool returns two URLs (voteUrl and adminUrl), clarifies that voters need no account, and mentions the mode differences (duel/swipe) which are behavioral. It doesn't contradict annotations and adds meaningful context beyond structured fields.
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 two sentences: the first states the purpose and the second gives usage context and key output. Every word earns its place, with no redundancy. It's front-loaded and easy to scan.
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 5 parameters (2 required), full schema coverage, and no output schema, the description effectively covers the essential context: what to use it for, the core output (two URLs), and key behavioral nuances like voter account requirement and mode differences. It's complete for an agent to decide when and how to invoke it.
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 each parameter already has a description. The tool description adds extra value by explaining that 'mode' has two behaviors (duel vs swipe) and mentions the return URLs, which are not in the schema. It also clarifies the use case for public vs private visibility, although some of that is in the schema. Overall, it goes slightly beyond the schema to enhance understanding.
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 creates a photo poll, specifies the resource (photo poll) and its purpose (to ask which option to pick), and distinguishes it from siblings (get_poll, get_poll_results) by focusing on creation rather than retrieval. The verb 'create' is specific and the scope is well-defined.
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?
It explicitly says 'Use it whenever the user is torn between things they can show a picture of' with concrete examples (outfits, furniture, etc.), which is strong usage guidance. It doesn't explicitly mention when not to use it, but given siblings are retrieval tools, the distinction is implicit. It also notes that voters need no account, which adds context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pollGet pollARead a Whichli poll's question and its options (photo URLs, captions, shop links) without vote counts.
| Name | Required | Description | Default |
|---|---|---|---|
| poll | Yes | Poll id (e.g. 'k7m2q9xr4t') or a whichli.com/p/... URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false) already establish safety; the description adds value by specifying what is included (question, options with photo URLs, captions, shop links) and what is excluded (vote counts). It does not disclose details like formatting or whether options are returned in order, but with annotations covering the safety profile, this is adequate.
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 a single sentence that is concise and front-loaded with the core purpose, followed by detail on contents and exclusions. Every element adds value, and there is no 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 read tool with one parameter, complete schema, and safety annotations, the description covers the key aspects: what data is returned (question, options, URLs, captions, shop links) and what is not (vote counts). It could mention return format, but that's less critical given the tool's simplicity and the lack of an output schema.
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 documents the 'poll' parameter with an example ID and URL format, covering 100% of the parameter description. The description adds no new meaning beyond the schema, so baseline 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 clearly states the tool reads a poll's question and options (photo URLs, captions, shop links) but excludes vote counts, which distinguishes it from the sibling 'get_poll_results' that likely returns votes. It uses a specific verb ('Read') and resource ('Whichli poll') with precise scope, differentiating it clearly from 'create_photo_poll' as well.
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 when to use this tool: when you need poll content without votes, and explicitly excludes vote counts, which steers users toward get_poll_results for vote data. It doesn't explicitly name get_poll_results as an alternative, but the exclusion of vote counts is a clear contextual hint differentiating it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_poll_resultsGet poll resultsARead the current standings of a Whichli poll: the winner, the votes per option and how many people voted.
| Name | Required | Description | Default |
|---|---|---|---|
| poll | Yes | Poll id (e.g. 'k7m2q9xr4t') or a whichli.com/p/... URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. The description adds value by specifying the return content (winner, votes per option, voter count), which clarifies what the agent will receive beyond the simple read operation.
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 a single sentence with no redundant words. It front-loads the verb and resource, then immediately lists the outputs, making it concise and well-structured.
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 read-only tool with one parameter, the description adequately covers functionality and return expectations. It does not mention output structure, but no output schema exists and the description conveys the key information an agent needs to invoke it correctly.
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 documents the 'poll' parameter, including its format (id or URL) and that it is required. The description adds no additional parameter information, so a baseline score of 3 is appropriate given the 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 uses the specific verb 'Read' and explicitly names the resource ('Whichli poll') plus the exact outputs (winner, votes per option, voter count). This clearly distinguishes it from sibling tools like create_photo_poll and get_poll, which have different purposes.
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 the tool is for viewing current poll standings, but it does not explicitly state when to use it over get_poll or provide exclusions. The read-only context is clear from the verb and annotations, but no direct usage guidance is given.
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!
