Loading ToolBench
MCP Server for Contentful Delivery API - provides tools to query and retrieve entries, assets, and content types from Contentful
This server has 7 read-only tools with basic schemas and descriptions, but significant gaps in parameter completeness and error handling guidance. All tools follow verb_noun naming (get_*, query_*). Descriptions are present and explain the action, but most are terse (30-50 chars, below the baseline 194-char average). Input schemas are properly structured with JSON Schema types, but many parameters lack descriptions or constraints. No output schemas are documented. Error handling is minimal, tools throw generic errors without recovery guidance or actionable messages. The server is STDIO-only, which is a hard cap at 50 for protocol readiness. Definition quality alone scores 54 based on adequate but basic tool design.
Get a specific Contentful asset by ID
Get all assets from Contentful
Get a specific Contentful content type by ID
Get all content types from Contentful
Get multiple entries from Contentful with optional filters
Get a specific Contentful entry by ID
Query and find content in Contentful delivery API
No output schemas documented. Tools return JSON responses but LLMs cannot plan downstream calls without knowing the structure. Example: get_entries returns 'items' array but size, field names, and nested structure are not specified in any tool definition.
Parameter constraints missing. 'limit' parameters (get_assets, get_entries) have no min/max bounds. LLMs could request limit=999999, causing excessive API load or timeouts. Should specify range, e.g., limit 1 - 100.
Descriptions are below baseline (avg 194 chars). Most are 30 - 60 chars, too terse for LLM selection. Example: 'Get all assets from Contentful' does not explain what assets are, when to call this vs other tools, or expected result size. Should include context like 'Returns list of media, images, and files; call this first to see available media before referencing in entries.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Error handling is generic and non-actionable. All tools throw 'Failed to [action] [id]: [error]' without categorizing errors or suggesting next steps. Example: 'Failed to get entry ABC123: 404' tells the LLM nothing about whether to retry, lookup a different ID, or ask the user. Should return structured errors with recovery guidance.
Pagination not supported. Tools like get_assets and get_entries accept 'limit' but no offset/cursor for iterating large result sets. If a space has 500 entries and limit=50, the LLM cannot fetch page 2. Should add 'offset' or 'cursor' parameter and document in description.
No guidance on dependency or mutual exclusivity. get_entries has both 'contentType' and 'contentTypeIds' parameters; the code notes 'contentTypeIds takes precedence if both provided' but the parameter descriptions do not mention this. LLMs will pass both, wasting reasoning cycles and risking ambiguous behavior.
Parameter naming inconsistency with Contentful API. The server filters by 'contentTypeIds' (plural array), but get_entry and query_entries also use 'contentTypeIds'. However, query_entries description says 'Optional: Filter search results by content type IDs', unclear if it filters the query results or restricts what types are searchable. Should clarify with examples in parameter description.
Response filtering and size limits not enforced. Tools return raw Contentful API responses (JSON.stringify(asset, null, 2) or JSON.stringify(assets.items, null, 2)). No stripping of irrelevant metadata, audit fields, or pagination internals. Large result sets (e.g., 100 assets with full metadata) waste tokens and risk exhausting context windows.