Loading ToolBench
Construction-plans-reading MCP server: vision-first takeoff intelligence for commercial construction PDFs
conmcp demonstrates solid domain-specific tool design with clear, action-oriented names and well-structured schemas. All 8 tools have descriptions (avg 180 chars, within baseline 194) and input parameters with types and descriptions. However, output schemas are not formally documented in the visible code, only inferred from return statements. Error handling is minimal; most tools lack recovery guidance. Tool composition is strong (each does one thing), but parameter validation and edge-case messaging could be more explicit. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles.
Scan page text for quantity callouts using construction-domain patterns: quantities with units (LF/SF/SY/CY/EA/TON), fence callouts (height, material), gate callouts (width, type), and post spacing (O.C.). These are deterministic leads to verify against the drawing — not a finished takeoff.
Extract ruled tables (gate schedules, hardware schedules, plant schedules) from a page as row grids. Cross-check schedule rows against plan-view callouts — mismatches are RFI candidates.
Validate a completed takeoff against the schema and render it as Markdown (review/Obsidian), CSV (spreadsheets), or JSON (contractor-bid compatible line_items). Validation errors come back as readable messages — fix and retry.
Get the extractable text of one page (notes, callouts, title block). Drawings carry most information graphically — pair this with render_page rather than relying on text alone.
Get plan set metadata and a per-page sheet index (sheet number, title, type like site_plan/details/schedule, and discipline). Call this first to orient yourself in a plan set before reading individual sheets.
Output schemas not formally documented. Return types are inferred from code (e.g., get_plan_overview returns dict with 'version', 'disciplines', 'sheets') but not declared in tool metadata. LLMs cannot reliably predict response structure for downstream chaining.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). generate_takeoff_report is marked WRITE in risk profile but tool definition lacks destructiveHint annotation. All read-only tools lack readOnlyHint. Agents cannot infer safety/retry semantics.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Get the construction takeoff playbook for a trade: workflow steps, field-tested gotchas (scope traps, duplicate-sheet pitfalls, spec locations), UOM conventions, and the JSON schema your final TakeoffReport must match. Call this before building a takeoff.
Render a plan sheet (or a cropped region) as a PNG image so you can visually read the drawing: follow fence lines, count gate symbols, read the legend and graphic scale. Use clip + higher dpi to zoom into details.
Find which pages mention the given keywords, ranked by relevance, with a text snippet per hit. Use this to locate scope-relevant sheets in large plan sets instead of reading every page.
Minimal error handling and recovery guidance. extract_quantities validates page ranges and raises ValueError, but most tools (render_page, extract_tables) do not document failure modes or recovery steps. No pattern like 'If PDF is corrupted, try a lower DPI' or 'If table extraction fails, use get_page_text instead.'
Parameter constraints not fully specified. render_page accepts clip as [x0, y0, x1, y1] in PDF points but does not validate that x0 < x1 and y0 < y1. extract_quantities accepts pages array but does not document max length or warn about performance on large page sets.
No pagination or result limits for potentially large outputs. search_plan_pages caps at 50 results (good), but get_plan_overview returns all sheets without limit. A 500-page plan set could return 500+ sheet objects, exhausting context.