holiday-photo-plus
Server Details
Show holiday photos from Vercel Blob inline in Claude chats.
- Status
- Healthy
- Uptime
- 73.4% over 37 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion. The purpose is clear: fetching a photo from the library.
The single tool uses a consistent verb_noun pattern ('get_photo'), and there is no other tool to create inconsistency.
The server has just one tool, which feels thin for a photo library. More tools for listing or managing photos could be expected, but a single retrieval tool might suffice for a very narrow scope.
The tool only fetches a photo by name or randomly. There is no way to list available photos, search metadata, or manage the library, making the surface significantly incomplete for a standalone photo library.
Available Tools
1 toolget_photoAInspect
Fetch a photo from the Holiday Photo Plus library and display it inline in the chat. name is the filename of the photo as it lives in the repo's public/holidayphotos/ folder (e.g. 'Photo1.png'). A substring also matches. Omit name to get a random photo.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Photo pathname, filename, or substring. Omit for a random photo. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the key behavior: fetching from a known repo folder, displaying inline, substring matching, and random fallback. It does not cover error behavior or permissions, but for a read-only photo lookup these are minor omissions.
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?
Three tight sentences: the first states the action and display behavior, the second defines the parameter, and the third explains the default. No wasted words or repetition.
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 optional parameter and no output schema, the description is complete. It explains where photos come from, how to reference them, and what happens when no name is given. No critical context is missing.
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?
Even though the schema describes the parameter, the description adds crucial semantics: exact folder location (`public/holidayphotos/`), example filename ('Photo1.png'), substring behavior, and the random-photo default. These details empower correct use beyond the schema's generic 'pathname, filename, or substring'.
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?
Description uses a specific verb 'Fetch' and names the exact resource ('photo from the Holiday Photo Plus library') and display behavior ('inline in the chat'). Even with no sibling tools, it is unambiguous and self-contained.
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?
Provides clear invocation context: `name` is a filename in the repo's `public/holidayphotos/` folder, substring matches, and omitting returns a random photo. There are no alternatives to compare, so it lacks explicit when-not-to-use guidance, but it sufficiently tells the agent how and when to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
get_photo
Related MCP Connectors
Holiday photo MCP server: list and fetch personal holiday photos inline in Claude chat.
- lightgenOAuthapp.lightgen
Generate and edit images and create short videos inside Claude. Prepaid credits, no subscription.
Plan trips directly into TravelOwl from a conversation with Claude.
Generate AI images, videos, music, SFX & speech in any AI assistant. Results appear inline in chat.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceImage generation for Claude using every model on fal.ai, inline in conversations. Supports FLUX Schnell, Ideogram, SDXL, and more with privacy option via Venice.ai.-
- AlicenseNot gradedqualityDmaintenanceEnriches Claude with tools to generate brand-consistent images using OpenAI's gpt-image-2 and upload them directly to Notion pages.MIT
- AlicenseAqualityCmaintenanceEnables Claude to generate and edit images using OpenAI's GPT Image models, with automatic model selection and local file saving.3MIT
- FlicenseAqualityDmaintenanceEnables Claude Code to display images inline within supported terminals like Ghostty and Kitty using the Kitty graphics protocol on macOS. It allows users to view various image formats including PNG, JPEG, GIF, and WebP directly in the terminal interface.11-
Glama MCP Gateway
Add one secure layer between your agents and this server.