Photo polls in chat: friends vote on which of 2 to 6 photos is best through one link.
Scored across 1 tool
There is only one tool, so there is no possibility of confusing it with another tool in the set. Its purpose is clearly specified as creating a PicJury photo poll.
The single tool name start_photo_poll follows a clear verb_noun snake_case pattern. With only one tool there are no inconsistent naming conventions to compare.
A single tool is minimal but potentially sufficient for a narrowly scoped poll-creation integration. However, the surface feels thin because there are no companion operations for retrieving results or managing polls.
The tool covers creation of a photo poll and returns links for voting and following results, which supports the core flow. It lacks programmatic operations for reading results, closing a poll, or listing existing polls, so the lifecycle coverage is notably partial.
Creates a PicJury photo poll: friends vote on which of 2 to 6 photos is best through one link, without signing up. For choices between photos (profile picture, dating photo, outfit, logo, thumbnail, product) that the user wants other people to decide. Photos attached in the chat are not passed to PicJury: the tool shows a PicJury card in which the user picks the photos and gets the vote link and a private link to follow the votes. question is what friends are asked, in the user's language; language sets the language of the PicJury page.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language of the PicJury page, the one the user writes in. Other languages: en. | |
| question | Yes | What friends are asked, in the user's language. Example: "Which photo should be my profile picture?" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says the tool 'Creates a PicJury photo poll' and involves generating vote and private follow-up links, which implies a side effect or external state change. This directly contradicts the annotation readOnlyHint=true, so the behavioral signal is inconsistent and misleading.
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 core action is front-loaded, and the paragraph remains dense with useful details rather than filler. The workflow explanation is slightly long-winded but every element serves to explain usage or behavior.
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 only two parameters and no output schema, the description covers the workflow, use cases, user-selected photo behavior, and the vote link and private follow-up link. Completeness is strong, though the annotation contradiction leaves side-effect expectations unclear.
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 schema already documents both parameters, including the language enum and question length bounds. The description restates the semantic roles of question and language but adds no constraints or format details beyond what the schema provides, so it meets the baseline for a fully documented 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 states a specific verb and resource: it creates a PicJury photo poll where friends vote on 2 to 6 photos through one link without signing up. It also lists concrete use cases such as profile pictures, dating photos, outfits, logos, thumbnails, and products, so an agent can easily distinguish 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 clear usage context: use it for choices between photos that the user wants other people to decide. It also explains a relevant constraint that photos attached in chat are not passed to PicJury, though it does not provide explicit when-not-to-use guidance or alternatives, which are unnecessary here because there are no sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
start_photo_pollTurn photos or product links into a poll your friends vote on. One link, free, no account needed.
Create one-tap polls, share them by link or QR code, and read the results from your AI assistant.
One-link team polls: create polls, vote, fetch results, and close polls.
Create a group date poll in one sentence; participants vote with no account.
Add one secure layer between your agents and this server.
