MCP Server By TestMu AI

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds that the app must be local and tunneled, but says nothing about whether the analysis is synchronous, whether a status poll (e.g. checkAppProcessingStatus) is needed, or what triggers the scan.

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

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

A single tight sentence with the key scoping qualifier ('locally running', 'via tunnel') front-loaded. Nothing is wasted, though it is arguably too terse to carry the workflow context an agent needs.

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

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

With no output schema, the description should clarify what the call yields (e.g. a scan/report id) and whether further steps are required. It leaves the completion path implicit despite the presence of related siblings like checkAppProcessingStatus and getAccessibilityScanReport.

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

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

Schema description coverage is 100% and all three parameters (port, tunnelId, tunnelName) are self-explanatory and documented in the schema. The description adds no extra meaning beyond what the schema provides, which is the expected baseline.

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 (Analyzes), the resource (a locally running app), the goal (accessibility), and the transport (via LambdaTest tunnel). It is clear about what it does, though it does not explicitly contrast itself with nearby siblings such as buildLocalAppForAnalysis or getAccessibilityReport.

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

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

The phrase 'locally running app ... via LambdaTest tunnel' implies the preconditions (an app served on a local port reachable through a tunnel), but there is no explicit when-to-use vs when-not guidance or named alternative for already-uploaded apps.

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 (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds useful behavioral context: it discloses that the tool makes a deep recursive traversal of all tasks and stages and returns an aggregated structured report rather than a single resource, implying heavier cost/latency than the granular siblings.

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

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

Two sentences, no waste. The core capability is front-loaded in the first sentence and the second sentence supplies the routing examples, so the reader gets purpose before use cases.

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 no output schema, the description compensates by naming what the report contains (test results, per-scenario logs, pass/fail statistics). Combined with annotations covering safety and a fully documented single required parameter, an agent has everything needed to call this 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?

There is a single parameter with 100% schema description coverage, so the schema already documents jobId fully. The description adds only marginal meaning (that the id is the job to analyze), which is the expected baseline when the schema does the heavy lifting.

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 (analyze/fetch/traverse) and resource (HyperExecute job) and enumerates exactly what the deep traversal covers: job info, sessions, tasks → scenario stages → console logs, plus the returned report contents. This scope description makes it distinguishable from the granular per-resource siblings like getHyperExecuteJobInfo or getHyperExecuteStageLogs.

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 gives use cases with two concrete example questions ('which tests failed and why', 'show me the console logs for job X'), which tells the agent when to pick this aggregate tool. It stops short of naming alternatives such as answerHyperExecuteQuery or the individual getter tools, so there is no 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety and closed-domain profile is covered. The description adds that answers are sourced from documentation (not live job state), which is useful, but it says nothing about grounding, citation behavior, or answer completeness.

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

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

A single front-loaded sentence that spends its words on the tool's purpose and mechanism with no filler. The enumerated topics are slightly list-heavy but each earns its place by sketching the question domain.

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 no output schema and a trivial input schema, the description covers the essentials: what it answers and that it searches documentation. It stops short of describing the answer format, source citations, or limitations, which would help an agent know what to expect back.

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

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

There is a single parameter with 100% schema description coverage, so the schema already defines 'query' as a question about HyperExecute. The description adds no syntax, phrasing, or scope detail beyond that, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('answers questions about HyperExecute features...') and names the mechanism ('searching through documentation'). It clearly delineates the topical scope, though it does not explicitly distinguish itself from any named sibling tool.

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

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

Usage is implied by the topical scope (HyperExecute questions), but there is no explicit when-to-use/when-not guidance or pointer to alternatives such as analyzeHyperExecuteJob for job-specific data rather than general documentation questions.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the pagination-object caveat versus result_set.total, and the fact that logType 'instrumentation' returns XCUI and Espresso logs. It omits auth constraints and rate limits, so it is strong but not exhaustive.

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 purpose, then lists capabilities and caveats in a compact, information-dense paragraph. Every sentence earns its place: the resource enumeration, platform applicability, pagination warning, and sibling routing all add distinct value with no filler.

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

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

Given 14 parameters, a multi-action dispatcher design, and no output schema, the description covers the essential call semantics: resource/action combinations, platform scope, logType behavior, and pagination handling. It does not describe return shapes for get/list operations or error behavior, but for a read-only query tool with rich schema coverage this is nearly complete.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including required combinations and logType enums. The description reinforces useful relational semantics—every resource/action combination works on web or app, and logs require a logType—but adds little syntax or format detail beyond what the schema provides. 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?

States a specific verb and resource family: 'Read-only query of LambdaTest automation resources', then enumerates the exact reads it covers (builds, sessions, tests, logs). It distinguishes itself from mutation siblings by explicitly naming updateBuild, stopBuild, and deleteBuild, so an agent can tell it apart without inspecting schemas.

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

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

Provides clear when-to-use context: read-only automation queries across web and app, with explicit exclusions for build mutations (updateBuild, stopBuild, deleteBuild). However, it does not distinguish itself from specialized log-retrieval siblings like getAutomationTestCommandLogs or getSessionV2CommandLogs, leaving overlap unresolved.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: it performs no build/run/scan side effects itself, and it guarantees the access key is never emitted — a meaningful security disclosure for a tool whose output is instructions containing tunnel setup steps.

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

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

Two sentences, no filler; the core purpose is front-loaded and the second sentence adds only the two constraints that matter (no execution, no access key). 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 no output schema, the description must convey what is returned, and it does — step-by-step build/serve/tunnel instructions. It also covers the relationship to the downstream scan tool and the scope limits, which is everything an agent needs to call and use it correctly.

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

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

Schema description coverage is 100% and all three parameters (port, codebasePath, customBuildCommand) carry their own descriptions, so the schema does the heavy lifting. The description adds no parameter-level detail such as port/range constraints or how customBuildCommand interacts with the default build — 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?

States a specific verb and output ('Returns step-by-step instructions to build and serve a local web app and open a LambdaTest tunnel'), and explicitly disclaims doing the building, running or scanning itself. It also names the sibling tool (analyzeAppViaTunnel) that consumes the result, so it is distinguishable from siblings 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?

The description makes the workflow ordering explicit: this tool produces instructions so accessibility 'can then be scanned with analyzeAppViaTunnel', which tells the agent where it sits relative to that sibling. It doesn't state when to prefer this over, say, analyzeHyperExecuteJob or direct uploads, but the sequencing context is clear and actionable.

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?

Adds substantial behavior beyond the annotations: the API exposes no read-only status call, so this call starts or refreshes processing, mutating the app's last-updated timestamp, and an unknown app id returns an error. This directly resolves the trap of reading a 'check' tool as a safe read (annotations do correctly declare readOnlyHint=false).

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, no redundancy, and the mutated-state warning is front-and-center right after the purpose. Every sentence carries distinct information (readiness semantics, mutation side effect, error behavior).

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 no output schema, the description should ideally hint at what the returned status looks like (e.g., pending/processed/failed and per-feature readiness), which is the one gap for a 'check status' tool. Otherwise it covers purpose, side effects, and error behavior adequately for a 4-param mutation-adjacent 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 100%, so the schema already documents all four parameters, making 3 the baseline. The description earns above baseline by explaining that the boolean flags correspond to 'the requested features' whose processing is started/refreshed, tying the flags to an observable side effect rather than just 'check X support'.

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 ('check whether an uploaded app has been processed') and scopes it to real devices and the features it gates (image injection, network logs, screenshot unblock). It cannot be confused with listUploadedApps or deleteUploadedApps, though it never names a sibling tool to route away from.

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 implied usage is clear enough — call it to confirm an uploaded app is ready before relying on injection/network-log/screenshot-unblock features. However, it never states when NOT to call it, names no alternative, and gives no precondition such as 'requires the app to be uploaded first'.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds real value beyond that: it discloses cascading deletion of associated test results and irreversibility, which the annotations do not express.

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

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

Two terse sentences with the destructive scope front-loaded and the irreversibility warning immediately after. Every word earns its place.

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

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

For a one-parameter mutation tool with full annotation coverage and no output schema, the description covers the essential unknowns: permanence and cascade scope. Missing only edge-case context such as permission requirements or behavior when the build does not exist.

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?

Single buildId parameter with 100% schema description coverage, so the baseline is 3. The description adds no format, type, or sourcing detail for buildId beyond what the schema already states.

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 (permanently deletes) and resource (LambdaTest web automation build plus its test results). This clearly separates it from stopBuild and updateBuild in the sibling list, which act on the same resource with different semantics.

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

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

No guidance on when to delete versus stop (stopBuild) or update (updateBuild) a build, and no mention of prerequisites or authorization. The 'Cannot be undone' warning signals severity but is not a usage routing rule.

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 destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the path-based identity mechanism and does not discuss irreversibility, required permissions, or what happens to a file still referenced by a pre-run/post-run configuration.

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, appropriately sized for a simple delete operation.

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 destructive tool the description covers the bare minimum: what is deleted and by what key. With no output schema and zero required parameters, it omits return/confirmation behavior and any caveat about the duplicate path parameter, so it is adequate but thin.

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

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

Schema coverage is 100%, so the baseline is 3. However, the schema exposes two near-identical parameters (filePath and file_path) and the description does not clarify which one is authoritative or that the value must originate from uploadPrerunFile, leaving a real ambiguity unaddressed.

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

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

States a specific verb ('Delete') and resource ('an uploaded prerun file') plus the identifier mechanism ('stored LambdaTest file path'). It is clear what the tool does, but it does not distinguish itself from similar siblings such as deleteUserFile or deleteUploadedApps.

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

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

No when-to-use guidance, no preconditions, and no mention of alternatives despite several delete-oriented siblings (deleteUserFile, deleteUploadedApps, deleteBuild, deleteSession) that an agent must choose between. The agent is left to infer the distinction entirely.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the destructive nature is known. 'Permanently' reinforces irreversibility, which is a small addition, but nothing is said about permissions, side effects, or whether the parent job is affected.

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

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

One front-loaded sentence naming verb, resource, qualifier and identifier. Zero waste, no repetition of the 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?

For a one-parameter destructive tool whose annotations already cover the safety profile and with no output schema, the description is essentially sufficient. Only the sibling-choosing guidance is missing.

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

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

Schema description coverage is 100% and the single parameter has its own description ('The session ID to delete'), so the schema carries the semantics. The description adds no format or sourcing detail beyond it; baseline 3 applies.

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 (permanently delete), resource (automation test session), and scope (by session ID) on LambdaTest. It does not explicitly name the near-sibling stopSession, but 'permanently' implicitly distinguishes it from a mere stop.

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

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

Usage is implied: delete a session you no longer need. However, it never states when to prefer stopSession over deleteSession, or any prerequisites (ownership, active vs completed session). No explicit when/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 declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered externally. The description confirms deletion but adds no depth beyond that — no mention of irreversibility, whether apps in active use are blocked, or any confirmation requirement.

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

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

A single front-loaded sentence with zero filler; the verb, resource, and key are all in the first clause.

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

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

For a one-parameter delete operation whose safety profile is carried by annotations, the description is largely sufficient and no output schema is needed. It stops short of noting whether deletion is permanent or has side effects on linked test runs, which would round it out.

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

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

Schema coverage is 100% with the single appIds parameter fully documented as an array with minItems 1. The description's 'by their app IDs' and 'one or more' merely restate the schema, adding no format or constraint detail beyond it. Baseline 3 applies.

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 (delete), resource (uploaded apps), scope (one or more), and the key used (app IDs). An agent can distinguish this from sibling deletion tools like deleteBuild, deleteSession, and deleteUserFile 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?

The description implies usage through 'delete one or more uploaded apps' but never states when to use this over listUploadedApps or the upload tools, nor any preconditions. No when/when-not guidance or named alternatives are present.

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 destructiveHint=true and readOnlyHint=false, so the agent knows this is an irreversible write; the description correctly does not contradict that. However it adds almost nothing on top of the annotations: no statement that deletion is permanent, no auth/permission requirement, no behavior when the path does not exist. With annotations carrying the safety profile, this is a minimum-viable 3.

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

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

A single front-loaded sentence with the verb and the identifying key in the first few words, and zero filler or restatement of the 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?

For a destructive delete with no output schema, the description covers the essential purpose but leaves the notable ambiguity in the schema unresolved: filePath and file_path are both optional and identically described, and the description does not say which one is canonical or whether either is required. It is adequate but not 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 100%, so both parameters are already documented as 'Key of the stored user file, as uploadUserFile returns it'. The description repeats the same idea ('by stored LambdaTest file path') without adding syntax, format, or precedence guidance, so the baseline 3 applies.

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 (Delete) and resource (an uploaded user file) qualified by an identifier source (stored LambdaTest file path), which is enough to separate it from deleteBuild, deleteSession, and deletePrerunFile. It does not explicitly name those siblings or state what distinguishes a 'user file' from a 'prerun file', so it stops short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the neighboring delete tools (deletePrerunFile, deleteUploadedApps) that an agent must choose between. The only implicit cue is the word 'uploaded', which does not constitute 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds genuinely useful behavior beyond them: it returns a URL rather than bytes, and that URL must be fetched with LambdaTest credentials, which is critical for correct downstream use.

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: what it returns, the prerequisites, and the key behavioral caveat. Nothing is redundant and the most important fact (URL, not bytes) is front-loaded.

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

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

There is no output schema, so the description carries the return-value burden and does so by naming the URL plus size/status metadata. Auth requirements, the required input source, and optional scoping are all covered for a simple three-parameter 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 100%, so all three parameters are already documented, including that artefactName comes from getHyperExecuteJobArtifacts. The description restates that origin but adds no new format, validation, or scoping semantics. Baseline 3 applies when the schema does the heavy lifting.

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 ('Get an authenticated download URL ... for a specific HyperExecute job artifact') and clarifies the return contract ('URL to fetch ... rather than the raw file bytes'). This cleanly separates it from getHyperExecuteJobArtifacts (which lists names) and getJobArtifactDetail.

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 names the prerequisite source for artefactName ('from getHyperExecuteJobArtifacts') and explains when to use the optional taskId scope. It gives clear context for use but does not state explicit exclusions or contrast with the closest sibling beyond that prerequisite mention.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds modest behavioral context: smart framework defaults, input validation with security checks, and which fields are optional. It does not clarify whether output is returned as text or written to a file, so it only partly exceeds the annotation baseline.

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?

Purpose and required fields are front-loaded, and the bulleted framework list is scannable. There is some redundancy (appTesting is explained in the features list and again in a closing paragraph) and the feature bullets lean promotional, but overall it is well organized and appropriately sized for a 9-parameter tool.

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

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

For a complex, deeply nested tool with no output schema, the description covers required inputs, supported frameworks, and the mobile-vs-web branch well. Its one notable gap is the return value – it never says whether the tool returns YAML text, a file path, or a validated object – which matters since there is no output schema to fill that role.

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

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

Schema description coverage is 100%, so the schema already documents every parameter and its nested fields. The description restates the required fields (project, testing) and the mobile/web distinction, which mirrors rather than extends the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Generates a HyperExecute YAML configuration for running tests on LambdaTest's HyperExecute platform'), which is unambiguous and distinct from every sibling (none of which produce configuration artifacts). It also names the concrete required fields, so an agent immediately knows the minimum viable call.

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

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

The description gives clear conditional guidance: mobile frameworks 'ONLY use appTesting for these', and web automation 'leaves it out'. It also flags which fields are required vs optional. However, it never states when to prefer this tool over alternatives or any preconditions (e.g., that this only generates config, not runs tests), so it stops short of explicit when/when-not routing.

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

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

Annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) signal a non-read compute action with external effects; the description adds the crucial cost implication ("costs another run"), the auth distinction between a11yReportLink (needs login) and shareableLink (public, scan-only), and the pagination completion contract. This is substantial context the structured fields do not 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?

Purpose is front-loaded, then output shape, then pagination workflow, then link caveats. Despite its length, every sentence carries operational information (offset alignment, re-scan cost, link auth) that an agent needs; nothing 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?

There is no output schema, so the description bears full responsibility for return-value semantics, and it delivers: it names issueDetails sub-fields (allIssues, rules, pages, failedRules, pagination), explains severity ordering and per-element howToFix/criteria, and defines the pagination termination condition. An agent has everything needed to call and consume 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?

With 100% schema coverage the baseline is 3, but the description adds real meaning on top: it clarifies the urls/testId exclusivity, the testId+offset pairing for paging, and that filters must stay constant across pages. It leaves some params (severity, pageUrl, include_rules) to the schema, which documents them adequately.

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 ("Runs an accessibility scan on the given URLs") and immediately distinguishes its two operating modes: starting a scan via urls versus re-reading via testId. An agent understands both what it does and the dual nature of the tool 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 states the exactly-one-of constraint between urls and testId, explains when to use each, and proactively warns that re-passing urls to page starts a new scan, costs another run, and yields misaligned offsets. This is precisely the conditional guidance that prevents incorrect invocation.

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, non-destructive, closed-world), and the description usefully adds operational context: it is computed from the automation test list, capped at 5000 tests per call, yet the total is always exact, and pass rate is defined to match the Insights page. This clarifies how the numbers are derived rather than just repeating annotation hints.

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

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

A single front-loaded sentence that opens with the verb and then lists metrics and grouping options compactly. Dense but every clause carries information; no filler.

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

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

No output schema exists, so the description carries the burden of explaining returns, and it does so thoroughly by naming each aggregated metric and the possible grouping dimensions. Minor gap: it does not describe the shape of the returned records per group, but otherwise complete for a read-only analytics 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 coverage is 100% and the parameter descriptions already document formats, defaults, and the 59-day retention limit for fromDate. The description adds no parameter-level detail beyond restating the date-range grouping, so the baseline of 3 applies.

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 ('Summarises web automation test results') and enumerates the exact metrics produced (total, passed, failed, pass rates, avg duration, distinct builds) plus the group-by dimensions. This makes it clearly distinguishable from siblings such as getTestTrends, getFlakyTests, and getAnalyticsErrors 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?

The date-range scope and aggregate nature imply when the tool applies, but there is no explicit when-to-use versus alternatives guidance and no mention of getTestTrends or getAnalyticsErrors as related options. Usage is left 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 cover the safety profile (readOnly, non-destructive, non-open-world), so the description's job is to add context — and it does: the ~7-day window for failure categories and the fact older failures fall back to 'uncategorised' is a real, non-obvious data caveat. It stops short of noting ordering, latency, or empty-result behaviour.

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 core purpose and return shape are front-loaded, and the second sentence is a genuine caveat that earns its place rather than 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?

With no output schema, the description carries the burden of describing returns and does so — counts by failure category and status, plus the failing tests with build and environment. Combined with the fully documented input schema and safety annotations, an agent has everything needed to call this 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 100%, with limit, fromDate and toDate all fully documented including defaults and the 59-day bound. The description only restates 'date range' generically and adds no format or boundary detail beyond the schema, so the baseline 3 applies.

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 (summarises) and a tightly scoped resource (failed and errored web automation tests) plus the exact breakdowns returned, which separates it from broad analytics tools. However, it never names the neighbouring tools (getAnalyticsData, getFlakyTests, getTestTrends), so an agent must infer the distinction from scope alone.

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

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

Usage is implied rather than stated: the 'date range' framing and the failure-only scope let an agent infer it is for troubleshooting recent failures. There is no explicit when-to-use, no when-not-to-use, and no pointer to alternatives such as getTestTrends for pass/fail trends or getFlakyTests for intermittency.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description. The description adds the mobile-platform limitation, which is real context, but says nothing about pagination, log retention windows, truncation, or what the returned logs look like. Useful but thin beyond 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 short sentences, zero filler, with the core purpose front-loaded and the platform caveat immediately after. Nothing could be removed without losing information.

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

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

For a two-parameter read-only tool this is close to adequate, but there is no output schema, so the description is the only place the return shape could be described (log entries, ordering, volume). It also omits any sibling routing for the four near-identical log tools, leaving the agent to guess.

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

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

Schema description coverage is 100%, so both testId and platform are already documented in the schema, including the enum note that 'app' is unsupported. The description restates the mobile restriction but adds no new syntax or format guidance, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Fetches Browser Console logs for a specific automation test.' That distinguishes it by log type from siblings like getAutomationTestCommandLogs and getAutomationTestNetworkLogs, though those alternatives are never named. It is clear on its own but leaves the agent to infer the sibling boundaries.

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 one useful exclusion ('Not available for mobile app automation tests'), which tells the agent when this tool does not apply. However, it never states when to reach for this tool versus the command/network/Selenium log siblings, so the positive selection condition 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description contributes nothing beyond that: no mention of pagination behavior, log volume/ordering, or output shape. It neither contradicts nor enriches 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?

A single short sentence with no waste and the key resource front-loaded. It is efficient, though arguably too terse for a tool sitting in a crowded log-retrieval family.

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 no output schema and four parameters, the description should carry the load on what command logs actually contain, pagination expectations, and how this differs from sibling log tools. None of that is present, leaving the definition under-specified for a 4-param, paged retrieval 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 100%, including a notably useful note that sessionId is required for the app platform and comes from listMobileSessions/getAutomationTestDetails. The description adds no parameter meaning of its own, so the schema-driven baseline of 3 applies.

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 (Fetches) and resource (command logs for a specific automation test), so the basic purpose is clear. However, it does not differentiate itself from near-identical siblings such as getSessionV2CommandLogs, getAutomationTestSeleniumLogs, getAutomationTestNetworkLogs, and getAutomationTestBrowserConsoleLogs, which an agent must choose between.

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

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

The description gives no when-to-use guidance, no exclusions, and no routing to alternatives. In a cluster of four-plus log-retrieval tools this is a real hazard, since nothing tells the agent why it would pick command logs over console/network/Selenium logs.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds no further behavior beyond 'fetches details' — no note on which fields come back, whether results are cached, or the platform-routing behavior. With annotations doing the heavy lifting, this is merely adequate.

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 verb and resource front-loaded and zero filler. Nothing to trim.

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

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

There is no output schema, so the description must at least hint at what 'details' contains — it does not. Given a crowded sibling namespace of test-fetching tools, the definition also fails to position this tool relative to them, leaving the agent under-informed for a two-required-parameter call.

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

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

Schema description coverage is 100% and the schema itself explains both testId and the platform enum's mobile-API effect. The description contributes only the vague phrase 'by ID', adding no meaning beyond the schema, so the baseline of 3 for high coverage applies.

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 ('Fetches detailed information about an automation test by ID'), which is clear enough to act on. However, it does not distinguish itself from the many nearby siblings that also fetch automation-test data (getAutomationTestCommandLogs, getAutomationTestNetworkLogs, getAutomationTestSeleniumLogs, getAutomationTestBrowserConsoleLogs) — those are log-specific, but the description never frames this tool as the general test-metadata lookup versus those.

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

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

No when-to-use guidance at all: nothing says whether this should be called before/after the log-fetching siblings or what prompts it. The only routing hint ('set to "app" to fetch details from the mobile API') is buried in the schema, not the description. An agent has to infer the whole call context.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond the annotations — no return format, log volume, or pagination behavior — so a baseline 3 is appropriate.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity comes at the cost of any usage or behavioral detail rather than being a model of informative 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?

For a simple read-only log fetch with a fully documented 3-parameter schema and no output schema, the annotations and schema carry most of the burden. The description still omits any usage context or output expectations, leaving it only minimally adequate.

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

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

Schema description coverage is 100%, and the schema itself documents testId, the platform enum, and the conditional sessionId requirement in detail. The description adds no parameter meaning beyond what the schema already provides, so the baseline 3 applies.

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

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

The description names a specific verb (fetches) and resource (network logs) scoped to a single automation test, which distinguishes it from the log siblings (browser console, command, Selenium logs) by resource type. It does not explicitly say how it differs from those siblings, 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?

There is no guidance on when to use this tool versus the other automation-test log tools, and no mention of prerequisites such as the app-platform sessionId requirement. The description leaves the agent to infer the selection criteria entirely.

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

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

Annotations already declare the safe read-only profile (readOnlyHint=true, destructiveHint=false). The description adds useful behavior — the three log categories and the fact that XCUI/Espresso are auto-detected — but says nothing about log size, truncation, or availability windows for a log-retrieval tool.

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

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

Two compact sentences with no filler, and the log-type mapping is front-loaded. Efficient, though the second sentence could be folded in without loss.

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 no output schema, the description carries the return-value burden and does identify what comes back (web/Appium/instrumentation logs). It is adequate for a three-parameter read tool, missing only edge details like empty-log or unavailable-session behavior.

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

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

Schema description coverage is 100%, including the important sessionId constraint (required for app platform, not the test ID) and the platform enum. The description adds no parameter guidance beyond the schema, so the baseline of 3 applies.

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?

Clear verb ("Fetches") plus a specific resource (Selenium/Appium/instrumentation logs) scoped to "a specific automation test". However, it does not distinguish itself from close siblings like getAutomationTestBrowserConsoleLogs, getAutomationTestCommandLogs, or getAutomationTestNetworkLogs, so the agent must infer which log family each tool returns.

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

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

Usage is implied (use it to get logs for one test), and the note about auto-detecting XCUI/Espresso gives some routing help. But there is no explicit when-to-use/when-not or named alternative versus the other getAutomationTest*Logs siblings.

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 the safe, read-only, closed-world profile. The description adds genuinely useful non-annotation context: flakiness is only computed for roughly the last 7 days, only flaky tests are returned, and the payload includes a scanned-test count with how many had flakiness computed. No auth or rate-limit detail, but the disclosure goes meaningfully beyond 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?

Three tight sentences with no filler; the what-it-returns content is front-loaded and the 7-day limitation is attached directly to the flakiness concept rather than buried at the end.

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?

No output schema exists, so the description carries the return-value burden and does so well, naming flake rate, build, environment, and the scanned count. It stops short of describing ordering or empty-result behavior, but for a zero-required-parameter read tool this is nearly complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description still adds value by explaining a constraint the schema hints at only partially: the 7-day flakiness computation window versus the 59-day serviceable range, which tells the agent results will be sparse or absent for older fromDate values.

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 (Lists) and a precise resource (tests marked flaky, i.e. passing/failing intermittently) scoped to a date range, and enumerates the returned fields (flake rate, build, environment). An agent can distinguish this from report/exception siblings like getTestTrends or postTestExceptions 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?

The date-range scope and the 'returns only flaky tests' framing imply when to reach for this tool, and the 7-day flakiness window is a useful caveat. However, no alternative tool is named and there is no explicit when-not guidance, so usage is only implied rather than directed.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the two-mode behavior (all artifacts vs categorized errors); it says nothing about result volume, pagination, or how large artifact sets are returned.

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

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

A single front-loaded sentence with zero filler. It is efficient, though bordering on under-specified for a tool with multiple retrieval modes and several sibling artifact tools.

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

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

For a simple read tool with annotations and no output schema, the description is minimally adequate. It does not define what 'categorized errors' contains or how this differs from downloadJobArtifact and getJobArtifactDetail, which is the main open question an agent would have.

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

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

Schema description coverage is 100%, and the schema already states that taskId is optional and drives categorized errors. The description restates this rather than adding format, constraints, or interaction details, so the baseline 3 applies.

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?

Clear verb (Retrieve) plus resource (artifacts / categorized errors) scoped to a HyperExecute job or task. However, it does not distinguish itself from close siblings like downloadJobArtifact or getJobArtifactDetail, so an agent cannot tell which artifact-retrieval tool to pick from the description alone.

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

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

Usage is only implied: passing taskId selects the 'categorized errors' mode while jobId alone returns all artifacts. There is no explicit when-to-use, no mention of alternatives such as downloadJobArtifact/getJobArtifactDetail, and no note on limits or size of results.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value by enumerating returned content (status, test results, progress), which matters because there is no output schema, but it omits auth requirements, result freshness, or behavior for an unknown/invalid jobId.

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

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

One sentence, front-loaded with the verb and the return content, with no filler. It is slightly generic in the 'Fetches and displays' opening but wastes nothing.

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

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

For a one-parameter read tool with annotations covering safety and no output schema, the description adequately conveys what the caller gets back. It falls short on sibling differentiation against the several other HyperExecute read tools and on any behavioral edge cases, leaving it minimum-viable.

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

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

There is a single parameter with 100% schema description coverage ('The ID of the HyperExecute job'), so the schema already carries the semantics and 3 is the baseline. The description only implies that jobId selects the job and adds no format or sourcing detail.

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

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

States a specific verb and resource ('Fetches and displays information about a HyperExecute job') and even names the content returned (status, test results, progress), which distinguishes it from artifact/log/session fetchers in the sibling list. It does not, however, differentiate itself from analyzeHyperExecuteJob or listHyperExecuteJobs, so an agent must still infer which HyperExecute read tool to pick.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as analyzeHyperExecuteJob or getHyperExecuteJobSessions. The agent gets a purpose but no routing signal.

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/destructiveHint=false, so the safety profile is covered. The description adds useful behavioral signals: output is live/streaming rather than a one-shot fetch, and the tool is explicitly undocumented and unstable. It does not describe stream termination, blocking behavior, or error handling, so it is only partially 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?

Two short sentences, front-loaded with the core action and immediately followed by the stability caveat. Nothing is wasted and no filler is present.

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 streaming tool this is somewhat thin: it does not explain how the stream is consumed or terminated, and there is no output schema to compensate. Annotations cover the safety profile and the single parameter is fully documented, so it is minimally adequate but leaves the streaming semantics under-specified.

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

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

Schema coverage is 100% and the single jobId parameter is documented as 'The running job ID' in the schema. The description adds no syntax, format, or constraint detail beyond what the schema already provides, so the baseline of 3 applies.

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 ('Stream live output') scoped to a 'running HyperExecute job'. The words 'live' and 'running' naturally distinguish it from siblings like getHyperExecuteJobInfo or getHyperExecuteStageLogs, though it stops short of explicitly naming those 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?

There is no when-to-use / when-not-to-use guidance, and no alternative is named. The only caveat, 'may change without notice,' is a stability warning rather than usage direction, so the agent must infer when a live stream is preferable to the batch log tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention of pagination via 'limit', result ordering, or whether sessions include live versus completed runs.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity reflects under-specification rather than disciplined conciseness.

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

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

For a simple two-parameter read tool with full annotation coverage and no output schema, the description is minimally adequate. It omits what a 'session' represents in this context and how results are scoped or ordered, which would help disambiguate it from the many adjacent HyperExecute readers.

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

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

Schema description coverage is 100%, so both jobId and the limit default of 10 are already documented in the schema. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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 clear verb ('Fetches and displays') plus a specific resource ('session information for a HyperExecute job'). The resource distinguishes it from job-level siblings like getHyperExecuteJobInfo and listHyperExecuteJobs, but the description does not explicitly contrast with them.

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

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

No guidance on when to use this tool versus sibling options such as getHyperExecuteJobInfo, getHyperExecuteStage, or getHyperExecuteJobLiveStream, and no stated preconditions or exclusions. The agent must infer the context from the name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is carried by structured data. The description adds the structural insight that stages are keyed by parent task, but says nothing about return shape, pagination, or error behavior when a stageId is not found.

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, all earning their place, with the core purpose front-loaded before the parameter guidance. No redundancy or filler.

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

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

For a read-only, two-parameter tool with full schema coverage and annotations covering safety, the description gives enough context to call it correctly. The only minor gap is that return content is undescribed, which is tolerable given there is no output schema and the resource is intuitive.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema by explaining WHY taskId is required (stages are keyed by their parent task) and by indicating the optional stageId narrows the result to a single stage.

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 (Retrieve) and resource (stages of a HyperExecute task) and clarifies the resource with examples (cache/prerun/scenario). An agent can distinguish it from getHyperExecuteTask and getHyperExecuteStageTasks, though it never names those siblings explicitly to reinforce the distinction.

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 guidance for the optional stageId ('Pass a stageId to return just that one stage') and explains when taskId is required ('Stages are keyed by their parent task'). It does not name alternative tools or a when-not-to-use case, so it stops short of a 5.

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

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

The annotations already establish this is a safe, read-only, non-destructive, closed-world operation, so the bar is lower. The description adds one genuinely new behavioral fact – the endpoint is undocumented and may change without notice – which is useful for an agent assessing reliability, but it omits anything about log scope, size, or pagination.

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, purpose front-loaded first, with a caveat second. Nothing is padded or redundant.

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

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

With no output schema and only one parameter, the definition is minimally serviceable, but it never indicates what the returned logs contain or how they are scoped (per stage, per run). The stability warning is a nice touch but does not compensate for the absent return expectations.

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

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

Schema coverage is 100% for the single stageId parameter, so the schema already carries the parameter documentation; there is only a minimal 'The stage ID' description. The tool description adds no format or sourcing detail beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb (Retrieve) and resource (logs for a HyperExecute stage), so the purpose is unambiguous. However, it does not distinguish itself from the closely related sibling getHyperExecuteTaskLogs or clarify its relationship to getHyperExecuteStage/getHyperExecuteStageTasks, leaving an agent to guess which log-retrieval tool applies at which granularity.

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

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

There is no guidance on when to use this tool versus the many sibling log and stage tools such as getHyperExecuteTaskLogs or getHyperExecuteJobArtifacts. The only added sentence concerns API stability, not selection criteria or prerequisites.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the notable 'UNDOCUMENTED - may change without notice' stability caveat, which is genuine behavioral information beyond annotations, but says nothing about return contents, pagination, or auth.

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 stability caveat appended. Front-loaded and zero waste.

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

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

For a simple single-parameter read tool with annotations covering safety and a fully described schema, the core need is met. However, no output schema exists and the description doesn't say what the tasks response contains, and it omits routing guidance among several HyperExecute task/stage 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 coverage is 100% with the single stageId parameter fully documented in the schema. The description adds no syntax or format detail, so baseline 3 applies when the schema carries the load.

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 (Retrieve) and resource (tasks for a HyperExecute stage), which clearly identifies the operation. It doesn't explicitly differentiate from close siblings like getHyperExecuteTask (singular) or getHyperExecuteStage, but the resource scope is clear enough.

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

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

No guidance on when to use this versus siblings such as getHyperExecuteTask or getHyperExecuteStage. The '(UNDOCUMENTED - may change without notice)' caveat is a warning, not usage direction.

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 is a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds a genuinely useful behavioral signal not present in the structured data: the tool is UNDOCUMENTED and may change without notice, warning the agent about stability risk.

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

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

One sentence states the action plus a compact parenthetical warning. Nothing is padded and the purpose is front-loaded.

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

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

For a single-parameter read tool with full schema coverage and annotations carrying the safety profile, the description is adequate. It stops short of describing the shape of returned details or how it differs from the several similar HyperExecute retrieval tools, leaving some ambiguity in a dense sibling set.

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

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

Schema description coverage is 100% with a single required taskId parameter documented in the schema. The description restates the task ID lookup without adding format, validation, or sourcing details, so it earns the 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 (Retrieve) and resource (HyperExecute task details) with the lookup key (task ID). It is reasonably distinguishable from siblings like getHyperExecuteJobInfo or getHyperExecuteStageTasks, but it never explicitly contrasts itself with those tools.

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

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

There is no guidance on when to use this tool versus the many sibling getHyperExecute* tools, and no prerequisites or context is given. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description does add one genuinely useful behavioral trait beyond the annotations: the '(UNDOCUMENTED - may change without notice)' caveat warns that output/behavior is unstable. It still says nothing about log availability timing, size, or format, so it is adequate but not rich.

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

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

Two short clauses with zero padding, and the core purpose is front-loaded ahead of the caveat. Nothing is repeated from the title or 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?

For a single-param read tool with full schema coverage and annotations, the description covers the essentials, and no output schema exists so return values need not be explained. It is still missing the sibling disambiguation and any note on when logs become available, which leaves a real gap in a crowded log-retrieval family.

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

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

There is a single parameter with 100% schema description coverage, so the schema already documents 'taskId'. The description adds no syntax, format, or sourcing detail (e.g. where to obtain a task ID) beyond what the schema provides, matching the baseline 3 for schema-covered params.

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 ('Retrieve logs for a HyperExecute task'), so the agent knows the operation. However, it does not distinguish itself from close siblings such as getHyperExecuteStageLogs or getHyperExecuteTask, and does not clarify whether logs are task-scoped or stage-scoped, which is the key ambiguity in this family.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g. whether the task must be completed or still running), and no routing to alternatives like getHyperExecuteStageLogs when stage-level logs are wanted. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no additional behavioral context such as authentication needs, pagination, or what happens for missing artifacts, but it also does not contradict 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?

A single clear sentence, front-loaded with the action and resource. Every word earns its place with no redundancy.

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

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

For a simple two-parameter read operation with complete schema and read-only annotations, the description is minimally sufficient. It does not explain what artifact details are returned, but no output schema exists to carry that burden either.

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

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

Schema description coverage is 100%, so both jobId and artifactId are fully documented in the schema. The description adds no further meaning to these parameters, which is acceptable given the high schema coverage baseline.

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: get details for a specific artifact within a HyperExecute job. It distinguishes itself from list-oriented siblings like getHyperExecuteJobArtifacts by emphasizing a specific artifact, though it does not explicitly name 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?

Provides no guidance on when to use this tool versus alternatives such as getHyperExecuteJobArtifacts or downloadJobArtifact. The intended context is implied only by the phrase 'specific artifact'.

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?

Adds real behavioral context beyond annotations: that app automation sessions return a not-found error and which sibling carries app-session media. Annotations already declare readOnly/openWorld=false, so the description's job is smaller, but it could still note log retention, size limits, or completeness of the live log.

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 packed sentences with the core capability front-loaded, immediately followed by the platform restriction and the alternative. 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?

Given one parameter, no output schema, and annotations covering the safety profile, the description is nearly complete for correct invocation. The remaining gap is output shape (log format, truncation), which is minor for a read-only retrieval 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 100% and the single sessionId already documents the accepted ID format (DA-WIN-... or session ID). The description adds no format or identifier nuance beyond that, so 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?

Specific verb+resource ('Retrieve the request and response log of a test session') with explicit scope ('while it runs or after it ends'). It explicitly distinguishes itself from mobile siblings by restricting to web automation and pointing app-session consumers to listMobileSessions.

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?

States the exact when: web automation (Selenium, Playwright, Cypress) only, and the when-not: app automation returns not found, with the alternative listMobileSessions called out for video/screenshots. This is explicit routing, not 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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no note on whether the capability payload reflects live org state, whether it can fail on unconfigured accounts, or what a typical response looks like.

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

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

A single front-loaded sentence with no filler or repetition. It is appropriately sized, though its brevity comes at the cost of substance rather than from efficient editing.

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

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

There is no output schema, so the description carries the burden of explaining what 'capability generation data' consists of, and it does not. For a zero-parameter getter the agent cannot infer the return shape or any gating condition from anywhere else in the definition.

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. No parameter-level confusion is possible.

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 verb (Retrieve) and a nominal resource (capability generation data for mobile automation test configuration), so the domain is identifiable. However, 'capability generation data' is undefined jargon that restates the tool name rather than explaining what is actually returned, leaving the agent unable to distinguish it confidently from siblings like getMobileConcurrency or getSupportedPlatforms.

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 contains no when-to-use guidance, no prerequisites, and no mention of any alternative tool. Given the large sibling set of mobile/test-configuration getters, the absence of routing guidance is a real 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=true, destructiveHint=false, openWorldHint=false, so the safe-read profile is covered. The description adds the useful scope that the numbers are mobile/real-device specific and that it returns both usage and limits, but says nothing about whether values are a live snapshot or cached.

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 resource and its scope appear immediately.

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?

No output schema exists, and the description does name what comes back (usage and limits), which covers the core need for a parameterless read tool. It stops short of describing freshness, units, or per-platform breakdown.

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?

Zero parameters, so the schema carries no semantics to supplement and the baseline is 4. Nothing in the description misrepresents the empty input contract.

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 (Retrieve) and resource (current concurrency usage and limits) scoped to mobile automation / real device testing. It is clear, but it never explicitly distinguishes itself from the sibling getOrgConcurrency, leaving the mobile-vs-org boundary 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?

The scoping phrase 'for mobile automation (real device testing)' implies when the tool is relevant, but there is no explicit when-to-use, prerequisite, or named alternative such as getOrgConcurrency. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows this is a safe read operation. The description adds the context that the concurrency is for web automation, which is useful. It does not, however, disclose behavioral traits beyond what annotations provide, such as whether this is a real-time lookup or if the response includes historical data.

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

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

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and scope with no wasted words.

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

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

Given the simplicity (no params, no output schema) and the annotations covering safety, the description is adequate. However, it lacks a crucial piece: an explicit statement that this tool is for web automation (Selenium/Cypress) and not mobile, which would help the agent choose between it and getMobileConcurrency.

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 has zero parameters, so the baseline is 4. The description correctly implies no parameters are needed, and it clarifies the scope (organization-level, web automation) without introducing unnecessary parameter details.

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 'retrieve' and resource 'current concurrency usage and limits for the organization on web automation (Selenium/Cypress)', clearly scoping it to web automation. However, it does not explicitly differentiate itself from the sibling 'getMobileConcurrency', which retrieves mobile concurrency limits.

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

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

There is no explicit guidance on when to use this tool versus alternatives. While the tool name and description imply it should be used to get org concurrency, the presence of 'getMobileConcurrency' as a sibling creates ambiguity that is not resolved – the description does not state that this tool is for web (Selenium/Cypress) as opposed to mobile.

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 safety (readOnlyHint true, destructiveHint false, openWorldHint false). The description adds meaningful behavioral context beyond that: it specifies the web-only scope, the error behavior for app sessions, and that it returns per-step screenshot URLs. It does not cover pagination or auth requirements, but for a read-only tool this is a strong addition.

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 zero waste: the core action and return value are front-loaded, followed by scope constraints and the alternative tool. Every sentence earns its place.

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

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

Given no output schema, the description still tells the agent what to expect (screenshot URLs for each step). It also fully covers the key usage boundary (web vs app automation) and points to the sibling that handles app sessions, so an agent has all needed context to call this 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 100% for the single sessionId parameter, which already documents its expected format (e.g., DA-WIN-...) and dual meaning (test ID or session ID). The description adds no further parameter detail, so baseline 3 applies.

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 (retrieve) and resource (command-by-command screenshots captured during a test session), and immediately clarifies the output (screenshot URLs for each step). It also distinguishes itself from sibling getSessionVideo by focusing on screenshots and from listMobileSessions by confining scope to web automation.

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 states when to use this tool (web automation sessions only) and when not to use it (app automation sessions return not found). It names the alternative tool for app sessions (listMobileSessions), leaving no ambiguity about routing.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is low. The description adds genuinely useful behavior beyond them: the web-only constraint, the concrete failure mode (not found) for app sessions, and the return shape ('structured JSON'). It does not mention volume, pagination, or retention limits for logs.

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, zero filler, and the core purpose is front-loaded before the scope constraint and the redirect to the alternative. Every sentence earns its place.

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

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

For a single-parameter log retrieval tool with no output schema, the description covers purpose, scope, and a rough return shape, which is close to sufficient. Minor gaps remain around log volume/pagination expectations, but nothing blocks 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?

Only one parameter, and schema coverage is 100% – the schema already documents sessionId as a web automation test ID or session ID. The description adds no format nuance, examples, or validation rules beyond that, so the baseline 3 applies.

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 (retrieve v2 command execution logs for a test session) and explicitly positions itself against the v1 variant by promising 'enhanced detail compared to v1 logs'. It also carves out a hard scope boundary (web automation only) that separates it from log-retrieval siblings like getAutomationTestCommandLogs.

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 an explicit when-not ('an app automation session returns not found') and routes the agent to the alternative for that case ('listMobileSessions carries the video and screenshot links of app sessions'). It does not, however, clarify when to prefer this over getAutomationTestCommandLogs or the other log endpoints for web sessions.

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, non-destructive, closed-world). The description adds a genuinely useful behavioral fact beyond that: app automation sessions produce a not-found result rather than logs, which prevents a wasted call. Return format and pagination are still unstated.

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

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

Two tight sentences: the core action first, then the web-only constraint and the escape hatch to listMobileSessions. Every clause earns its place with no filler.

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

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

No output schema exists, so the description ideally would hint at log shape or volume, which it does not. However, it fully covers the tool's scope, the platform constraint, and the failure case, which is sufficient for a single-parameter log retrieval call.

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

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

Schema description coverage is 100% and there is a single required parameter, so the schema carries the semantic load (session ID, with the DA-WIN- example). The description only confirms 'for a test session' and adds no format or syntax detail 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 (Retrieve) and resource (v2 Selenium/WebDriver grid request and response logs) scoped to a test session. It clearly separates web automation from app automation sessions, though it does not explicitly disambiguate itself from the similarly named sibling getSessionV2CommandLogs.

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 states the when-not: app automation sessions return not found. It also names an alternative (listMobileSessions) for video and screenshot links, though it does not route the agent among the other v2/automation log siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: it only succeeds for completed web sessions and fails with 'not found' for app sessions. It does not cover auth requirements or whether the URL is time-limited, so it lands just short of 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 sentences, zero filler, front-loaded with the core action followed by the platform constraint and fallback. Every clause earns its place.

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

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

For a single-parameter read-only lookup with no output schema, the description states what is returned (the video recording URL), the precondition (completed session, web automation), and the failure mode. Nothing an agent needs to invoke 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?

Only one parameter and schema description coverage is 100%, so the schema already documents sessionId including its format examples. The description adds no syntax or format detail beyond that. Baseline 3 is correct.

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

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

Specific verb+resource ('Retrieve the video recording URL for a completed test session') that an agent can immediately distinguish from sibling tools like getSessionScreenshots or getSessionV2SeleniumLogs. Scope ('completed test session') is stated up front.

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 restricts usage to web automation sessions and states the negative case (app automation returns not found), then routes the agent to the correct alternative (listMobileSessions) for app sessions. This is exactly the when/when-not/alternative pattern.

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 (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds what data categories are aggregated, which is useful, but does not disclose freshness, aggregation scope, or authorization requirements beyond the annotations' coverage.

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

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

A single efficient sentence that front-loads the verb and resource and packs the returned content into a compact list. No wasted clauses, though the enumerated payload detail is arguably redundant with the 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-value details are unnecessary, and the single required parameter is fully documented in the schema. The definition is complete enough to invoke correctly; only the absence of routing context against sibling read tools keeps it from a 5.

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?

Only one parameter (projectId) and schema description coverage is 100%, so the schema fully documents it. The description adds nothing about the parameter beyond what the schema already states, which is the expected baseline at full coverage.

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

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

Clear verb ('Gets') plus specific resource ('suite overview for a project') with an enumerated list of what the overview contains (run counts, latest status, scores, schedule info, active calls). It is distinguishable from mutation siblings like triggerSuiteRun, but does not differentiate itself from read-oriented siblings such as tm_get_coverage_summary or getTestTrends.

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

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

No when-to-use guidance is given: no statement of when a suite overview is preferable to getTestTrends, tm_get_coverage_summary, or the various HyperExecute job queries. The agent must infer the use case from the description alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral context the annotations don't: the exact shape of the unfiltered response (per-OS browser counts, newest/oldest versions, resolutions; per-mobile device counts and OS versions) and how filters change the output.

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

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

Front-loads what the tool returns, then the filter modes, with no filler sentences. The second and third sentences are dense (nested counts, resolutions, version ranges), but every clause carries information an agent needs.

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

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

With no output schema, the description compensates by describing the return shape in each mode, and annotations cover the safety profile. Missing only minor operational details such as result size or any cap on the unfiltered summary.

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

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

Schema coverage is 100%, so per-parameter meaning is already documented and the baseline is 3. The description goes beyond it by explaining parameter interaction — that os+browser yields a full version list while os=ios/os=android yields device names — which the schema's individual field descriptions do not convey.

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

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

States a specific verb and resource ('Lists the OS, browser and device combinations LambdaTest supports') plus the downstream purpose ('to find valid os, browser and version values for a test configuration'). This distinguishes it from nearby siblings like listDevicesForTesting and getMobileCapabilityGenerator, which serve different lookups.

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

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

Clearly explains the three invocation modes: no filters for a compact summary, os (optionally browser) for full version lists, os=ios/os=android for device names. That is strong guidance on how to call it, but it never states when to prefer this tool over listDevicesForTesting or getMobileCapabilityGenerator.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. With no output schema present, the description carries real weight by disclosing the returned metric set and, importantly, clarifying that 'completed without a pass/fail mark' is a distinct bucket and that two different pass-rate definitions are returned — a genuinely ambiguous point for an agent interpreting results. It stops short of stating retention/aggregation behavior beyond what the schema already says.

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

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

A single front-loaded sentence that names the resource and scope first, then enumerates outputs. The list is dense but every clause maps to a distinct returned value, so nothing is filler; it could be broken up for scannability but is not 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?

For a two-optional-parameter read tool with no output schema, the input side is fully covered by the schema and the output side is covered by the description's metric enumeration. What is missing is orientation — whether this is suite-wide or scoped to a project/test set, and how it relates to the other analytics tools — which keeps it short of 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 100%, with both optional parameters fully documented including formats, defaults, and the 59-day retention limit. The description adds nothing about fromDate/toDate, so this is the baseline 3 case where the schema does all the work.

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 ('Daily trend of web automation test results in a date range') and enumerates exactly what each day's bucket contains. It is unambiguous on its own, but it never contrasts itself with adjacent analytics tools such as getFlakyTests, getAnalyticsData, or getSuiteOverview, so sibling differentiation is left to the caller.

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 at all: no mention of when trend data beats a point-in-time report, no exclusions, and no alternatives named among the ~70 siblings. The date-range expectation is only inferable from the parameter names, not stated as usage guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: the default page size of 50 and the fact that the response text reports the total number matched, which is the only source of return-shape information since there is no output schema.

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

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

Three short sentences with zero filler: what it lists, the default page size, the filterable dimensions, and the returned total. The resource and default are front-loaded so the agent gets the essential facts immediately.

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

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

For a read-only paginated list tool with a fully documented schema and no output schema, the description covers pagination defaults, filter dimensions, and the returned total count. It is nearly complete, lacking only a note on ordering or how to interpret the matched-total value.

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

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

Schema description coverage is 100% and every parameter is documented in the schema, including the substring/case-insensitive match semantics and the '14 matches 14.x' version behavior. The description only restates those same filters, so the baseline of 3 is appropriate with no added syntax or format detail.

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

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

States a specific verb and resource: 'Lists the real devices available on LambdaTest for mobile app testing', which clearly identifies a device-catalog read. It does not distinguish itself from the closest sibling (getSupportedPlatforms), which also concerns available platforms, so it stops short of a 5.

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

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

Usage is implied rather than stated: the description explains that you can filter by region/OS/name/version and paginate, which hints at the discovery/search scenario. But it never says when to prefer this tool over getSupportedPlatforms or other listing siblings, and offers no exclusions or prerequisites.

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 (readOnlyHint, destructiveHint=false, openWorldHint=false). The description adds behavior beyond that: results are newest-first, pagination is offset-based, and critically the status filter only ranges over the 200 most recent jobs, which would otherwise cause silently incomplete results.

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

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

Two sentences, no filler, with the core scope front-loaded and the filter limitation placed immediately after so it is read before the agent commits to a query.

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 no output schema, the description still gives an agent enough to call the tool correctly: scope, ordering, pagination and the filter window. It stops short of indicating what a returned job record contains, but that is a minor omission for a straightforward list endpoint.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, making 3 the baseline. The description's restatement of the 200-job filter window duplicates the status parameter description rather than adding new syntax or format detail.

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

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

States a specific verb and resource ('List the account's HyperExecute jobs') plus the ordering and pagination model, which cleanly separates it from the many single-job siblings like getHyperExecuteJobInfo and getHyperExecuteJobSessions. It does not explicitly name an alternative for the job-detail use case, but the list scope 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?

Usage is implied rather than stated: an agent can infer this is for browsing jobs rather than inspecting one, and the 'status filter looks at the 200 most recent jobs' caveat is a genuinely useful boundary. However, there is no explicit when-to-use vs when-not, nor a pointer to the detail/artifact siblings for drilling into a specific job.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structure. The description adds genuinely non-obvious behavior beyond that: newest-first ordering, a 10-per-page default, and most importantly that the API only returns builds from the last 90 days so the reported total can exceed what is pageable. That retention/consistency caveat is exactly the kind of disclosure annotations cannot convey.

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

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

Three sentences, no filler, and the ordering/default-page-size facts are front-loaded before the caveat. Every sentence carries distinct information: what is listed, how to page, and the retention limitation.

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

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

There is no output schema, so the description carries the burden of describing returns, and it does: ordering, page size, and the behavior of the total relative to the pageable set. Combined with full schema coverage on all three parameters and safe-read annotations, an agent has everything needed to call this 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 100%, so limit and offset are already documented and the baseline would be 3. The description goes slightly beyond the schema by explaining the total-vs-pageable interaction that arises from the 90-day truncation, which affects how an agent should interpret paging results. The status parameter is not addressed at all in the 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 opens with a specific verb+resource ('Lists mobile app automation builds') plus ordering ('newest first') and default page size, which is far more than a restated title. It does not, however, name or implicitly distinguish itself from nearby siblings such as listMobileSessions, listUploadedApps, or listHyperExecuteJobs, leaving the resource name alone to do the disambiguation.

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

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

There is no explicit when-to-use / when-not-to-use statement or reference to an alternative tool for retrieving build data, so tool selection is left to inference from the resource name. The description does give practical usage mechanics (paging with limit/offset) and a conditional caveat about the 90-day window, which is useful but not 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds genuine behavioral context: newest-first ordering, a 10-per-page default, and that video/screenshot/log links are included in each row.

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 dense, front-loaded sentences that lead with what is listed and then cover ordering, paging, filtering, and return contents. No filler and no redundancy.

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

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

With no output schema, the description usefully tells the agent the response carries video/screenshot/log links and a total count, and it explains the pagination contract. It is essentially complete for a simple read-only list tool, though ordering ties and auth expectations are 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 coverage is 100%, so the schema already documents all four parameters including defaults and the buildId provenance. The description only restates that limit/offset page and buildId/status filter, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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 (Lists) and resource (mobile app automation sessions/tests), and adds useful scope detail such as ordering and default page size. It does not explicitly name a near sibling (e.g., listMobileBuilds or getHyperExecuteJobSessions) to disambiguate, so it stops short of a 5.

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

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

The description explains how to use the tool (page with limit/offset, or filter by buildId or status) but never states when to choose it over alternatives or any prerequisites. Usage is implied rather than directed, which is minimum-viable.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds the 'active' scoping qualifier and intent context, but says nothing about result size, pagination, or what an account with no tunnels 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 sentences, zero filler, with the core action front-loaded before the use-case rationale. Every sentence earns its place.

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

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

For a parameterless read-only listing tool whose annotations already cover the safety profile, this is nearly complete. The only mild gap is that with no output schema present, the description does not indicate the shape or fields of the returned tunnel entries.

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 compensate for; the baseline for a 0-parameter tool is 4. The description correctly implies account-scoped retrieval with no input needed.

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

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

States a specific verb and resource — 'Retrieve all active LambdaTest tunnel connections for the account' — which is unambiguous. It does not explicitly distinguish itself from related tunnel siblings such as stopTunnel or analyzeAppViaTunnel, so it falls just 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?

Gives concrete usage contexts: checking running tunnels before starting a new one, and debugging local testing connectivity. However, it names no alternative tools and states no exclusions, so it is clear context without full when/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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds the scope of what is listed (all uploaded mobile apps) but says nothing about result size, pagination, or whether all items are returned at once.

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

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

Two sentences, no filler, with the core purpose front-loaded and the parameter hint following. Every clause 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?

For a read-only, two-optional-parameter list tool with no output schema and full annotation coverage, this is close to sufficient: purpose, platform scope and enum semantics are all present. Minor gaps remain around result size/pagination and how the returned apps relate to downstream tools like analyzeAppViaTunnel.

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

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

Schema description coverage is 100% and both enums are fully documented in the schema, including the level=org mapping that the description omits entirely. The description's type sentence largely restates the schema's own wording, so it adds little beyond structured data — baseline 3 applies.

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 (retrieve all uploaded mobile-testing apps) with the platform named, which distinguishes it from siblings like listMobileBuilds or listMobileSessions. It does not explicitly name or contrast with any sibling (e.g. upload_app, deleteUploadedApps), so it stops short of a 5.

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

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

The second sentence gives real selection guidance for the type parameter (android/ios = real devices, emulator/simulator = virtual), which is genuine usage help. However there is no guidance on when to use this tool versus alternatives, and the level parameter is never mentioned, so usage remains 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 this as a non-read-only, non-destructive, non-open-world write. The description adds genuinely useful behavior beyond that: the result reads exceptions back to confirm storage, and — critically — that the automation dashboard may not reflect exceptions uploaded after the test ended. That delayed-visibility caveat is real operational context the annotations cannot convey.

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

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

Four sentences, front-loaded with the core action and scope, and each subsequent sentence adds distinct value (use case, verification behavior, caveat). Minor slack, but 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 no output schema, the description usefully explains the read-back confirmation behavior, and annotations cover the safety profile. For a nested-parameter mutation tool this is close to complete; permission requirements for uploading to an arbitrary session are the only noticeable 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 100% and the nested `data.exception` structure is fully documented with an example, so the schema carries the parameter semantics. The description only restates 'by session ID' and adds no format or constraint details beyond what the schema provides; 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?

States a specific verb and resource: 'Upload exception/error logs from the client machine for a test session, by session ID.' The session scoping implicitly separates it from the sibling postTestExceptions, which handles test-level exceptions, though that sibling is never named 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?

Gives clear when-to-use guidance: 'Use this to attach assertion failures or unexpected errors to a session.' However, it offers no explicit when-not condition or named alternative (e.g. postTestExceptions for the test-level case), so the agent must infer the split.

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 (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description only needs to add behavior beyond that — and it does, disclosing that the call reads the exceptions back as a storage confirmation and that dashboard visibility may be unreliable post-test. It does not cover idempotency, overwrite semantics, or auth requirements.

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, front-loaded with the action and the distinguishing scope, followed by verification behavior and the one operational caveat. No sentence 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?

For a two-parameter mutation with annotations covering safety and a fully documented nested schema, the definition supplies the distinguishing scope, the read-back behavior, and the post-test visibility caveat. The read-back partially compensates for the absence of an output schema, though the exact response shape remains unspecified.

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

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

Schema description coverage is 100% and the nested data object, its required 'exception' array, and item constraints are fully documented in the schema. The description only restates that identification is by test ID, adding no syntax or format detail beyond the structured fields. Baseline 3 applies.

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 (upload exception logs) with an explicit scope qualifier ('for a specific test (by test ID) rather than by session ID'). This directly distinguishes it from the sibling postSessionExceptions without needing to open 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 a clear selection rule against the session-based alternative and a caveat about when the result may be misleading ('automation dashboard may not show exceptions uploaded this way after the test ended'). It does not name the sibling tool explicitly or state prerequisites such as whether the test must already exist.

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 destructiveHint annotation by disclosing the merge lifecycle: names resolve to builds, the merged build is polled, terminal status is reported, and error/zero-screenshot outcomes surface as tool errors rather than success. Critically warns that the merged build takes the baseline flag, so a failed merge leaves the baseline on an empty build — a non-obvious destructive consequence.

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, front-loaded with purpose and the read alternative before behavioral detail. Dense but every clause (polling, error semantics, baseline-flag side effect) carries information an agent needs. Slightly packed, but no waste.

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

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

For a destructive, multi-mode mutation tool with no output schema, the description covers what the tool does, when to use it vs the read sibling, how success/failure is signaled, and the lasting state change. Nothing an agent needs to call it safely 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 coverage is 100% (baseline 3), but the description adds meaning: source/target are names that get resolved to builds, and merge_branch vs merge_build reinterpret those same fields as branches or build names. This clarifies the enum-conditional parameter semantics beyond the schema text.

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 (merge) and resource (SmartUI baselines) with scope (across branches or builds), and explicitly distinguishes itself from the read-path sibling smartui_project_query. An agent can identify this as the mutation counterpart to the SmartUI query 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?

Explicitly routes the agent: 'to read baseline settings, use smartui_project_query with action=get', and names the two merge modes (merge_branch/merge_build) with their distinct source/target semantics. When-to-use and the alternative for the read case are both 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, destructiveHint=false, so the trailing "Read-only" only confirms them. The description earns credit for disclosing semantics annotations cannot: the full verdict enum, that totals include missing baseline screenshots, that blocking[] carries per-item detail, and notably that verdict=failed conflates rejections with dropped baseline screenshots.

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 three operations, then the high-value gate return contract, with no filler sentences. Minor waste is repeating "Read-only" already asserted by readOnlyHint=true annotations.

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

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

With no output schema, the description correctly compensates for the gate path by enumerating verdicts and blocking fields. However, list and get return shapes and pagination behavior go unmentioned, leaving an agent guessing about the other two action paths of this 8-parameter 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 100%, including action enum meanings, build_id/build_name dual usage, and the client-side substring caveat, so the schema already carries parameter semantics. The description only re-expresses action=gate usage and adds no syntax or constraint beyond the schema — 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?

The first sentence names the resource (SmartUI builds) and all three distinct verbs/operations (list, get, gate verdict), so an agent can map action values to intent without opening the schema. The resource itself separates it from smartui_project_query and smartui_comparison_query 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?

"Use action=gate in pipelines" gives an explicit context that selects one of the three actions, which is real routing guidance. It stops short of saying when NOT to use this tool or naming SmartUI siblings (e.g. baseline/comparison tools) as alternatives for related questions.

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/destructiveHint, and the description reinforces that while adding real behavioral detail beyond them: consolidated/pixel do not run their own image analysis, lens=dom degrades to a structured error when artefacts are absent, and no local filesystem is required. Failure and degradation modes are disclosed, which is exactly the added value the annotation does not 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?

Front-loaded with the core action and lens list, then layers consequences. Dense but every clause carries information; losses come only from mild repetition of the lens behavior in two sentences.

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 no output schema, the description must describe returns, and it does: mismatch %, verdict, labelled asset URLs, and the DOM byte delta for lens=dom. Combined with the error-degradation note, an agent has enough to call it correctly; only the exact error/response shape remains unspecified.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including the inline size limits, so the baseline is 3. The description mostly restates the lens semantics already present in the schema and adds no new format or syntax guidance for comparison_id or include_assets.

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 (Analyze) and resource (one SmartUI comparison) with an explicit scope limiter (one, not many), and names the three lens modes. It is clearly distinguishable from the sibling smartui_comparison_query, whose output feeds the required comparison_id.

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 when each lens matters (dom gives a real byte delta and needs served artefacts; consolidated/pixel merely surface upstream numbers) and gives an actionable condition for include_assets=inline ('when you cannot fetch URLs'). It stops short of stating when to prefer this tool over smartui_comparison_query.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description reinforces this with 'Read-only' and adds real value by enumerating return contents (comparison_id AND ss_id for list; mismatch %, status, labelled baseline/current/compared URLs for get). It does not discuss pagination behavior, which would have helped.

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?

Dense and front-loaded: the primary list/get capability comes first, followed by the key value proposition and a trailing safety note. The standalone 'Read-only.' repeats the annotation, a minor redundancy, but nothing else is wasted.

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

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

With 8 parameters, no output schema, and only readOnly annotations, the description does the necessary work of summarizing what each action returns. It is nearly complete for agent selection; only pagination/filtering behavior and its relationship to smartui_comparison_analyze are left 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 100%, with each of the 8 parameters already documented in the schema including the list-only markers and the list/get enum. The description adds no parameter-level detail (formats, defaults, edge cases) beyond what the schema provides, so the 3 baseline applies.

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

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

The description names a specific resource (comparisons) with two clear modes (list in a build vs get one), plus the fields each returns. It is easy to distinguish from the other smartui_* siblings by name, but it never explicitly differentiates itself from smartui_comparison_analyze, so it stops short of a 5.

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

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

It hints at intent with 'This is how you obtain a comparison_id — you never need the dashboard', which tells the agent why to call it. However, it gives no when-not guidance and does not route the agent between this tool and the nearby smartui_comparison_analyze or smartui_build_query alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds non-obvious behavioral detail: exactly which settings fields (baseline_branch, approvers[], smart_baseline, etc.) come back from action=get. That return-shape disclosure is genuine value beyond 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?

One front-loaded sentence that leads with the list/get split and closes with the routing hint. The field enumeration is slightly long but earns its place given there is no 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 no output schema, the description compensates by naming the fields action=get returns, and it flags read-only behavior. Pagination defaults and the full parameter set are left to the schema, which is acceptable since coverage is 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 100%, so list-only/page/limit/search/project_id semantics are already documented in the schema. The description only echoes action=get's purpose and its returned fields, adding little parameter meaning beyond the structured data. Baseline 3 applies.

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 specific verbs (list / get) and the resource (SmartUI projects), and enumerates the fields returned by action=get. An agent can distinguish this from sibling smartui_build_query and smartui_baseline_manage 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 gives a usage cue: 'Start here when you do not have a project_id.' This tells the agent when to reach for this tool first. It does not name an alternative tool or state exclusions, so it stops short of a 5.

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

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

Annotations only supply readOnlyHint=false and destructiveHint=true; the description adds substantive behavior beyond that: ids are validated against the build before writing, results are verified by re-reading status, the response reports real per-item updated[]/failed[], and approving on the baseline branch can promote the build to baseline. It also discloses that comparison_ids are resolved server-side.

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 packed sentences with no filler; the operation and its two modes are front-loaded. Slightly dense (multiple ideas per sentence), but every clause carries information an agent needs.

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

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

No output schema exists, and the description compensates by describing the response shape (per-item updated[]/failed[]) and the baseline-promotion side effect. Combined with full schema coverage of all 6 parameters, an agent has everything required to invoke and interpret the call.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the per-parameter blurbs do not: that comparison_ids and ss_ids are two alternative individual targeting paths, and that all_matching:{status} is a bulk selector over the whole build. The relationship between the targeting parameters is clarified rather than merely restated.

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 pair (approve/reject) on a specific resource (SmartUI comparisons) and enumerates the two operating modes (individual ids vs whole-build all_matching:{status}). An agent can distinguish this from smartui_comparison_analyze or smartui_baseline_manage 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?

Clearly explains when to use each targeting mode: individual comparison_ids/ss_ids versus bulk all_matching by status. It does not name rival siblings (baseline manage, comparison query/analyze) or state exclusions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this mutates state. The description adds the build_id return and the gate follow-up, which the annotations do not convey. However, it never explains the destructive side — e.g. that mark_baseline=true may overwrite an existing baseline — which is the most important behavioral caveat for a tool flagged destructive.

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, correctly front-loaded with the core action and the highest-value caveat (server-side fetch vs client filesystem). Slight redundancy: the 'fetched server-side' note repeats the schema's 'Works in hosted mode'.

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 no output schema, the description correctly discloses the return value (build_id) and the next step, so an agent can chain into the gate query. The only gap is behavioral — what marking a baseline displaces — which a destructive-flagged mutation tool should mention.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including the stdio-vs-hosted constraint and the 'no extension added' rule for screenshot_name. The description largely restates this, adding only the minor tie between mark_baseline and later screenshot_name binding. Baseline 3 applies when the schema does the heavy lifting.

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 ('Upload screenshots to a SmartUI project as a new build') and covers both ingestion modes, file_paths and source_urls. This distinguishes it cleanly from siblings like smartui_screenshot_review and smartui_build_query, which operate on existing builds.

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 conditional guidance: file_paths only works over local stdio, source_urls for hosted mode, project_id for token auto-resolution, mark_baseline to seed a baseline. It also names the follow-up tool (smartui_build_query(action=gate)). It stops short of saying when to use this vs smartui_baseline_manage for baseline operations.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds the concrete blast radius – every running test stops and running sessions end immediately – which is meaningful context for a destructive operation beyond what the annotations 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?

Two tight sentences with no filler, and the scope-defining clause (every running test in a build) is front-loaded ahead of the effect.

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

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

For a one-parameter destructive stop tool with no output schema, the description covers purpose, scope, and immediate effect. It could note error behavior (e.g., already-finished builds) or what is returned, but nothing critical for correct invocation is missing.

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

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

There is a single buildId parameter with 100% schema description coverage, so the schema fully documents it. The description adds no format, type, or constraint detail beyond the schema, which is the expected baseline when the schema does the work.

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 (stops) and resource (every running test in a LambdaTest web automation build), and scopes it to the whole build rather than a single session, which distinguishes it from sibling stopSession. An agent can select it 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?

Usage is implied by the verb and scope, but the description never states when to prefer this over stopSession or deleteBuild, nor any prerequisite conditions. It is adequate but gives no explicit routing guidance.

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