Skip to main content
Glama
delimit-ai

delimit

Official
by delimit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Delimit Ledger Auto Close External

delimit_ledger_auto_close_external

Auto-close ledger items when their linked GitHub issue or pull request is resolved. Use dry-run for a plan, then apply to mark merged/completed items done and archive others.

Instructions

Auto-close ledger items whose linked GitHub issue/PR already resolved.

When to use: as periodic maintenance to keep the ledger in sync with external reality — LEDs whose tracked GitHub issue/PR is closed/merged should not stay open. When NOT to use: to close one item by hand (use delimit_ledger_done) or to read external state (delimit_resource_get).

Sibling contrast: delimit_ledger_done is per-item; this auto-detects across many items.

Side effects: when dry_run=False, marks/archives via delimit_ledger_bulk under the hood. Default dry_run=True returns a plan only. Detection scans description/context/last_note/tags for github links / shorthand / gh: tag form.

Detection scans description / context / last_note / tags for:

Action map (per LED-1146 deliberation):

  • PR with merged=true → mark_done with merge SHA in note

  • issue/PR closed with state_reason="completed" → mark_done with closed_at

  • issue/PR closed with state_reason="not_planned" or no reason → archive

  • state="open" → leave alone

  • gh API error / 404 → leave alone, recorded in errors

Implementation re-uses bulk_action() under the hood; nothing new on the write path. dry_run=True (default) returns a plan; dry_run=False applies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoTrue (default) returns a plan without writing.
ventureNoproject name or path. Auto-detects if empty.
max_itemsNohard cap on items processed in one call (default 200). When the candidate set exceeds this, the response is `truncated=True`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.7.9

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses meaningful behavioral details beyond the annotations: dry_run defaults to true and returns a plan, false applies changes via delimit_ledger_bulk, detection fields and link formats are specified, an action map covers merged/closed/open/error cases, and errors are recorded. This is thorough and does not contradict the readOnlyHint=false/destructiveHint=false annotations.

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?

The description is well-structured and front-loaded, with clear sections for purpose, usage, side effects, detection, and action mapping. It loses one point because the detection fields are introduced twice in near-identical wording: once in prose and again in the bulleted list.

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 tool of this complexity, the description is remarkably complete: it covers side effects, dry-run behavior, detection patterns, per-state actions, error/404 handling, implementation reuse, and output truncation. The presence of an output schema means return-value details do not need to be repeated.

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%, and the description largely restates what the parameter schemas already say (dry_run plan vs apply, venture auto-detection, max_items cap with truncated=True). It adds no significant parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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: 'Auto-close ledger items whose linked GitHub issue/PR already resolved.' It also distinguishes itself from delimit_ledger_done, making the tool's batch/auto-detection scope immediately clear.

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 concrete alternatives (delimit_ledger_done for manual per-item closing, delimit_resource_get for reading external state) and clarify the periodic-maintenance context. This leaves little ambiguity about when this tool should be selected.

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