deletePrerunFileDelete an uploaded prerun file by stored LambdaTest file path.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | No | Stored path of the pre-run or post-run file, as uploadPrerunFile returns it (<name>/pre/<file> or <name>/post/<file>) | |
| file_path | No | Stored path of the pre-run or post-run file, as uploadPrerunFile returns it (<name>/pre/<file> or <name>/post/<file>) |
Changes observed during successful MCP inspections.
Input schema / properties / filePath / descriptionPrevious value: -"Stored LambdaTest file path to delete"New value: +"Stored path of the pre-run or post-run file, as uploadPrerunFile returns it (<name>/pre/<file> or <name>/post/<file>)"Input schema / properties / file_path / descriptionPrevious value: -"Stored LambdaTest file path to delete"New value: +"Stored path of the pre-run or post-run file, as uploadPrerunFile returns it (<name>/pre/<file> or <name>/post/<file>)"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.
Add one secure layer between your agents and this server.