Loading ToolBench
MCP server providing tools for searching and fetching media from multiple sources including Pexels, Unsplash, web crawling, and image generation via OpenAI and Silicon-compatible APIs
This MCP server has 18 tools with basic registration but significant quality gaps. Tool descriptions are present but often generic and under-specified (e.g., 'say hi to MCP' for greet). Input schemas are registered via AddTool but parameter schemas are NOT visible in the source code, only inferred struct tags (SearchPhotosArgs, GetPhotoArgs, etc.). Without seeing the actual JSON Schema definitions, parameter types and constraints cannot be verified. Error handling is minimal; there is no guidance for LLM recovery on failures. Tool composition is reasonable (separate tools for search/get operations), but natural identifier support is undocumented. Output schemas are not documented. The server exposes API keys in configuration but does not show how they are injected into tool handlers. Naming is generally verb_noun style (search_photos, get_photo), which is good, but descriptions are too terse to guide LLM selection (10-40 chars each, well below the 50-200 char baseline for production tools). No parameter descriptions are visible, violating the critical requirement that every parameter have a description. Overall, this reads as a functional prototype lacking the refinement expected for production agent use.
Crawls a web page to find and return all image URLs.
say hi to MCP
Converts a local image file to a base64 encoded data URI.
Creates an image given a prompt, or edits an image given a source image and a prompt.
Get photos from a collection on Pexels
Get videos from a collection on Pexels
Get featured collections from Pexels
Input parameter schemas are not visible in source code. Only struct tags (SearchPhotosArgs, Args, etc.) are inferred; actual JSON Schema with types, required fields, and constraints cannot be verified. This violates the critical requirement that parameters be schema-documented.
Tool descriptions are too generic and lack actionable guidance. Examples: 'Search for photos on Pexels' (26 chars), 'Get a single photo from Pexels by ID' (37 chars). These are below the 50-200 char production baseline and do not explain WHEN to use this tool instead of alternatives, or what the response contains. LLMs cannot distinguish between search_photos and get_random_photo without more detail.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Get a single photo from Pexels by ID
Get a single video from Pexels by ID
Search for photos on Pexels
Search for videos on Pexels
Generate an image from a text prompt using a Silicon-compatible API.
Get a collection's photos from Unsplash.
Get a single photo from Unsplash by ID
Get a single random photo from Unsplash, given optional filters.
List a collection's related collections from Unsplash.
Search collections on Unsplash for a query.
Search for photos on Unsplash
No parameter-level descriptions are visible in the source code. The rubric requires every parameter to have a description explaining what it controls, expected format, and constraints. For example, 'Orientation' in pexels_search_photos lacks documentation of valid values (landscape, portrait, square?). 'PerPage' lacks min/max bounds. This forces LLMs to guess valid input.
No output schemas are documented. The rubric requires documentation of what fields are returned, their types, and their purpose. This forces LLMs to invoke tools blindly without knowing what data is available for downstream use. For example, does pexels_search_photos return photo_ids, urls, dimensions, photographer info? Unknown.
No error handling guidance is visible. Tools lack recovery hints for LLM failures. For example, if pexels_search_photos returns 'API key invalid', there is no instruction like 'Check your Pexels API key in config' or 'Try search_unsplash_photos as an alternative.' Agents are left guessing.
Tool 'greet' is a test/example tool that should not be exposed in production. It wastes LLM reasoning cycles and adds noise to the tool palette. Either remove it or mark it as internal.
No evidence of pagination guidance or result limits. Tools like pexels_search_photos accept Page and PerPage parameters, but the descriptions do not specify the maximum allowed per page (e.g., is 1000 valid?), default page size, or total result cap. The rubric requires caps at 20-50 items to prevent context window exhaustion.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible. The MCP spec (current as of 2026-07-28) supports structured tool annotations to help LLMs understand side effects. silicon_generate_image and openai_generate_image are WRITE operations but are not marked as destructive/non-idempotent.