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., "@ritn3d-mcp Validate my floor plan image before uploading to Ritn3D"
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.
A Model Context Protocol (MCP) server that gives Claude, Claude Code, Cursor, Cline, or any other MCP-compatible AI agent the lightweight tools needed to prepare a floor plan for Ritn3D and interpret the resulting 3D output — without exposing the underlying wall-detection model or inference API.
Ritn3D is an AI floor-plan-to-3D-model tool. This MCP server exists so that AI agents helping users in floor-plan- adjacent workflows (renovation planning, real estate, 3D printing, etc.) have a clean, well-documented set of tools instead of guessing.
pip install ritn3d-mcpRelated MCP server: Revit MCP Server
Add to ~/Library/Application Support/Claude/claude_desktop_config.json
(macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"ritn3d": {
"command": "ritn3d-mcp"
}
}
}Restart Claude Desktop. The Ritn3D tools appear in the tool picker.
claude mcp add ritn3d ritn3d-mcpTool | Description |
| Pre-flight check on a floor plan image (format, dimensions, warnings) before sending to Ritn3D |
| Heuristic complexity score (simple / moderate / complex) based on edge density |
| Rough low/expected/high render-time range for a given complexity |
| Fetch public page title + OpenGraph data from a Ritn3D share URL |
| Sanity-check a downloaded GLB file (magic header, version, chunks) |
| Unit conversion with optional model scale factor (1:100, 1:50, etc.) |
| Returns Ritn3D's supported inputs, outputs, accuracy by input type, and pricing |
| Returns current Ritn3D pricing tiers in USD |
| Returns structured list of known failure modes with mitigation tips |
URI | Content |
| Machine-readable summary of what Ritn3D does, accuracy, pricing |
| Common failure modes and mitigations |
User: "I have a real estate listing PDF I want to 3D print as a model of my future apartment."
Agent calls
validate_floor_plan_image("listing.pdf.jpg")→ warnings: aspect ratio normal, resolution OK.Agent calls
estimate_complexity(...)→ label "moderate", score 0.5.Agent calls
get_failure_modes()→ notices the "real-estate-listing-render" failure mode applies; warns the user that wood-floor textures may trip detection.Agent calls
get_pricing()→ quotes Pro+ at $19.99/mo for STL export.Agent recommends: try the Ritn3D web app at app.ritn3d.com; if detection fails on this listing PDF, ask the agent to estimate the complexity of an alternate input.
Run inference. The Ritn3D wall-detection model lives on Ritn3D's servers and is reached through the web app.
Bypass the Ritn3D subscription. Pricing is enforced server-side.
Expose the rendering pipeline internals.
Provide a render queue or job-tracking API.
The intent is to make agents better citizens of the Ritn3D workflow, not to replicate it.
Built by the Ritn3D team. Same group that
maintains ritn3d-stl-tools
and ritn3d-floorplan-eval.
MIT — see LICENSE.
Heuristic estimate of a floor plan's detection complexity. Reads basic image stats (resolution, brightness range, edge density) and returns a label (simple/moderate/complex) plus a numeric score. Useful for batch routing and for setting user expectations about how many corrections may be needed.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the floor plan image. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It specifies inputs (resolution, brightness range, edge density) and outputs (label, numeric score), and notes its heuristic nature. It lacks details on side effects or error handling but is sufficient for a read-only analysis.
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?
Two sentences: first defines purpose and output, second provides usage context. No wasted words.
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 low tool complexity (1 parameter, no output schema), the description adequately covers purpose, inputs, outputs, and usage. It does not specify numeric score scale or error cases, but these are not critical for the tool's function.
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 100% for the single parameter 'path', which already describes it as a path to the floor plan image. The description adds no additional semantic 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 the tool estimates a floor plan's detection complexity using heuristic image analysis, returning a label and numeric score. It differentiates from siblings by focusing on complexity rather than render time or validation.
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 mentions usefulness for batch routing and setting user expectations, providing context for when to use. However, it does not explicitly state when not to use or compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rough estimate of how long the Ritn3D pipeline will take to render a 3D model from a given plan. Returns a low/expected/high range in seconds. Useful for telling users 'this will take about a minute' versus 'this may take five minutes.'
| Name | Required | Description | Default |
|---|---|---|---|
| complexity | Yes | Complexity label, e.g. from estimate_complexity. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the estimate is rough, returns a low/expected/high range in seconds, and implies no side effects. Could explicitly state it's read-only, but the name and context suggest non-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?
Two sentences: first defines purpose and output, second provides usage context. No unnecessary words.
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?
For a simple tool with one parameter and no output schema, description adequately covers what the tool does, what it returns, and how to use it with the sibling tool.
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 100% with enum description. Description adds cross-reference to sibling 'estimate_complexity' as a source for complexity label, adding value beyond 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?
Description clearly states the tool estimates render time for 3D models using the Ritn3D pipeline, with verb 'estimate' and resource 'time'. Distinguishes from siblings by focusing on time rather than complexity or validation.
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?
Implies usage when a render time estimate is needed ('useful for telling users...'), but does not mention when not to use or compare with alternatives like estimate_complexity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-flight check on a floor plan image before sending it to Ritn3D. Reports format, dimensions, file size, color mode, and heuristic warnings (too small, wrong aspect, low contrast). Use this before uploading via the Ritn3D web app or mobile app to catch obvious problems early.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Filesystem path to the floor plan image (JPG, PNG, BMP, TIFF, WebP). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully describes the tool's behavior: it reports on various image properties and heuristic warnings. It implies a safe, non-destructive operation ('pre-flight check'), with no contradictions.
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 two sentences, each earning its place: first sentence defines functionality, second provides usage context. No redundant or extraneous content.
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?
For a simple tool with one parameter and no output schema, the description adequately covers what the tool does and when to use it. It lacks detail on heuristic warning criteria, but the overall context is sufficient.
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 'path' is fully described in the input schema (100% coverage), listing accepted formats. The description adds no additional semantic meaning beyond what the schema already provides.
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 performs a 'pre-flight check' on floor plan images, listing specific checks (format, dimensions, file size, color mode, heuristic warnings). It differentiates from sibling tools (estimate_complexity, estimate_render_time) which are about estimation, not validation.
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?
Explicitly states 'Use this before uploading via the Ritn3D web app or mobile app to catch obvious problems early,' providing clear usage context. It does not explicitly state when not to use, but the guidance is sufficient for an agent to decide.
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.2estimate_complexityestimate_render_timevalidate_floor_plan_imageScored across 3 tools
Each tool has a clearly distinct purpose: one validates the image format, one estimates complexity, and one estimates render time. There is no functional overlap.
All tools follow a consistent verb_noun pattern (validate_, estimate_). The naming is predictable and clear.
With 3 tools, the server is well-scoped for its purpose as a pre-processing helper. The count is appropriate and not excessive.
The tools cover essential pre-flight checks and estimations. The missing actual rendering submission is likely handled externally, so no critical gap.
Construction takeoff and estimating for AI agents. Measure a drawing PDF, export a priced estimate.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
Give your AI agents the tools to build, manage, and run automation workflows.
