Permanently remove a logged Beyond the Whiteboard result using its session ID. Use this to correct mistakes, since deleted sessions cannot be restored or undone.
Permanently delete an already-logged BTWB result by its session ID. This cannot be undone - BTWB has no trash/undo for deleted sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The workout_sessions ID to delete |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it does so well: it explicitly warns the deletion is permanent and that BTWB has no trash/undo. This is exactly the irreversibility disclosure an agent needs before invoking a destructive tool.
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?
Two tight sentences, zero waste. The permanence warning is front-loaded as the consequence and the no-undo fact immediately follows.
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 single-parameter destructive tool with no output schema, the description covers the critical behavior (irreversibility), the target (logged session by ID), and the scope (session-level). Nothing an agent needs is missing.
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 coverage is 100% (sessionId documented as 'The workout_sessions ID to delete'), so the baseline is 3. The description adds the constraint that the session must be an already-logged result, slightly exceeding the schema's generic wording.
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 (permanently delete) and resource (an already-logged BTWB result), and identifies it by session ID. The 'permanently' qualifier distinguishes it sharply from siblings like get_workout_session or refresh_session_cookie.
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?
Clearly conveys this is for an already-logged result and implies the destructive context via 'permanently' and 'cannot be undone'. No explicit alternative named, but the destructive framing makes the when-to-use condition obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.