delete_tag
Remove a tag from RogerRoger CRM by providing its ID, cleaning up unused tags and keeping your CRM data organized.
Instructions
Delete a tag
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the tag to delete |
Remove a tag from RogerRoger CRM by providing its ID, cleaning up unused tags and keeping your CRM data organized.
Delete a tag
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the tag to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not disclose whether deletion is permanent/irreversible, whether related references to the tag become invalidated, whether authorization/permissions are required, or what happens on success/failure. For a destructive mutation tool with zero annotation coverage, this is a significant gap.
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 efficient—three words, zero waste. It's appropriately short for a simple delete operation. However, this brevity is borderline under-specification rather than genuine conciseness, since critical behavioral details are omitted.
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 with no annotations, no output schema, and a single parameter, the description fails to cover critical context: irreversibility, cascading effects on tasks/other entities that reference the tag, and what error conditions might occur. The tool is simple in interface but the consequences of use are not disclosed.
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%—the single 'id' parameter is fully documented in the schema as 'The ID of the tag to delete.' The description adds no additional meaning beyond the schema. Baseline 3 applies since the schema does the heavy lifting and there's only one self-explanatory parameter.
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 clear verb+resource ('Delete a tag'), and the sibling tools include get_tag, create_tag, update_tag, so the purpose is reasonably distinct. However, it doesn't go beyond the tool name itself—'Delete a tag' essentially restates the name without adding scope, constraints, or differentiating detail beyond what the name implies.
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 is provided on when to use this tool versus alternatives. There's no mention of check-before-delete patterns (e.g., get_tag first), cascading effects, or whether deletion is permanent or reversible. Given sibling tools like get_tag and update_tag exist, some guidance on prerequisites or ordering would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RogerRogerHQ/rogerroger-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server