Compass OS: Career

delete win

delete_win

DestructiveIdempotent

Delete one win from the user's wins log, named by its date and its text as list_wins shows them. Use edit_win to correct a win rather than delete it. It asks the user first and removes only that win; resumes and the profile don't change. When the text doesn't match, the reply lists that day's wins instead. Once it's saved, undo can put it back within 24 hours.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date": "<date>",
      "what": "<what>"
    },
    "name": "delete_win"
  }
}

Input Schema

Name	Required	Description	Default
`date`	Yes	The win's date as list_wins shows it, YYYY-MM-DD
`what`	Yes	The win's text as list_wins shows it; its first 8 or more characters are enough

Output Schema

Name	Required	Description
`text`	Yes	The answer, or what was done, in plain words for the user: the same text as content
`undo`	No	On a saved write: its undo handle, for undo within 24 hours
`widget`	No	The card the host draws with it, e.g. "pipeline"; "confirm" means a write waits for the user's Yes and nothing is saved yet

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

changedInput schema / properties / date / description

Previous value: -"The win's date as the wins tool shows it, YYYY-MM-DD"New value: +"The win's date as list_wins shows it, YYYY-MM-DD"

changedInput schema / properties / what / description

Previous value: -"The win's text as the wins tool shows it; its first 8 or more characters are enough"New value: +"The win's text as list_wins shows it; its first 8 or more characters are enough"

Changed1 schema field changedNov 5, 2026

addedOutput schema / properties / undo

Added value: +{
+  "description": "On a saved write: its undo handle, for undo within 24 hours",
+  "type": "string"
+}

Changed3 schema fields changedNov 4, 2026

addedInput schema / properties / date / description

Added value: +"The win's date as the wins tool shows it, YYYY-MM-DD"

addedInput schema / properties / what / description

Added value: +"The win's text as the wins tool shows it; its first 8 or more characters are enough"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "text": {
+      "description": "The answer, or what was done, in plain words for the user: the same text as content",
+      "type": "string"
+    },
+    "widget": {
+      "description": "The card the host draws with it, e.g. \"pipeline\"; \"confirm\" means a write waits for the user's Yes and nothing is saved yet",
+      "type": "string"
+    }
+  },
+  "required": [
+    "text"
+  ],
+  "type": "object"
+}

First observedNov 4, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds real context beyond them: a user confirmation prompt, the exact blast radius ('removes only that win; resumes and the profile don't change'), and a 24-hour undo window. The only gap is it doesn't say what a successful reply looks like, which is partly covered by the output schema.

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?

Front-loaded with the action and scope, then alternatives, then side effects, then edge-case behavior. Four sentences, all carrying distinct information; slightly dense but nothing is wasted or repeated from the schema.

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

Completeness5/5

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

For a destructive two-parameter tool, the description covers confirmation, scope of effect, sibling routing, mismatch handling, and reversibility, while an output schema handles return shape. An agent has everything needed to call it correctly and safely.

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, but the description adds provenance the schema lacks: both values must be taken verbatim from list_wins output rather than guessed or reformatted. That is a meaningful usage constraint beyond the field-level descriptions.

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?

States a specific verb and resource ('Delete one win from the user's wins log') and immediately scopes it with the identification keys ('named by its date and its text as list_wins shows them'). It also distinguishes itself from edit_win, so an agent can separate deletion from correction without opening either schema.

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

Usage Guidelines5/5

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

Explicitly routes the agent: 'Use edit_win to correct a win rather than delete it' names the alternative and the condition that selects it. It also gives fallback guidance for the failure case ('When the text doesn't match, the reply lists that day's wins instead'), which tells the agent how to recover.

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

All Compass OS: Career tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?