Upload an attachment to a test case by ID. Add screenshots, test data, configs, or reference documents to support test case documentation.
Upload an attachment for a test case. Upload a new attachment to a test case.
Attachments help document your test cases with supporting files such as screenshots, test data files, configuration examples, or reference documents.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| path | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds nothing beyond them: no size limit (schema allows 14MB base64), no behavior on duplicate filenames given non-idempotency, no permission requirements, and no note that the upload only adds and never overwrites.
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 first two sentences say the same thing ('Upload an attachment for a test case' / 'Upload a new attachment to a test case'), consuming a third of the text without adding information, and the remaining sentence is generic filler about what attachments are.
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, non-idempotent write with a nested body object, no output schema, and no parameter documentation, the description is too thin. It omits the 14MB base64 ceiling, the naming/MIME expectations, and any auth or permission context an agent would need before calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description supplies no parameter information at all — no mention of testCaseId, filename, mimeType, or the base64 encoding of file content (only the nested schema comment mentions base64). With two required parameters and a nested body object, the description should compensate and does not.
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 an attachment for a test case') and the 'test case' qualifier distinguishes it from post_issue_attachment and post_test_result_attachment. The second sentence merely restates the first rather than sharpening the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of alternatives such as get_test_case_attachments or delete_test_case_attachment. The list of example file types describes what attachments are for in general, not when this tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.