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, and it discloses almost nothing beyond the action itself. It does not say whether firing a cue changes transport state, what happens on an out-of-range index, whether the operation is idempotent or destructive, or what authorization/context is required.

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 front-loaded sentence with no filler; the action and both scoping indices come first, and the parenthetical qualifier is placed where it is needed.

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 presence of an output schema removes any need to describe return values, so the main gaps are behavioral and routing-related: no guidance on obtaining indices and no delineation from the by-number sibling. For a two-parameter actuator this is minimally adequate but leaves real ambiguity.

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%, so the description must compensate for two undocumented parameters. It adds one genuinely useful fact, that indices are zero-based, but says nothing about how to obtain valid timeline or cue indices or how out-of-range values are handled.

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 gives a concrete verb (fire), resource (cue), and scope (a cue index on a timeline index), so the agent knows exactly what the call does. It only implicitly distinguishes itself from the sibling pixera_apply_cue_by_number via the word 'index', without stating the index-vs-number difference explicitly.

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?

There is no statement of when to use this tool rather than the near-identical pixera_apply_cue_by_number, nor any prerequisites (e.g., a loaded project, a transport state, or how to discover valid indices). The agent must infer usage entirely from the name.

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 are provided, so the description carries the full behavioral burden. 'Fire' implies a live mutation, but there is no disclosure of whether it interrupts the running cue, whether the cue number must already exist, what happens on an invalid number, or whether transport must be running.

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 front-loaded sentence with no waste. It is arguably too terse for a mutation tool, but nothing is padded or 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?

The tool is simple (two integer params) and an output schema exists, so return values need not be explained. However, with zero annotations and zero schema param coverage, the description is thin for a live-firing operation and leaves the agent guessing about side effects.

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 only partially compensates: it clarifies that cue_number is a cue's number (not a name or id) and that the timeline is identified by index. It does not clarify index origin, ordering, or valid ranges, so the two integer params remain largely 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?

States a specific verb and resource: 'Fire a cue by its cue number on a timeline by index.' The 'by its cue number' and 'by index' qualifiers distinguish it from the sibling pixera_apply_cue, though 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?

No when-to-use guidance, no mention of when this should be chosen over pixera_apply_cue or pixera_set_timeline_transport, and no prerequisites. The agent must infer the choice from the tool name alone.

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; it usefully discloses the coordinate system (world-space), the flat x,y,z encoding, and critically that the write targets whatever marker calibration is currently open with no screen handle. It omits whether existing marker positions are overwritten, whether the operation is reversible, and any error/ordering behavior.

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, front-loaded with the action and the API target. Slightly under-explained rather than verbose, which is the right failure mode, though the trailing 'no screen handle' note is confusing given the schema.

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?

Output schema exists, so return values need not be described. Still, for a 3-parameter mutation with 0% schema coverage, the missing marker_ids/positions correspondence rule and the unresolved screen_name parameter (the description says the API takes no screen handle, yet the schema offers one with a null default) leave a 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?

Schema coverage is 0%, so the description must compensate; it explains 'positions' as a flat x,y,z array, which is genuinely informative. However, 'marker_ids' semantics (e.g., that it is a parallel array whose length must match positions/3) and the role of 'screen_name' are left entirely unstated.

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 concrete verb+resource ('Push world-space markers') and names the underlying API (Pixera.Calibration.setMarkerPositions), which pins down exactly what operation occurs. It does not, however, distinguish itself from calibration siblings such as pixera_run_calibration or pixera_validate_marker_calibration.

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 when-to-use guidance, no prerequisites, and no routing to alternatives among the many calibration/marker siblings. The only implicit condition is that a marker calibration must already be open, but this is described as a constraint, not as usage 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?

With no annotations, the description carries the full burden and does so well: it discloses the validation gate against a pinned rev 481 method/param index (and that validate=false skips it), a destructive-call gate requiring allow_destructive=true with the destructive categories enumerated, an immutability constraint ('protected timelines can never be removed or renamed'), and the return envelope {ok, result | errors, stage}. These are exactly the behaviors an agent cannot infer from structured fields.

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: purpose plus example first, then the gating rules, then the return shape. The example is well chosen and front-loaded. The middle sentence packs several independent constraints into one long clause chain, which slightly reduces scannability but wastes no words.

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 mutation-capable catch-all tool with 0% schema coverage, the definition covers purpose, validation, destructive gating, immutability constraints, and the error/result envelope; the output schema handles return details. The remaining gap is routing: it does not point at pixera_describe, pixera_get_api_revision, or pixera_has_function for discovering and confirming valid methods, which matters given this tool's breadth.

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% across 4 params, so the description must compensate, and it does: method is demonstrated with a fully-qualified example, params is shown as the method's argument dict, validate is tied to the index check it toggles, and allow_destructive is tied to the destructive categories it unlocks. It stops short of explaining how to discover valid method signatures, but the four parameters are all given meaning.

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 ('Call any Pixera API method') and immediately grounds it with a concrete example method plus params object, so an agent knows this is the generic escape hatch to the Pixera API. It is distinguishable from the many typed siblings, but it never states the relationship to them (e.g. that pixera_set_screen_pose is a typed wrapper of this call), so differentiation is implicit 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 states preconditions for use ('getHasFunction must confirm the method', destructive calls need allow_destructive=true) but gives no guidance on when to reach for this generic call versus the dozens of specialized siblings such as pixera_set_screen_pose or pixera_save_project. Usage is implied by the naming conventions rather than spelled out.

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 are provided, so the description carries the full burden. It usefully discloses two validation behaviors — uniqueness enforcement and protected-prefix rejection — which is real value for a mutation tool. However, it omits auth/permission requirements, whether the operation is reversible, and what the output schema returns, leaving meaningful behavioral gaps.

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, front-loaded with the action and followed by the constraint. No filler or repetition. It is efficient, though slightly terse given the absence of annotations.

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 tool is simple (one required param) and the output schema covers return values, so the bar is moderate. The description covers the core action and its key failure mode, but with zero annotation coverage it should say more about permissions, reversibility, or naming rules for a create operation.

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%, so the description must compensate. It implies the single `name` parameter and, via the protected-prefix/uniqueness clause, communicates constraints on acceptable values that the schema does not. It stops short of describing the name format or naming rules, so 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 verb and resource ("Create and name a new timeline"), which cleanly differentiates it from the list/query siblings like pixera_list_timelines. It does not name an alternative, but the create operation is distinct enough that an agent can select it without ambiguity.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as pixera_list_timelines to check for existing names first. The only clause present is a failure condition ("Refuses existing names and protected prefixes"), which is behavioral rather than usage direction. An agent must infer the context of use.

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 does well: it discloses the offline/static nature, the API revision, and that results vary by query shape (full name -> signature + doc, prefix -> method list, substring -> matches). It does not explain the 'limit' cap or result-count behavior, leaving one 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?

Front-loaded with purpose and the no-connection fact, then the three query forms, then the routing instruction. Every sentence earns its place; the examples are compact and load-bearing.

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?

An output schema exists, so return values need no prose, and the description covers query semantics and the offline constraint well. The only material omission is the undocumented 'limit' parameter, which an agent would have to infer from the schema 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?

Schema coverage is 0%, so the description must compensate; it thoroughly explains the required 'query' param across three input modes and even documents the params.handle convention for class methods. The optional 'limit' parameter is never mentioned, so compensation is strong but 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?

States a specific verb and resource ('Look up Pixera API methods offline') with the data source identified (rev 481 API JSON). It clearly separates itself from the invocation sibling by ending with 'Use before pixera_call.'

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 agent: use this before pixera_call, and it clarifies that no connection is needed, which distinguishes it from the live-call siblings. It does not state when *not* to use it (e.g., to merely test existence use pixera_has_function), so it falls short of full when/when-not coverage.

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 are provided, so the description carries the full behavioral burden. It does disclose the output shape ('-> cause + fix') and implies a read-only diagnostic, which is useful, but it says nothing about whether it inspects live system state, requires an active connection, or has any side effects on the project.

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 sentence with zero waste, using an arrow to front-load the transformation from input to output. Every element 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 one-parameter tool with an output schema already describing return values, the description supplies the essential framing plus example inputs. The remaining gap is routing guidance against the overlapping validate_* siblings rather than any missing invocation detail.

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, and it partially does by giving example symptom strings, clarifying that this is free-text symptom input rather than an ID or enum. However, it does not specify the expected format, accepted vocabulary, or whether arbitrary phrasing is matched.

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 (diagnose) and resource (projection-mapping symptom), and the concrete examples 'visible seam' and 'black output' make the scope unambiguous. It is distinguishable from the recommend_* and set_* siblings, but it does not explicitly separate itself from the validate_* family (e.g. pixera_validate_softedge), which could plausibly address the same 'visible seam' symptom.

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?

Usage is implied by the examples — you call it when you observe a symptom like a seam or black output — but there is no explicit when-to-use statement, no guidance on when to reach for this versus the many validate_* tools, and no stated prerequisites (e.g. whether a project must be loaded first).

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, so the description carries the burden. It does usefully disclose what is written to disk (a service_<ip>/mapping_NNN.axp file plus original_output_structure.json), which tells the agent the output is a folder of files. It does not say whether existing files are overwritten, whether it requires a live connection, or whether it is read-only with respect to the console.

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, front-loaded with the action and resource, with the artifact naming appended as useful detail. Nothing is wasted.

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?

An output schema exists so return values need not be explained, and the destination artifacts are described. However, for a write-to-disk tool with no annotations and undocumented parameters, key operating details (overwrite behavior, live_system form, required connectivity) are 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 coverage is 0% for two parameters. The description only implies that 'path' is a destination folder ('to a folder'), and says nothing about what 'live_system' accepts (hostname/IP/target selector) or how it defaults.

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 (export) and resource (projector mappings: warp, soft edge, color correction) and names the output artifacts, so the operation is unambiguous. It does not explicitly contrast with pixera_import_mappings, but the direction is obvious from the verb.

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?

There is no statement of when to use this tool versus alternatives such as pixera_import_mappings, pixera_refresh_mapping, or pixera_save_project, and no prerequisites (e.g. connection to a live system) are given.

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 are provided, so the description carries the burden; 'find' and the returned identifiers imply a safe read-only lookup, which is real signal. However, it omits failure behavior (what happens if the path or name does not match), case/path-format expectations, and any permission requirements — gaps that matter for a 0-annotation 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?

A single front-loaded sentence with zero filler: the action, the lookup keys, and the return fields are all packed in without redundancy. Nothing could be removed without losing 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?

An output schema exists, so the listed return fields are largely redundant, and the description otherwise covers what the tool does. It is thin on routing versus pixera_list_resources and on failure behavior, which are the remaining things an agent needs to invoke it confidently.

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 does partially by clarifying that folder_name_path is a folder-name path (not a filesystem path) and resource_name is the resource's name. It still gives no format, separator, or matching-rule detail for either parameter.

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 ('Find one resource') plus the lookup keys ('by folder name path and name'), which distinguishes it from the sibling pixera_list_resources that returns many. It stops short of naming that sibling explicitly, so differentiation is inferred 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?

The phrase 'find one resource by folder name path and name' implies the correct usage context (a single lookup when the path and name are already known), but there is no explicit when-to-use, when-not-to-use, or pointer to pixera_list_resources for enumeration cases.

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 are provided, so the description carries the burden. It does disclose the key behavioral detail that the returned revision is encoded by parity: even means release and odd means beta. It does not mention error behavior or side effects, but for a zero-parameter getter this is reasonably transparent.

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 front-loaded sentence with no wasted wording. The most important information, the return value and its parity convention, is immediate.

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 tool is a simple zero-parameter getter, and an output schema exists. The description adds the one non-schema detail an agent needs: how to interpret even versus odd revision numbers. Nothing essential for correct invocation 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 tool takes zero parameters, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, a 4 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 and resource: 'Return the Pixera Native API revision.' The parity explanation further clarifies what the returned value means, making it distinguishable from generic siblings like pixera_describe or pixera_get_param.

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?

Usage is implied by the tool's purpose as a revision/version lookup, but the description does not explicitly say when to use this instead of siblings such as pixera_describe, pixera_ping, or pixera_has_function. No exclusions or preconditions are 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?

No annotations are supplied, so the description carries the full burden. It does disclose one genuinely useful behavioral trait beyond the schema: the return is a raw, unparsed JSON string from Pixera (Layer.getLayerJsonDescrip), which tells the agent to expect opaque JSON rather than a normalized object. It says nothing about read-only guarantees, permissions, or failure modes, so it is only partially sufficient.

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 front-loaded sentence with no filler; the scope ('for one layer') is placed immediately after the verb. The internal method name is mildly jargon-heavy but does convey that the payload is a raw Pixera structure.

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?

An output schema exists, so the description is not obligated to enumerate return fields, and the raw-JSON note is a reasonable pointer to it. However, with two required, undocumented parameters and no usage guidance, an agent still lacks enough to invoke this confidently without inspecting the schema and guessing at identifier formats.

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 both parameters (timeline, layer) are required with no descriptions. The description only implies that 'layer' identifies the target layer and never mentions the timeline parameter or the expected identifier format (name vs. index vs. UUID), so it fails to compensate for the 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 gives a concrete verb (Return) and resource (Layer.getLayerJsonDescrip for one layer), so an agent knows it fetches a layer's JSON descriptor rather than lists or mutates anything. It does not differentiate itself from nearby read-adjacent siblings like pixera_get_param, pixera_describe, or pixera_call, which is the only thing keeping it out of the top band.

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?

There is no statement of when to reach for this tool versus pixera_get_param, pixera_describe, or pixera_call, nor any prerequisite (e.g., an active project/timeline). The description is purely a statement of what the call returns, leaving selection entirely to inference.

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 burden, and 'Read' does disclose a safe, non-mutating operation. The path example adds useful behavioral context, but there is no mention of error behavior for invalid paths, case sensitivity, or lookup semantics.

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 front-loaded sentence with the key action first and the clarifying example immediately after. No waste, though it is terse enough to leave gaps.

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?

An output schema exists, so return values need not be explained. For a single-param read tool the description is adequate, but with no annotations and no error/behavior notes it is only minimally 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 coverage is 0% (only a bare 'Path' title), so the description must compensate, and it does by supplying a concrete dot-delimited example ('Timeline 1.Layer 1.Opacity'). That example conveys the hierarchical path format the schema omits, though it doesn't cover edge cases.

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 (parameter value) with scoping (by instance path), and the example path clarifies exactly what is addressed. It does not name a sibling to distinguish from, but the verb+resource combination is unambiguous against alternatives like get_layer_json or get_timeline_time.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as pixera_call or pixera_get_layer_json. The agent must infer usage entirely from the name and 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?

No annotations are provided, so the description carries the full burden. It implies a read via 'Get' and notes values are 'live' (not cached) with units, but says nothing about side effects, permissions, or connection requirements. For a tool with zero annotation coverage, this is thin behavioral disclosure.

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 tight sentence with the key information front-loaded and no wasted words. Well-sized for a simple read 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?

An output schema exists, so return formatting needn't be explained, and the description does convey the returned quantities and their units. The only real gap is the undocumented 'name' parameter, which is minor for a single-argument read 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 single required parameter 'name' has 0% schema description coverage and is not mentioned anywhere in the description. The description does not clarify that 'name' identifies the target projector, so it fails to 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?

States a specific verb (Get) and resource (projector's live position and rotation), plus units (m/deg) that clarify the return data. It is clear on its own but does not distinguish itself from siblings like pixera_list_projectors or pixera_set_screen_pose beyond the read vs. write implication.

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?

There is no guidance on when to use this tool versus alternatives (e.g., pixera_list_projectors or pixera_get_param), and no preconditions or context are given. The description is purely a one-line statement of purpose with no usage framing.

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 at all, the description carries the full burden, and it does add one useful behavioral detail: the value is in seconds. Beyond that it says nothing about behavior when the named timeline does not exist, whether transport must be running, or any permissions/error conditions for this read.

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 front-loaded sentence with zero filler; the unit detail is the only qualifier and it 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?

An output schema exists, so return-value documentation is unnecessary, and this is a simple one-parameter read. Still, the undefined 'name' parameter and absent usage/error context leave the definition only minimally adequate.

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 single parameter 'name' has no description anywhere. The description implies 'name' refers to a timeline, but never clarifies the identifier form (id vs. label) or matching rules, so it fails to compensate for the 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?

States a specific verb (Get) and a specific resource (a timeline's current playhead time), plus the unit (seconds). It is unambiguous on its own, though it does not explicitly contrast itself with siblings like pixera_set_timeline_transport or pixera_list_timelines.

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?

There is no when-to-use guidance, no mention of alternatives (e.g., transport or cue tools that also touch timeline position), and no prerequirements such as the timeline already being loaded. Usage can only be inferred from the name and verb.

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 are provided, so the description carries the full behavioral burden. 'Probe' implies a safe read-only query, but the description does not explicitly confirm non-mutation, side effects, authentication needs, or rate limits; it adds little beyond the name itself.

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 definition is a single, front-loaded sentence with no filler. It is efficient, though its sparseness reflects missing information rather than disciplined conciseness.

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 with no annotations and 0% schema description coverage, the description omits parameter semantics and usage context. The existence of an output schema means return values need not be explained, but the remaining gaps are significant.

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% for the single required 'name' parameter. The phrase 'supports an API function' hints that the parameter is an API function name, but the description gives no format, case-sensitivity, or naming-convention details to compensate for the empty schema description.

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 ('Probe') and resource ('whether the connected Pixera supports an API function'), so an agent can tell what the tool does without opening the schema. It does not, however, distinguish itself from adjacent siblings such as pixera_get_api_revision, pixera_describe, or pixera_call, which all touch API capability or invocation.

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?

There is no guidance on when to use this probe rather than pixera_get_api_revision, pixera_describe, or pixera_call. The description only states the tool's purpose and leaves the selection context entirely to inference from the sibling names.

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 does so well: it discloses the overwrite semantics of target outputs and the resulting requirement that allow_destructive=true be set, plus a hard capability limit. It stops short of saying whether the operation is atomic, what happens on partial failure, or whether a live system connection is needed.

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 tight sentences, front-loaded with the tool pairing, then the parameter mechanic with an inline example, then the destructive constraint. No sentence is 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?

Output schema exists, so return values need not be described, and the most dangerous behavior (overwrite plus the required flag) is covered. The remaining gap is the semantics of the path and live_system inputs, which an agent must infer for a 4-parameter tool with zero schema documentation.

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 output_map thoroughly with a concrete idPath example ({"1/1": "1/2"}) and the allow_destructive precondition, but leaves "path" and "live_system" entirely undefined for the agent.

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+resource ("Import mappings") and immediately anchors it to the sibling that produces its input, pixera_export_mappings. An agent can distinguish it from pixera_import_resource or pixera_import_warp_context without opening any 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?

Names the paired tool that generates valid input and gives a negative constraint ("Cannot create Art-Net outputs or feeds"), which routes the agent away from misuse. It does not, however, state when this should be preferred over the other pixera_import_* siblings or what prerequisites the live system must satisfy.

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 does real work: it discloses that directory import is non-destructive ('never removes existing resources'), that OBJ files are mapped to a specific resource type, and that the return is name/id/type per resource. It does not address permissions, auth, or single-file conflict behavior, so it falls short of complete behavioral coverage.

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 purpose sentence is front-loaded ahead of the mode detail, and the parenthetical '(or, with directory=true, ...)' keeps the flag semantics adjacent to the behavior they control. Slightly dense but every clause carries information; 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 3-param mutation tool with no annotations but a present output schema, the description covers purpose, the key behavioral caveat (non-destructive directory import), the follow-up workflow, and return shape. The main gap is the unexplained folder_name_path parameter, which the agent must infer from the schema title 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?

Schema description coverage is 0%, so the description must compensate, and it only partially does: it explains the 'directory' flag's mode-switching behavior but leaves 'path' and especially 'folder_name_path' (the destination folder) undefined. One of three parameters is meaningfully clarified in prose.

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+resource ('Import a file ... into a resource folder') and immediately clarifies the directory-mode scope. It also distinguishes its role from siblings by naming pixera_setup_layer as the follow-up for assigning the resulting resource. An agent can tell this apart from list_resources/find_resource/import_mappings without opening any 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?

It gives clear operational context: use directory=true to import a whole folder, OBJ files become '3DModel' resources, and the next step is pixera_setup_layer(model_resource_id=...). It never states when *not* to use it or names a competing tool, so it stops 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, the description carries the full burden and does reasonably well: it discloses offline operation, the exact data categories returned, and a real caveat that the parsing is heuristic for Pixera build 26-1. It does not state failure behavior for an invalid or non-.avp path, which is the remaining 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?

Front-loaded with the core action and resource, then a compact enumeration of returned data and a one-line build caveat. Each sentence earns its place; only the parenthetical '(offline)' duplication is slightly 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 an output schema exists, the description goes beyond its obligation by describing return content, and it supplies the offline assumption and build-version heuristic an agent needs. Missing only error/permission behavior and explicit sibling routing for a fully complete picture.

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 avp_path parameter has 0% schema description coverage, so the description must compensate. It clarifies the expected input is a '.avp show-file' path and that it is read offline, which adds format meaning, but gives no syntax, path form, or handling guidance.

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 ('parse') and resource (Pixera .avp show-file) and enumerates exactly what is extracted: projectors, FFD warp modifiers, marker calibration sets, soft-edge presence. It implicitly distinguishes itself from API-based siblings by noting this is warp data 'the Native API cannot expose', though no sibling is named directly.

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 word 'offline' implies the usage context (working from a project file rather than a live Pixera connection), which helps an agent choose this over pixera_load_project or pixera_load_warp_file. However, there is no explicit when-to-use/when-not statement and no alternative tool is 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?

With no annotations, the description carries the full behavioral burden. It does disclose the default-selection behavior and the idPath format convention, which is genuinely useful, but it omits what a 'live system' is, whether the call is read-only/side-effect free, and any permission or error behavior.

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 the returned fields front-loaded and the idPath linkage placed last where it belongs. No filler, though the second sentence's phrasing is slightly clipped.

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?

An output schema exists, so the return shape need not be re-explained, and the description covers the essentials for a simple read-only list. The residual gap is the absent behavioral/permission context given that no annotations back it up.

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% for the single live_system parameter, so the schema alone is unhelpful. The description partially compensates by explaining the default ('first'), but it never clarifies the accepted identifier format or what values live_system takes.

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 resource (outputs of a live system) and enumerates the returned fields (idPath, resolution, assigned projectors and screens), which distinguishes it from siblings like pixera_list_screens and pixera_list_projectors. It is clear, though it never states the action verb explicitly and offers no direct 'not this' contrast against the other list 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 '(default: first)' note implies context for omitting live_system, and the pointer that idPath is consumed by pixera_import_mappings gives a downstream usage cue. However, it never states when to call this vs pixera_list_screens/list_projectors or what prerequisites exist, leaving usage mostly inferred.

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 are provided, so the description carries the behavioral burden. "List" and "names" imply a read-only, narrow-result operation, and "current project" scopes it, but ordering, pagination, permissions, and empty-project behavior are not 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?

The description is a single, front-loaded sentence with no filler. It communicates the action, result type, and scope efficiently.

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 zero-parameter list tool with an output schema, the description is complete enough: it says what is listed and in what scope. Return values are handled by the output schema, so further detail is not required.

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 tool takes zero parameters, so there are no parameter semantics to explain. The baseline for zero parameters is 4, and no misleading parameter information is present.

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 and resource: it lists projector names, scoped to the current project. That clearly separates it from pose or screen tools, 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?

Usage is implied by "List projector names": an agent can infer it is used when projector names are needed. However, the description gives no explicit when-to-use guidance, exclusions, or comparison to sibling listing 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?

No annotations are provided, so the description carries the full burden. It implies a safe read by describing returned data and the effect of 'detailed' (adds file path and resolution), but says nothing about permission requirements, traversal/recursion limits, or whether the call is expensive on large projects. An output schema exists, so return-shape disclosure is not required.

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?

Front-loads what the tool returns, then explains each behavior-bearing parameter, then closes with the downstream usage. Every sentence is doing work and none of it repeats the schema or title.

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?

With an output schema present, return values need no explanation, and the description covers output content, the two behavior-changing parameters, and the follow-on call. The gaps are minor: max_depth semantics/default and whether folder_name_path omitted means 'list all'.

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 and largely does: folder_name_path gets a concrete example ('Media/Screens') and its semantics ('starts at one folder'), and 'detailed' is explained as adding file path and resolution. Only max_depth is left completely 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?

States a specific verb+resource ('Resource folder tree with each resource's name, id and type'), so an agent knows this returns a hierarchical listing of resources with identifying fields. It doesn't explicitly contrast with the sibling pixera_find_resource, but the tree-listing scope is distinct enough to be usable.

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 concrete usage context: folder_name_path 'starts at one folder' and the returned id feeds directly into pixera_setup_layer(resource_id=...). That's a clear downstream workflow, though it never names an alternative tool (e.g. pixera_find_resource) or states when not to call it.

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 are provided, so the description carries full behavioral burden. It does not state that this is a safe read-only operation, whether results are paginated, or anything about rate/permission constraints — though 'List' makes read-only intent reasonably inferable, and an output schema exists so return values need not be described.

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 short sentence, front-loaded with the verb and resource and carrying no redundant or filler text. Every word 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 zero-parameter listing tool with an output schema describing the return shape, the description covers what is listed and where. The only material omission is guidance distinguishing it from pixera_list_screens_detailed, which would help an agent choose 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?

The tool takes zero parameters, and the schema confirms an empty properties object with no arguments to document, so the baseline of 4 applies. The description correctly implies nothing is required to scope the call beyond the current project.

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 (screen names) with a clear scope scoping ('in the current project'). The word 'names' faintly distinguishes it from the sibling pixera_list_screens_detailed, but the description never explicitly says what the detailed variant adds or that they differ.

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?

Usage is only implied: 'names' suggests a lightweight lookup versus pixera_list_screens_detailed, but there is no explicit when-to-use statement, no when-not-to-use, and no mention of the sibling alternatives (detailed, list_projectors, list_outputs).

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 are provided, so the description carries the full burden; it implies a read-only enumeration but never states it explicitly. It does add genuinely useful behavioral detail by specifying units for the returned values (position in meters, rotation in degrees), which the structured fields may not 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?

A single front-loaded sentence listing the resource and its fields with zero filler. Nothing could be removed without losing 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 zero-parameter read tool with an output schema, the return values need not be explained, and the description covers the field set adequately. The remaining gap is the absence of any distinction from pixera_list_screens, which is the one thing an agent selecting between the two actually needs.

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 tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly spends no words on arguments.

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 specific resource (all screens) and enumerates the returned fields, so an agent knows exactly what data this yields. It does not, however, differentiate itself from the sibling pixera_list_screens, leaving the agent to infer the 'detailed' distinction from the name alone.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative pixera_list_screens. The agent gets no signal about when the detailed variant is preferable to the plain list.

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 burden, and it does disclose the return shape (handles + count) and the scope (current project), which implies a non-mutating read. It omits any statement of permissions, error behavior when no project is loaded, or pagination, so it is only partially transparent for a tool with zero annotation coverage.

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 short sentence with the resource and scope front-loaded and zero filler. Nothing in it fails to earn 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?

An output schema exists, so return values need no explanation, and with zero parameters the surface area is small. The one meaningful omission is the explicit relationship to pixera_list_timelines_detailed, which is the only real ambiguity for this simple read 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 tool takes no parameters, so there is nothing to document and the baseline of 4 applies. No parameter-related claims are made or needed.

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 (timelines) scoped to the current project, and the parenthetical '(handles + count)' signals it returns a lightweight summary. It implies but never names the sibling pixera_list_timelines_detailed, so differentiation from that near-identical tool is left to inference.

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 explicit when-to-use or when-not-to-use guidance. The '(handles + count)' phrasing hints this is the lightweight alternative to pixera_list_timelines_detailed, but the description never states that relationship or the condition that would route an agent to one over the other.

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 are provided, so the description carries the burden. It discloses that returned timelines include fps/transport mode and per-layer fields, and that protected timelines are marked, which is useful behavioral context. It does not discuss read-only nature or other operational traits beyond the name.

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 that front-loads the timeline attributes and then lists per-layer fields. It is efficient and error-free, though somewhat telegraphic.

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?

An output schema exists, so the description need not fully explain return structure. However, for a detailed-list tool with a sibling basic-list tool, it should clarify the include_layers parameter and when to choose this variant over pixera_list_timelines; those gaps keep it at adequate.

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?

There is one optional parameter, include_layers, with 0% schema description coverage, and the description never mentions it. The phrase "per layer" weakly implies layer details are included, but the effect of setting include_layers to false is 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 clearly identifies the resource as timelines and enumerates the detailed fields returned: fps, transport mode, per-layer resource/model/home screen/scale mode. It does not name or distinguish the sibling pixera_list_timelines, and it lacks an explicit verb, so it falls short of a 5.

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 no explicit guidance on when to use this detailed listing versus pixera_list_timelines or other siblings. Usage is only implied by the word "detailed" in the tool name.

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 disclose the critical side effects: replacement of the current project and invalidation of the handle cache (implying previously issued handles can no longer be used). It does not cover failure modes, required path format, or permissions, so the coverage is meaningful but partial.

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 efficient sentence with the destructive consequence front-loaded in the parenthetical. Nothing is wasted, though it is minimal by design rather than especially well-structured.

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?

An output schema exists, so return values need no explanation, and the destructive behavior is stated. However, for a tool whose only required input is a path, the complete silence on path semantics leaves an agent unable to confidently construct a valid 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?

There is one required parameter with 0% schema description coverage, and the description says nothing about what 'path' should contain (absolute file path, project file name, relative to what). The single parameter that determines whether the call succeeds is left entirely 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?

States a specific verb and resource ('Load a Pixera project'), which cleanly separates it from siblings like pixera_save_project and pixera_import_warp_context. It does not explicitly contrast itself with alternative load/import paths, but the action 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 description gives no when-to-use guidance and names no alternative (e.g., import vs load, or what to do instead if a project is already open). The only guidance is the implicit warning that it replaces the current project, which is behavioral rather than selectional.

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 behavioral burden. 'Load' implies a mutation to screen state, but it does not say whether an existing warp is overwritten, what happens on failure, or what permissions/paths are valid. Only the MPCDI default 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?

A single front-loaded sentence with no filler or redundancy. It is appropriately sized, though its brevity is partly a symptom of under-specification rather than deliberate economy.

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?

An output schema exists so return values need not be explained, but for a state-mutating tool with zero annotation coverage and 0% parameter documentation, the description leaves key operational questions (overwrite behavior, path semantics, screen prerequisites) unanswered.

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 only hints at two of the three parameters (path via 'warp file', mpcdi via 'MPCDI by default') and says nothing about screen_name's expected format or whether path is a local or remote path.

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: loading a warp file onto a screen, with the format default (MPCDI) called out. It is clear what the tool does, but it does not distinguish itself from closely related siblings like pixera_import_warp_context or pixera_recommend_warp_method.

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?

There is no guidance on when to use this instead of pixera_import_warp_context or pixera_import_mappings, nor any prerequisites (does the screen need to exist, must the file be local?). The agent is left to infer the selection conditions entirely.

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 are provided, so the description must carry the behavioral burden. It discloses the mechanism—API revision plus noop round-trip—which suggests a lightweight read-only connectivity test, but it does not explicitly state side effects, permissions, or timeout behavior.

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: "Liveness check: API revision + noop round-trip." Every element earns its place by identifying the operation and the mechanism.

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 zero-parameter, low-complexity liveness tool with an output schema, the description is largely complete. It explains the mechanism, and return details are covered by the output schema, though explicit usage context relative to siblings 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 tool takes zero parameters, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and nothing in the description creates 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 a specific operation: a liveness check performed through an API revision lookup and a noop round-trip. That distinguishes it somewhat from pixera_get_api_revision, but it does not explicitly name or contrast with sibling tools such as pixera_diagnose.

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 "Liveness check" implies when the tool should be used: verifying that the API is responsive. However, there is no explicit guidance on when to prefer it over pixera_get_api_revision, pixera_diagnose, or pixera_poll_monitoring.

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 are provided, so the description carries the full burden. 'Produce... plan' implies a read-only planning operation, but it never states that no scene mutation occurs, whether it depends on a loaded project, or whether results are deterministic. For a 5-parameter planning tool, this leaves key behavioral traits undisclosed.

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 front-loaded sentence with the artifact and pipeline order stated immediately; nothing is padded or redundant. It is efficient, though the extreme brevity is part of why surrounding gaps (params, usage) are unfilled.

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?

An output schema exists, so return values need not be explained, but that is the only burden lifted. With no annotations, 0% schema coverage, and five undocumented inputs, the description omits usage conditions, parameter meaning, and side-effect profile, leaving the agent under-equipped for a relatively complex 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?

Schema description coverage is 0%, so the description would need to compensate for all five parameters. It mentions none: 'curved', 'tracked', 'content_type', 'surface_type', and 'projector_count' get no explanation, and content_type/surface_type expose no enums so valid values are unknown. The names are partly intuitive, but no semantic value is added.

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?

Names a specific verb ('Produce'), a concrete artifact ('ordered, scenario-tailored Pixera setup plan'), and even sketches the internal pipeline (Screens -> Mapping -> Compositing). It is clearly a planning tool, distinguishable in spirit from siblings like pixera_recommend_warp_method or pixera_validate_softedge, though it never names an alternative to contrast against.

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?

There is no guidance on when to invoke this versus the many sibling recommenders (pixera_recommend_calibration_method, pixera_recommend_markers_for_projector) or validators. No prerequisites, no statement of whether a project must be loaded, and no exclusions are given. The agent must infer applicability entirely.

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 behavioral burden. 'Fetch' implies a read, but nothing is said about polling frequency, side effects, auth/permissions, or whether calls are rate-limited or safe to repeat.

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 short sentence with zero filler and the resource front-loaded. It is efficient, though its brevity borders on under-specification rather than tight conciseness.

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 tool is simple, parameterless, and has an output schema covering return values, so little is strictly required. Still, the description omits when to prefer it over the diagnostic siblings (pixera_diagnose, pixera_ping), leaving a meaningful routing 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 tool takes zero parameters, so there is nothing to document and the schema imposes no burden. Baseline 4 applies; no parameter meaning is missing or contradicted.

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 ('Fetch') and resource ('Pixera monitoring data') and the parenthetical 'alerts/heartbeat' concretely identifies the payload. It does not, however, distinguish this from closely related siblings such as pixera_diagnose or pixera_ping.

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?

There is no guidance on when to call this rather than pixera_diagnose or pixera_ping, and no stated preconditions or exclusions. The agent must infer the monitoring-poll use case from the name alone.

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 behavioral burden yet only says it 'recommends.' It does not clarify that this is a non-mutating advisory call, whether it depends on existing project state, or what deterministic criteria drive the recommendation (versus the actual calibration performed by pixera_run_calibration).

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 front-loaded sentence that lists the possible outputs without filler. It is tight and readable, though its brevity is partly the cause of the gaps elsewhere rather than pure economy.

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?

An output schema exists, so return-value explanation is not required, but for a 5-parameter recommendation engine with zero input documentation and no annotations the description is far too thin. An agent cannot tell which inputs are decisive or how to phrase them to get a useful recommendation.

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% across five parameters (surface_type, has_camera, projector_count, accuracy_need, time_budget) and the description compensates for none of it. Terms like 'scenario' gesture at inputs but give no meaning, valid values, or defaults for the parameters that actually shape the recommendation.

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 ('Recommend a calibration approach') and enumerates the candidate methods (homography / PnP markers / VIOSO / MPCDI), so the agent knows exactly what kind of output to expect. It does not, however, explicitly distinguish itself from close siblings like pixera_recommend_warp_method, so a small inference gap remains.

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 only scoping is the vague phrase 'for a scenario'; there is no statement of when this recommendation tool should be used instead of pixera_recommend_warp_method, pixera_run_calibration, or the validate_* siblings. No prerequisites or exclusions are given.

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 carry behavioral disclosure, and it does disclose the live connection requirement and that the projector pose is read live before culling. It does not state whether the tool mutates project state, whether recommendations are persisted, or what happens if the projector or lens data is missing, leaving important behavioral traits unstated.

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 action is front-loaded in the first sentence, followed by compact definitions of key input shapes and the live-connection requirement. The structure is efficient, though the parameter detail is unevenly allocated because four parameters are omitted.

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?

This is a complex tool with eight parameters, nested objects, no annotations, and 0% schema description coverage. The output schema means return values need not be explained, but missing parameter semantics, no sibling routing guidance, and limited behavioral caveats leave the definition only partially 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 explain all eight parameters. It usefully describes lens fields, mesh_path formats, and mesh_transform, but omits euler_order, grazing_deg, num_markers, and do_occlusion entirely, leaving half of the parameters without semantic guidance.

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 three-step verb chain: read the projector pose live, cull the mesh to what it sees, and recommend marker placement. That makes the tool's purpose clear, but it does not name or contrast with nearby tools such as pixera_apply_markers, pixera_validate_marker_calibration, or pixera_plan_projection_mapping.

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 states the prerequisite that a live Pixera connection is required and implies this is a planning/recommendation step. However, it gives no explicit guidance on when to use this instead of pixera_apply_markers, pixera_validate_marker_calibration, or other marker/calibration siblings, nor when not to use it.

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 are provided, so the description carries the full behavioral burden. It implies an advisory, non-mutating operation by promising a 'rationale', but says nothing about determinism, whether it reads live project state, or any side effects.

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 tight sentence with the deliverable front-loaded; nothing is wasted. It could afford to spend a clause on the input criteria without becoming bloated.

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?

An output schema exists, so return values need not be explained, but for a tool whose entire purpose is mapping inputs to a recommendation, the absence of any parameter semantics or usage context leaves the agent guessing about how to fill the five arguments.

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 there are 5 parameters (curved, tracked, has_3d_model, surface_type, non_rectangular) whose meaning and value domain are documented nowhere. The named warp methods in the description are outputs, not inputs, so they do not compensate.

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 (Recommend) and resource (warp tool), and even enumerates the candidate outputs (FFD, Vertex, Polygonal, Multi-Pos), so the agent knows exactly what it gets back. It is distinguishable from unrelated siblings like pixera_recommend_calibration_method, though it doesn't explicitly draw that contrast.

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?

There is no statement of when to call this versus alternatives such as pixera_plan_projection_mapping or pixera_import_warp_context. The five boolean/string inputs clearly encode selection criteria, but the description never says which conditions favor which method.

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 discloses nothing about side effects, idempotency, whether the refresh is synchronous or asynchronous, or what permissions are needed. For a trigger/mutation-style operation this is a meaningful gap, though the presence of an output schema partially limits how much return-value detail is needed.

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 front-loaded sentence with no wasted words, but its brevity borders on under-specification rather than efficient conciseness.

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 a mutation-style trigger with no annotations and an undocumented parameter, the description is too thin; only the return-value aspect is covered by the output schema. An agent cannot tell when the refresh is needed, what it affects, or whether it blocks.

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?

There is one required parameter (screen_name) with 0% schema description coverage, and the description adds nothing about naming, format, or whether the screen must already exist. The description fails to 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 pairs a specific verb ('Trigger') with a specific resource ('a mapping refresh on a screen'), so an agent knows the action and target. It doesn't differentiate itself from siblings like pixera_export_mappings or pixera_import_mappings, but the operation is distinct enough from the rest of the list.

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 when-to-use, prerequisite, or alternative guidance is given. The agent must infer that this should be invoked after mapping changes, and nothing indicates whether it is safe to call repeatedly or when it is required.

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 implies a mutating launch action but does not state side effects, required permissions, whether existing calibration is overwritten, expected duration, or what happens on failure.

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 efficient sentence with the action front-loaded and parameter hints parenthesized. There is no redundant or empty wording.

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?

Although an output schema exists and return values need not be explained, the description is incomplete for a calibration-launch operation with no annotations. It does not address operational context such as prerequisites, side effects, or how this relates to adjacent calibration planning/validation tools.

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 meaningfully covers all three parameters by naming the screen target, giving the two mode values ('newCalib'|'autoRecalib'), and providing an example tool value ('vioso'), though the tool parameter is only exemplar-based rather than comprehensive.

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 ('Launch a calibration tool') and target resource ('a screen'), with mode and tool hints. It does not explicitly distinguish this tool from siblings such as pixera_recommend_calibration_method or pixera_validate_marker_calibration, but the core purpose is 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 gives no guidance on when to use this tool versus alternatives like recommending a calibration method or validating marker calibration. It only explains what the parameters can contain, not when this launch action is appropriate.

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, and it says nothing about where the project is saved, whether it overwrites the existing file, whether it is reversible, or whether it can fail. 'Save' implies mutation but the description never confirms persistence, side effects, or failure conditions.

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 short, front-loaded sentence with zero filler, appropriately sized for a no-argument tool. It could be a 5 only if it also carried the missing behavioral or usage context 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?

Complexity is low and an output schema exists, so return values need not be described. However, for a write operation with no annotations and no parameter documentation, the description leaves the important behavioral facts (overwrite semantics, required loaded project) entirely uncovered.

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 accepts zero parameters with 100% coverage, so there is nothing for the description to clarify. A 4 is the baseline for a no-argument tool; the description neither needs nor adds parameter detail.

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 (Save) and a specific resource (the current Pixera project), so an agent immediately knows this persists project state rather than loading or exporting it. It does not, however, explicitly contrast itself with siblings like pixera_load_project or pixera_export_mappings, which a one-line save tool could easily have done.

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?

There is no when-to-use guidance: nothing says whether the tool should be called after mutations, whether it requires a project to be loaded first, or whether it supersedes any other persistence mechanism. The only signal is the verb 'Save' in the name, leaving usage entirely to inference.

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 burden, and it discloses one real trait: a live Pixera connection must exist. It also names the output shape (VQI + breakdown). However, it says nothing about whether the call is read-only, how long the scoring takes, or what happens on a failure — significant gaps for a tool with no annotation coverage.

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-loaded with the core action and followed by the output hint and the connection requirement. Nothing is wasted, though there is little substance to be concise about.

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?

An output schema exists so return values need not be described, but the tool has six parameters at 0% schema coverage, nested lens/mesh_transform objects, and no annotations. The description is far too thin for an agent to invoke it 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 description coverage is 0% across six parameters, including two nested objects (lens, mesh_transform), yet the description explains only that a projector and a mesh are involved. Undocumented knobs such as grazing_deg, euler_order, and the required mesh_path are left entirely without meaning.

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?

Specific verb+resource: 'Score how calibratable a mesh is from a projector' names the operation and its inputs, and the '(VQI + breakdown)' parenthetical hints at the result. It does differentiate from pixera_run_calibration and pixera_recommend_calibration_method, though it never explicitly names those siblings.

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 only guidance is the prerequisite 'Requires a live connection'. There is no indication of when to score calibratability versus calling pixera_recommend_calibration_method or pixera_run_calibration, nor any ordering relative to those steps.

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 behavioral burden and does disclose the important non-obvious dual-mode behavior (list vs. set depending on mode_index). It says nothing about permissions, whether (de)activation is reversible, or side effects on running streams, and it avoids explaining returns — partly excusable since an output schema exists.

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 zero filler. The primary write behavior is front-loaded and the caveat about listing follows immediately after, which is exactly the ordering an agent needs.

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?

Return values are covered by the output schema, so the description isn't obliged to explain them. But for a 4-parameter mutation tool with no annotations and 0% schema coverage, omitting any guidance on the required folder/resource identifiers leaves the definition thinner than the tool's complexity warrants.

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, and it only partially does: it gives real meaning to mode_index (absence triggers list mode) and implies activate's effect. The two required parameters, folder_name_path and resource_name, are never explained — no path syntax or lookup guidance — leaving a significant documentation hole.

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 — 'Set the stream mode of an existing Live Input resource and (de)activate its streams' — so an agent knows exactly what is being mutated. It also surfaces the secondary list-only behavior. It does not, however, differentiate itself from any named sibling (none of which appear to be live-input specific).

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 conditional 'Without mode_index, only lists the available modes' tells the agent that this tool doubles as a discovery call, which is genuinely useful routing information. But it never states when to prefer this over alternatives such as pixera_get_param or pixera_list_resources, so usage is only implied.

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 behavioral burden. It does convey that one tool handles both blackout and restore, which helps interpret the boolean, but it does not say whether this is a live state change, whether it requires the projector to be online, or whether it is immediately visible on 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?

A single short sentence, front-loaded with the action. It is efficient with no filler, though its brevity is the source of the missing detail rather than a separate flaw.

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?

An output schema exists, so return values need not be explained, but for a no-annotation mutation tool with 0% parameter coverage the description is too thin. It omits the boolean polarity, name sourcing, and any state/permission context an agent would need to invoke it 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 description coverage is 0%, so the description must disambiguate both parameters. 'By name' partially clarifies projector_name, but the polarity of the 'on' boolean is left ambiguous — it is unclear whether on=true means blackout engaged or restored, which is critically important for a toggle.

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 gives a specific verb pair (blackout/restore) and a clear resource (projector), scoped by name. It does not explicitly distinguish itself from siblings like pixera_list_projectors or pixera_get_projector_pose, but 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?

There is no when-to-use or when-not-to-use guidance, and no pointer to alternatives or prerequisites. It never tells the agent that the projector name must first be obtained (e.g. via pixera_list_projectors), nor when blackout is appropriate versus other projector operations.

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 does well: it discloses partial-update semantics ('Omitted vectors stay unchanged'), that it reads the pose back, the coordinate frame (right-handed, Y-up, metres), and a refusal condition (rotation rejected under convention='blender'). It does not cover permissions or failure behavior for a missing screen, but the key behavioral traits are present.

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?

Front-loads the action and effect in the first clause, then adds only the convention/units detail an agent needs. Two tight paragraphs with no filler, though the convention explanation is somewhat dense.

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?

An output schema exists, so return values need not be explained. For a mutation tool with no annotations the description adequately covers frame, units, partial-update behavior, and the blend-convention edge case; only the screen_name identity requirement is left implicit.

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%, so the description must compensate, and it does for most parameters: units for position (m) and rotation (deg), the meaning of the convention parameter and its blender conversion formula, and the fact that omitted vectors are left unchanged. Only screen_name is left entirely to the schema.

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?

Specific verb ('Set') plus resource ('screen pose') with the exact manipulable fields (position [x,y,z] m, rotation [x,y,z] deg, scale). Distinguishable from the nearby sibling pixera_get_projector_pose, which targets projectors and reads rather than sets.

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 the coordinate convention mode and the partial-update rule, but never states when to reach for this tool versus alternatives (e.g., a get_projector_pose or listing tool). Usage is implied by the effect rather than routed explicitly.

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 are provided, so the description carries the full burden of behavioral disclosure. It names the three actions but does not describe side effects (e.g., whether stopping affects other timelines), required state, permissions, or what happens on failure. Minimal behavioral context is given.

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, front-loaded sentence that contains the core operation and the exact action tokens without any wasted words. Appropriate for a simple transport-control 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 simple transport tool with an output schema and no annotations, the description is minimally viable. It omits usage guidance relative to the by-name sibling and lacks behavioral detail (side effects, prerequisites), leaving meaningful gaps for an agent to infer.

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 does define the valid action values ('play'|'pause'|'stop'), which is critical since the schema has no enum, but it adds no meaning for timeline_index beyond the phrase 'by index' (e.g., zero-based, how to obtain it). Partial compensation.

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 (Play/Pause/Stop) on a resource (timeline) and clarifies it operates by index, distinguishing it from the sibling pixera_set_timeline_transport_by_name. The verb+resource+discriminator combination is clear, though it doesn't explicitly name the alternative tool.

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 use when a timeline index is available ('by index'), but provides no explicit when-to-use guidance, no conditions for selecting this over pixera_set_timeline_transport_by_name, and no prerequisites or exclusions.

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 are provided, so the description carries the full behavioral burden, and it discloses very little: nothing about what happens if timeline_name does not match an existing timeline, whether the call is synchronous, whether it requires a live project connection, or what side effects transport control has on other timelines. It conveys only the set of transport actions.

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 tight sentence with the operation front-loaded and the action enumeration parenthetically appended. Nothing is wasted, though it is terse to the point of omitting useful 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?

An output schema exists, so return values need not be described, and the action space is covered. What is missing is routing relative to the near-identical sibling tool and any statement of failure behavior for an unmatched name, which for a two-parameter transport tool leaves a 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?

Schema description coverage is 0% and neither parameter has an enum in the schema, so the description's enumeration of action values ('play'|'pause'|'stop') is genuinely additive and prevents the agent from guessing synonyms. However, timeline_name is left completely unexplained (exact-match? case sensitivity? names of timelines loaded from a project?), so compensation for the coverage gap 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?

States a specific verb and resource ('Play/Pause/Stop a timeline') plus the selector ('by name'), so the agent knows exactly what the tool affects. It does not, however, distinguish itself from the sibling pixera_set_timeline_transport, which presumably targets a timeline by ID or index rather than name.

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?

There is no explicit when-to-use guidance and no mention of the alternative pixera_set_timeline_transport. The only implicit signal is the 'by name' phrasing in the name and description, which the agent must infer means 'use this when you have a timeline name rather than an ID'.

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 behavioral burden. It usefully discloses that the operation is a mutation, that it will create the layer if absent, and that it refuses protected timelines. It says nothing about permission/auth requirements, idempotency, or what a refusal looks like to the caller, leaving meaningful gaps for a write 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 core action and constraints are front-loaded and the field enumeration is compact. It is dense and slightly run-on, but each clause conveys distinct information with little waste.

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?

An output schema exists, so return values need not be explained, and the description covers most of what an agent needs to call this mutation tool correctly, including the protected-timeline refusal. Missing coverage of the 'create' default behavior and the layer/timeline identifiers keeps it from being 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 coverage is 0% and there are 8 parameters, so the description must compensate. It explains resource_id, model_resource_id (including the '3DModel' resource type), home_screen, render_only_on_home_screen, and crucially supplies enum values for scale_mode that the schema does not constrain. It leaves layer, timeline, and create only implicitly covered.

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 specific verbs ('find or create', 'set') on a named resource (a layer) and enumerates the settable attributes, so the agent knows exactly what the tool operates on. It does not explicitly contrast itself with the read-oriented sibling pixera_get_layer_json, so it stops short of a 5.

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?

Usage is implied by the find-or-create semantics and the 'Refuses protected timelines' constraint, which tells the agent a precondition failure mode exists. However, there is no explicit when-to-use guidance nor any pointer to alternatives such as pixera_create_timeline or get_layer_json for read-only inspection.

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 are provided, so the description carries the full burden of behavioral disclosure. It says nothing about what a failed validation produces, whether any pixera state is modified, whether aspect mismatch vs resolution mismatch are reported differently, or the meaning of keep_square.

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 front-loaded sentence with zero filler. It is not padded or rambling, though its brevity reflects under-specification rather than tight editing.

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?

An output schema exists so return values need not be described, but for a 5-parameter validation tool with no annotations and 0% schema coverage, the definition leaves the comparison semantics, the keep_square behavior, and any usage context unstated.

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 does not name any of the five parameters. '(resolution + aspect)' hints that width/height pairs are compared, but keep_square and the distinction between canvas and projector values are left entirely unexplained by both schema and description.

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 (validate) and resource (canvas resolution against projector output), including the two dimensions checked (resolution and aspect). It is clear enough to distinguish from siblings like validate_softedge or validate_feed_mode by resource, though it doesn't explicitly name an 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?

No when-to-use guidance, no prerequisites, and no mention of how it relates to sibling validators or the planning/recommendation tools. An agent must infer that this is a pre-flight check run before rendering.

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 are provided, so the description carries the burden, but 'validate' strongly implies a non-destructive read-only check and an output schema exists to describe the result. It discloses the key constraint rule but not whether it throws, returns a boolean, or what failure looks like beyond that 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?

A single front-loaded sentence with the validating purpose first and the constraint example second; no filler. It is lean to the point of being terse, which slightly undercuts structure.

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?

With three parameters at 0% schema coverage and no annotations, the description covers only one constraint rule. The output schema relieves the need to document return values, but an agent still lacks the meaning of surface_type and the accepted feed_mode values.

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%, so the description must compensate. It effectively explains the feed_mode/UV-continuity relationship, but surface_type is never described (what values, why it matters) and no concrete enum values for feed_mode are given, leaving two of three parameters under-specified.

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+resource: validating a feed-mode choice for a surface, which is unambiguous about what the tool does. It does not contrast itself with the other validate_* siblings (validate_softedge, validate_canvas_resolution), so it stops short of a 5.

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 parenthetical ('None' only for 3D/non-continuous UV) conveys a validity rule that implies when this check matters, but there is no explicit when-to-use/when-not-to-use or reference to an alternative approach. Usage must be inferred from the validation framing.

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 are provided, so the description carries the full behavioral burden. It implies a validation/read operation but does not state whether it is side-effect-free, what permissions are needed, or how errors are reported. The output schema may cover return values, but behavioral context remains thin.

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 wording. Its brevity is efficient, though it also contributes to the sparse coverage of usage and parameter 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?

With 9 parameters, no annotations, and 0% schema description coverage, the description is too thin for the tool's complexity. It names only a subset of inputs and provides no usage or behavioral context; the output schema helps with return values but does not compensate for the missing input and usage detail.

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% across 9 parameters. The description maps only some parameters (marker_count, coplanar, edids_set/lens_preset, reprojection_error) and omits placement, depth_varied, surface_type, and model_from_scan, leaving several inputs without semantic explanation beyond their names and defaults.

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 and resource: validate marker-calibration parameters. The parenthetical list (count, coplanarity, EDID/lens prereqs, error) clarifies the validation scope, but it does not explicitly distinguish this validate tool from sibling validate tools such as softedge, canvas resolution, or feed mode.

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?

There is no guidance on when to use this tool versus alternatives like pixera_recommend_markers_for_projector or pixera_run_calibration. It also omits any prerequisites or exclusions, leaving the agent to infer usage from the name alone.

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. 'Validate' and 'flag' imply a read-only diagnostic, but it never states that it is non-destructive, whether it requires an active project/loaded warp, or how results are reported beyond the output schema's existence.

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 tight sentence with no filler and the core purpose front-loaded. Efficiency is good; the problem is missing content, not verbosity.

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 7-parameter validation tool with zero annotation and zero schema description coverage, the description is far too thin. The output schema helps explain returns, but the semantics of the inputs and the nature of the validation are left to guesswork.

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% across 7 parameters, and the description explains none of them. Critical inputs such as the 'overlaps' numeric array, 'feed_mode', 'surface_type', and the boolean flags like 'dynamic_softedge' are entirely undocumented, so an agent cannot know what values or formats to supply.

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 (validate) and resource (soft-edge/blend setup) plus an outcome (flag what is wrong). It is distinguishable from siblings like pixera_validate_feed_mode, though 'what is wrong for the workflow' is vague about what checks are actually performed.

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 on when to run this versus pixera_validate_feed_mode, pixera_recommend_calibration_method, or pixera_diagnose, despite heavy overlap (a feed_mode parameter even exists here). No prerequisites or when-not-to-use conditions are given.

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