openreality-mcp

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

With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly. It discloses the five-phase execution flow, the single-active-run constraint, the 409 conflict with active_run_id, the attach_if_active escape hatch, bounded server-side LLM costs, the 202 response containing run_id, and the recommended follow-up call.

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?

Three dense sentences deliver the action, constraints, status code, cost behavior, and next step without filler. Key information is front-loaded: the operation and phases come first, followed by edge-case handling and follow-up.

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?

Despite lacking annotations and an output schema, the description is complete enough to invoke the tool correctly: it states what the run does, how to handle an existing active run, what response shape to expect (202 and run_id), cost implications, and the next monitoring call.

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 0%, so the description must compensate. It adds meaning for attach_if_active through the active-run constraint and for the run_id response. However, it never explicitly defines scan_id beyond the word 'scene' appearing in context, leaving the required parameter under-explained.

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 opens with a specific verb ('Start') and a precise resource ('five-phase scene annotation run'), listing the phases. It clearly distinguishes itself from siblings like agent_chat, agent_pilot, or scene_measure_distance by framing this as a structured annotation workflow on the server-side scene agent.

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?

It gives clear operational context: a run should be started, there is one active run per scene, and the caller should follow with agent_run_events wait_for_done. It also explains the attach_if_active option. However, it does not explicitly state when not to use this tool or name alternatives, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden, and it does a good job: it discloses that this is a bounded run, that the server agent may call scene tools mid-turn, that the tool waits by default, and that it returns the event transcript. It also adds the useful instruction that the agent's numbers carry units/scale_source and should be repeated honestly. It stops short of describing side effects or the wait=false behavior, but the disclosed behavior is substantially richer than typical.

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 three sentences with no filler. The first sentence frames the core action and scope, the second states the default behavior and return type, and the third gives a practical domain-specific instruction. Every sentence earns its place and the most important information is front-loaded.

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 tool with no annotations and no output schema, the description covers the essential operational context: the bounded run, mid-turn tool calling, waiting behavior, and returned event transcript. The main gaps are edge cases like wait=false behavior, polling semantics, and possible side effects from the agent's mid-turn tool calls, but these are secondary to the core use case and partly inferable from the schema.

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 only 17%, so the description must compensate. It does partially: 'By default waits for the run to finish' explains the wait parameter's default behavior, and 'returns the event transcript' clarifies the output tied to the run. However, it does not explicitly explain poll_s, timeout_s, scan_id, or message, although their names and schema constraints make much of that inferable. The description adds some value but does not fully fill the low-coverage gap.

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 a specific verb ('chat'), a specific resource ('the scene agent'), and a precise scope: one chat turn, its own bounded run, and a return value of the event transcript. It also distinguishes this tool from siblings like agent_replay or agent_runs by explaining that the server agent may call scene tools mid-turn. This is unambiguous and not a tautology.

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 implies when to use the tool: when you want one interactive chat turn with the scene agent and want the resulting transcript. However, it does not explicitly name alternatives or state when not to use it, such as when you need to replay an existing run or inspect run events. The usage context is clear but the exclusionary guidance is missing.

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

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

With no annotations, the description must disclose behavior itself, and it does: the call is asynchronous, returns a 202 with a run_id, and requires polling agent_run_events. It does not address side effects, authorization, or failure modes, but the most important behavioral trait is communicated.

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 compact and front-loaded with the core instruction. The trailing '202 {run_id}; poll agent_run_events' is telegraphic but conveys necessary follow-up behavior efficiently. It is shorter than ideal but each part serves a purpose.

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?

The description is adequate for understanding the async flow and the pilot agent's capabilities, but it omits the meaning of scan_id and does not describe the response format beyond the 202 status. Given the low schema coverage and no output schema, this leaves noticeable gaps.

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 0%, so the description must compensate. It explains that 'instruction' is a free-text instruction, but it does not explain 'scan_id' at all, despite it being a required field. This leaves the agent guessing about a key input.

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 action: give the pilot agent a free-text instruction for navigate/inspect flows, and it lists the tools the agent can use. This differentiates it from siblings like agent_run_events or agent_chat by focusing on launching the pilot agent rather than querying or chatting.

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 gives concrete usage context: use for navigation/inspection instructions and expect a 202 run_id, then poll agent_run_events. It does not explicitly state when not to use it or mention alternatives like agent_chat, so it falls slightly short of a full 5.

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

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

With no annotations provided, the description carries the full burden of behavior disclosure. It honesty states that replay is $0, does not spend LLM calls, replays the persisted event log, and produces a new replay-badged run. This is useful context beyond the bare schema, though it does not cover effects such as run creation visibility or whether the original run is modified.

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 with no filler: the first states the core behavior and formatting traits, the second gives the practical use case. Every sentence earns its place.

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?

While no output schema exists and the description clarifies the high-level purpose, an agent cannot correctly invoke the tool without understanding scan_id and speed. No annotations or schema descriptions fill those gaps, so the definition is incomplete for confident tool selection and use.

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 0%, so the description must compensate, but it does not explain scan_id or speed at all. It only implies that source_run_id refers to the earlier recorded run, leaving two of three parameters sematically opaque.

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 names a specific verb ('re-serve') and resource (a recorded run's persisted event log) and clearly states the result: a new replay-badged, $0 run. This distinguishes agent_replay from agent_run_events and agent_runs, which list or stream existing run data rather than creating a new replayed run.

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?

It explicitly says to use this when reviewing what an earlier run found without spending LLM calls, which gives a clear use case. It does not name alternative siblings or state when not to use it, so it falls short of fully explicit when-not guidance.

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

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

Beyond the readOnlyHint annotation, the description discloses real behavioral detail: it uses a cursor, and with wait_for_done it polls at ~1 Hz until the run finishes. This gives the agent meaningful expectations about side effects and timing. It does not describe output format, but the annotations already cover the safety profile.

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, no redundant words. The purpose is front-loaded, and the second sentence adds useful behavioral context. Every clause contributes to selecting and invoking the tool.

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 tool with 6 parameters, no output schema, and no param-level descriptions, this description is too thin. It omits required scan_id meaning, timeout_s behavior, and return/pagination details. An agent would need additional inference to call this tool confidently in all modes.

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 0%, so the description must compensate. It adds meaning for 'after' via the cursor endpoint and for wait_for_done/poll_s via the polling behavior, but it says nothing about the required scan_id, timeout_s, or the exact semantics of poll_s beyond the default cadence. This leaves a substantial portion of the input schema unexplained.

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 states a specific verb ('Read') and resource ('a run's event log'), and includes the endpoint. This clearly distinguishes it from sibling tools like agent_runs, which list runs rather than reading their event logs. Even without naming a sibling, the purpose is unambiguous.

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 usage is implied by the description: use this to read run events, with wait_for_done for polling. However, it does not explicitly explain when to choose this over alternatives or when not to use it. The description provides clear context but no exclusions or alternative routing.

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

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

Annotations already declare readOnlyHint=true and there is no contradiction. The description adds useful behavioral detail beyond the annotation: newest-first ordering, live-run indication, return fields, and the no-cost replay path. It does not discuss pagination or the meaning of 'live,' but this is reasonable for a read-only list tool.

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 with no filler. The core result (scene run index, ordering, live status, and return fields) is front-loaded, and the replay pointer is a useful, compact add-on.

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 one-parameter read-only listing tool with no output schema, the description is mostly complete: it names the fields returned and the ordering. The main gap is that scan_id's exact role is only implied, but this does not seriously impair an agent's ability to use the tool correctly.

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 0%, and the description does not explicitly say that scan_id is the scene identifier or describe its format. However, the phrase 'The scene's run index' strongly implies the single required parameter identifies the scene, so the parameter's purpose is partially inferred rather than fully documented.

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?

Title names the verb and resource ('List agent runs'), and the description sharpens it: a scene-scoped run index ordered newest-first plus live-run info. The reference to agent_replay as the replay mechanism distinguishes this listing tool from that sibling.

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 clearly implies 'use this to get the run list for a scene' and explicitly points to agent_replay for replaying persisted runs, giving an alternative. It does not explicitly exclude other run-related tools like agent_run_events, but the listing purpose is clear enough.

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

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

The readOnlyHint already estabishes safety; the description adds useful behavioral detail: bytes are never returned into context, only a path is returned, and the default target path pattern is disclosed. It does not discuss overwrite/error behavior, but that is minor for a read-only download.

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 compact sentences front-load the action and resource, then the side-effect and default path. Every element earns its place and the parenthetical examples aid matching without bloat.

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?

There is no output schema, so the description correctly supplies the returned path and default behavior. It could specify failure modes or overwrite semantics, but for a simple read-only download with two required parameters the definition is nearly complete.

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 schema documents derived_key and out_path, while the description's default-target template gives scan_id and derived_key relational meaning plus artifact examples. It does not restate out_path, but that parameter is already self-describing.

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?

States a specific action ('download ... to a local file and return the path') on a specific resource ('derived/... artifact') with concrete examples. This clearly separates it from scene/workspace tools and from the specialized artifact_etch_splat/cloud siblings by establishing it as the local-file artifact fetcher.

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?

Gives clear context: use when artifact bytes should be written to disk rather than brought into context, with a default output location. It does not explicitly name exclusions or the specialized siblings, so it stops short of a 5.

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

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

The readOnlyHint annotation already signals no server-side mutation. The description adds that the tool writes a file locally and returns a path, which is useful. However, it does not disclose overwrite behavior, directory requirements, or what happens when out_path is omitted.

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?

A single, well-structured sentence that says exactly what the tool does and returns. Every word earns its place, and the key action is front-loaded.

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 read-only download tool, the description gives the essential action and return value. But because there is no output schema and no parameter documentation, the missing details about out_path behavior and sibling differentiation leave noticeable gaps for an agent deciding how to invoke it.

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 0%, so the description carries full responsibility for parameter meaning. It never mentions scan_id or out_path explicitly; 'scene's cloud.ply' and 'local file' hint at them, but the optionality and expected format of out_path are left unclear.

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 states a clear verb ('Download'), a specific resource ('scene's cloud.ply'), and the result ('to a local file and return the path'). It distinguishes this tool from splat or generic artifact fetchers by naming the point cloud file, but it does not explicitly compare against sibling tools like artifact_fetch or artifact_fetch_splat.

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?

No guidance is given about when to prefer this tool over artifact_fetch or artifact_fetch_splat. The description implies the use case by describing the operation, but it provides no context, conditions, or alternatives.

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

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

Annotations already provide readOnlyHint=true, and the description adds client-side behavior: it downloads the original file to disk and returns the path. It does not imply server-side mutation or hidden side effects, so it aligns with the annotation while adding context beyond it.

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 short sentences, with the core action first and the alternative guidance second. There is no filler, repetition, or unnecessary detail.

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 download tool with a readOnlyHint annotation, the description covers the core behavior, the returned path, and when to route to LOD alternatives instead. The only notable gap is explicit parameter explanation, which is already accounted for in the parameter semantics score.

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 0%, and the description never explicitly maps scan_id or out_path to their roles. While 'to a local file' and 'return the path' hint at out_path, the optionality/default behavior of out_path and the exact meaning of scan_id are left to inference, which is insufficient at this coverage level.

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 action ('Download') and resource ('the scene's original splat.ply') and specifies the output ('to a local file and return the path'). It also differentiates itself from render-sized variants and names the LOD/artifact_fetch alternative, so distinguishing from siblings is straightforward.

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 explicitly tells the agent when not to use this tool: 'For a render-sized variant prefer the LOD levels (scene_lod → artifact_fetch of a level key).' This is direct routing guidance to an alternative, leaving no ambiguity about which tool to select.

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

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

Beyond the readOnlyHint annotation, the description discloses that the tool performs no build and no writes, and reveals format-specific constraints: isaac_usd is metric-gated and needs an anchor. This gives the agent concrete behavioral expectations that are not visible in the schema alone.

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 compact, front-loaded with the tool's purpose, and packs essential constraints (no writes, format list, metric gating) into three sentences without redundancy or filler.

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 dry-run manifest tool, the description covers the core scope: what is returned, the no-write guarantee, supported formats, and gating. It is slightly incomplete in not specifying how the anchor is supplied or clarifying the relationship between source and the isaac_usd requirement, but overall an agent can call this tool correctly in most cases.

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 only 33%, so the description must compensate. It adds meaningful format-level semantics by enumerating the three export formats and flagging that isaac_usd requires an anchor. However, it does not explicitly connect the 'anchor' to the source parameter or explain scan_id, leaving some ambiguity.

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 states exactly what the tool does: it returns a dry-run manifest of what an export WOULD contain, listing file tree, sizes, component status, and zip-route viability. It clearly distinguishes itself from actual export tools by saying 'No build, no writes' and naming the endpoint GET /demo/export/manifest.

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 clearly implies this is a preview/read-only tool and explicitly says there is no build or write, which tells an agent this is not the tool for performing an export. It does not explicitly name export_prepare as the alternative, but the dry-run framing and endpoint make the intended use clear.

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

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

With no annotations, the description carries the behavioral burden and does it well: it discloses the POST endpoint, 202 response with job_id, 409 conflict when a job is running, default wait behavior, polling, and returned download_path. This is substantial, though it omits details like response error shapes and whether repeated calls create new artifacts.

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 compact and front-loaded with the primary purpose. The HTTP status codes and workflow hint are dense but valuable, though the parameter gap makes the compactness slightly less effective.

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 6-parameter tool with no output schema and no annotations, the description does not fully cover the contract. It explains the overall flow and wait behavior but leaves parameter semantics unexplained and does not describe the full response structure beyond download_path.

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 0%, so the description must compensate. It explains wait=true and its polling behavior, but gives no meaning for scan_id, format, source, poll_s, or timeout_s, leaving most parameters undocumented.

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 names a specific verb and resource ('Build the export zip'), identifies it as a background job, and gives the HTTP endpoint. It is clearly distinguishable from sibling tools like export_status and export_manifest, which handle inspection/downloading rather than preparation.

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?

It implies usage: call this to prepare an export, wait/poll, then fetch the artifact. However, it does not explicitly state when to prefer this over siblings or when not to use it, so the guidance is more implicit than explicit.

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

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

The description explicitly discloses the always-200 response behavior, the exact status enum values (ready|running|error|none), and that a 'ready' status carries the artifact and download_path. This is valuable because no output schema is provided. It also reinforces the readOnlyHint annotation with no contradiction, making the tool's behavior predictable.

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 with no filler. The first sentence states the purpose and HTTP path, and the second gives the critical response contract. Every word adds value, and the structure is easy to parse quickly.

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 status endpoint with readOnlyHint and no output schema, the description covers the response shape well. However, it lacks workflow context: it does not explain that this tool is meant to poll preparation progress, what 'none' or 'error' implies for next steps, or how the source parameter affects results. These gaps leave an agent with partial, though not minimal, understanding.

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 0%, so the description must compensate for the schema's lack of parameter explanations. It identifies 'scene+format' which maps to scan_id and format, but it does not explain the optional 'source' parameter or provide any additional detail about parameter meanings, formats, or constraints beyond what the schema already gives.

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 this is a query for what export is prepared for a given scene and format, with an explicit HTTP path. It distinguishes itself from sibling tools like export_prepare and export_manifest by focusing on status and readiness. It could be more explicit about not creating or modifying exports, but the 'status' wording largely covers this.

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 does not state when to use this tool versus alternatives such as export_prepare, export_manifest, or artifact_fetch. It does not mention that it should be called after export_prepare or before artifact_fetch. The intended usage is only weakly implied by the word 'status', so an agent receives no concrete guidance on the workflow.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the operation is non-destructive, writes new derived artifacts and updates a pointer, and describes the async job behavior with 202 and job_id polling. This is strong transparency.

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?

Three sentences deliver the core purpose, side effects, and async response behavior without redundancy. The most important information is front-loaded and every sentence adds value.

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?

The description covers purpose, side effects, and the default async response, which is enough for typical invocation. It does not mention the behavior of the 'sync' materialize option or the exact return shape beyond job_id, so there is a small completeness gap given no output schema exists.

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 0%, so the description must add meaning beyond bare parameter names. It explains point_a and point_b as picked world points, distance_m as real distance in metres, and materialize:'job' behavior. However, scan_id is not mentioned and the sync variant is not explained, leaving some burden unaddressed.

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 states a specific operation: metric-anchor calibration with two world points and a real distance in metres. It clearly names the endpoint and explains the purpose (unlocking 'm' units), which distinguishes it from measurement siblings like scene_measure_distance.

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 conveys when to use the tool: it is the calibration step that unlocks metric units for measure, navigation, and export. It does not explicitly name alternatives or exclusions, but the context around units and siblings makes the intended usage clear.

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

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

With readOnlyHint=true already provided, the description adds useful behavioral context by defining the card's scope and compact nature. It discloses that this is intentionally a summary-level response and points elsewhere for deeper detail. It does not describe output format, pagination, or error behavior, but for a simple read-only card the added context is meaningful.

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 a single dense sentence plus a short routing instruction. Every phrase earns its place: it states the tool's role, lists the contents, and directs the agent to sibling tools for details. It is front-loaded with the key identification ('Tier-1 context card for a scene').

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 single-parameter, read-only summary tool with no output schema, the description adequately explains what the response contains by listing the major content categories. It also sets expectations about scope and directs the agent to other scene tools for deeper data. Nothing critical is missing for an agent to decide whether to call this 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?

The schema has one required parameter, scan_id, with 0% schema-level description coverage. The tool description minimally connects the parameter to the domain by saying 'for a scene,' but it does not explain the format, source, or expected semantics of scan_id. The parameter name is fairly self-explanatory, which keeps this adequate, but the description does not meaningfully compensate for the missing schema coverage.

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 identifies the tool as a Tier-1 context card for a scene and enumerates its contents (source, metric/anchor state, room + summary, closed-world object inventory, ground frame, workspace artifacts). It distinguishes itself from sibling detail tools by saying 'small by design' and 'pull details with the other scene tools,' though it does not name a specific sibling or use an explicit verb like 'retrieve.'

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 phrase 'Tier-1 context card' and 'small by design — pull details with the other scene tools' communicates when to use this tool: as a lightweight overview before going deeper. It gives clear context but does not explicitly enumerate alternatives or state when-not-to-use conditions beyond the general 'pull details' guidance.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered externally. The description's added value is the conditional-absence warning, which discloses that missing numbers are intentional and must not be hallucinated as heights — a genuinely useful behavioral trap that annotations cannot convey.

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, both load-bearing: the first states the operation, the second carries the crucial absence warning. The warning is front-loaded right after a short lead, and there is zero filler.

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 one-parameter, read-only tool with no output schema, the description covers the main failure mode an agent would otherwise hit: inventing heights when the frame is intentionally absent. The only omission is the return shape or units of the frame, which is minor given the readOnlyHint and the simplicity of the call.

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 0% — scan_id is only typed as a string with no description — and the description never mentions the parameter. The name is predictable among scan-scoped siblings, but the description does not compensate for the coverage gap, leaving the agent to guess the ID's format or provenance.

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?

States a specific verb ('Read') and resource ('recorded floor/ceiling frame'), and pins it to the GET /ground_frame endpoint. The reading semantics implicitly separate it from the related sibling scene_ground_frame_fit, whose name signals computation or fitting rather than retrieval. An agent can tell this tool apart from its closest alternative without opening either schema.

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?

Provides an explicit conditional — 'If vertical_axis_known is false... say so rather than guessing heights' — telling the agent how to behave when the frame lacks data. It does not explicitly name alternatives like scene_ground_frame_fit, but the recorded-vs-fit distinction and the endpoint make the intended use context reasonably clear.

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

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

Explains that the tool writes/persists to scene metrics and that dry_run=true computes without persisting, adding meaningful behavioral context beyond the destructiveHint annotation. It does not mention auth or rate limits, but the non-destructive profile is already covered by annotations.

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?

Single sentence, front-loaded with the action, then endpoint and dry_run behavior. Every part earns its place with no filler.

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 two-parameter tool with no output schema, the description covers the action, effect, persistence switch, and endpoint. Minor gaps are the exact return value and which scene metrics fields are updated, but the calling contract is largely complete.

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 0%, so the description must compensate. It clearly explains dry_run semantics ('computes without persisting'), but leaves scan_id entirely to the schema and name; scan_id is obvious from context but not documented.

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?

States a specific verb and resource: '(Re)fit the floor plane' and 'write the result onto the scene metrics (POST /ground_frame)'. This distinguishes from read-oriented siblings like scene_ground_frame, but does not explicitly name any alternative.

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?

Clearly implies the tool is for fitting the floor plane and mentions the dry_run mode for computing without persisting, but gives no explicit when-to-use guidance or exclusions relative to scene_ground_frame or scene_planes.

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

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

Annotations already declare readOnlyHint=true, and the description adds a GET method and 'status' semantics, reinforcing non-destructive behavior. It does not describe what statuses are returned, pagination, or behavior when no imported objects exist; with annotations covering safety, this is acceptable but not rich.

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?

One sentence with no filler, and the endpoint is a useful anchor. The status semantics are front-loaded and every word contributes meaning.

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?

Adequate for a simple one-param read-only status query, and the annotation covers side-effect safety. It is not fully complete because it omits expected output/status values and the relationship to scene_imported_objects_run, which would help an agent know when data is available.

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 single scan_id parameter has no schema description and the description never names it. The phrase 'for an imported splat' gives enough context to infer that scan_id selects the imported splat, but explicit parameter documentation is missing. Given only one parameter, this is minimally adequate.

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?

States that it reports the status of geometry-derived objects for an imported splat and identifies the GET endpoint. This is distinguishable from scene_imported_objects_run by status-vs-run, though it does not explicitly name that sibling. The phrase 'geometry-derived objects' is slightly vague but acceptable.

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?

No guidance is given on when to use this tool versus scene_imported_objects_run or scene_list_objects. The description implies a read-only status check but does not state prerequisites, exclusions, or the relationship to the run tool.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the mutating POST operation and adds a genuinely useful caveat that 'confidence 0.0 is honest, not a bug,' plus provenance semantics. However, it does not mention side effects, rerun behavior, or whether the operation is asynchronous.

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 with no filler. The core action is front-loaded, and the second sentence adds a valuable clarification about label provenance and confidence scores that would otherwise be surprising.

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 one-parameter tool, the description covers the action, the endpoint, and an important output semantic. However, with no output schema and no annotations, it still omits what the response looks like, whether the run is asynchronous, and what prerequisites must be satisfied before calling it.

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 input schema contains only scan_id with no description, and schema description coverage is 0%. The description never explains what scan_id should refer to or how to obtain it, so the parameter meaning is left entirely to its self-descriptive name. That prevents a score of 1 but does not compensate for the documentation gap.

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 opens with a specific action verb ('Cluster') and names the target resource ('an imported splat's geometry into facts.objects'), while also giving the exact endpoint. It is clear what the tool does, though it does not explicitly differentiate itself from the sibling scene_imported_objects.

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?

No guidance is given about when to use this tool versus alternatives such as scene_imported_objects or scene_synthetic_views. There are no prerequisites, no mention of checking job status afterward, and no when-not-to-use conditions; the context is only weakly implied by 'an imported splat's geometry'.

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

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

The readOnlyHint annotation already indicates a safe read, and the description adds non-annotation context: the operation is a single status read and these jobs 'honestly 404 across a broker restart.' This extra caveat meaningfully informs agent expectations beyond the structured annotation.

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 short sentences with no wasted words. The core operation is front-loaded, and the notable 404 caveat is appended cleanly without distracting from the main purpose.

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 two-parameter status tool, the description conveys the core operation and a key failure mode. However, with no output schema, it omits any sense of what statuses or return payload the caller should expect, and the parameter relationship remains underspecified.

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 0%, so the description carries the full burden for explaining scan_id and job_id. It gives no parameter-level detail and does not explain the relationship between scan_id, job_id, and the scene job. Only the phrase 'scene job' loosely anchors job_id.

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 single status read of a scene job and enumerates the relevant job types (SAM-3D completion, variants, view renders). It does not explicitly distinguish itself from siblings such as scene_job_wait, but the phrase 'One status read' strongly implies a non-blocking check.

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 implies when to use it ('one status read') and gives a useful operational caveat about 404s after broker restarts. However, it does not explicitly contrast with scene_job_wait, workspace_job_status, or other status-related siblings, nor does it state when not to use this tool.

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

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

Annotations already provide readOnlyHint=true, and the description adds meaningful behavioral context: the tool polls repeatedly and terminates on done/error/timeout. This signals that the call may be long-running, which is useful for agent planning. It does not contradict the read-only annotation.

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 a single front-loaded sentence with no wasted words. It communicates the action, resource, and termination conditions efficiently, though it could have included a bit more parameter context without becoming verbose.

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 polling tool with read-only annotations, the description is minimally viable: it says what it waits for and when it stops. However, there is no output schema and no mention of what the tool returns on done/error/timeout, nor how scan_id and job_id relate to launching a scene job.

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 input schema has 0% description coverage, so the description needed to explain what scan_id, job_id, poll_s, and timeout_s mean. It only indirectly references timeout as a terminal condition and never explains the identifiers or the poll interval. An agent must infer parameter semantics from names alone.

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 states a specific verb ('Poll'), a resource ('a broker-thread scene job'), and the terminal conditions ('until done/error/timeout'). This makes the core purpose clear and distinguishes it from one-shot status tools like scene_job_status, though it does not explicitly name sibling alternatives.

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 phrase 'Poll ... until done/error/timeout' implies the intended use: block or repeatedly check on a scene job while waiting for completion. However, there is no explicit guidance about when to prefer this over scene_job_status, workspace_job_wait, or other job-related tools.

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

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

The readOnlyHint annotation already establishes this as a safe read operation. The description adds that this is a real capture photo and suggests using it as photo evidence, which is useful domain context. However, it does not disclose response format, potential errors, or how the image data is returned.

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 short sentences with no filler. It front-loads the core action and endpoint, then immediately provides the essential parameter provenance and the evidence-use context.

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 two-parameter image fetch, the description covers the endpoint, where to obtain the blob_key, and the intended use as evidence. The main gap is the implicit role of scan_id, and since there is no output schema, slightly more detail about the returned image could improve completeness, but the description is largely 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 schema provides no descriptions for the parameters, so the description must compensate. It meaningfully explains that blob_key comes from scene detail keyframes[] refs, which is critical for invocation. However, scan_id is left completely unannotated and its relationship to the endpoint is not clarified.

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 fetches a single capture keyframe as an image, names the endpoint, and identifies the blob_key as the target resource. It distinguishes real capture photos from synthetic views by explicitly saying 'Real capture photos,' which differentiates it from sibling tools like scene_synthetic_view_image.

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 gives a clear precondition: blob_key comes from the scene detail keyframes[] refs. It also implies usage context by noting these are real capture photos to cite as evidence, but it does not explicitly name alternatives or state when not to use the tool.

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

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

Annotations already provide readOnlyHint=true, so the safety profile is known. The description adds useful behavioral context beyond that: data originates from the persisted facts.objects record, the result is a closed-world inventory, and it lists the included fields. It does not explain include_dismissed behavior, but that is a parameter-level detail rather than a core behavioral gap.

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 terse sentences with the most important constraint front-loaded. Every clause adds meaningful information, and there is no repetition of the title or schema details.

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 read-only listing tool with no output schema, the core source and closed-world scope are present, and the returned field names give helpful output context. However, the optional include_dismissed parameter is never described, and since the schema offers no descriptions either, an agent cannot fully understand how to use that flag. The definition is sufficient for a basic call but leaves a real semantic gap.

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?

With schema description coverage at 0%, the description needed to compensate for the schema's bare parameter names, but it does not explain include_dismissed or its effect. The listed items are output fields, not input parameters, and scan_id is only inferable by name. This leaves the optional parameter underspecified for an agent deciding whether to set it.

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?

Clearly identifies the action (list) and resource (scene objects), and sharpens the scope by naming the persisted source (facts.objects) and the inventory nature. The closed-world warning distinguishes it from tools that might return inferred or imported objects.

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 'closed-world' and 'ONLY objects that exist' phrasing implies this is the authoritative object inventory to consult, but the description does not explicitly say when to choose it over sibling tools like scene_imported_objects or scene_planes. No exclusions or alternative-routing guidance are provided, so usage guidance is mostly implicit.

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

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

The readOnlyHint annotation already establishes that this is a read-only operation, and the description adds useful behavioral detail: it always returns HTTP 200 and exposes a `status` field with enumerated values. This goes beyond the annotation and gives agents concrete expectations about the response.

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 extremely concise: two short sentences that front-load the purpose, include the endpoint, and enumerate the response values. Every word earns its place and there is no redundant 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 read-only status tool with no output schema, the description covers the essential return value and its possible states. However, it omits any explanation of the `scan_id` parameter and does not clarify what each status value implies, leaving a small but real gap in agent guidance.

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 0%, so the description must compensate for the undocumented `scan_id` parameter, but it never mentions or explains it. While `scan_id` is somewhat self-explanatory from its name, the description adds no parameter-level meaning, leaving the agent to infer the required input.

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 identifies the tool as returning level-of-detail index status for the scene splat, names the endpoint (GET /lod), and specifies the response field `status` with its possible values. This distinguishes it from a build tool like scene_lod_build by focusing on status retrieval.

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 implies this is for checking LOD status, but it never explicitly states when to use it versus alternatives such as scene_lod_build. There is no direct guidance on when to poll, what states to act on, or that building LOD is a separate operation.

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

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

There are no annotations, so the description carries the full burden, and it does well by disclosing the 202 {job_id} success response and the 409 lod_job_active concurrency failure. It could add side-effect or permission context, but the async spawn behavior and conflict condition are clearly surfaced.

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?

One dense sentence conveys the endpoint, success payload, error condition, and next step with no filler. The most important action and response are front-loaded.

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 one-parameter async job spawner with no output schema, the description covers the essential interaction: request shape, success response, conflict case, and polling instruction. The main gap is the undocumented scan_id parameter, which is simple enough that overall completeness remains high.

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 only parameter, scan_id, has 0% schema description coverage and the tool description never mentions it. Though the name is self-explanatory, the description does not compensate for the lack of schema documentation by clarifying what scan_id refers to or how it relates to the LOD job.

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 uses a specific verb, 'Spawn', and names the resource ('the LOD decimation job') plus the endpoint POST /lod, which clearly distinguishes the action from generic scene inspection tools. It does not explicitly compare itself to siblings like scene_lod, so the differentiation is implied rather than stated.

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?

It gives a clear workflow context: call this to launch the async job and then poll with workspace_job_wait. It does not state explicit when-not-to-use conditions or alternatives, but the 409 behavior implicitly warns against spawning while another job is active.

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

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

Annotations already provide readOnlyHint=true, so the description need not re-disclose safety. The description adds useful behavioral detail: it returns degrees and operates on WORL-frame coordinates. Beyond that, it does not describe side effects, errors, or edge cases, but those are not critical given the read-only hint.

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?

One tightly packed sentence with no wasted words. The critical semantic information is front-loaded and the endpoint/kind/units are efficiently included.

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 two-parameter, read-only measurement tool with no output schema, this description is complete: it explains the input frame, point ordering, the specific angle definition, the endpoint/kind, and the return units. An agent has enough information to call the tool correctly without additional context.

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 input schema gives zero property descriptions, so the description must carry the semantic load. It meaningfully explains points_world: three worl-frame points, with the second point as the angle vertex. That is essential to using the tool correctly. scan_id is left implicit, but its meaning is standard for scene tools and inferable from the parameter name.

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 names the exact operation (measure an angle), the resource and semantics (three WORL-frame points), and how the angle is defined (vertex = second point). It also differentiates from the sibling scene_measure_distance by specifying kind=angle and returning degrees.

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 context is clear: an agent should invoke this when it needs the angle formed by three world-frame points, with the vertex at the second point. It does not explicitly name alternatives or give when-not-to-use guidance, but the angle/distance split with sibling scene_measure_distance is obvious from the description.

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

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

Beyond the readOnlyHint annotation, the description discloses important behavioral context: units are 'm' only when a metric anchor exists, otherwise 'relative', and the agent must always report units and scale_source and never call relative units metres. This is substantive operational guidance.

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 three sentences with no filler: operation, unit behavior, and reporting instruction. Critical information is front-loaded and every sentence earns its place.

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 measurement tool it covers the main hazards around metric vs relative units and reporting requirements. However, with no output schema, scale_source is left undefined and the response shape is not described, so an agent still has some ambiguity about the full return value.

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?

With 0% schema description coverage, the description needs to compensate for parameter meaning. It adds the key clarification that point_a and point_b are world-frame points, but it does not explain scan_id, coordinate ordering, or how points relate to the scan. The compensation is partial.

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 states a specific operation — measuring distance between two WORLD-frame points — and names the endpoint (POST /measure). This clearly differentiates it from the sibling scene_measure_angle by the core concept of distance.

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 phrase 'Distance between two WORLD-frame points' implies the main use case, but the description never explicitly says when to prefer this tool over alternatives like scene_measure_angle, nor does it provide when-not-to-use conditions. Usage is inferred rather than stated.

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

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

With zero annotations, the description carries the full disclosure burden and does it well: it reveals the call is asynchronous (POST → 202 {job_id}), prescribes polling via scene_job_wait, and — most valuably — warns that 'Output is GENERATED geometry' with an honesty envelope in the artifact meta.json, preventing an agent from presenting synthetic mesh as scan truth. Error cases (e.g., uid that is not a segmented object) are not covered, but every non-obvious behavioral trait an agent needs is disclosed.

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?

Roughly 40 words, front-loaded with the purpose and then the HTTP contract, follow-up, and output nature in order of use. Every clause carries information; the only weak spot is the cryptic 'broker-thread lane' fragment, which adds jargon without clear value to an agent.

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 tool with no annotations and no output schema, it covers the full lifecycle: invocation (POST /objects/<uid>/complete), async handshake (202 job_id), polling (scene_job_wait), and output handling (GENERATED geometry + honesty envelope in artifact meta.json). Gaps: it never names where scan_id/uid come from or which sibling retrieves the produced artifact (artifact_fetch), leaving that inference to the agent. Given the workflow indirection, that is a meaningful but small gap.

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 schema has 0% description coverage, so the description must compensate. It partially does: the endpoint '/objects/<uid>/complete' ties uid to the segmented-object identifier, and 'segmented object' gives both parameters purpose. However, scan_id is never explained — no guidance on how to obtain it or what relationship it must have with uid. That is marginal but real interpretive value.

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?

States a specific verb and resource: 'SAM-3D-Objects mesh completion for a segmented object,' which distinguishes it from sibling tools like scene_segment or scene_object_variants. The concrete endpoint '/objects/<uid>/complete' and the 202 response further pin down exactly what the tool does.

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 routes the follow-up: 'Poll with scene_job_wait,' naming the sibling tool to call next. The phrase 'for a segmented object' implies the prerequisite workflow (segment first, then complete), and the async lane detail signals this is a job-style call. It does not explicitly name when-not-to-use alternatives, but the conditional workflow is clear.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the asynchronous nature via '202 {job_id}' and mentions generated assets, but it omits side effects, job lifecycle, authentication requirements, failure behavior, and what 'GENERATED assets' concretely means. These are material gaps for a mutation-style generation tool.

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 notably short and front-loaded with the endpoint and core purpose. The 'GENERATED assets.' fragment is vague and the 'see server docs' is a weak pointer, but overall the description wastes little space and is easy to scan.

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 tool with no annotations, no output schema, and only 33% parameter schema coverage, the description leaves important gaps: what scan_id means, how to poll or consume the returned job_id, what generated assets look like, and what body fields are allowed. The endpoint and 202 hint are useful but not sufficient for an agent to invoke this reliably.

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 only 33%, with uid and scan_id having no descriptions. The description clarifies that uid is used in the URL and that body fields pass through, but it never explains scan_id, the relationship between scan_id and uid, or what body fields are expected. It fails to compensate for two undocumented required parameters.

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 identifies the operation: TRELLIS-based variant generation for a completed object, including the exact endpoint POST /objects/<uid>/variants. It distinguishes the tool from scene_object_complete by noting the object must already be completed, though it does not explicitly name sibling alternatives.

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 phrase 'for a completed object' implies the tool should be used after object completion, and the endpoint/202 response suggests an asynchronous job. However, there is no explicit guidance on when to prefer this over related tools like scene_object_complete or scene_synthetic_views, and no exclusions or alternatives are named.

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

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

The readOnlyHint annotation already covers safety, and the description adds useful behavioral details: results are cached per-scene and the endpoint is POST /planes. It also implies that force recomputation is possible, which aligns with the force parameter. No contradiction with annotations.

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 compact and front-loaded, stating the core result in the first phrase, then adding endpoint/caching behavior and use cases. Every sentence provides useful information with no redundancy.

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 read-only, cached retrieval tool, the description gives enough context about output type, purpose, and caching behavior. The absence of an output schema is partly mitigated by 'plane candidates,' though a bit more detail about return shape would make it fully complete.

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 only 33%, with only 'force' documented. The description says 'cached per-scene,' which hints at scan_id, but it does not explain scan_id's role or the meaning of max_walls. The description does not compensate for the schema's missing parameter documentation.

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 title and description clearly identify a specific resource: floor/wall plane candidates derived from scene geometry. This distinguishes it from siblings like scene_list_objects, scene_ground_frame, and scene_measure_distance without needing to inspect their schemas.

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 names use cases ('restyle scoping and understanding room structure') but does not explicitly say when to prefer this tool over related scene-analysis tools or when not to use it. The usage context is implied rather than directly contrasted with alternatives.

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

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

The description transparently discloses failure codes, provenance requirements, and artifact behavior, but these disclosures contradict the readOnlyHint=true annotation: the tool is labeled read-only while also causing the camera flythrough to be left on disk and returning a full-trajectory artifact key. Per the rubric, an annotation contradiction caps this dimension at 1.

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?

Every clause earns its place: purpose, exclusivity constraint, failure modes, provenance obligation, and artifact retrieval. The core action is front-loaded and the rest is dense but not redundant.

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 no output schema and eight parameters, the description covers the main call shape, failures, provenance, and artifact key. It is still incomplete on the meaning of start, clearance, and up_override, so an agent could mis-specify those inputs.

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?

With only 25% schema description coverage, the description carries a lot of parameter meaning: it explains object_uid/point_world exclusivity, waypoint sampling, and artifact retrieval. However, start, clearance, and up_override remain semantically unexplained, so the compensation is only partial.

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 states a specific action (planning a path), the resource domain (scanned free space), and the two target forms (object uid or world point). This clearly differentiates it from the scene measurement, list, and image sibling tools, and it includes the endpoint for confirmation.

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?

It tells the agent when to use the tool and imposes the key constraint 'Provide exactly one of object_uid | point_world'. It also enumerates failure modes, but it does not explicitly name alternative sibling tools or state when not to use them.

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

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

With no annotations, the description carries the transparency burden. It honestly discloses that this is a raw, unvalidated passthrough and that the body must match the server contract. However, it does not mention response format, side effects, auth requirements, or error behavior, so the behavioral disclosure is incomplete.

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 compact and front-loaded with the operation and endpoint, and each sentence contributes information. The only minor redundancy is that 'Advanced' in the title is echoed by 'Advanced:' in the description.

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 tool with no output schema, no annotations, and a free-form body, the description is not self-sufficient. It points to external files/UI for the exact contract and omits response and error details, so an agent cannot reliably construct a valid request or understand the result from the definition alone.

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 schema only describes body as a raw request object, while the description adds that it must contain a click point and view selection, and points to external contract references. This adds meaningful guidance for constructing the body, even though scan_id receives no extra explanation.

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 identifies the action as SAM-3 click segmentation via POST /segment, and the 'raw passthrough' framing distinguishes it from higher-level scene tools. It names the exact operation and resource, so an agent can differentiate it from siblings like scene_object_complete or scene_object_variants.

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 advanced/raw passthrough language implies this should be used when the full server surface must be reached, but it does not explicitly state when not to use it or name an alternative wrapper. Usage context is implied rather than explicitly scoped against sibling tools.

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

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

With no annotations, the description carries the full burden, and it does so well: it discloses read-only behavior, single-scene scope, default TTL, and the critical limitation that share tokens cannot reach OS feature routes. It does not mention auth requirements or revcation, but the important behavioral traits are clearly stated.

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 with no fluff. The primary purpose and scope are front-loaded, the endpoint and default TTL are compactly included, and the critical viewer-only constraint is stated emphatically. Every clause earns its place.

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 two-parameter tool with no output schema and no annotations, the description is largely complete: it explains the result (token + embed URL), the default expiration, and the access boundary. It could be stronger by naming exact response fields or auth prerequisites, but the core calling 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?

Schema description coverage is 0%, so the description must compensate. It adds value by revealing the default TTL (30 days) and implying that scan_id identifies the scene to share. However, it does not explain ttl_seconds unit or scan_id format, leaving partial but not complete param semantics.

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 action ('Mint'), the resource ('read-only, single-scene share token + embed URL'), and the endpoint (POST /share). It sharply differentiates this tool from siblings like scene_share_access by emphasizing the read-only, viewer-only nature.

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 provides clear context for when this tool is appropriate: creating a read-only, single-scene share link with a default TTL. It does not explicitly name alternatives or state when not to use it, but the intended use case is evident and the viewer-only restriction prevents misuse.

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

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

With no annotations, the description carries the full disclosure burden. It does well: it states owner-only access, read-only semantics, defines key computed fields (visits, returned, first/last seen), and explains the events flag behavior. It does not mention pagination or error cases, which prevents a perfect score.

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 dense but every sentence earns its place: owner restriction, endpoint, output fields with definitions, the L5 signal, and the events flag. Parenthetical definitions keep it structured and scannable.

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 read-only analytics tool with no output schema and no annotations, the description covers return fields, field definitions, owner restrictions, and the optional events behavior. It is nearly complete, but missing explicit scan_id semantics and default/error behavior leaves a small but real gap.

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 description explains the events parameter ('events:true appends the raw event list') and clarifies the access_id output concept. However, the required scan_id parameter is never explained, and the schema has zero property descriptions, so a critical parameter's semantics are left to inference.

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 is specific: it names the resource ('share-link access log'), the endpoint ('GET /share/access'), and the exact operation ('Owner-only read'). It clearly differentiates this analytics tool from siblings like scene_share by focusing on per-link usage behavior rather than sharing or scene measurement.

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?

It gives a concrete use case: this is the behavioural evidence for customer discovery, with the important L5=returned signal explicitly defined. It also tells the agent to match access_id to the person the link was sent to. It does not explicitly mention alternatives or exclusions, so it falls just short of a 5.

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

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

Annotations declare readOnlyHint=true, and the description adds valuable behavioral context beyond that: the result is a rendered PNG rather than a photograph, and the agent should explicitly say so when citing it. This is a useful disclosure about the nature and appropriate framing of the output.

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 a single, tightly written sentence. It front-loads the output type ('One synthetic view PNG') and includes the most important caveat ('not a photo') along with an actionable instruction for citation. There is no wasted text.

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 two-parameter read-only fetch, the description is mostly adequate: it names the output type and the render-versus-photo distinction. However, with no output schema and no parameter descriptions, an agent is left to infer how scan_id and view_id are used and where view_id comes from, so some guidance is missing.

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 0%, so the description carries the burden of explaining the parameters. It does not explain what scan_id or view_id mean, what format they take, or how to obtain a valid view_id. The parameter names are somewhat self-explanatory, but the description adds no semantic value for them.

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 title 'Fetch a synthetic view image' plus the description 'One synthetic view PNG' clearly identify the tool's resource and output. The phrase 'a RENDER of the splat, not a photo' also helps distinguish this from camera/keyframe images, though it does not explicitly name sibling tools.

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 implies the tool is for retrieving a single synthetic rendered view, and the 'not a photo' caveat helps set expectations. However, it does not explicitly state when to use this tool over alternatives like scene_keyframe_image or scene_synthetic_views, nor does it mention that view_id likely comes from scene_synthetic_views.

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

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

The description goes beyond the readOnlyHint annotation by clarifying that results are synthetic renders, not photographs, and that provenance must be carried when citing. This is actionable behavioral guidance for an agent consuming the output.

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 short sentences with no filler. The first fronts the core behavior and endpoint, and the second gives an essential caveat about provenance and photography. Every sentence earns its place.

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 one-parameter, read-only list operation with no output schema, the description provides enough: it defines what is returned, scopes it to the scene's splat, and warns about correct citation semantics. No critical calling information is missing.

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 only parameter, scan_id, has no schema-level description, and the tool description never mentions it explicitly. However, the phrase "the scene's own splat" implies the resource is scoped by scene, making the required parameter name reasonably self-explanatory despite the lack of explicit elaboration.

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 identifies the tool as listing renders of the scene's own splat that are registered as evidence, and explicitly distinguishes them from photographs. This matches the title and separates it from similar image-related siblings like scene_keyframe_image.

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?

It conveys the key context: use these as synthetic-view evidence, not as photographs, and always preserve the synthetic-view provenance when citing. It does not explicitly name alternative tools for when to use something else, but the context is clear enough for selection.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this by specifying a GET endpoint and a status read. It adds value by disclosing the response shape, including the status enum and optional fields like stage, scan_id, and error, which are not present in the annotations.

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 entire definition is one compact sentence that states the action, endpoint, and response format. There is no filler, and the most important information is front-loaded.

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 single-parameter, read-only status tool, this description is complete: it covers the endpoint, the status values, the optional fields, and the error case. No output schema exists, but the description provides the necessary return structure directly.

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 0% and the schema only says job_id is a required string. The description compensates by embedding job_id in the endpoint path (GET /api/workspace/jobs/<job_id>), clarifying that it is a path parameter and tying it to the job being polled.

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 uses a specific verb ('status read') and resource ('ingest/export job'), names the exact endpoint, and lists the response fields. This clearly distinguishes it from scene_job_status (scene jobs) and workspace_job_wait (waiting on a job).

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 clearly indicates this is for checking a single ingest/export job's status, which implies it should be used for polling rather than waiting. It does not explicitly name alternatives or state when not to use it, but the 'one status read' phrasing provides clear functional context.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds useful behavioral context beyond annotations: it polls, exits on done/error/timeout, and returns the final status plus a stage trail. This gives the agent a good sense of observable behavior without contradicting the read-only hint.

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 a single sentence that front-loads the action and resource, then states the termination conditions and the return value. Every clause earns its place, with no repetition of schema details or annotation information.

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 3 parameters, no output schema, and a read-only annotation, the description covers the core behavior and return value. The main gap is the lack of explicit notes on timeout/error handling, but the mention of 'timeout passes' and 'done or errored' is sufficient for correct invocation in most cases.

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 0%, so the description must compensate. It partially does by explaining the polling behavior and timeout condition, which maps to timeout_s and poll_s by name. However, it does not explicitly define the units or semantics of poll_s, nor clarify that job_id identifies the target job, so the compensation is incomplete.

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 states a specific verb ('Poll') and resource ('an ingest/export job') and clearly defines the terminal conditions: 'done or errored (or the timeout passes)'. This differentiates it from the sibling workspace_job_status, which is a status check rather than a blocking wait.

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 clearly conveys the intended use case: wait for a job to reach a terminal state. It does not explicitly name alternatives like workspace_job_status or scene_job_wait, but the polling/blocking behavior makes the context clear. No exclusions or when-not-to-use guidance is provided.

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

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: results are sorted newest first, it reports which scan_ids are new since the last list, and the account is positioned as a sync layer. This gives the agent useful expectations that are not present in the schema or annotations.

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 three compact sentences: main purpose, key behavioral detail, and next-step guidance. Every sentence adds value and the most important information comes first.

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 read-only listing tool with one optional, fully documented parameter and no output schema, the description covers the essential behavior and the sync context. It does not describe the exact shape of the returned scene list, but it gives enough for an agent to invoke correctly and follow up with scene_card.

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%, and the parameter since_epoch_s is already clearly described in the schema as 'Only return scenes created at/after this epoch-seconds timestamp'. The tool description does not add extra meaning about the parameter, so the baseline of 3 is appropriate.

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?

States a specific verb ('List') and resource ('all persisted scenes in the signed-in Open Reality account'), with an ordering detail ('newest first'). This clearly differentiates it from scene-specific tools like scene_card or scene_list_objects.

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 explains when this tool is relevant: persisted scenes in the account, with the account acting as a sync layer for scans from phone or web. It also gives an explicit next step ('Use scene_card next for anything you want context on'), though it does not exhaustively contrast with every sibling.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses meaningful side effects: the recordings pipeline runs (recon → odometry-consistency score → QC gate), the scene persists with source='robot_recording', and a QC report is stored under derived/demo/recordings/. It also explains the async nature by returning {job_id, scan_id} and directing the caller to workspace_job_wait.

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?

Three dense sentences with no filler: the first states the action and constraint, the second describes the pipeline and persisted result, and the third gives the response shape and recommended next step. Every sentence earns its place.

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 single-parameter tool with no output schema, the description is complete: it explains the input format, what happens during the operation, what persists, where the QC report lives, what is returned, and how to follow up. No critical operational information is missing.

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 input schema already documents the path parameter well at 100% coverage. The tool description adds extra constraint information beyond the schema: the file must be a DimOS memory2 .db and at most 2 GB, which helps the agent validate input before calling.

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 names a specific verb and resource: 'Upload a robot recording (DimOS memory2 .db, ≤2 GB) into the account.' It also gives the exact file format and size limit, making it clearly distinct from sibling tools like workspace_upload_video and workspace_upload_splat.

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 intended use case is clear: upload a robot recording in DimOS memory2 .db format and then follow up with workspace_job_wait. It does not explicitly state 'use this instead of workspace_upload_video/splat,' but the file-type and pipeline context make the appropriate use obvious.

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

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

No annotations exist, so the description carries the full burden. It discloses size-dependent behavior, sync/async return shapes, error condition (422 not_a_gaussian_splat), and the resulting source tag, going well beyond the schema.

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?

Three dense sentences pack scope, size thresholds, return shapes, and error behavior without waste. Key action is front-loaded.

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 2-parameter upload tool with no output schema, the description fully covers return values, async polling, and failure modes. An agent could invoke and handle both success paths correctly.

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%, so baseline is 3. The description adds value by reinforcing that path must be local .ply/.spz and by warning about non-Gaussian PLY rejection, which the schema alone wouldn't convey.

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?

States a specific verb ('Import'), resource ('local .ply/.spz Gaussian splat'), and result ('as a scene'), with the source tag distinguishing it from other upload tools. Sibling names like workspace_upload_video make the differentiation clear.

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 clarifies the workflow for small vs large files and directs the agent to workspace_job_wait for polling large uploads. It doesn't explicitly state when not to use this tool versus alternatives, but the format and source tag make selection unambiguous.

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

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

With no annotations provided, the description carries the behavioral burden and does it well. It discloses that the upload starts an asynchronous reconstruction job, returns immediately with a 202, and that the scene only appears later. It also specifies file format and size constraints, which is useful for anticipating failures.

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 tight sentences with no fluff. The core action, constraints, immediate return value, and follow-up steps are all packed efficiently into a compact description that front-loads the most important information.

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 tool with no annotations and no output schema, the description is remarkably complete: it explains the input constraints, the immediate return payload, the next step (workspace_job_wait), and the eventual observable outcome (scene in workspace_list_scenes). An agent has enough context to invoke it correctly and know what happens afterward.

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%, so the baseline is 3. The description adds value by stating the acceptable video formats and the 1 GB limit for the path parameter, but does not go beyond the schema in explaining label or source semantics. Baseline is appropriate.

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 specific action: uploading a local video file into the account and starting a reconstruction job. It distinguishes this tool from its siblings like workspace_upload_recording and workspace_upload_splat by explicitly focusing on video files and reconstruction, including supported formats and size limits.

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 gives clear context on how to use the tool: upload a video, receive job_id and scan_id immediately, then follow with workspace_job_wait, and later check workspace_list_scenes. It does not explicitly mention when to use this tool over other upload variants, but the sequencing and expected workflow are clear.

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