The DatumGuard MCP server provides an end-to-end engineering design assurance pipeline for drafting, validating, generating, verifying, repairing, comparing, and exporting CAD designs across architecture, piping, and plate domains — ensuring only independently verified drawings are approved.
design_contract_draft – Draft a structured design contract from raw input without inferring ambiguous numbers or units.
design_contract_validate – Normalize and validate a design contract to ensure it is well-formed and ready for deterministic DXF generation.
drawing_generate – Generate an unverified R2013 DXF file and SVG preview from a validated design contract.
drawing_verify – Independently re-read and remeasure a serialized DXF (as base64) against the contract's targets, tolerances, and constraints — completely separate from the writer.
repair_propose – When verification fails, propose bounded corrections targeting only declared free parameters (e.g., column centers, opening offsets) via CP-SAT optimization, without touching locked dimensions.
repair_apply – Apply an accepted repair proposal to the contract while enforcing locked/free parameter policies.
drawing_compare – Compare two contract revisions side-by-side by public dimension and feature IDs (same design_kind only).
export_bundle – Regenerate the design, run independent verification, and write an approved bundle (DXF + SVG + DO NOT SCALE PDF + verification JSON) locally — only if verification passes.
rhino_preview – Report Rhino preview availability as optional secondary evidence only; does not replace official DXF-based verification.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DatumGuard MCP Server Validate the piping contract for route R-101"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
CAD command success is not accuracy evidence.
DatumGuard는 요구사항을 versioned contract로 잠그고 저장된 DXF·STEP을 다시 열어 재측정한 뒤, 검증된 파일만 내보내는 오픈소스 Engineering Design Assurance 도구입니다. Fail-closed verification for AI-assisted CAD workflows.
검증된 Frame 실행 → · 60초 Case Study → · v0.4.0 release evidence → · Benchmark 재현 →
Safety boundary: FrameGuard는 제한된 2D 선형 탄성 frame의 초기 screening이며 구조 안전 인증이나 전문 구조 검토를 대체하지 않습니다.
/openbim은research_validation_only=true,approval_eligible=false인 합성 연구 preview입니다.
Related MCP server: Construction ISO 19650 (UK BIM) MCP
핵심 | |
문제 | 자연어·폼에서 CAD가 생성되어도 저장 파일의 실제 치수, datum, 공차가 요구조건과 같다는 보장은 없습니다. |
방법 | 요구를 versioned contract로 고정하고, writer와 분리된 reader가 serialized DXF 또는 STEP을 다시 열어 측정합니다. 모든 필수 검사가 통과할 때만 bundle을 활성화합니다. |
증거 | v0.4.0 release는 413 pytest, 41 Playwright, 15-page build, container/SBOM와 security gate를 통과합니다. 실제 Rhino 8·Grasshopper source에서 6개 GUID의 provenance를 DXF XDATA까지 보존했고, DXF completeness gate는 지원하지 않는 내용을 동일 형상으로 주장하지 않습니다. 정확한 run·deployment ID는 release notes에 고정합니다. |
한계 | 구조·안전·법규·산업표준 적합성이나 범용 3D를 인증하지 않습니다. FrameGuard는 제한된 2D 선형 탄성 frame의 초기 screening이며 전문 구조 검토를 대체하지 않습니다. 3D는 세 가지 제한형 solid family의 STEP 기하 검증만 local/CI에서 지원하며, 공개 Render Free API에서는 비활성입니다. OpenBIM 결과도 합성 연구 evidence일 뿐 제작·시공 승인이 아닙니다. 100개 golden contract + 자연어 50개 benchmark는 계획 단계입니다. |
결과 | 재현 fixture | 승인 게이트 |
PASS | CAD 경로는 독립 재측정 후 bundle 승인, FrameGuard는 screening PASS evidence 생성 | |
FAIL | violation을 반환하고 CAD bundle 또는 frame screening PASS 차단 |
중요: PDF 미리보기는
DO NOT SCALE입니다. 2D 설계의 검증된 bundle에 포함된 DXF만 제작 기준 파일이며,/intake의 외부 파일 감사 결과는 informational evidence로서 제작 승인이 아닙니다.
공개 Architecture 데모 열기 → · 실행·재현 가이드 보기 →
이미지의 재현 절차와 화면 계약은 Architecture Demo Guide에 고정되어 있습니다. Architecture, Piping, Plate는 저장된 DXF evidence가 통과해야만 bundle을 활성화합니다. 제한형 Solid은 같은 원칙을 STEP에 적용하지만 local/CI 전용이고, /intake는 외부 CAD 산출물을 변경하지 않고 감사합니다.
분야 | Route | 검증 예시 |
Architecture |
| wall 폐합·연결, opening, grid/column, room area |
Plant / Semiconductor Piping |
| route 연결·직교성, valve/support 위치, equipment clearance |
Structural Frame Screening — v0.4.0 production |
| Rhino/GH source GUID→2D exact solver→DXF semantic 재개봉 gate→surrogate triage |
Mechanical / Ship Plate |
| hole/slot/cutout, edge distance, ligament, overlap |
3D Solid Part — local/CI, hosted run disabled |
| 세 family의 OpenCascade B-rep, bbox, topology, hole/bore diameter와 axis |
Existing CAD Artifact |
| DXF support matrix·completeness gate, STEP·IFC 구조 감사와 revision compare |
OpenBIM Evidence — public research UI, hosted run disabled |
| IFC4+IDS 정보요구조건, IFC integrity, project AABB clearance, protected revision |
세부 범위와 분야별 비목표는 Engineering Domains에 정리되어 있습니다.
FrameGuard는 Rhino 8/Grasshopper가 추출한 centerline·support·load·section metadata를 명시적
unit/datum과 함께 mm contract로 정규화합니다. datumguard_numpy_2d_frame_v1이 변위·반력·member
end force·combined stress를 계산하고, 별도 reader가 serialized R2013 DXF를 다시 열어 좌표·단위·datum을
0.001 mm gate로 검증합니다. 둘 중 하나라도 실패하면 공식 screening PASS와 DXF download를
차단합니다. 상세 교환 계약은 Rhino/GH + DXF Guide에 있습니다.
실제 Rhino 8 + Grasshopper + Cordyceps 실행에서 6개 Rhino GUID → contract entity → DXF
XDATA provenance를 보존하고, DXF 내부의 전체 semantic contract를 독립 재개봉해
0.0 mm endpoint 편차로 통과시켰습니다. 원본
Grasshopper document,
exchange JSON,
verification result,
evidence ZIP을 그대로 재현할 수 있습니다.
이 bundle의 역할은 geometry_evidence이며 안전 인증이나 시공 승인이 아닙니다.
독립 검증 evidence로 genuine openseespy==3.8.0.0 해석과 6개 사례를 비교해 6/6 parity
PASSED를 기록했습니다. solver-labeled 90-case topology holdout에서는 3-seed PyG ensemble의
GraphSAGE가 displacement MAE 0.6274 mm/R² 0.8049, utilization MAE 0.03718/R² 0.7327,
GAT가 각각 0.6512 mm/0.7924, 0.02944/0.8065를 기록했습니다. 이 수치는 합성
pipe-rack family의 연구 결과이며 안전 인증이 아닙니다. surrogate는 PREDICTED 또는
REVIEW_REQUIRED만 반환하고, 공식 PASS는 계속 exact solver와 DXF gate가 결정합니다.
OpenSees parity, PyG benchmark와 uncertainty gate,
ridge historical baseline에 원본 수치와 한계를 공개합니다.
/frame과 FrameGuard assurance API/MCP는 v0.4.0 production 범위입니다. v0.4.0은 실제 Rhino/Grasshopper round-trip evidence와 one-stepframe_rhino_roundtripAPI/MCP를 더했으며, 결과는 여전히 구조 안전 인증이 아닌 초기 screening입니다. 정확한 CI·배포·strict smoke ID는 release evidence에 고정합니다.
protocol-v1에서 동결한 합성 Virtual FAB evaluation 30 case를 실행했다. 120 candidate record와
1,200 measured engine run에서 engine error 0, canonical payload 10/10 일치를 기록했다. 수정 후 Full
pipeline은 TP/FP/FN 330/0/0, clean·authorized false positive 0, engine p95 1,876.222ms였다.
최초 집계에서 발견한 evaluator 구현 오류 2건은 detector를 재실행하지 않고 보존 raw
sha256:58dcf7dc...에서 analysis-v1.0.2로 재분석했다. 사전등록하지 않은 zero-support 처리의
supported-rule macro-F1은 별도 post-freeze sensitivity로만 남겨 두 가설을 NOT_CONCLUSIVE로
표시했다. 전체 provenance, 수정 전후 수치와 한계는
BIM Awards 2026 연구 evidence에 공개한다. BCF 독립 viewer,
배포 license와 production smoke는 아직 gate가 열려 있으므로 BCF 또는 실사업장 성능을 핵심 성과로
주장하지 않는다.
재현 절차와 브라우저 계약은 Piping Demo Guide에 고정되어 있습니다.
Mounting plate, angle bracket, flange만 생성합니다. STEP writer와 격리된 OpenCascade process의 재입력·측정은 local/CI에서 통과하지만 공개 Render Free API의 실행 endpoint는 메모리 안전을 위해 503 DG_CAPABILITY_DISABLED로 닫혀 있습니다. 상세 contract·측정·Rhino 8 왕복 검증은 3D Solid STEP Assurance에 기록되어 있습니다. 외부 CAD 파일은 Artifact Lab Guide의 /intake에서 검사합니다.
flowchart LR
UI["DesignContract<br/>form + confirmed intent"] --> CORE["Canonical geometry<br/>DXF writer"]
CORE --> DXF["Serialized R2013 DXF<br/>layers + XDATA"]
DXF --> VERIFY["Independent reader<br/>remeasure + constraints"]
VERIFY -->|passed| GATE["Approval gate"]
VERIFY -->|repairable| REPAIR["Bounded repair<br/>free parameters only, max 3"]
REPAIR --> CORE
GATE --> BUNDLE["DXF · SVG · DO NOT SCALE PDF<br/>verification JSON"]Writer의 메모리 형상은 verifier로 전달되지 않습니다. Verifier는 직렬화된 DXF를 별도로 다시 읽고, 실제 측정값이 계약의 target·tolerance·constraint를 통과했을 때만 공식 bundle을 승인합니다.
제한형 3D 경로도 SolidPartContract → OpenCascade STEP writer subprocess → 별도 OpenCascade re-import process → approval gate로 writer와 verifier의 데이터 경로를 분리합니다. 이는 mounting plate, angle bracket, flange의 저장 STEP 기하 일치만 검증하며 범용 3D, assembly, 구조·압력·피로·재료·가공성 해석은 범위 밖입니다.
폼 입력을 DesignContract의 source of truth로 사용합니다.
DXF writer와 verifier는 분리되어 있으며 verifier는 직렬화된 DXF를 재측정합니다.
locked 치수와 datum은 자동수정하지 않습니다.
공차·필수 제약을 모두 통과한 경우에만 공식 ZIP bundle을 만듭니다.
Rhino 결과는 선택적 secondary evidence일 뿐 공식 판정을 대체하지 않습니다.
요구 사항은 Python 3.12+와 Node.js 20+입니다.
python -m venv .venv
# Windows: .venv\Scripts\activate
# macOS/Linux: source .venv/bin/activate
pip install -e ".[dev]"
datumguard-api다른 터미널에서 웹을 실행합니다.
cd web
npm ci
npm run dev브라우저에서 다음 경로를 엽니다.
http://localhost:3000/case-study: 60초 product case study
http://localhost:3000/: Interactive Architecture demo
http://localhost:3000/piping: Plant/Semiconductor Utility Piping demo
http://localhost:3000/frame: Structural Frame Screening demo
http://localhost:3000/plate: 샘플 플레이트 설계·검증
http://localhost:3000/solid: 3D solid STEP 생성·독립 재입력
http://localhost:3000/intake: 외부 DXF·STEP·IFC 감사·revision 비교
http://localhost:3000/openbim: IFC4·IDS 연구 검증과 JSON/HTML, 선택적 BCF evidence export
http://localhost:8000/docs: FastAPI 문서
docker compose up --buildWeb: http://localhost:3000
API: http://localhost:8000
Health: http://localhost:8000/api/v1/health
Readiness: http://localhost:8000/api/v1/ready
현재 공개 배포는 아래 주소에서 바로 사용할 수 있습니다.
Product Case Study: /case-study
Architecture: web root
Plant / Semiconductor Piping: /piping
Structural Frame Screening: /frame
Mechanical / Ship Plate: /plate
3D Solid STEP UI: /solid — UI·schema는 공개되지만 실행은 local/CI 기능이며 현재 Render Free API에서는 메모리 안전을 위해 비활성
CAD Artifact Lab: /intake
OpenBIM Research Preview: /openbim — UI와 동결 evidence는 공개되지만 Render 실행 capability는 비활성
/openbim은 production URL에서 조회할 수 있지만 hosted API 실행은 비활성이고,
research_validation_only=true인 합성 연구 evidence만 공개한다. /frame 역시 제한된 2D 선형 탄성
screening이며 두 경로 모두 제작·시공·구조 안전 승인을 발행하지 않는다.
현재 공개 기준은 v0.4.0 release입니다. Vercel 선행 smoke는 새 web과 기존 API의 하위 호환성을 확인하고, Render 완료 이벤트가 실행하는 최종 smoke는 API version, release_sha, capability, Architecture·FrameGuard canary, Artifact Lab audit, Solid 503 fail-closed와 CORS를 같은 배포 revision에서 검사합니다. 도메인 evidence에서 Architecture는 96m²와 4개 room seed, Piping은 12.0m route와 1,975mm minimum clearance, Plate는 전체 치수 편차 0.000000mm를 보고합니다. 이전 v0.3.0은 직전 evidence snapshot, v0.2.1은 rollback baseline으로 유지합니다.
직접 복제해 배포하려면 공개 저장소 tjwnsdhfz/datumguard를 사용합니다. 먼저 Render 버튼으로 backend를 만들고 발급된 API origin을 Vercel 배포 화면의 NEXT_PUBLIC_DATUMGUARD_API_URL에 입력합니다.
Backend는 루트 Dockerfile을 Render, Fly.io, Railway 같은 컨테이너 서비스에 배포합니다.
Frontend는 Vercel 프로젝트의 Root Directory를 web/으로 지정하고, build 전에 NEXT_PUBLIC_DATUMGUARD_API_URL을 backend URL로 설정합니다.
Backend의 DATUMGUARD_CORS_ORIGINS에는 frontend origin을 쉼표로 구분해 설정합니다.
render.yaml은 보호된 main commit을 backend에 자동 배포합니다. Vercel for GitHub는 Root Directory web/에서 PR Preview와 main Production을 만들며, v0.4.0 strict smoke는 /frame DOM, structural_frame domain, deterministic FrameGuard canary와 exact release_sha까지 요구합니다. 최종 원격 run과 deployment ID는 v0.4.0 release notes에 고정합니다. 정확한 연결 계약은 GitHub Deployment Guide, 환경변수·cold start 순서는 Deployment Guide를 따릅니다.
배포 후에는 $WEB_ORIGIN/case-study, /, /piping, /frame, /plate, /solid, /intake,
/openbim을 함께 확인합니다. Frontend를 build한 뒤
NEXT_PUBLIC_DATUMGUARD_API_URL을 바꾸었다면 반드시 rebuild해야 합니다.
공개 데모는 stateless입니다. 계정·DB·서버 프로젝트 저장을 사용하지 않으며, 요청 파일과 자연어 원문을 영구 저장하지 않습니다. Hosted demo에는 Rhino 연결을 요구하지 않으며, Rhino evidence는 로컬 adapter가 있을 때만 secondary cross-check로 사용합니다.
운영 경계도 코드로 고정했습니다. 실제 수신 byte 제한, 파일별·합계 upload 제한, optional API key, anonymous/authenticated quota, heavy CAD queue, parser subprocess, request ID·redacted JSON log, /live·/ready·bounded /metrics, Solid/Artifact Lab kill switch를 제공합니다. 브라우저 draft는 30일 TTL의 IndexedDB에만 저장되며 /privacy에서 전체 삭제할 수 있습니다. 10k DAU는 현재 Free 배포의 용량 주장이 아니며, 출시 체크리스트·장애/rollback·SLO·비용 후보는 Operations Guide와 Cost Guard에 분리했습니다.
OpenCascade Solid은 코드·Linux CI·Docker image에서 실제 STEP 생성과 재입력을 통과하지만, Render Free 512MB Production canary에서 HTTP 502가 발생해 DATUMGUARD_ENABLE_SOLID=false로 fail-closed했습니다. OOM 또는 worker restart는 의심되지만 직접 확인되지 않았습니다. 유료 변경 없이 기능을 과장하지 않기 위한 운영 결정이며, Cost Guard의 Render Standard 이상 staging에서 canary와 부하 검증을 통과한 뒤에만 다시 활성화합니다.
한 번에 생성·검증: POST /api/v1/designs/run
계약 검증: POST /api/v1/contracts/validate
건축 평면 생성·검증: POST /api/v1/architecture/designs/run
건축 계약 검증: POST /api/v1/architecture/contracts/validate
배관 route 생성·검증: POST /api/v1/piping/designs/run
배관 계약 검증: POST /api/v1/piping/contracts/validate
frame 선형 구조 screening: POST /api/v1/frame/designs/run
frame 계약 검증: POST /api/v1/frame/contracts/validate
frame/Rhino schema: GET /api/v1/schema/frame-contract, GET /api/v1/schema/rhino-frame-exchange
Rhino/GH exchange adapter: POST /api/v1/frame/rhino/adapt
frame DXF 생성·독립 재개봉 gate: POST /api/v1/frame/cad/run
비공식 surrogate triage: POST /api/v1/frame/surrogate/predict
정적 연구 evidence: GET /api/v1/frame/benchmarks/opensees, GET /api/v1/frame/benchmarks/gnn
3D solid 생성·STEP 독립 검증: POST /api/v1/solid/designs/run
CAD 파일 감사: POST /api/v1/artifacts/audit
CAD revision 비교: POST /api/v1/artifacts/compare
OpenBIM IFC·IDS evidence: POST /api/v1/openbim/evidence/run — research validation only, MCP 도구 없음
Liveness/readiness/metrics: GET /api/v1/live, GET /api/v1/ready, GET /api/v1/metrics
단계별 endpoint는 TRD에 정리되어 있습니다.
로컬 MCP: datumguard-mcp
MCP는 기존 9개 설계 도구에 artifact_audit, artifact_compare, solid_generate_verify,
frame_analyze, frame_repair_propose, frame_rhino_adapt, frame_rhino_roundtrip,
frame_dxf_generate_verify, frame_surrogate_predict, frame_opensees_parity_evidence를 더한
19개 도구를 제공합니다.
MCP contract 분기는 입력의 design_kind로 결정합니다.
| MCP application service | Web route |
| Architecture |
|
| Piping |
|
| Deterministic 2D frame screening |
|
| OpenCascade STEP |
|
필드 없음 | Plate/panel 호환 경로 |
|
기존 9개 도구 이름은 plate·architecture·piping에서 하위 호환됩니다. artifact_audit과 artifact_compare는 contract 없는 실제 파일에 informational evidence만 만들고, solid_generate_verify는 solid_part contract를 실제 STEP으로 직렬화한 뒤 별도 OpenCascade worker에서 재측정합니다. rhino_preview는 secondary evidence이며 공식 판정을 변경하지 않습니다.
$env:UV_LINK_MODE = "copy" # Windows OneDrive only
uv sync --frozen --extra dev
uv run --frozen ruff check src tests tools
uv run --frozen mypy src/datumguard
uv run --frozen pytest
Set-Location web
npm run typecheck
npm run lint
npm run buildCase Study, Architecture, Piping, FrameGuard, Plate, Solid, Artifact Lab, OpenBIM route의 브라우저 계약은 실제 FastAPI를 함께 시작하는 Playwright E2E로 검사합니다.
Set-Location web
npm run test:e2ev0.4.0 release evidence는 backend
413 passed / 6 optional-runtime skipped, Chromium Playwright 41 passed, typecheck·lint·15-page
build, 두 container build, CycloneDX SBOM, fixed-critical scan, dependency review, pip audit와 두 CodeQL
language 결과를 실제 run에 연결합니다. 선택형 research workflow도 genuine OpenSeesPy와 PyG smoke를
run 29194964854에서 재실행했습니다.
Render 배포 완료 뒤의 Production smoke는 health release_sha까지 대조합니다.
합성 예제 계약은 Architecture의 통과 4-room studio·300mm open-loop 실패, Piping의 통과 CDA route·clearance 실패, FrameGuard의 통과 pipe rack·missing-brace 실패로 제공합니다. 기존 Architecture fixture도 하위 호환 회귀용으로 유지합니다. 모든 예제는 실사업장 도면이 아닌 공개 합성 데이터입니다.
MIT
Draft a contract without inferring ambiguous numbers or units.
| Name | Required | Description | Default |
|---|---|---|---|
| contract | Yes | ||
| intent_text | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses one behavioral trait (not inferring ambiguous numbers/units), which adds value, but lacks information on mutation, side effects, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the purpose. Could include more structure but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested object parameter and output schema, the description omits details about return values and parameter semantics, making it inadequate for a tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'contract' or 'intent_text'. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drafts a contract and adds a specific constraint about not inferring ambiguous numbers or units. This differentiates it from sibling tools like design_contract_validate, but could be more explicit about the type of contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like design_contract_validate. The description only provides a constraint, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalize and validate a DesignContract for deterministic generation.
| Name | Required | Description | Default |
|---|---|---|---|
| contract | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides basic behavioral context: normalization and validation for deterministic generation. However, it lacks details on side effects, idempotency, or what validation entails, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 8 words, with no redundancy. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits critical details about normalization rules, validation criteria, and return behavior. For a validation tool, this incompleteness could lead to incorrect usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'contract' with no description, and schema description coverage is 0%. The tool description does not explain the expected structure, format, or constraints of the contract, adding no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it normalizes and validates a DesignContract for deterministic generation, using specific verbs and a distinct resource. It differentiates from sibling tools like design_contract_draft (drafting) and drawing_* (drawings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a DesignContract needs validation, but does not explicitly state when to use or not use this tool versus alternatives. No exclusion criteria or contextual hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two contract revisions by public dimension and feature IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| baseline | Yes | ||
| candidate | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden of behavioral disclosure. It only states the comparison action without mentioning side effects, required permissions, or output format. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it could be restructured to include key details upfront, but as is it is efficiently brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what the comparison returns (e.g., diff list, similarity score). With two required nested objects and no schema details, the description offers insufficient completeness for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no property descriptions. The description hints that parameters should include 'public dimension and feature IDs', but does not specify the exact fields or structure. The open-ended nature (additionalProperties: true) is not elaborated, leaving the agent under-informed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('compare') and the resource ('contract revisions'), and specifies the comparison criteria ('by public dimension and feature IDs'). It distinguishes from siblings like 'drawing_verify' by mentioning specific IDs, but could be clearer about the output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'drawing_verify' or 'design_contract_validate'. The description lacks any 'when to use' or 'when not to use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an unverified R2013 DXF and SVG preview.
| Name | Required | Description | Default |
|---|---|---|---|
| contract | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description should disclose behavioral traits. It only mentions 'unverified' but does not explain side effects (e.g., file overwrites, resource consumption, authentication needs) or whether operations are read-only or destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly terse. It front-loads the key output, but omits needed details, making brevity a trade-off rather than a structural strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested object parameter and lack of schema descriptions, the description is radically incomplete. It does not explain the input contract, output schema, or how this tool fits with siblings like drawing_compare or export_bundle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'contract' is an opaque object with no schema description (0% coverage) and no hints in the tool description. The agent receives no information about its structure, required fields, or purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (generate) and output format (unverified R2013 DXF and SVG preview), distinguishing it from sibling tools like drawing_verify or design_contract_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no prerequisites, exclusions, or references to sibling tools, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Independently re-read and remeasure serialized DXF bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| contract | Yes | ||
| dxf_base64 | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It implies a read-only safety (re-read) but does not disclose potential side effects, performance impact, or failure modes. The description is too brief to provide meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and to the point, but it lacks structure. It is efficient without being verbose, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters (one nested object) and an output schema, the description is insufficient. It does not explain how to use the parameters or what the output means, though the output schema partially mitigates that. The lack of usage context and behavioral details leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, and the description adds no meaning. It does not explain what 'contract' or 'dxf_base64' represent or any constraints, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (re-read and remeasure) and the resource (serialized DXF bytes). It distinguishes itself from sibling tools like drawing_compare and drawing_generate by implying a verification role, though it could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., drawing_compare, repair_propose). There is no mention of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Regenerate, independently verify, and write an approved bundle locally.
| Name | Required | Description | Default |
|---|---|---|---|
| contract | Yes | ||
| workspace | Yes | ||
| auto_repair | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses key behaviors: regeneration, independent verification, and local writing. However, it omits details like permissions, side effects (e.g., overwriting), or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main action. It is efficient but could benefit from slightly more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (including a nested object) and no annotations, the description is too sparse. It does not explain parameter usage, output expectations, or the meaning of 'approved bundle.' The existence of an output schema does not compensate for missing guidance on inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no information about the three parameters (contract, workspace, auto_repair). The contract object, workspace string, and auto_repair boolean are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Regenerate, independently verify, and write an approved bundle locally.' It specifies the resource (bundle) and distinct actions, differentiating it from sibling tools like design, drawing, or repair tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., design_contract_validate or repair_apply). The description lacks context about prerequisites or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply an accepted repair after enforcing locked/free policy.
| Name | Required | Description | Default |
|---|---|---|---|
| contract | Yes | ||
| proposal | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but offers minimal behavioral insight. It mentions enforcing a policy but does not disclose side effects, destructiveness, permission requirements, or what changes occur. For a mutation-like tool, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but too sparse to be adequately informative. It is front-loaded with the action but omits necessary details, making it underspecified rather than efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (two opaque parameters, a vague policy mention, and sibling tools like repair_propose), the description is incomplete. It does not connect to the repair workflow, explain what 'accepted' means, or clarify the output schema's content. The agent lacks sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the description adds no meaning to the two parameters 'contract' and 'proposal'. Both are typed as arbitrary objects with additionalProperties true, leaving the agent with no clue about their structure or role. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'apply' and the resource 'accepted repair', which clearly indicates the tool's core action. However, the phrase 'after enforcing locked/free policy' introduces ambiguous jargon without explanation, slightly diminishing clarity. It distinguishes from sibling tools like repair_propose by focusing on the application step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., an accepted repair from repair_propose) or when not to use it. The context 'after enforcing locked/free policy' is vague and does not serve as actionable guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose bounded changes to declared free parameters only.
| Name | Required | Description | Default |
|---|---|---|---|
| contract | Yes | ||
| iteration | No | ||
| violations | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details such as whether the tool is read-only, destructive, or has side effects. 'Propose' suggests non-destructive intent, but nothing is explicit. No annotations are provided to mitigate this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded, but it is too terse to be effective. It sacrifices completeness for brevity, missing parameter explanations that are essential for proper usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and nested objects, the description provides no information about return values, errors, or how inputs relate to the tool's operation. This is highly incomplete for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (contract, iteration, violations). 'Bounded changes' and 'declared free parameters' are too vague to clarify the meaning of these inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool proposes bounded changes to declared free parameters, which is a specific action on a defined resource. It is not a tautology and distinguishes from siblings like repair_apply by the action 'propose'. However, it assumes domain knowledge about 'declared free parameters' without explanation, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings such as repair_apply or design_contract_draft. The word 'only' hints at a restriction but does not clarify prerequisites or appropriate contexts. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report Rhino preview availability as secondary evidence only.
| Name | Required | Description | Default |
|---|---|---|---|
| contract | No | ||
| artifact_hash | Yes | ||
| contract_hash | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions 'Report... availability' and 'secondary evidence', which vaguely suggests a read-only lookup, but does not explicitly state whether it is destructive, requires authentication, or has side effects. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of clarity and completeness. It earns a baseline score for brevity, but the conciseness does not serve the agent's needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and an output schema, the description is far too sparse. It does not explain what the tool returns, how to interpret 'availability', or the relationship between parameters. The output schema may provide return-type details, but the description still leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters (contract, artifact_hash, contract_hash) with 0% description coverage. The description does not mention or explain any parameter, so the agent learns nothing beyond the schema's bare names and types. For a tool with required parameters, this is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Report Rhino preview availability as secondary evidence only', but the resource is vague. 'Rhino preview' and 'secondary evidence' are undefined, making it hard for an agent to determine what exactly the tool retrieves. Compared to siblings like design_contract_draft or drawing_compare, the purpose is not clearly distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The phrase 'secondary evidence only' hints at a specific role, but it is not elaborated, so the agent receives no practical usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0design_contract_draftdesign_contract_validatedrawing_comparedrawing_generatedrawing_verifyexport_bundlerepair_applyrepair_proposerhino_previewScored across 9 tools
Each tool has a distinct purpose: contract drafting/validation, drawing comparison/generation/verification, exporting, repair proposal/application, and preview. No overlap.
All tools follow a consistent verb_noun pattern with underscores (e.g., design_contract_draft, drawing_compare). No mixing of conventions.
With 9 tools, the set is well-scoped for the domain, covering contract design, drawing operations, repair, and export without being excessive.
The tool set covers the full lifecycle: draft, validate, generate, verify, export, and repair. No obvious gaps for the stated purpose.
Turn agent intent into physical parts: engineering review, measured geometry, calibrated pricing.
Turn construction drawings into takeoffs, measured routes, schedules and estimates.
AEC subcontractor vendor procurement plumbing layer. Preview - V3 launches 2027.
Navisworks clash detection, 4D simulation, quantity takeoff.
