Delete an attachment from an Aegisub/ASS subtitle document, removing its name and payload lines. Use it to clean unused fonts, graphics, or embedded files by name.
Remove an attachment (its name line and every payload line).
Returns {"doc_id", "name", "removed", "lines_removed"}.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| doc_id | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the destructive scope precisely — the name line and all payload lines are removed — which is genuinely useful. However, it says nothing about whether the removal is undoable, what happens when the named attachment does not exist, or whether the document must be open/writable.
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 the destructive scope front-loaded and the return shape appended. Nothing is padded, though restating the return keys is somewhat redundant given the output schema exists.
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?
Since an output schema exists, the description need not spell out return values, and it correctly omits deeper behavior. But for a mutating tool with zero annotations and zero schema descriptions, the missing doc_id default semantics and undo/not-found behavior leave real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description explains neither parameter. It never says that 'name' identifies the attachment to remove, nor that 'doc_id' is optional and defaults to the current document — the most important ambiguity for this tool given the default-null doc_id.
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 ('Remove an attachment') and clarifies the scope of removal ('its name line and every payload line'), which is more than a restatement of the name. It reads as distinct from ass_add_attachment and ass_list_attachments, though it never explicitly names the siblings it should not be confused with (e.g. ass_extract_attachment).
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 note on preconditions, and no mention of alternatives such as ass_extract_attachment for pulling an attachment out without deleting it. The intended usage is only inferable from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.