Skip to main content
Glama
delimit-ai

delimit

Official
by delimit-ai
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Delimit Ledger Done

delimit_ledger_done

Close out a ledger item in one call, marking it done and optionally attaching PR URL or commit SHA as verified proof. Use to mark completion without editing other fields.

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.
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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 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."
  2. 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."
  3. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only mark readOnlyHint=false and destructiveHint=false, leaving the mutation profile unspecified; the description fills this by stating it 'writes status="done"' and calls ai.ledger_manager.update_item. It also discloses the conditional side effect of attaching a ship_proof block with verified=True and mentions Phase 2 changes, which are exactly the behavioral traits an agent cannot infer from the schema.

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?

The description is front-loaded with the one-line purpose, then uses clear headings for usage, alternatives, and side effects. It is a few sentences longer than minimal, but each section earns its place; no filler.

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?

The tool has a rich 100%-covered schema, an output schema, and non-conflicting annotations, so the main missing context was when to use it and what side effects it triggers, both covered. An agent has enough information to select it, call it with correct parameters, and anticipate the verified=True behavior.

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

Parameters3/5

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

Schema coverage is 100%, with each parameter already documented (e.g., pr_url says it is parsed into pr_owner/pr_repo/pr_number and sets verified=True). The description cross-references the ship-proof behavior but does not need to add per-parameter detail; baseline 3 applies.

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?

Description opens with a specific verb and resource: 'Mark a ledger item as done (convenience wrapper).' It immediately positions itself against delimit_ledger_update ('this is the close-out shortcut'), so an agent can distinguish it from the large ledger sibling family.

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 state the condition for choosing this tool (single-call close-out) and direct other field edits to delimit_ledger_update and creations to delimit_ledger_add. Sibling contrast reinforces the distinction, so routing is unambiguous.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/delimit-ai/delimit-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server