Skip to main content
Glama
Sign In

TaScan

by io.github.snowbikemike
OverviewDiscussionsAdmin

tascan_delete_project

DestructiveIdempotent

Delete a project that has NO history, after typing its name. Refused 409 project_has_history (with the counts) when it has any task or subtask completion, action receipt, issue, invoice or coordination task: archive it instead (tascan_update_project status archived). confirm_name must equal the project name exactly (400 confirm_name_mismatch). A receipted audit event (actor, project, name, counts, your audit note) is written BEFORE the delete; if it cannot be written nothing is deleted. The check, the audit event and the delete are one database transaction that locks receipts, tasks and the project first, so history created meanwhile is never deleted (503 busy, nothing deleted, when those locks are not had within 3 seconds: retry). Irreversible.

Input Schema

NameRequiredDescriptionDefault
auditNoOptional audit note stored verbatim in the audit event (e.g. { reason })
project_idYesProject ID to delete
confirm_nameYesThe project name, typed exactly

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / audit
      Added value: +{
+  "description": "Optional audit note stored verbatim in the audit event (e.g. { reason })",
+  "type": "object"
+}
    • addedInput schema / properties / confirm_name
      Added value: +{
+  "description": "The project name, typed exactly",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "project_id"
-]New value: +[
+  "project_id",
+  "confirm_name"
+]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructive=true and idempotent=true, and the description goes well beyond them: it discloses the 409 refusal semantics with counts, the pre-delete receipted audit event, the transactional locking behavior, the 3-second lock timeout with 503/retry, and that the operation is irreversible. None of that is in the structured fields.

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 core purpose and precondition, and every sentence carries operational information. It is dense — the long second sentence chains several guarantees together — but there is no filler or repetition.

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, irreversible tool with no output schema, the description covers refusal conditions, audit side effects, transaction/locking semantics, retry behavior, and the alternative path. An agent has everything needed to call it safely and interpret failure codes.

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. The description still adds real meaning: confirm_name must equal the project name exactly (with the 400 confirm_name_mismatch code) and audit notes are stored verbatim in the audit event, which is more than the schema conveys.

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 (delete), resource (project), and a hard precondition (NO history, name confirmation). It also names the sibling alternative (tascan_update_project status archived), so an agent can distinguish it from update/archive paths without opening the 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 says when the call is refused (409 project_has_history with counts) and what to do instead (archive via tascan_update_project). It also covers the 503 busy retry path and the exact-match requirement for confirm_name, leaving no routing or retry ambiguity.

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

All TaScan toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources