Loading ToolBench
Diagram generation for codebases using Google Gemini 3 Pro Image model
Blueprint MCP has fundamental structural issues. Three tools are visible with some descriptions and partial schemas, but critical gaps in parameter documentation, error handling, and schema completeness severely limit LLM usability. Tool names follow verb conventions but descriptions are sparse. Parameters lack proper type constraints and format guidance. Output schemas are undocumented or inferred rather than formally declared. Error responses are generic strings rather than actionable guidance. The server lacks any tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having clear read vs. write semantics. No pagination support despite the image generation pattern involving multiple lookup steps. Security: API key is properly injected via requires_secrets, but error messages returned as plain strings could leak implementation details.
Check generation progress.
Download diagram. Format: IMAGE|filename|width|height|base64
Start diagram generation.
Output schemas are undocumented or encoded as prose delimited strings rather than structured JSON. All three tools return plain strings instead of typed objects. LLM must parse and reason about unstructured text to extract data, leading to token waste and hallucination risk.
Enum parameters (diagram_type, aspect_ratio, resolution) are documented in descriptions as free-form text ('Type: architecture, flowchart, ...') rather than declared as JSON Schema enums. LLM cannot validate or autocomplete valid options, must infer from description prose.
Tool descriptions are too brief (28-34 characters). None explain WHEN to use the tool, WHAT happens to state, or prerequisites. Pattern:tool-description requires 50-200 characters explaining what, when, and any dependencies.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). start_diagram_job modifies state (creates job in _diagram_jobs dict) and has side effects (background thread). download_diagram deletes state (del _diagram_jobs[job_id]). These should be marked @destructive. check_job_status is read-only and should be marked @readOnly.
Error responses are generic strings with no recovery guidance. Pattern:recovery-guide requires errors to tell LLM what to do next. E.g., 'Job not found' should be 'Job ID {job_id} not found. Check job ID spelling, or start a new diagram with start_diagram_job().'
Parameter 'output_dir' in start_diagram_job lacks format guidance. Is it an absolute path, relative to cwd, or a preset alias? Defaults to None → Path.cwd(), but this is implicit and not documented. Violates pattern:tool-description which requires format, range, and constraints to be explicit.
No pagination or batching support. If an agent needs to check multiple jobs, it must call check_job_status N times sequentially. Violates pattern:paginated-result (list endpoints) and composition guidance for batch operations.
Threading and in-memory job storage have no documented guarantees. Job retention is heuristic (MAX_JOBS_IN_MEMORY=3, JOB_EXPIRY_MINUTES=10) with no SLA. Agents cannot rely on status checks after process restart. Pattern:idempotent-operation requires tools to be reliable for retry, unspecified retention breaks idempotency.
start_diagram_job returns a prose string ('Job ID: {job_id}\nWait 30 seconds, then check_job_status') instead of a structured object with job_id and next_steps fields. LLM must parse and extract job_id from text, error-prone.