Loading ToolBench
Pattern checks a coding agent's UI decisions against real evidence before it builds, whether that means your own design system in code or Figma, or components from popular libraries. It helps the agent choose what the product actually needs without overbuilding. An opt-in enforcement boundary can make that check required, and every decision is recorded in an auditable ledger you can verify later.
Pattern MCP defines 9 tools with moderate schema and description quality. All tools have descriptions (94-270 chars, median ~160), meeting the 10-1024 baseline. However, the server exhibits significant gaps in parameter descriptions, schema completeness, and error handling guidance. Most tools accept optional parameters without clear documentation of their purpose or constraints. Tool names follow verb_noun convention (recommend_, extract_, record_, export_, register_, list_, init), which is good. However, parameter naming is sometimes vague (e.g., 'checklist' in recommend_component lacks detail on format). Schemas are present for most tools but lack comprehensive constraint documentation (enums, formats, ranges). Output schemas are not explicitly documented, forcing LLMs to infer structure. Error handling is minimal, most tools lack guidance on retry logic, failure recovery, or actionable next steps. The verify-export-ledger-provenance-tool.mjs script shows the tool works, but production error paths are not visible in the source.
Exports a specific ledger entry as formatted markdown documentation, verifying the entry exists for the given project and returning a human-readable decision record with full provenance information.
Extracts concrete requirements from a component need description into a checklist of specific elements the component must contain, grounded in the stated domain.
Sets up Pattern for the first time, detecting the MCP client being used and writing the necessary configuration to connect to the Pattern server, including ANTHROPIC_API_KEY setup.
Lists all entries in the project's decision ledger, optionally filtered by feature_id or verdict. Returns an array of ledger entries with their metadata.
Recommends whether a UI component need should be met with an existing shadcn/ui, 21st.dev, or ReUI component, or requires a custom build guided by a real-app reference from Mobbin. Returns a verdict (use_existing or custom_build), confidence level, coverage percentage, and detailed recommendation with reasoning.
Output schemas not documented. LLMs cannot infer what recommend_component, extract_requirements, and register_design_system return. No parameter schemas visible for fields like 'verdict', 'coverage', 'confidence', 'candidates_evaluated'. This forces LLMs to guess downstream structure.
Parameter 'checklist' in recommend_component and record_component_decision lacks format specification. Is it an array of strings? Objects with properties? No enum or pattern constraint. LLMs cannot validate input.
Error handling guidance missing. Tools (e.g., register_figma_design_system calling Figma API) can fail but provide no recovery hints. LLM receives errors with no actionable guidance: retry? Provide a different ID? Check permissions? Required by pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Recommends a component from a previously registered design system (local directory or Figma) by scoring the component_need against the registered candidates using Jev or Anthropic scoring, returning a use_existing verdict if a suitable component is found.
Records a confirmed component decision to local per-project memory, appending to a memory.json file for consistency context in future calls via project_id.
Registers a project's design system by scanning a directory for UI components, extracting their names, props, descriptions, and file paths to create a candidate pool for recommendations. Returns a registration with all discovered candidates.
Registers a Figma file as a design system by fetching the file via the Figma API, parsing its components, extracting names and descriptions to create a candidate pool for recommendations.
init() tool lacks clear description of what 'setup' does. Does it create files? Modify configs? What happens on second invocation? Description is vague ('Sets up Pattern for the first time, detecting the MCP client being used and writing the necessary configuration...') but doesn't explain idempotency or what files/envvars result.
Optional parameters (project_id, feature_id, checklist in recommend_component) lack documentation of when they should be omitted vs provided. LLMs cannot decide whether passing project_id for 'consistency context' is beneficial or wasteful.
No pagination or limits documented for list_ledger. If a project has thousands of ledger entries, does the tool return all? Truncate? Accept a limit parameter? Baseline requires limit/offset + count returned.
Destructive tools (record_component_decision, init) not annotated with risk hints. record_component_decision modifies local state (appends to memory.json/ledger.jsonl) but has no 'destructive' or 'state-mutating' flag to warn the LLM.