3D New Era AI

Overview Schema Source Related Servers Discussions Admin

Project settings

edit_home

Destructive

Set a home project's name, properties, compass, city building code, and occupant details so ergonomic and compliance scores reflect the right rules.

Instructions

Rename the project, set or remove project properties (properties {key: value|null}, or a storey's with level), set the compass (north), set the city whose building code applies (city=sao-paulo), and say who lives there (people {occupants, children, elderly, wheelchair, stature cm, scope}). City and people belong to the project: ergonomics, layout and every dry run then weigh the same rules for the same people, so a change can be tested against the score it moves.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	City whose building code applies, e.g. `sao-paulo`; `""` clears it. Kept with the project, so `ergonomics`, `layout` and every dry run weigh the same municipal rules
`name`	No	The project's name
`level`	No	Storey whose properties `properties` changes, e.g. `lv2`
`north`	No	Clockwise degrees from plan up to north
`people`	No	Who lives there — occupants, children, elderly, wheelchair, stature cm, scope — kept with the project: ergonomics and every dry run then score for them. What is left out stays as it was
`region`	No	State or province whose code applies: `sp`, `fl`; `""` clears it. In the United States it is the state that adopts a building code, so it matters as much as the country there
`country`	No	Country whose standards apply, ISO 3166-1 alpha-2: `br`, `us`, `de`; `""` clears it. It decides which sources oblige and which only inform — a Brazilian standard is a reference in Florida, and the IRC is a reference here. A city we hold implies its country, so this is for saying where a project is when no code was picked
`compass_d`	No	Compass diameter cm
`compass_at`	No	Where the compass sits on the plan, `[x,y]` cm
`properties`	No	Project properties to set, `{key: "value"}`, or remove, `{key: null}` — what an import leaves behind (window sizes, panel dividers, ids of the program it came from). With `level`, that storey's instead
`compass_visible`	No	Show or hide the compass

Output Schema

TableJSON Schema

Name	Required	Description	Default
`v`	No
`ok`	Yes
`ids`	No
`rev`	No
`text`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv3.0.0Sep 30, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds genuinely non-structured behavior: omitted fields 'stay as it was' (patch semantics), `{key: null}` removes a property, and city/people are persisted with the project and inherited by ergonomics/layout/dry runs. That persistence vs per-call distinction is real added value.

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?

Two sentences, front-loaded with the enumeration of editable settings so the agent sees scope immediately. The second sentence is slightly meandering but earns its place by explaining why city/people matter. No filler sentences.

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 not be described, and the safety profile is carried by annotations. The description covers the semantically rich parameters (properties, people, city) adequately. It under-describes the compass geometry and the region/country code-selection parameters, though the 100%-covered schema compensates.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 11 parameters in depth, including the People and ReviewScope sub-objects. The description mostly restates what the schema carries (properties as {key: value|null}, the people fields, city=sao-paulo) and omits region, country, compass_d, compass_at and compass_visible entirely. Baseline 3 is appropriate.

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 description names specific operations on a specific resource: rename the project, set/remove properties, set the compass, set the city code, and set occupants. An agent knows this is the project-level settings editor. It does not, however, distinguish itself from overlapping siblings such as edit_levels (storey properties are set here too via `level`) or the `home` tool.

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

Usage Guidelines3/5

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

Usage is only implied: the trailing sentence about `ergonomics`, `layout` and dry runs hints that this is where project-wide context is established before scoring. There is no explicit when-to-use statement, no when-not to use it, and no named alternative among the many `edit_*` siblings.

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