Clear my brand
clear_my_brandRemove your saved brand to start over with a different one.
Instructions
Remove your saved brand so you can start over with a different one.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
clear_my_brandRemove your saved brand to start over with a different one.
Remove your saved brand so you can start over with a different one.
| 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?
This is a delete/reset operation and annotations only declare readOnlyHint=false, with no destructiveHint. The description says 'Remove' but never discloses whether the action is reversible, whether brand-associated assets (products, ads, creatives) are also affected, or whether confirmation is required. For a destructive tool with minimal annotations, this leaves the key behavioral risk undisclosed.
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 short sentence with zero filler, front-loading the action. Appropriately sized for a no-argument tool, though it could have spent that brevity budget on a risk note.
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 zero-param tool with no output schema, the definition is minimally adequate to invoke correctly, but the omission of any irreversibility or data-loss warning is a real gap for a destructive reset operation.
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?
Zero parameters, so there is nothing for the description to document. Baseline 4 applies; no compensation is needed.
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 (Remove) and resource (your saved brand) plus a hint of scope (start over). An agent can tell it apart from get_my_brand and save_my_brand by the verb alone, though it never explicitly names those siblings.
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?
The clause 'so you can start over with a different one' implies the use case (resetting to configure a new brand), but no explicit when/when-not or alternative is named. Given the close sibling save_my_brand, a routing statement would have been valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.