Loading ToolBench
MCP server that provides image search functionality from Unsplash. It retrieves images based on keywords and returns relevant results with metadata.
Single tool with reasonable parameter schema definition but weak description quality. Tool name 'search_photo' follows verb_noun convention (positive). Input schema is comprehensive with proper types and enums (Zod schema visible in source: query string, page/per_page numbers, order_by enum, etc.). However, description is verbose, includes formatting artifacts, and lacks WHAT/WHEN/WHY clarity expected in LLM-optimized descriptions. Description mentions '[Image 1](image_url_1)' template syntax which confuses intent. Output schema not explicitly documented, only shows raw JSON stringification of Unsplash API response with no shape documentation. Error handling present but minimal ('Error fetching file: ' is generic). No parameters lack type definitions, which is positive. Single tool limits composition assessment.
The search_photos function retrieves images from Unsplash based on a given keyword. It sends a search request, fetches matching images, and returns relevant results with metadata. The resulting images can be accessed via the following links: [Image 1](image_url_1) [Image 2](image_url_2) [Image 3](image_url_3) ...
Description lacks LLM-optimized clarity. At ~400 chars, it is verbose and includes template syntax ('[Image 1](image_url_1)') that confuses the intent. Effective descriptions state WHAT (retrieves images), WHEN (when user needs photos), and any dependencies. Current description reads like API documentation rather than tool selection guidance.
Output schema not documented. Tool returns raw JSON.stringify(response.data) with no shape specification. Agents cannot plan downstream calls or validate response structure. Expected: document that results include 'results[]' array with fields: id, slug, description, urls{}, user{}, etc.
Error handling is generic. Returns 'Error fetching file: {error}' without categorization (retryable vs fatal) or recovery guidance. Per pattern:recovery-guide, errors should guide LLM action: 'API key invalid, check UNSPLASH_API_KEY env var.' or 'Rate limited, retry in 60s.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
API response stripping not applied. Unsplash API returns metadata (description, profile_image, portfolio_url, etc.) irrelevant to image discovery. Raw response bloats output and wastes tokens. Per mxe:strip-api-responses, filter to essential fields: id, description, urls.regular, user.name, links.download.
Result limits not enforced in tool or description. API default is 10 per_page, but no guidance states max acceptable limit or what happens if per_page is set to 1000. Per mxe:enforce-result-limits, cap at 50 and document in description.