Skip to main content
Glama

delete-attachment

Destructive

Permanently remove a file attachment from a Dooray task by providing the project, task, and file IDs.

Instructions

Delete a file attachment from a Dooray task.

Required Parameters:

  • projectId: The project ID

  • taskId: The task ID (post ID)

  • fileId: The file ID to delete (get from get-attachment-list)

Example: { "projectId": "123456", "taskId": "789012", "fileId": "abc123" }

Returns: Success message confirming deletion.

Note: This action is irreversible. The file will be permanently removed from the task.

Input Schema

NameRequiredDescriptionDefault
fileIdYesFile ID to delete
taskIdYesTask ID (post ID)
projectIdYesProject ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.3/5.0
Behavior4/5

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

The annotations already declare destructiveHint=true, and the description adds useful context: the deletion is irreversible, the file is permanently removed from the task, and the return is a success message. It does not cover permissions or error behavior, but it adds meaningful destructive-operation context beyond annotations.

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

Conciseness4/5

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

The purpose is front-loaded, followed by organized parameter, example, return, and warning sections. Some parameter text duplicates the schema, but the overall length remains appropriate for a destructive tool.

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

Completeness4/5

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

For a no-output-schema destructive tool, the description covers the required inputs, an example call, the return message, and the irreversibility warning. Minor gaps around authorization or failure modes remain, but the core invocation context is complete.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value by identifying where fileId comes from (get-attachment-list) and provides a concrete example payload with all three IDs.

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

Purpose5/5

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

The description uses a specific verb and resource: 'Delete a file attachment from a Dooray task.' This clearly distinguishes it from sibling tools such as delete-drive-file, delete-wiki-page-file, and delete-task-comment.

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

Usage Guidelines4/5

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

It gives a clear prerequisite by telling the agent to get the fileId from get-attachment-list. It does not explicitly compare when to use this versus similar deletion tools, but the task-attachment scope is clear.

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