3D New Era AI

Overview Schema Source Related Servers Discussions Admin

Review ergonomics

ergonomics

Read-only

Check a home layout for people: walking clearances, bed and seat counts, kitchen work zones, doors, windows, and wheelchair turning. Get a habitability score with findings and fixes.

Instructions

Ergonomics and habitability review for the people living there: room to walk beside beds and in front of kitchen equipment, beds, seats, bathrooms and wardrobes per person, the kitchen (work triangle, counter heights and lengths, work zones, sockets, gas ventilation, extraction), doors, ceiling heights, windows, minimum furniture, wheelchair turning. It advises and never blocks. Answers {score, score_basis, scope, scores:{architecture,electrical,plumbing}, layout, coverage, capacity, findings:[{sev, place, msg, key, weight, discipline, in_scope, src?, fix?, accepted?}], sources:{src:[title, tier, url]}}. weight is what the score gains if that finding goes; fix is a checked change as move or update arguments, to apply and review again; tier A–E is how much the source obliges where the project is. People and city given here weigh this call only; edit_home keeps them for every review. accept marks a finding right as drawn. How the score and the tiers work: rules topic=ergonomics.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	City whose building code applies for this call only, e.g. `sao-paulo`; `edit_home(city=…)` keeps it with the project
`level`	No	Storey to review, an id like `lv3` (default: the one shown)
`scope`	No	Disciplines included in the score. Architecture always counts; excluded findings remain visible
`elderly`	No	Of them, elderly people
`stature`	No	Height of the main cook, cm, to size the countertop (default 165)
`children`	No	Of them, children (sleep in single beds or cribs)
`occupants`	No	People living in the home (default 2)
`wheelchair`	No	Someone uses a wheelchair: NBR 9050 turning space, doors and reach

Output Schema

TableJSON Schema

Name	Required	Description	Default
`scope`	No
`score`	Yes
`layout`	No
`scores`	No
`sources`	No
`capacity`	No
`coverage`	No
`findings`	Yes
`orphaned`	No
`score_basis`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedv3.0.0Sep 30, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / city / description

Previous value: -"City whose building code applies for this call only, e.g. `sao-paulo`; `set_home(city=…)` keeps it with the project"New value: +"City whose building code applies for this call only, e.g. `sao-paulo`; `edit_home(city=…)` keeps it with the project"

addedInput schema / properties / level

Added value: +{
+  "description": "Storey to review, an id like `lv3` (default: the one shown)",
+  "type": "string"
+}

removedOutput schema / properties / capacity / description

Removed value: -"What the home holds: beds, bedrooms, bathrooms, seats, wardrobe cm"

removedOutput schema / properties / coverage / description
```
Removed value: -"What was checked and what was not"
```

removedOutput schema / properties / findings / description

Removed value: -"{sev, place, msg, key, weight, discipline, in_scope, src?, fix?, accepted?}"

removedOutput schema / properties / layout / description

Removed value: -"Layout issues of the storey, as check_layout gives them"

removedOutput schema / properties / orphaned / description

Removed value: -"Acceptances whose finding is gone: [key, reason, successor key?]"

removedOutput schema / properties / scope / description

Removed value: -"Disciplines counted: {electrical, plumbing}"

removedOutput schema / properties / score / description
```
Removed value: -"Habitability score 0-100"
```

removedOutput schema / properties / score_basis / description

Removed value: -"What the score is: habitability_heuristic"

removedOutput schema / properties / scores / description

Removed value: -"Score by discipline: {architecture, electrical, plumbing}"

removedOutput schema / properties / sources / description

Removed value: -"Standards cited, by code: [title, tier, url]"

First observedv0.1.0Sep 24, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint=false, and the description adds genuine context beyond them: 'It advises and never blocks', the meaning of `weight` (score gain if a finding is removed), how `fix` produces `move`/`update` arguments to apply and re-review, and that `accept` marks a finding as-drawn. It does not discuss rate limits or auth, but for a read-only advisory tool the behavioral picture is substantially complete.

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

Conciseness3/5

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

Purpose is front-loaded effectively, but the second half becomes a dense inline dump of the return object's shape and field semantics that largely duplicates the existing output schema. Fully packed with information, yet the run-on clauses make it harder to parse than it needs to be.

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 the description need not explain return values, yet the tool is complex (8 params, scoring model, tiers, fixes) and the description supplies the domain context an agent needs: what is scored, what 'advises and never blocks' means, and where to learn the scoring rules. Minor over-explanation of outputs is the only shortfall.

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 description coverage is 100%, so the baseline is 3. The description goes further by explaining that people and city supplied here weigh this call only (unlike `edit_home`), and by interpreting output fields such as `weight`, `fix`, `tier`, and `accept` — meaning that is not carried by the input schema's parameter descriptions.

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?

Names a specific verb and resource — an ergonomics/habitability review of a home — and enumerates the concrete check areas (bed clearance, kitchen work triangle, wheelchair turning, etc.), so an agent knows exactly what it produces. It does not explicitly differentiate itself from siblings like `layout`, `electrical`, or `plumbing`, though the mention of `rules` topic=ergonomics partially routes the reader.

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?

Guidance is implied rather than stated: the contrast with `edit_home` clarifies parameter persistence ('People and city given here weigh this call only'), which helps an agent choose between a one-off review and a project-level update. There is no explicit when-not-to-use or a named alternative for the review itself among the many sibling review/edit tools.

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