Uxia

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description's job is to add context, and it does: the server generates and returns blockId for later edits, and 'No launch' clarifies that adding a task does not start the test. It does not cover failure modes, permission requirements, or what happens on duplicate/position conflicts.

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 wall of text mixes tool purpose, parameter constraints, and three long field-authoring style guides. The sentence 'Preserve supplied or accepted wording unless the user requests a rewrite or delegates wording choices' is repeated verbatim three times, wasting space, and none of the drafting guidance is visually separated from the operational instructions.

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 the key selection and constraint facts an agent needs plus the unusual drafting conventions for task/scenario/stopCondition. Given the 9-parameter surface, it is complete enough despite the padding; only testId and position semantics are left entirely to the schema.

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

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

Schema description coverage is 67%, so the schema already documents blockId, isPrototype, task, scenario and stopCondition — and the description's long drafting rules for those fields largely restate what the schema descriptions already say. The one genuinely additive item is the cross-field constraint 'stopCondition requires url', which the schema does not express. Baseline 3 is appropriate.

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

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

The opening sentence gives a precise verb+resource+scope: 'Add a website task or empty task to an existing draft.' It goes further than most siblings by naming the boundary case and the alternative tool ('Use add_test_block for uploaded prototypes or advanced settings'), so an agent can distinguish add_task from add_test_block without opening either schema.

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

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

It states when to use the alternative ('add_test_block for uploaded prototypes or advanced settings'), field-conditional rules ('stopCondition requires url', 'Supply url for a website task', 'Omit wording only for an intentionally incomplete draft'), and a scope limit ('No launch'). The tool-selection guidance is real but compressed into one clause and buried among field-authoring conventions, with no guidance on when not to add a task at all.

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

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

Annotations already convey non-read-only, non-idempotent, non-destructive, and closed-world. The description adds real value beyond them: the return contract (blockId plus the saved draft), the "No launch" boundary, and the credential-safety constraint. It does not detail what happens to existing blocks on conflict, but for an additive create operation this is minor.

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 and compact, but telegraphic to the point of choppiness and slightly redundant — the return contract is stated twice ("returns blockId and the saved draft" then "Returns current draft"). Tightening would improve it.

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 not be explained, and the description plus 80% schema coverage handle a complex four-variant block payload adequately. The main gap is deeper routing against the many sibling setup 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?

At 80% schema coverage the schema carries most parameter meaning, but the description adds operational semantics the schema does not spell out: omit id for server-side generation, omit position to append, and keep AI fields inside configuration. These clarify how the required block object must be shaped.

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 (Add) and resource (Test Block) and enumerates the exact block types supported: AI task, Survey, Accessibility, and Card sorting. It also distinguishes the tool from a sibling by directing website tasks to add_task, so an agent can tell them apart without opening the 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?

"Prefer add_task for website tasks" gives one explicit alternative with its selecting condition, and "No launch" signals this only writes a draft. However, no guidance distinguishes it from other block/setup siblings like prepare_test_block, create_block_test, or update_test_block, so routing is only partially complete.

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

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

Annotations cover the safety profile (not read-only, not idempotent, not destructive). The description adds genuinely useful context beyond that: creation happens synchronously and the operation also generates tester profiles, which signals a potentially slow/expensive call and that repeat calls produce new resources. It omits auth/permission prerequisites but is otherwise solidly 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?

Three tightly written sentences with the core action and the crucial "not recruit people" clarification front-loaded. No filler, no restatement of the tool name.

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 detail is not required, and annotations carry the safety profile. However, for a 19-parameter creation tool the definition leaves most parameter semantics and all when-to-use routing unaddressed, making it only adequately complete.

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

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

Schema description coverage is only 11% across 19 parameters, so the description must compensate and largely does not. Naming the filter categories (age, gender, geography, demographics) maps to a few params, but roles, techLiteracy, maritalStatus, employmentStatus, income objects, isReusable, customDetails, and languagesRequirement receive no semantic explanation anywhere.

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 ("Create a new audience") and immediately clarifies what an audience is here — targeting filters for synthetic AI testers, "not recruit people." This distinctly separates it from siblings like list_audiences and set_test_audience.

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?

Explains the domain concept and disambiguates "audience" from human recruiting, but never states when to call this versus siblings such as list_audiences (discovery) or set_test_audience (binding an existing audience to a test). Usage is implied rather than instructed.

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

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

Annotations already declare a non-destructive, non-idempotent write. The description adds meaningful context beyond them: the result is a saved draft with a URL and the call never launches a test or consumes credits, resolving the main ambiguity for a write tool. It doesn't mention retry/idempotency consequences, which keeps it from a 5.

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 short sentences, no filler, with the core action and optionality front-loaded before the behavioral caveat. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a very large nested block/audience schema and the presence of an output schema (so return structure needn't be detailed), the description covers the operation, optionality, and the critical 'does not launch' constraint. It could say more about the draft-vs-launched lifecycle and idempotency, but it is sufficient for correct invocation.

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?

Top-level schema description coverage is 0%, so the description carries the load and does explain that the definition holds 'known blocks and audience' and is optional, mapping to both parameters. It adds little on the title parameter (e.g., the 200-char bound), so not a 5.

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 (create) and resource (a draft test) with the two things it takes: a title and an optional definition of blocks and audience. The closing clause 'Never launches or spends test credits' cleanly separates it from launch_test and preview_test_launch, so an agent can pick it without opening a 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?

Offers one useful usage rule ('Omit definition for an empty draft') but gives no explicit when-to-use versus alternatives such as add_test_block, update_test_definition, or prepare_test_block. Usage is implied rather than contrasted, which is the minimum-viable level.

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

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

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real context beyond them: results are computed over actual participants (data semantics, not raw config) and legacy tests are supported.

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 with the core purpose front-loaded and no filler. Slightly dense/telegraphic in the second half ('Legacy tests also supported'), but every sentence carries 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 return values need no explanation, and annotations cover the safety profile. For a read-only tool at this complexity, the remaining gap is only the undocumented runId/testId parameters.

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

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

Schema description coverage is only 33% (runId and testId are undocumented). The description partially compensates by telling the agent that block/run IDs come from list_test_blocks and that omission uses defaults, but it adds nothing for the required testId beyond 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?

States a specific verb (Read) and resource (audience targeting and demographic breakdowns) and scopes it to 'the actual participants in this test', which is a meaningful distinction from a configured-audience lookup. It explicitly separates itself from get_tester, though it stays silent on list_audiences/create_audience neighbors.

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 one-participant case to get_tester and tells the agent to source block/run IDs from list_test_blocks, plus notes omission behavior and legacy support. It gives clear when-to-use context but no when-not or full alternative map (e.g. vs list_audiences).

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuine context beyond that: how 'agreement' is computed, that similar participant-created category names are grouped, and that participantType=ai resolves to the latest run while human reads completed sessions.

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 purpose, then supporting semantics. Every sentence carries information, though the agreement-definition sentence and the return-value enumeration are somewhat long for a tool that already ships an output 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?

With an output schema present, return values need not be described, yet the description helpfully summarizes them. Combined with annotations covering safety and the participantType semantics, an agent has enough to call this correctly; only permissions/error behavior for non-card-sorting blocks is 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%, so the description must carry the load. It fully explains the one non-obvious parameter (participantType default ai, latest run or runId; human reads completed sessions) and implies runId selects a specific run. The remaining three parameters are opaque IDs whose format the description does not elaborate on.

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 ('Read results for a Card sorting block') and enumerates the exact payload (categories with agreement, card placements, similarity pairs, participant sorts). No sibling tool returns card-sorting data, so the block-type scoping alone is enough to distinguish it.

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: you call this when you have a card sorting block and want its results. There is no when-to-use/when-not guidance and no routing to alternatives such as get_test_report or get_question_responses. The participantType default/human explanation is parameter behavior rather than tool-selection guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description only adds that the response concerns both available credits and usage — a small content hint, with no note on account scope, freshness, or rate limits. Modest added value over the structured fields is the right level here.

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 sentence, front-loaded with the verb and the two data points returned. Nothing is wasted, though it is arguably terse enough to be under-specified rather than optimally tight.

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-value detail is unnecessary, and annotations carry the safety profile; for a zero-argument read tool the description is nearly sufficient. The only real gap is that it never anchors 'credits' to a system or account context.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The empty input schema also makes the call signature self-evident.

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 (credits and usage), so an agent can tell it retrieves a balance/consumption view rather than test data. No sibling in the list covers credits, so no sibling differentiation is needed. It loses a point because it never clarifies whose credits or in what unit/scope (account-level, plan-level), leaving 'credits' ambiguous.

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 condition, no exclusions, and names no alternative. It is a no-argument account read, so the omission is low-risk, but the definition provides zero routing guidance beyond 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: images may be unavailable, merged captures are included, and legacy tests are supported. It stops short of explaining pagination behavior implied by limit/offset.

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 core action, but the four sentences are loosely stitched, with caveats ('Images may be unavailable', 'Legacy tests also supported') appended rather than organized. Reasonable size, uneven 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 return-format explanation is unnecessary. For a 6-param read tool the description covers retrieval source, defaulting, availability caveats, and legacy support – adequate, with limit/offset behavior the only notable omission.

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

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

Schema coverage is only 33%, so the description must compensate. It does map frameNumber to its source (finding evidence) and blockId/runId to list_test_blocks IDs with default behavior, but limit and offset are left entirely undocumented in 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 and resource ('read one gallery frame') and identifies the key input (frameNumber from finding evidence) plus the return content (one available image preview, merged captures). It is clear what the tool does, though it never explicitly contrasts with near-neighbors like get_screen_details or get_insight.

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 one concrete routing hint – 'Use IDs from list_test_blocks to target a block/run' – and notes omission falls back to documented defaults. However there is no guidance on when to prefer this over get_screen_details/get_insight, nor 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?

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds genuinely useful context — results are aggregates, scoping is by block or run, defaults apply on omission, and legacy tests are supported — but says nothing about auth requirements, metric freshness, or how legacy behavior differs.

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 short sentences, front-loaded with the capability statement, followed by input sourcing and legacy support. Nothing is padded, though the trailing 'Legacy tests also supported' is thin enough to be nearly 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?

An output schema exists, so return values need no explanation. The description covers input sourcing, default behavior, and legacy compatibility, which is most of what an agent needs; the remaining gap is the absence of disambiguation from the non-human navigation siblings.

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

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

Schema description coverage is only 33%: blockId is documented in-schema, while runId and the required testId carry only patterns. The description partially compensates by explaining how block/run IDs are sourced and what omission means, but it never clarifies testId usage even though it is the only required 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 — 'Read aggregate navigation metrics for human sessions' — which cleanly separates it from raw-session tools like get_human_session and from the aggregate get_navigation_summary. However, it never names that sibling or states the human-vs-other distinction explicitly, so differentiation is inferred rather than asserted.

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?

'Use IDs from list_test_blocks to target a block/run' routes the agent to the correct source for inputs, and 'omission uses the documented defaults' describes fallback behavior. But there is no explicit when-to-use-this-instead-of guidance against get_navigation_summary or get_human_session, leaving the choice of tool 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that retrieval is by exact reference, that omission triggers defaults, and that legacy tests are supported, but says nothing about pagination behavior despite limit/offset params.

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 with the core operation front-loaded; the legacy-tests note is a useful trailing caveat rather than padding. Little wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The existence of an output schema removes the need to describe return values, and annotations cover safety. But with 6 parameters at 17% schema coverage, the description leaves testId/limit/offset undocumented and gives no when-to-use routing against transcript/list siblings, so 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 description coverage is only 17% (just blockId), so the description must carry the load, and it only partly does: it clarifies 'exact ref' and the block/run-sourcing plus defaults. The required testId, plus limit and offset, are left completely unexplained in 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?

The description gives a concrete verb+resource ('Read a human session, task and transcript by exact ref'), which clearly separates it from the plural sibling list_human_sessions. It stops short of naming the natural alternatives (get_transcript, list_human_sessions), so sibling differentiation is implied rather than stated.

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

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

It tells the agent to source block/run IDs from list_test_blocks and that omitting them falls back to documented defaults, which is real usage context. However it never states when to choose this tool over get_transcript or the list variants, leaving the main routing decision 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds meaningful behavior beyond that: paywalled details may be redacted, only up to three screenshot previews are returned, and images may be unavailable. It still doesn't say what happens on an invalid or expired ref.

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 what the tool returns, then caveats, then parameter sourcing. Dense but every sentence carries information; only the trailing 'Legacy tests also supported' is thinly connected to the rest.

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 detail is not strictly required, yet the description usefully previews the payload (quotes, impact, fix suggestions, prompts). Remaining gaps are minor: no failure/redaction-trigger detail and no explicit runId/testId semantics.

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

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

Schema coverage is only 25%, so the description must carry weight. It clarifies that ref comes from list_insights and that blockId comes from list_test_blocks with omission using documented defaults, but it never explains the distinction between runId and testId or the 24-hex format constraint.

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 ('Read a finding by exact ref from list_insights') and immediately enumerates exactly what the finding contains. An agent can distinguish it from list_insights (listing) and show_evidence (evidence display) without opening either schema.

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

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

Gives concrete routing guidance: use 'get_frame_details for additional frames' and take block/run IDs 'from list_test_blocks'. It does not explicitly say when to prefer this over show_evidence or list_insights, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is fully covered structurally. The description adds nothing beyond 'Read' – no note on what the summary contains, freshness, or whether a test must be completed first.

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 no padding or redundancy. It is efficient, though its brevity is partly the under-specification flagged elsewhere rather than disciplined concision.

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, which lightens the burden. Still, for a tool in a dense read-tool family the description omits usage context and any parameter detail, leaving clear gaps for an agent choosing among many get_* options.

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 testId parameter, whose only constraint (a 24-char hex pattern) lives in the schema with no description. The phrase 'for a test' hints at the id's referent but gives no source (e.g., list_tests) or format context 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 ('Read') and resource ('market research summary') scoped to a test, so an agent knows what the tool fetches. It does not, however, differentiate itself from the many adjacent read siblings such as get_test_summary, get_test_report, or get_insight, leaving the resource's actual content ambiguous.

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 and no mention of alternatives, despite a crowded sibling set of get_* summary/report tools. The agent must infer the appropriate situation 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that omission falls back to 'documented defaults' and that legacy tests are supported, which is useful but vague — it never says what the defaults actually are.

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 short sentences, front-loaded with the purpose before the targeting details. 'Legacy tests also supported' is a slightly tacked-on fragment, but nothing is redundant or padded.

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 and full read-only annotations mean return values and safety need not be re-explained. The remaining gap is orientation: with get_human_navigation_summary as a sibling, the definition should say which summary applies to which test type, and it doesn't.

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

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

Schema coverage is only 33% (only blockId is documented inline), so the description must compensate. It partially does, telling the agent where IDs come from (list_test_blocks) and that omission is safe, but it says nothing about runId or the required 24-hex testId beyond the schema's pattern.

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: 'Read aggregate navigation and completion metrics.' Clear about what it returns, but it does not distinguish itself from the near-identically named sibling get_human_navigation_summary, leaving the agent to guess which audience (simulated vs. human) each summary covers.

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?

'Use IDs from list_test_blocks to target a block/run' gives context for obtaining inputs, and 'Legacy tests also supported' hints at an edge case. However, there is no explicit when-to-use/when-not guidance and no routing to the alternatives (e.g., get_human_navigation_summary) that share this tool's space.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description still adds genuine context beyond annotations: omitted IDs fall back to documented defaults, and legacy tests are supported.

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 with the purpose front-loaded and the parameter-sourcing hint following. No filler, though "documented defaults" is a vague pointer that costs a little precision.

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 and annotations cover the safety profile, so return values need no explanation. With only three parameters and one required, the description supplies enough to call it, though the referenced defaults remain unexplained.

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

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

Schema coverage is only 33% (blockId documents itself), so the description must compensate. It partially does by tying block/run targeting to list_test_blocks, but testId (the required parameter) and runId receive no added 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?

States a specific verb (read) plus resource (optimization score) and adds the scope of contributing factors. The resource is unique among siblings, but the description does not explicitly distinguish it from adjacent scoring tools like get_satisfaction_score or get_strengths.

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?

"Use IDs from list_test_blocks to target a block/run" gives a concrete prerequisite for sourcing parameters, and the omission note hints at a default path. However, it never says when to reach for this tool versus other scoring/reporting siblings, 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?

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), lowering the burden. The description adds that the question ref must be exact, which hints at matching behavior, but says nothing about pagination (limit default 30, max 50) or how filter interacts with the base query.

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 operative scope ('exact ref') comes early. Slightly terse given the ambiguity of 'market-research question' against the sibling 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 values need no explanation. For a 4-param tool with 25% schema coverage and a confusingly similar sibling, the description omits pagination semantics and tool-selection guidance, leaving it 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 description coverage is only 25% (only filter is documented), so the description should compensate more. 'Using its exact ref' does add meaning beyond the schema's bare minLength=1 for questionId by implying exact-match lookup, but testId and limit remain unexplained in both places.

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 (participant responses for a market-research question), which an agent can act on. However, it does not distinguish itself from the near-identically named sibling get_test_question_responses, nor clarify the 'market-research question' vs 'test question' scope.

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 named alternative. With a sibling like get_test_question_responses in the same family, the absence of routing guidance is a clear gap.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds useful behavioral context ('contributing factors' as return content, 'legacy tests also supported'), but the phrase 'the documented defaults' points at documentation that isn't present here, leaving the fallback behavior opaque.

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 read purpose front-loaded and no filler. Slightly penalized for the dangling reference to 'documented defaults' rather than stating the behavior inline.

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 annotations cover the safety profile. Still, the ID-sourcing story is incomplete (testId/runId undocumented) and the default-resolution behavior is deferred to external docs, leaving an agent with gaps for a tool that reads from a nested test/run/block hierarchy.

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

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

Schema coverage is only 33% – blockId is documented but runId and testId are not. The description partially compensates by pointing to list_test_blocks for IDs and describing omission/default behavior for the block/run, but testId semantics and the runId format remain undocumented in both places.

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 (satisfaction score) plus the return content ('contributing factors'). It is clear what the tool returns, but it never distinguishes itself from the similar-sounding sibling get_optimization_score, leaving that inference to the agent.

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

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

It tells the agent where to obtain the ID ('Use IDs from list_test_blocks') and that omission uses defaults, which is genuinely useful routing. However, it gives no explicit when-to-use vs the neighboring score/report tools (get_optimization_score, get_test_report), 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?

Annotations already declare the safe read-only, idempotent, non-destructive profile, but the description adds real behavioral context they don't carry: one screenshot preview is included, images may be unavailable, prototype indexes are zero-based while live gallery numbers are one-based, and legacy tests are supported. This is the kind of operational caveat an agent needs before calling.

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 and its selector are front-loaded in the first sentence, and the remaining sentences are short and information-bearing. It is slightly choppy and 'Legacy tests also supported' partially duplicates the legacy note already in the blockId schema description, but no sentence is pure 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?

Because an output schema exists, return values need not be described, and the description covers the non-obvious gaps: index bases, image availability, legacy support, and where to source IDs. It omits what 'metrics' entails and whether a missing screen or image produces an error versus an empty result, which are minor given the output schema.

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

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

Schema description coverage is only 25% (only blockId is documented), so the description carries most of the burden. It explains frameIndex's numbering scheme and where to obtain it, and points to list_test_blocks for block/run IDs, but testId and runId are never explained and the relationship between them is left implicit.

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 ('Read one screen and its metrics') and names the input that selects it ('frameIndex from navigation results'), which cleanly separates it from list-style siblings like list_screen_metrics. It does not explicitly distinguish itself from get_frame_details, so an agent must infer the boundary.

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 useful sourcing guidance: frameIndex comes from navigation results, and block/run IDs come from list_test_blocks, with omission falling back to documented defaults. No explicit when-not conditions or direct sibling comparisons (e.g., vs. get_frame_details or list_screen_metrics), so it stops just short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world behavior, so the safety profile is covered. The description adds the useful detail that legacy tests are supported and that omission falls back to defaults, but says nothing about volume, pagination, or result shape beyond what the output schema provides.

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 tightly written sentences with the core purpose front-loaded and no filler. Every clause carries information, though the final 'Legacy tests also supported' fragment is slightly abrupt.

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 and rich annotations, the description only needs to add purpose and sourcing context, which it largely does by naming the ID source and legacy support. The unresolved overlap with get_insight/list_insights 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 description coverage is only 33%, with runId and testId having no schema descriptions, so the description is expected to compensate. It partially does by explaining that IDs come from list_test_blocks and target a block/run, but it never clarifies the required testId or the 24-hex ObjectId format, leaving gaps.

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 ('Read positive findings supported by participant evidence'), which is more precise than a tautology of the name. It does not, however, differentiate itself from close siblings like get_insight or list_insights, so an agent still has to infer the boundary.

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 partial routing guidance by pointing to list_test_blocks as the source of IDs and noting that omission uses documented defaults. It offers no explicit when-to-use-vs-alternative guidance against the many get_* sibling tools, leaving selection largely 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?

Annotations already cover read-only/idempotent safety, and the description adds genuinely new behavior: up to three image previews of affected frames and the caveat that images may be unavailable. It also notes legacy test support, which is not derivable from the schema.

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

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

Four tight sentences that front-load the read operation and the ID dependency, then add the image-preview caveat. No filler, though the 'Legacy tests also supported' clause is appended somewhat abruptly.

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 still flags the unreliable image previews. The main gap is that testId, a required parameter, is never addressed.

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

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

Schema coverage is only 25%, so the description must compensate. It explains scId's source, ties runId/blockId to list_test_blocks, and covers blockId omission semantics, but the required testId is never explained in the description and runId's role is only implied.

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 ('accessibility criterion and its evidence'), and ties the scId to list_success_criteria. It does not explicitly contrast itself with nearby siblings like get_insight or list_success_criteria, but the resource 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?

Explicitly routes the agent to list_success_criteria for scId and list_test_blocks for block/run targeting, and notes that omission falls back to documented defaults. No when-not-to-use guidance, but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful scope context beyond that: what the payload contains versus what it deliberately omits (findings, screenshots, session data), which prevents mis-expectation about return content.

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

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

Two sentences, zero filler. The primary purpose and the returned-field list come first, and the exclusion/routing clause follows in the same breath.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with a full annotation set and an output schema present, the definition covers everything the agent needs: purpose, id source, field inventory, and explicit boundaries against sibling result tools. Nothing material is missing.

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

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

Schema description coverage is 0% and there is a single required param, so the description must carry the load. It does add meaning beyond the schema by giving the parameter's provenance ('from list_tests'), which tells the agent how to obtain a valid value; the 24-hex format is already self-documenting via the schema pattern.

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 ('Read metadata for one accessible test') and enumerates the exact fields returned (title, goal, status, type, source, creation date, version, result flag, Uxia link). This distinguishes it from siblings like get_test_definition, get_test_progress and show_evidence 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?

Explicitly names the upstream source for the required id ('testId from list_tests') and states the exclusion boundary plus the alternative: 'Does not return findings, screenshots or session data; use result tools for those.' An agent knows both when to call it and when to route elsewhere.

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

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

The annotations already declare this as read-only, idempotent, non-destructive, and closed-world. The description adds useful content-level behavior: it includes ordered blocks and audience while excluding credential secrets, which tells the agent what data is safe to expect and what is omitted.

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

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

The description is two compact sentences with no wasted words. The purpose and inclusion/exclusion notes are front-loaded and easy to parse.

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 the read-only annotations and the presence of an output schema, the description covers the important selection and content context well: when to use it and what the returned definition includes or excludes. The main remaining gap is the 0% input-schema description coverage for testId, which the description does not compensate for.

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 sole required parameter, testId. The description never mentions testId, its expected format, or how to obtain it, so it adds no meaning beyond the raw schema pattern.

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 read action and enumerates the test definition's contents: current draft, revision, validation, editability, ordered blocks, and audience. It is clear what the tool retrieves, though it does not explicitly contrast itself with siblings like get_test or list_test_blocks.

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?

"Read ... before editing" gives a clear usage context: this tool is for preparing an edit. It does not name alternatives or state when not to use it, but the intended moment of use is explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful behavioral context (defaults on omission, legacy-test support), but nothing about auth requirements or pagination. Adequate add-on over the annotations.

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

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

Two compact sentences, front-loaded with the core purpose and followed by targeting guidance. No filler sentences or restated 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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. Still, with four parameters at 25% schema coverage, the description leaves the testId parameter and required-parameter coupling under-specified for a tool that demands both testId and name.

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

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

Schema coverage is only 25% (only blockId is documented), so the description must compensate. It explains the name parameter ('tester name from the results') and the block/run targeting role of blockId/runId, but leaves testId's role and the runId format undescribed.

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: 'Read a participant profile using a tester name.' An agent can distinguish it from get_test, get_test_definition, and get_test_report, though it never explicitly names those siblings as 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?

Gives implied guidance: 'Use IDs from list_test_blocks to target a block/run; omission uses the documented defaults' and notes legacy tests are supported. However it never says when to prefer this tool over get_human_session, get_transcript, or other read siblings, so the routing is only partially resolved.

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

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a behavioral default not in the annotations: omitting runId returns the latest run. It stops short of noting rate limits or the shape of the progress/credit data, but the output schema covers returns.

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, zero waste, and the core action is front-loaded ahead of the parameter default. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the description covers the default-run behavior. The remaining gap is that neither parameter format (the 24-hex pattern) nor testId's role is described, a minor omission for a simple two-parameter 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?

Schema description coverage is 0%, so the description carries the burden. It explains runId's behavior (omit → latest run) but says nothing about testId beyond it being required, leaving half the parameters relying on name inference alone. Partial compensation merits only a baseline 3.

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 scope (run status, progress, credit usage). It implicitly distinguishes itself from the sibling get_test by focusing on run progress/credit rather than test configuration, though it never names or contrasts that sibling 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?

'Omit runId for the latest run' gives clear operational guidance for one parameter, but there is no when-to-use-this-vs-alternatives guidance (e.g., get_test vs get_test_progress) and no prerequisites or exclusions 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds marginal context — the defaults on omission and 'Legacy tests also supported' — but discloses nothing about pagination or result volume beyond what the output schema would carry.

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?

Four tight sentences front-load the core action, then layer sourcing and defaults. No filler, though the final 'Legacy tests also supported' clause is a dangling fragment that could be integrated more cleanly.

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 annotations carry the safety profile, so the description's remaining burden is parameter sourcing and defaults — both addressed. The one notable gap is the failure to distinguish this tool from the non-test get_question_responses sibling.

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

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

Schema coverage is only 20% (just blockId documented), so the description must compensate and partially does: it sources testerName from list_test_questions and block/run IDs from list_test_blocks, and explains the omission default. However, 'exact ref' and the mandatory testId/runId relationship are not elaborated, leaving gaps for a low-coverage 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?

States a specific verb and resource ('Read typed participant answers for one Survey question') and pins scope with 'using its exact ref.' This is more precise than a generic read, but it never contrasts itself with the sibling get_question_responses, so sibling differentiation 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?

Gives clear conditional usage: testerName is optional and must be 'a real testerName returned by list_test_questions,' and block/run IDs come from list_test_blocks, with omission falling back to documented defaults. It names sibling tools for sourcing values but offers no exclusions or when-not guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real context beyond them: the report is a stale generated snapshot rather than fresh analysis, it does not require a blockId, and it prescribes handling of the available=false state.

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 purpose, then short declarative sentences covering scope, staleness, exclusions, and the failure path. No filler sentences; each clause adds distinct decision-relevant 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?

With an output schema present, return values need not be explained, and the description covers content, usage, staleness semantics, and the available=false fallback. Nothing an agent needs to call it correctly 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?

One parameter with 0% schema description coverage, so the description carries the burden. It clarifies the identifier semantics indirectly by stating a blockId is not required, but adds nothing about the testId format or validation beyond what the schema pattern shows.

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 ('Read the saved report for the whole test') and then enumerates the contents (introduction, study goals, task summaries, key findings, quotes, A/B comparison), which lets an agent distinguish it from sibling summary/insight tools without opening a 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?

Gives explicit when-to-use ('Use when asked about the report or its conclusions'), explicit when-not ('Does not generate or refresh a report'), and names the alternative behavior ('use evidence tools for analysis instead') for the no-report case.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: what the payload contains, that omitting IDs yields documented defaults, and that legacy tests are supported. It does not cover auth requirements or how runId/testId interact, which keeps it below a 5.

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-field list front-loaded and the targeting/omission rule following. Every clause carries information; nothing is padded. Slightly dense in the parenthetical definitions but not wasteful.

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, yet the description still names the key fields for selection purposes. For a read-only, idempotent, closed-world tool with three parameters, the description plus annotations plus output schema cover what an agent needs to call 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 coverage is 33%: only blockId carries a schema description, while runId and testId are pattern-only. The description partially compensates by explaining that block/run targeting uses IDs from list_test_blocks and that omission uses defaults, but it never clarifies the required testId or the relationship between runId and testId. Adequate but with clear gaps.

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+resource (get the current test setup) and enumerates exactly what is returned: title, task, scenario, and configured post-test questions. That field list distinguishes it from sibling readers like get_test, get_test_definition, and get_test_summary. It stops short of naming an alternative explicitly, so sibling differentiation is implied rather than stated.

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

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

It says to use IDs from list_test_blocks to target a block/run and that omission falls back to documented defaults, which is real usage context. However, it never says when to prefer this tool over get_test, get_test_definition, or get_test_summary, and gives no prerequisites or exclusions. Usage is implied rather than routed.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds genuinely new traits: bounded output ('top five findings'), graceful degradation ('missing, restricted or not-yet-ready sections are marked unavailable'), and a defined edge-case response for ambiguous block selection. It stops short of describing pagination or ordering, but the edge-case disclosure is substantive.

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

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

Three dense sentences with no filler; the payload enumeration is front-loaded and the negative constraint is last. It is compact for the amount of information conveyed, though 'strengths and navigation metrics' reads as a list dump rather than a prioritized statement.

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?

Because an output schema exists, return values needn't be spelled out, and annotations carry the safety profile, so the description's remaining job is scope plus edge cases — both covered. The only real gap is resolving the required testId versus the optional scoping IDs and the boundary against get_test_report.

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 three parameters, so the description carries the burden, and it only partially discharges it: it names runId and blockId as optional scoping inputs and hints that blockId may resolve ambiguously, but it says nothing about the required testId, nor about ID formats or why blockId takes an arbitrary string while the other two are 24-char hex.

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?

Starts with a specific verb ('Read') and a concrete resource ('usability-results overview'), then enumerates the payload (metadata, top five findings, optimization/satisfaction scores, strengths, navigation metrics). It differentiates itself from write siblings via 'Does not launch or modify tests,' but never contrasts itself with the near-neighbor get_test_report or get_test, so the reader must infer that this is the lighter-weight aggregate view.

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 how runId and blockId scope results, which implies usage, and the closing sentence excludes launching/modifying. However, it never states when an agent should pick this overview instead of the many sibling result tools (get_test_report, get_optimization_score, get_satisfaction_score, get_test_progress), so selection guidance 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond them: pagination semantics, that limits are measured in characters, legacy-test support, and the default behavior when block/run is omitted. The phrase "documented defaults" is slightly circular rather than stating the actual defaults.

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?

Five short, front-loaded sentences that lead with the core action before routing and pagination details. Efficient overall, though "omission uses the documented defaults" is vaguely worded filler rather than a concrete default value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. Combined with annotations and the routing/pagination guidance, the definition is nearly complete; the remaining gaps are the unexplained testId and the circular reference to "documented defaults" for block/run omission.

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

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

Schema description coverage is only 17%, so the description must compensate, and it does for most parameters: ref's source (list_transcripts), limit's unit (characters), offset as pagination, and blockId/runId sourced from list_test_blocks. Only testId lacks added meaning, and the limit bounds/max are left 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?

States a specific verb and resource ("Read a session transcript") and immediately scopes it to "by exact ref from list_transcripts," distinguishing it from the sibling list_transcripts and from get_test_question_responses. An agent knows exactly what this returns without opening the 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?

Explicitly routes the agent: post-test answers go to get_test_question_responses, refs come from list_transcripts, and block/run IDs come from list_test_blocks. It also states the pagination path (offset/limit) and that legacy tests are supported, covering both when-to-use and when-not-to-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?

Goes well beyond the annotations: discloses that credits are spent, that the definition gets locked, that cost changes invalidate approval, and gives explicit output-handling guidance (show the returned url link, never expose backend run/test IDs). The destructiveHint/openWorldHint annotations are corroborated and enriched rather than merely restated.

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?

Four tight sentences, action-front-loaded, with the cost/approval gate next and output guidance last. 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?

An output schema exists so return values needn't be documented, and the description still adds useful display guidance. The mutation and credit-spend semantics are covered; only the meaning of definitionRevision/testId 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 description coverage is 0%, so the description must carry param meaning. It does define maximumCharge as the approved cost amount, but testId and definitionRevision are left unexplained, so compensation is only partial.

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

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

States a specific verb+resource ('Launch the previewed revision and spend credits') and pins the scope to the previewed revision, which cleanly separates it from preview_test_launch. An agent knows exactly what this does without opening the 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?

Establishes the prerequisite flow by naming preview_test_launch as the source of the approved cost and warning that cost changes require new approval. It doesn't phrase an explicit 'do not call before previewing' exclusion, but the sequencing is clear enough to route the agent correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only that results include IDs and status, which is modest value beyond the structured fields; it says nothing about ordering, pagination behavior, or result volume.

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 key information front-loaded and no wasted words. It is terse to the point of under-specification, but nothing in it is padding.

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 list tool with a limit cap of 50, a query string, and a status enum, the definition leaves all invocation behavior unspecified. Given the dense sibling list, more context is needed to select this tool correctly.

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

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

Schema description coverage is 0% for three parameters (limit, query, status), and the description compensates for none of them: it never mentions pagination limits, free-text query matching, or filtering by the status enum. 'with IDs and status' merely names a returned field and implies status is meaningful without explaining the filter.

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 ('List accessibility tests') and adds the returned fields (IDs and status). It does not distinguish this from the many sibling list_* tools (list_tests, list_transcripts, list_insights), so an agent must infer 'accessibility' is the differentiator.

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 versus list_tests or the other list_* siblings, no prerequisite conditions, and no exclusions. The description is a bare capability statement.

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

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description still adds genuine value by disclosing the 'up to 10' result cap and the workspace scoping, which the annotations do 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?

Two sentences, front-loaded with the what and the cap, followed by the three use cases. Every clause carries information and there is 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?

With an output schema present, the description need not explain return values, and it covers scope, cap, and intent. It leaves one small gap: it doesn't say whether more than 10 audiences exist can be retrieved, which matters given there is no pagination parameter.

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 are zero parameters, so the baseline is 4. The description doesn't need to document input semantics, and it correctly implies the tool takes no filtering 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 gives a specific verb (List), resource (audiences), and scope (caller's Uxia workspace), plus a concrete cap of 10. An agent can immediately tell this apart from create_audience and the other list_* 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?

It lays out three concrete when-to-use scenarios: discovery before creation, id-references in other actions, and summarizing targeting setup. It stops short of naming a specific alternative tool or any when-not-to-use condition, so it falls just shy of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that omission falls back to documented defaults and that legacy tests are supported, which is useful context, but it says nothing about result size limits, pagination, or error behavior beyond what the annotations and schema already convey.

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

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

Two tight sentences with the core purpose front-loaded ahead of the targeting guidance; nothing is padded. The trailing fragment 'Legacy tests also supported' is slightly disjointed but still earns its place by flagging a compatibility case.

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 obliged to explain return values, and the annotations cover the safety profile. Still, for a 4-parameter tool with 25% schema coverage, the required testId and the limit parameter's semantics are unexplained anywhere, leaving the definition adequate but with visible gaps.

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

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

Schema description coverage is only 25% (only blockId is documented), so the description must carry weight: it explains block/run targeting via list_test_blocks IDs and the omit-for-defaults behavior, which covers blockId and partially runId. It never explains the required testId or what limit controls (default 8, max 20), so the low-coverage gap is only partially closed.

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 ('List screens where participants stopped progressing') and even describes the ranking and included metrics, so the purpose is unambiguous. It does not explicitly differentiate itself from near-neighbors such as list_insights, list_paths, or list_screen_metrics, 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?

'Use IDs from list_test_blocks to target a block/run; omission uses the documented defaults' gives real prerequisite guidance and points at the sibling that supplies IDs. However, there is no statement of when to prefer this tool over list_insights/list_paths, nor any exclusion or precondition beyond that, leaving usage 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?

Annotations already declare readOnly, idempotent, non-open-world, non-destructive behavior, so safety is covered. The description usefully adds that results carry refs and completion status and that omissions fall back to defaults, but says nothing about pagination, result caps, or scope breadth.

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 short sentences with the resource and returned scope front-loaded and no filler. Tightly written, though the trailing 'Legacy tests also supported' is a dangling caveat without any actionable detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, and annotations carry the safety profile. However, with two of three parameters undocumented and a 'legacy tests' caveat left unexplained, the definition is only minimally complete for a tool whose targeting logic is its main complexity.

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

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

Schema description coverage is only 33%: blockId is documented in the schema while testId and runId carry only regex patterns. The description vaguely gestures at 'IDs from list_test_blocks to target a block/run' but does not explain the required testId format, the runId relationship, or the difference between omitting blockId vs runId, 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 (List) and resource (human sessions) and adds the returned scope: exact refs and completion status. It distinguishes itself from the singular get_human_session only implicitly, so it is clear but not fully sibling-differentiated.

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 partial routing guidance: 'Use IDs from list_test_blocks to target a block/run' and notes omission uses documented defaults. It never states when to choose this over get_human_session or how it relates to list_transcripts, so usage is implied rather than explicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior. The description adds important behavioral context: limit is global when blockId is omitted, returned block/run IDs should be kept with evidence, and legacy tests are supported. There is no contradiction with annotations.

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

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

Front-loads purpose, then layers usage constraints and resolver guidance. It is dense but every sentence provides an actionable instruction, aside from the brief legacy-tests note which remains 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?

Output schema exists, so return values need not be explained, and annotations cover safety. However, for an 8-parameter tool with low schema description coverage, omitting required testId semantics and sortBy behavior leaves meaningful gaps.

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

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

Schema description coverage is only 13%, so the description must carry the load. It explains blockId omission/supply, global limit behavior, severity/category filter usage, and testerName scope, but does not explain sortBy (severity vs relevance), the required testId meaning, or the runId format.

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 'findings/insights', plus the ranking basis 'by severity'. It distinguishes from the singular sibling get_insight by describing a multi-item listing over AI task blocks.

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 explicit when-to-use rules: omit blockId for all AI blocks, supply blockId for one task, one call includes all severities, do not iterate per severity/category, and use filters only when requested. It also names list_transcripts and get_human_session as alternatives for name resolution.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and non-destructive, so safety is covered. The description does add real conceptual context by defining what a "loop" is and that it signals backtracking/possible confusion, which helps interpret the output; it does not add permission, rate, or pagination behavior beyond that.

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

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

Three sentences, purpose front-loaded, definitions placed before the ID-sourcing instruction. It is tight overall, though the vague phrase "the documented defaults" gestures at the schema rather than stating the fallback directly.

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 required testId plus the neutral safety profile are handled by structured fields. Still, for a 4-parameter analytical tool with low schema coverage, the description omits the default result count (8, max 20) and gives no cue on how this lens differs from its analytics siblings.

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

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

Schema description coverage is only 25% (blockId is the lone documented parameter). The description partially compensates by pointing to list_test_blocks for the targeting IDs and noting that omission falls back to "documented defaults," but it says nothing about limit's range/meaning or what testId/runId require beyond their regex patterns.

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?

It states a specific verb and resource ("List screens participants returned to after leaving") and even defines the term "revisit," so the agent knows exactly what data it gets. It does not distinguish this from close analytical siblings like list_paths, list_dropoff_points, or list_screen_metrics, which is the only thing keeping it from 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?

"Use IDs from list_test_blocks to target a block/run" gives a concrete routing hint toward a sibling for obtaining valid IDs, and it notes legacy tests are supported. However, there is no guidance on when to choose this tool over the nearby path/dropoff/loop-adjacent analytics tools, so usage is implied rather than delimited.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful context beyond that (participant counts are returned, defaults apply on omission, legacy tests are supported), but it says nothing about pagination behavior despite a limit default of 8.

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 short sentences with the core purpose front-loaded and no filler. Every sentence carries some signal, though the 'documented defaults' phrasing is vague enough to weaken the second sentence.

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 needn't be explained. But for a 5-parameter listing tool with low schema coverage, the description omits pagination/limit semantics and status filtering meaning, leaving gaps an agent needs to call it precisely.

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

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

Schema description coverage is only 20%, so the description must carry parameter meaning, and it largely does not. It gestures at block/run targeting and default behavior, but limit, status (enum success/drop-off/any), and testId are left unexplained, and the run/block semantics are asserted more than clarified.

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

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

States a specific verb and resource ('List navigation paths and participant counts'), which is more informative than a generic list tool. It partially differentiates from siblings by naming list_test_blocks as the ID source, though it does not distinguish itself from other list_* tools like list_dropoff_points or list_insights.

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

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

Provides workflow guidance by telling the agent to source IDs from list_test_blocks and that omission uses documented defaults. However, it gives no when-to-use vs when-not guidance or alternatives among the many sibling listing tools, leaving selection largely 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and non-openWorld, so the safety profile is covered. The description adds default sort ordering and legacy-test support, which is useful, but says nothing about pagination, result caps, or how metrics are aggregated, so it slightly exceeds the annotation bar without being rich.

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

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

Four compact sentences, front-loaded with what is returned and then the two knobs (sortBy, block/run targeting). No filler, though the closing 'Legacy tests also supported' is terse enough to be slightly ambiguous.

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 description covers the core selection controls plus ID provenance. The unaddressed limit parameter and the vague 'documented defaults' phrasing keep it from being fully complete.

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