Goals: Delete goal
delete_goal Cancel a financial goal (soft delete).
Args:
goal_id: The ID of the goal to cancel
Returns:
Confirmation of cancellation
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal_id | Yes |
delete_goal Cancel a financial goal (soft delete).
Args:
goal_id: The ID of the goal to cancel
Returns:
Confirmation of cancellation
| Name | Required | Description | Default |
|---|---|---|---|
| goal_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnly=false, and the description adds the meaningful nuance that this is a soft delete, not a permanent hard deletion. It also specifies that a confirmation is returned. This adds context beyond the structured annotations, though it stops short of describing reversibility or impact on related data.
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 tightly structured into purpose, argument, and return sections. There is no filler or redundant explanation, and the core action is front-loaded. Every element earns its place.
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 one-parameter soft-delete tool, the description gives the essential information: what it does, the parameter meaning, and the confirmation return. It lacks notes on post-cancellation visibility, reversibility, or effects on linked resources, but it is still nearly complete for invoking the tool correctly.
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?
The schema has one required integer parameter with no description (0% coverage). The description compensates with an Args section stating that goal_id is 'The ID of the goal to cancel.' For a single, simple parameter this is sufficient, though it does not indicate where to obtain valid goal IDs.
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 specific verb ('Cancel') and resource ('a financial goal'), and clarifies the mechanism ('soft delete'). This is easily distinguishable from the many sibling delete_* tools because it names the exact target resource and the action type.
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 guidance on when to use this tool versus alternatives, nor any exclusions. It does not mention related tools like update_goal, list_goals, or link_goal_plan, nor what happens to linked plans or shared goals when a goal is cancelled. Usage is implied only by the verb 'Cancel'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.