Loading ToolBench
MCP server that generates unique website design blueprints for local businesses using local Ollama instances. Produces detailed markdown specifications covering page structure, typography, color palettes, CSS specs, and design elements. Supports blueprint generation, comparison, critique, and improvement workflows.
Strong tool definitions with comprehensive descriptions (avg 250+ chars) and detailed parameter documentation. All 6 tools have explicit schemas with typed parameters and clear descriptions. Naming follows verb_noun convention (generate_*, critique_*, compare_*, improve_*, multi_*). However, output schemas are not formally documented in the code, responses are described narratively rather than as structured JSON schemas. Error handling is present but minimal (basic validation, no recovery guidance). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (WRITE vs READ_ONLY). Parameter descriptions are excellent but lack formal constraints (enums, min/max) for some fields like 'preset' and 'model'.
Head-to-head comparison of two blueprints for the same business. Returns per-dimension winners (industry fit, differentiation, visual specificity, CSS feasibility, audience fit), an overall winner, and a hybrid suggestion that names specific elements to graft from the loser into the winner. Useful when you have two strong candidates and need to choose — or want to engineer a stronger third option.
Run a tough, specific critique of an existing site blueprint. Returns scores (1-10) across five dimensions — industry-appropriateness, differentiation, visual specificity, CSS feasibility, audience fit — with reasoning that references the blueprint by section. Ends with three concrete weaknesses to fix and one thing the blueprint nails. Useful when comparing variations or before handing a blueprint off to a downstream code-generation step.
Generate a unique website design blueprint for a local business. Returns a detailed markdown spec covering page structure, typography system, color palette, section-by-section CSS specs, and unique design elements that differentiate the site from generic templates. Designed to be handed to a code-generation step (or another LLM) to produce a working HTML site. Runs against a local Ollama instance — no cloud calls, no API keys.
Like generate_blueprint, but also screenshots the competitor URL via headless Chrome and feeds the image to a vision-capable model so the differentiation guidance is visual, not just textual. Use this when you have a specific competitor whose design you want to counter-program. Requires Chrome/Chromium on the host running architect-mcp; takes ~10-20s longer than generate_blueprint due to the screenshot step.
Output schemas not formally documented. Tool descriptions state what is returned (e.g., 'Returns scores (1-10) across five dimensions') but no JSON Schema for response structure. LLMs cannot reliably parse unstructured markdown responses or plan downstream operations.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite explicit risk labels in metadata. generate_blueprint and generate_blueprint_from_url are marked WRITE (file I/O via output_path); others are READ_ONLY. Annotations enable agents to reason about side effects and retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Take an existing blueprint plus a critique of it, return a revised blueprint that addresses the critique's weaknesses while preserving the strengths. The natural pair to critique_blueprint — call critique first, then feed the original + critique here. Single model call (~60-90s on gemma4:26b), unlike a generate→critique→improve chain which would push past MCP client timeouts. Output ends with a 'What Changed From v1' section spelling out which weaknesses got addressed and which strengths were preserved.
Generate multiple blueprint variants for the same business in one call. Each variant uses a different sampling temperature (0.7, 0.95, 1.2) so the outputs explore different design directions — useful when you want to compare options or feed the best one(s) to compare_blueprints. Capped at 3 variants to keep total runtime under ~5 minutes. Variants run sequentially because a single GPU can only host one model at a time.
Parameter constraints not formalized. 'preset' accepts a known set (dentist, plumber, hvac, etc.) but is defined as free-form string, not enum. 'n' in multi_blueprint has max=3 stated in description only, not in schema. LLMs cannot validate inputs before calling.
Error handling lacks recovery guidance. errResult() returns plain error strings (e.g., 'blueprint generation failed: <err>'). No actionable next steps, no error classification (retryable vs fatal), no suggestions for user correction.
No pagination or result limits documented for multi-variant outputs. multi_blueprint can return 3 variants × 3-8KB each (~30KB total). No guidance on truncation, streaming, or chunking for large responses that may exceed context windows.