Skip to main content
Glama
delimit-ai

delimit

Official
by delimit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Delimit Ledger Done

delimit_ledger_done

Mark a ledger item as done in one call, optionally attaching verified ship proof via commit SHA or PR URL for trustworthy audit trails.

Instructions

Mark a ledger item as done (convenience wrapper).

When to use: to close out a ledger item with one call instead of using delimit_ledger_update with status="done". When NOT to use: to change other fields (use delimit_ledger_update) or create new items (delimit_ledger_add).

Sibling contrast: delimit_ledger_update changes any field; this is the close-out shortcut.

Side effects: writes status="done" + optional note via ai.ledger_manager.update_item. LED-1408 Phase 1: when commit_sha or pr_url is provided (or a PR URL is detected in the note), attaches a ship_proof block to the event with verified=True. Future audits use this flag to distinguish trustworthy-done from marked-done-but-never-verified. Phase 2 will tighten enforcement.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoOptional completion note. If the note contains a GitHub PR URL, it will be auto-extracted as ship proof.
pr_urlNoLED-1408: optional GitHub PR URL proving the fix shipped. Parsed into pr_owner/pr_repo/pr_number; verified=True flag set on the item.
item_idYesLedger item id (e.g. "LED-001"). Required.
ventureNoProject name or path. Empty = auto-detect.
evidenceNoOptional evidence object {class, kind, ref, observed_at, observed_by} (LED-5321 M4). Dict or JSON string.
commit_shaNoLED-1408: optional merge-commit SHA proving the fix shipped. Recorded as ship_proof on the event; verified=True flag set on the item.
review_diff_pathNoOptional diff file path the transcript must bind to.
review_diff_textNoOptional inline diff text the transcript must bind to.
review_transcriptNoOptional transcript path for independently_reviewed binding.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv4.19.1
    • addedInput schema / properties / evidence
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional evidence object {class, kind, ref, observed_at, observed_by} (LED-5321 M4). Dict or JSON string."
+}
    • addedInput schema / properties / review_diff_path
      Added value: +{
+  "default": "",
+  "description": "Optional diff file path the transcript must bind to.",
+  "type": "string"
+}
    • addedInput schema / properties / review_diff_text
      Added value: +{
+  "default": "",
+  "description": "Optional inline diff text the transcript must bind to.",
+  "type": "string"
+}
    • addedInput schema / properties / review_transcript
      Added value: +{
+  "default": "",
+  "description": "Optional transcript path for independently_reviewed binding.",
+  "type": "string"
+}
  2. Changed5 schema fields changedv4.7.9
    • addedInput schema / properties / commit_sha
      Added value: +{
+  "default": "",
+  "description": "LED-1408: optional merge-commit SHA proving the fix shipped. Recorded as ship_proof on the event; verified=True flag set on the item.",
+  "type": "string"
+}
    • changedInput schema / properties / item_id / description
      Previous value: -"The item ID (e.g. LED-001 or STR-001)."New value: +"Ledger item id (e.g. \"LED-001\"). Required."
    • changedInput schema / properties / note / description
      Previous value: -"Optional completion note."New value: +"Optional completion note. If the note contains a GitHub PR URL, it will be auto-extracted as ship proof."
    • addedInput schema / properties / pr_url
      Added value: +{
+  "default": "",
+  "description": "LED-1408: optional GitHub PR URL proving the fix shipped. Parsed into pr_owner/pr_repo/pr_number; verified=True flag set on the item.",
+  "type": "string"
+}
    • changedInput schema / properties / venture / description
      Previous value: -"Project name or path. Auto-detects if empty."New value: +"Project name or path. Empty = auto-detect."
  3. Changed3 schema fields changedv4.5.5
    • addedInput schema / properties / item_id / description
      Added value: +"The item ID (e.g. LED-001 or STR-001)."
    • addedInput schema / properties / note / description
      Added value: +"Optional completion note."
    • addedInput schema / properties / venture / description
      Added value: +"Project name or path. Auto-detects if empty."
  4. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations give readOnlyHint=false and destructiveHint=false, but the description goes well beyond by detailing side effects: writes status='done', optional note via update_item, and the LED-1408 ship_proof attach logic with verified=True. It also explains the audit rationale and future Phase 2 enforcement, which is valuable context not available in annotations.

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?

Well-structured with clear section headers (When to use, When NOT to use, Sibling contrast, Side effects). Every sentence adds value, and the core purpose is front-loaded. Length is justified by the behavioral complexity.

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?

With 9 parameterslor1 required, an output schema, and a complex side-effect chain, the description covers everything: usage conditions, alternatives, side effects, versioning context, and parameter-specific behaviors. An agent can confidently invoke this without additional lookup.

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 mechanism. The description enriches parameters beyond the schema: note auto-extracts PR URLs, pr_url is parsed into pr_owner/pr_repo/pr_number with verified=True, commit_sha recorded as ship_proof. It does not add detail to item_id or evidence, but the schema already covers those.

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 'Mark a ledger item as done (convenience wrapper)' which uses a specific verb and resource. It also contrasts with delimit_ledger_update (changes any field) and delimit_ledger_add (create new items), making it unmistakable from siblings.

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?

Explicit 'When to use' and 'When NOT to use' sections name the exact alternative conditions: use this for close-out only, use delimit_ledger_update for other field changes, delimit_ledger_add for new items. Sibling contrast reinforces the decision boundary.

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