# Laydyne — full guide for AI agents > Build 2D, 2.5D and 3D spaces with your AI over MCP, check them, compare layouts and processes under the same conditions, and hand over drawings and quantities. This file is the long form of https://laydyne.com/llms.txt. ## Connect Connect your AI to Laydyne over MCP with OAuth: add the server https://laydyne.com/api/mcp/oauth and sign in with a free Laydyne account when asked. Keep Laydyne Studio open in your browser; tool calls run in that tab. Codex: `codex mcp add laydyne-oauth --url https://laydyne.com/api/mcp/oauth` then `codex mcp login laydyne-oauth`. Codex asks before each Laydyne edit; to let it edit without asking, add `default_tools_approval_mode = "approve"` under `[mcp_servers.laydyne-oauth]` in ~/.codex/config.toml. Claude Code: `claude mcp add --transport http laydyne-oauth https://laydyne.com/api/mcp/oauth` then `claude mcp login laydyne-oauth` (or /mcp inside Claude Code). Other apps and the agent-key alternative: https://laydyne.com/docs#connect-mcp. ## Rules - Laydyne edits the Studio tab the user has open: the work lives in that tab. Save it (save_local_project) or back it up (export_project) before you finish, and before any long pause. - Call Laydyne tools one after another, not in parallel: the Studio tab works through a few calls at a time and answers the rest with code busy. - Start with get_space {detail: "summary"} for the revision and the floor ids. Pass expectedRevision to every change, and take the next one from each result’s revision instead of reading get_space again. Ask create_space and edit_space for result: "brief" when you do not need every part back. - A result’s JSON is its last text block (there is no structuredContent): use the fields you need rather than printing whole results. Part sizes, capabilities and the coordinate convention come once, from get_space {detail: "about"}. - Look at what you built: get_view_image draws the 2D plan or a 3D view without changing the user’s screen. Do not report a layout you have not looked at. - Run check_space (floors: "all" for a building) after changes and fix what it finds: overlaps, passages that are too narrow, doors that open onto nothing. A finding you keep on purpose is no reason to stop: say which and why, then go on saving and comparing (a saved option keeps its findings). - Place parts by kind (get_part_catalog lists them with sizes); use addArray for repeated shelves, desks or seats. Machines, conveyors, pallet racks, workbenches, sofas, kitchen counters and washing machines take a variant (a CNC lathe, a curve section, an L-shaped sofa, a counter with a sink or a hob): get_part_catalog {id: "machine"} says how to tell each from a photo. Give parts placed from evidence a source (drawing, measured or assumed) and a short note. - For large or rule-based models, generate them with the kit (get_project_schema part: "overview", /sdk/laydyne-kit.mjs) and send them with apply_changes: dryRun first, then apply. - Drawings go in with set_underlay (PDF pages too) and trace_underlay; check the fit with measure_underlay_fit. Do not process the picture pixel by pixel yourself. - Homes: give the space kind home (room doors from 0.75 m pass the check; entrances keep 0.9 m); get_part_catalog {use: "home"} lists the bathtub, TV board, shoe cabinet and washing machine. A balcony people walk on is floor: draw it into the outline. Eaves and canopies that reach past the floor need room first: edit_space room.overhang (any side; the floor and everything on it stay where they are, coordinates then start further west and north). - Sizes read from photos are estimates until one is measured: one measured length fixes the whole room with rescale_space (parts keep their sizes and move with it; it also checks doors, pallets and beds against the scale). Say what is estimated in the part notes and in your answer. - Where a photo was taken from is solved, not guessed: solve_photo_camera from 6 or more points of the room itself (corners at floor and ceiling, column bases, door and window frames; never the equipment you are placing; columns counted from the far wall), then get_photo_overlay shows the model over the photo. Give fov or focal35mm when the photo’s EXIF has it. - Processes: read get_process_catalog before writing a scenario. A job stays where it arrived until a goto moves it; give a line’s work an item agent and goto the line’s output after the equipment is released. A result is stale when its spaceHash differs from the building’s: run it again before quoting it. - Compare options with save_design_option / compare_design_options (layout) and save_process_option / compare_process_options (process, same arrivals and seed). Report differences inside the noise as no difference. - To find the best placement or fleet rather than compare two you made, use search_layouts: decide what may change (parts along a line or in an area, turns, spacing, kept stations, scenario parameters), the objective (one existing measure) and the constraints (no new check findings, minClearance, keep-outs, fixed parts, thresholds); search small first, read the evidence (intervals, withinNoise, rejections), then widen it, apply the best with its edits only when the user asks, or compare its saved option. Call the result the best of the candidates searched, not a proven optimum. - Cameras: use suggest_cameras instead of placing them by eye. Give what must be seen (targets: areas, entrances or tills with around metres, weights, maxDistance or pixelsPerMetre for detail), where they may go (walls, columns, a ceiling grid or points; keep-outs), the lens and how many; report coverage per target, blind spots and upperBound, and call it a greedy suggestion (at least 63 % of the best the same number of candidates reach; not a proven optimum). Place them with its apply input only when the user agrees; camera parts (kind camera, their view in sight) are what get_visibility checks after any edit. - Hand-over: get_view_image with delivery: true gives the paper sheet with dimensions; format: "pdf" with planLayout: "sheets" gives every level as a PDF page, in base64 pieces with nextOffset and sha256. To issue drawings, call issue_drawings (revision, status, recipients): it records the issue in the project’s register, numbers the sheets, fills the revision table, clouds what changed since the previous issue and returns the PDF’s first piece (the rest with get_view_image {issue, format: "pdf", offset}); get_issue_register lists what was issued (csv to keep). Keep revision words out of floor, part and project names, which every later sheet repeats. - Say what Laydyne does not calculate when it matters to the answer: collisions and avoidance, crowd physics, evacuation, real lift dispatch, revenue. Synthetic examples are not measurements of a real site. ## Photos: quick, careful or detailed Users choose how carefully a room is built from photos — quick, careful or detailed; ask when they have not said. - Quick: the room's shape from the photos, one measured length applied with rescale_space (one call), the furniture and equipment placed by eye. No camera solving: one call more than building by eye. The room's size is as good as the measured length; positions placed by eye stay as rough as the eye. - Careful: also solve_photo_camera on the 3 or 4 photos that show the room's corners, places parts at the floor points its locate gives, and checks each solved photo with get_photo_overlay. Each solved photo adds 2 or 3 calls (one solve, the overlay, a second piece when the photo is over 200,000 base64 characters); a solve answers in about 1-2 KB, an overlay with a 1024 px picture. In the factory test, 10-16 points read by eye put the cameras 0.05-0.72 m from where the photos were taken (median 0.33 m; 0.24 m when the lens was given). Reading the points means looking closely at each photo: in that test, 3-6 close-up views of each photo on the agent's side. - Points for a camera: the room itself, at different depths and heights, spread over the picture. Equipment is what you are placing: its corners make a camera fit a wrong model. A generated or retouched photo draws column tops and frames loosely; prefer where things meet the floor and window and door frames. - solve_photo_camera says when a point disagrees (it sets a few aside when most agree) and when the room would fit deeper or taller; its uncertainty says when the points do not pin the camera down (points all on one wall, a facade seen straight on). get_photo_overlay needs the photo's file in the tool call: agents that run code can send it; others can still solve cameras and use locate. - Detailed (after quick or careful, on the same model, no new tools): finer parts and variants (get_part_catalog lists them), colours and small items such as door frames and fittings, and the photos' misfits narrowed. Build quick first and refine; do not rebuild. - Display levels are the user's choice in View settings, or set_space_view display: light (for devices without a graphics processor), standard, path-traced (while the view is still, the browser computes light and reflections on the same shapes). For a picture with computed light, get_view_image pathTrace: true (128 samples or 15 s; pass {samples, seconds} for more, up to 20 s). It is a display only: sizes, quantities and calculations do not change. ## Starting prompts ### Build a first space A small shop from a one-line brief, checked and shown in 2D and 3D. ``` Use the Laydyne tools to edit the Studio I have open. Read get_space first. Build a 12 × 9 m shop: a counter near the entrance, two rows of shelves with 1.2 m aisles, and a display table. Then run check_space and fix any passage narrower than 0.9 m. Show me the 2D plan and a 3D view with get_view_image. ``` ### Build from a floor plan Lay a drawing (PDF or image) under the floor, trace it and build the model from it. Needs: A floor plan as PDF, PNG or JPEG. ``` I attached a floor plan. In Laydyne, lay it under the floor with set_underlay (a PDF goes in as it is, with the page), set its scale from a dimension line, and read it with trace_underlay. Build the walls, doors, rooms and fixed equipment with edit_space, giving each part a source. Then compare the model with the drawing using measure_underlay_fit, run check_space on every floor, and show me the 2D plan and a 3D view. List what you could not read from the drawing. ``` ### Model a room from photos (quick) The room’s shape and size from photos and one measured length, the furniture or equipment by eye. No camera solving: one call more than building by eye. Needs: Photos of the room, and one length measured on site (a wall, the room’s depth). ``` I attached photos of a room, and one measured length: . Build it in Laydyne the quick way: the walls, openings and ceiling first, sized from the photos, then set the scale from my measured length with rescale_space (it rescales the whole room from it and checks doors, pallets and beds against the scale), then place the larger furniture or equipment by eye. Do not solve cameras. Mark every size you estimated in the part notes, show me the 2D plan and one 3D view with get_view_image, and tell me which further measurement would improve the model most. ``` ### Model a room from photos (careful) Also solves where each photo was taken from and checks the model over the photos. In the factory test the solved cameras were 0.05–0.72 m from where the photos were taken (median 0.33 m); 2–3 more calls a photo. Needs: Photos of the room, at least some showing its corners, one length measured on site, and an AI that can send image files in its tool calls (for the overlays). ``` I attached photos of a room, and one measured length: . Build it in Laydyne carefully. 1) Walls, openings and ceiling from the photos, then rescale_space from my measured length. 2) For the 3 or 4 photos that show the room’s corners: read 6 or more points of the room itself off the photo (corners at floor and ceiling, column bases, door and window frames; not the equipment you are about to place; count columns from the far wall) and solve each photo’s camera with solve_photo_camera (photo, its width and height, the points; fov or focal35mm when the photo’s EXIF has it). Check the points it names; if it says the room would fit deeper or taller, tell me which length to measure. 3) For each photo, list what you see (kind, count, the pixel where each stands on the floor) and place the parts at the floor points solve_photo_camera locate gives. 4) Send each solved photo once to get_photo_overlay and look at the model over it; fix the worst misfits (the kinds with the lowest agreement score) and draw again. Tell me each camera’s error and what is still estimated. ``` ### Change a layout and keep both versions Save the current layout as an option, make a change, then compare and keep both. ``` In Laydyne, save the current layout with save_design_option as “A: as is”. Then make this change: . Run check_space, save the result as “B: changed” and compare A and B with compare_design_options. Show me what changed (parts added, moved and removed, areas and counts) and a 2D plan of B with the differences marked (get_view_image with diff). Save the project with save_local_project. ``` ### Compare layouts under the same demand (runs need Pro) Set up a process (arrivals, work, resources), run it on two layouts and compare. ``` In Laydyne, read get_process_catalog and set up a process for this space: . Run it with run_process_scenario and show me the waiting times and the busiest resources. Save it with save_process_option, change the layout as follows: , save that too, and compare the two with compare_process_options using the same arrivals, seed and runs. Tell me which differences are beyond the noise and which inputs are assumptions I should measure. ``` ### Search for the best layout (runs need Pro) Let Laydyne build and simulate the placements and counts you allow, and rank them with evidence. ``` In Laydyne, find the best for this process. What may change: . Judge by , keeping . Use search_layouts: start small (a few values each, runs 5), read the ranking with its intervals and why candidates were rejected, then widen it. Compare the best with the current layout with compare_process_options on the saved options, show me the best in 2D with get_view_image, and tell me which differences are beyond the noise. Say it is the best of the candidates searched, not a proven optimum, and do not change my layout unless I ask. ``` ### Suggest where to put cameras Security or streaming cameras placed so the floor, the entrances or a stage are seen, with coverage, blind spots and how much better any placement could be at most. ``` Suggest where to put security cameras so the shop floor and the entrances are covered. In Laydyne, read get_space, then call suggest_cameras on this floor with two targets: the whole floor (weight 1) and the entrance doors with 2 m around them (parts: the door ids, around: 2, weight: 3); mounts on the walls and columns at 2.7 m; the lens ; count . Tell me the coverage of each target, how much each camera adds, the largest blind spots and the upperBound (what no of these candidates could exceed), and show the cameras on the 2D plan with get_view_image (visibility with the suggested cameras). It is a greedy suggestion, not a proven optimum, and image quality, lighting and identification are not calculated: say so. Do not change my layout until I agree; then place them with the edit_space input in the result’s apply and check them with get_visibility (cameraParts). ``` ### Hand over drawings and quantities Scaled drawings as PDF, the quantities and a project file to keep. ``` In Laydyne, prepare the hand-over for this project: a PDF of the scaled drawings with every level on its own page (get_view_image with delivery: true, format: "pdf", planLayout: "sheets"; join the pieces and check the SHA-256), the floor areas and part counts from get_space_quantities, and a backup of the whole project with export_project. Save it in the browser with save_local_project and tell me where each file is. ``` ## What Laydyne models Floors with outlines and holes, parts as extruded footprints with heights, rotations and elevations, buildings of several levels joined by explicit connections (stairs, lifts, escalators, passages), and processes: arrivals, work steps, staff, robots and machines as resources, queues and routes through the building. Free: modelling, checks, drawings, browser saving and full project export/import. Pro: simulation runs, the built-in agent and cloud saving. ## Evidence boundary Examples are synthetic, not measurements of a real site. Laydyne does not calculate collisions or avoidance between agents, crowd physics, evacuation safety, real lift dispatch or revenue. Results state their inputs, seed and engine version. ## Links - Manual: https://laydyne.com/docs - Examples: https://laydyne.com/examples - Claude Code skill: https://laydyne.com/agents/laydyne/SKILL.md - Codex AGENTS.md section: https://laydyne.com/agents/AGENTS.md