Skip to main content
Glama

Delete Timelog

kaiten_delete_timelog
Destructive

Remove a time log from Kaiten by specifying the card ID and log ID. Verify the card-log pair beforehand to prevent deleting a log from the wrong card.

Instructions

Delete a timelog. WARNING: Kaiten ignores cardId in the URL path and resolves the log purely by logId — passing a wrong cardId will still delete the log from its real owner card. Always verify the pair via kaiten_get_card_timelogs(cardId) before deleting.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
logIdYesTime-log ID
cardIdYesCard ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.7

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations (destructiveHint=true), the description discloses a genuinely surprising backend behavior: cardId is ignored and deletion is resolved purely by logId, so a wrong cardId will delete the log from its real owner. This is exactly the kind of behavioral context annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences deliver the core action and the critical warning, with the most important caveat front-loaded after the verb. No filler or repetition of annotation data.

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, non-idempotent two-parameter call, the description supplies the required verification step and the risk model, while annotations already carry readOnly/destructive/openWorld flags. Nothing needed to invoke it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already documents both parameters, the description adds critical semantics: logId is the authoritative id, while cardId is ignored for resolution and can be wrong with irreversible consequences. This reframes how the agent should treat the cardId parameter despite 100% schema coverage.

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?

The description opens with a specific action and resource: 'Delete a timelog.' The WARNING further distinguishes it from sibling timelog tools by revealing the unique logId-only resolution behavior, so an agent can select it confidently.

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

Usage Guidelines4/5

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

It directly instructs the agent to verify the cardId/logId pair with kaiten_get_card_timelogs(cardId) before deleting, which is a clear precondition for safe use. It does not enumerate when-not-to-use alternatives like update_timelog, but for a delete operation the intended context is evident.

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

Deploy Server

Other Tools