This MCP server has 2 tools with explicit schemas and descriptions. However, it exhibits significant quality gaps across multiple dimensions. Tool naming follows verb_noun convention (get_site, get_sites), which is correct. Both tools have non-empty descriptions, but they are brief (90 and 82 characters respectively) and lack detail about when to use them or what prerequisites exist. The schemas are properly typed JSON Schema objects, but parameters lack descriptions, both tools have missing parameter annotations. The get_sites tool has an empty properties object with no required parameters, which is valid but offers no guidance. Error handling exists but is minimal: the code catches Webflow API errors and throws generic error messages without recovery guidance. No input validation beyond Zod schema parsing, no pagination support despite list operations, and no output schema documentation. The server does not implement any production patterns from the 54 Agentic Tool Patterns (no pagination, no confirmation requests, no batch operations, minimal error classification). Overall, this reads as a minimal proof-of-concept rather than a production-ready tool suite.
Retrieve detailed information about a specific Webflow site by ID, including workspace, creation date, display name, and publishing details
Retrieve a list of all Webflow sites accessible to the authenticated user
Parameters lack descriptions. The 'siteId' parameter in get_site has a description ('The unique identifier of the Webflow site'), but this is minimal and does not explain format, constraints, or how to obtain a valid site ID. get_sites has no parameters, but if expansion occurs, future parameters will lack context. Pattern baseline: 100% of A+ tools have descriptions for ALL params.
Tool descriptions are too brief and lack context. get_site (90 chars) and get_sites (82 chars) are below the baseline average of 194 chars. Descriptions do not explain WHEN to use the tool (e.g., 'Call this first to discover available sites'), prerequisites, or what to do if the site is not found. Pattern baseline: average 194 chars (p10=34, p90=392); descriptions under 20 chars automatically score 0-20.
No output schema documented. Callers cannot see the structure of the response. The handler returns {content: [{type: 'text', text: string}]}, but LLMs are not told what fields the formatted text contains or whether structured data is available. Pattern: Document the output schema so LLMs know what fields to expect for downstream tool calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
No pagination support in get_sites. The code retrieves all sites without limit, offset, or cursor. If a user has hundreds of sites, the response balloons and wastes tokens. Pattern baseline: Tools returning lists must accept page/offset and limit parameters. Should cap results and include next_cursor.
Error handling lacks recovery guidance. When a site is not found, the tool returns 'Site with ID {siteId} not found.' but does not suggest calling get_sites to discover valid site IDs. When a network error occurs, 'Failed to fetch site details' gives the LLM no actionable next step. Pattern: Error responses must tell the LLM what to do next.
No input validation beyond schema parsing. The siteId parameter is checked with Zod but only for non-empty string. No validation of format (expected length, character set, or pattern). If an invalid ID is passed, the Webflow API rejects it with a generic 'Failed to fetch site details' error. Pattern: Include the invalid value and the constraint it violated in error responses.
STDIO-only transport. The server uses StdioServerTransport and is not remotely accessible. This hard-caps protocol readiness at 50/100 per the rubric: 'STDIO-only servers are capped at 50 for protocol readiness. They are not remotely accessible and cannot work with hosted MCP clients.'
get_sites has empty input schema (no properties, no required array). While valid, this provides no parameter guidance. If the tool is extended to support filters (e.g., workspace_id, status), those parameters will need descriptions from the start.