3D New Era AI

Overview Schema Source Related Servers Discussions Admin

Read the home

home

Read-only

Query floor plan data by ids, room, rectangle, kind, or field to return only needed walls, rooms, dimensions, labels, furniture, or polylines.

Instructions

Home state. detail=summary is cheapest. Ask for less instead of reading everything: ids=[…] resolves ids (group parts included), room=<id|name> and rect=[[x0,y0],[x1,y1]] read one place, kinds=[walls|rooms|dims|labels|furniture|polylines] and fields=[…] trim each row, parts=true opens groups, ndjson=true prints one element per line so a long answer can be read a slice at a time. Every piece carries bounds (plan box with angle applied) and faces (the side it opens toward). Ids share one counter per version (w1, r2, f3…) and are never reused, so a new version may start at any number.

Input Schema

TableJSON Schema

Name	Required	Description
`ids`	No	Only these ids, group parts included, e.g. `["f833","w24"]`
`rect`	No	Only what meets this rectangle, `[[x0,y0],[x1,y1]]` cm
`room`	No	Only what stands inside this room, by id or name
`kinds`	No	Only these kinds: `walls`, `rooms`, `dims`, `labels`, `furniture`, `polylines`
`level`	No	Storey to read: an id like `lv3`, or `all`. Default: the one shown
`parts`	No	List what is inside groups instead of only counting the parts
`detail`	No	`summary` (counts, bounds, room areas) or `full` (default)
`fields`	No	Keep only these fields of each element; `id` is always kept
`ndjson`	No	One element per line (NDJSON) instead of one JSON object, each line tagged with its kind. Long answers stay readable a slice at a time

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rev`	No
`dims`	No
`name`	No
`lines`	No
`north`	No
`parts`	No
`rooms`	No
`walls`	No
`bounds`	No
`counts`	No
`labels`	No
`levels`	No
`warnings`	No
`furniture`	No
`polylines`	No
`background`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv3.0.0Sep 30, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. Beyond that the description discloses real behavior: every element carries bounds and faces, ids share one never-reused counter per version, and ndjson streams one element per line. It adds no auth or rate-limit notes, but the domain semantics are genuinely informative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the cheapest option and then walks the parameter effects in one dense but scannable sentence. It is efficient with no filler, though the fragment-opening and run-on list demand careful reading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, yet the description still adds bounds/faces and ID-counter semantics that matter for interpreting results. Filtering, detail level, and streaming are all covered, so an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining the intent behind the knobs (ids resolves group parts, detail=summary is cheapest, ndjson makes long answers readable). It adds rationale the schema does not, without contradicting any parameter definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title "Read the home" plus "Home state." make it clear this reads the plan/home model, and the body elaborates on filtering behavior. However, the description itself opens with a noun fragment rather than a verb+resource, and it never distinguishes this read tool from sibling reads like `model` or `show_plan`, so the agent must infer the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Ask for less instead of reading everything" and "detail=summary is cheapest" give explicit guidance on how to call this tool cheaply and when to narrow. It stops short of naming a specific alternative tool to prefer in a given situation, so it is strong context rather than full when/when-not routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.