measure-mcp

room_list_objects

List every furniture and appliance found in a room scan, with category, width x depth x height, footprint, and distance to the nearest wall.

Instructions

List furniture and appliances found in the scan with category, size (width x depth x height), footprint, height off the floor and nearest wall.

RoomPlan scans carry Apple categories (sofa, table, bed, storage, refrigerator, ...); raw point clouds give unknown. Filter by category (case-insensitive). Long listings are capped (detail="full" for all). load_options as in room_summary.

Input Schema

TableJSON Schema

Name	Required	Default
`path`	Yes
`units`	No	both
`detail`	No	summary
`category`	No
`load_options`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description still carries useful behavior beyond the schema: category provenance (Apple categories on RoomPlan scans vs 'unknown' on raw point clouds), case-insensitive filtering, and the important capping rule with detail="full" escalating to a complete list. It omits any statement of read-only/side-effect profile, but 'List' implies it.

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?

Purpose is front-loaded in the first sentence, with behavioral caveats following in compact sentences. Dense but each clause earns its place; slight clutter from the parenthetical category examples.

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?

An output schema exists, so return values need not be re-explained, and the description is sufficiently complete for a bounded listing tool. The main gap is units and path semantics, which remain undocumented given 0% schema coverage.

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 coverage is 0%, so the description must compensate. It adds real meaning for category (case-insensitive filter) and detail (full vs capped), and cross-references load_options to room_summary, but says nothing about units or path, leaving half the parameters to be inferred from enum values alone.

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

Purpose5/5

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

States a specific verb (List) and resource (furniture and appliances found in the scan) and enumerates the returned attributes. It is trivially distinguishable from siblings like room_list_walls and room_list_openings, which list different resources.

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 description notes filtering, capping, and that load_options works 'as in room_summary', but never states when to reach for this tool versus room_summary, room_load_scan, or measure_object. An agent can infer the context but gets no explicit when/when-not or alternative routing.

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