Skip to main content
Glama

trw_deliver

Persist learnings and progress from this session to future ones by checkpointing, reflecting, and running background housekeeping.

Instructions

Persist learnings and progress so future sessions inherit this session's work.

Use when:

  • Your session is about to end and you want discoveries to persist for future agents.

  • A milestone is reached and you want to close out the current run directory.

Before calling, check: did you record at least one discovery with trw_learn? If not, add even a one-line root-cause learning so the next agent avoids re-discovery.

Runs reflect + checkpoint synchronously, then launches housekeeping (consolidation, publish, telemetry, tier sweep) in the background. Background work is concurrency-safe — overlapping batches are skipped rather than queued.

Input:

  • run_path: path to run directory (auto-detected if None).

  • skip_reflect: skip reflection step (e.g., already reflected).

  • skip_index_sync: skip INDEX/ROADMAP sync step.

  • allow_unverified: explicit override for delivery without a passing trw_build_check record. Use only for documented acceptable failures.

  • unverified_reason: required rationale when allow_unverified is true.

Output: DeliverResultDict with fields {run_path: str, reflect: dict, checkpoint: dict, deferred: str, critical_steps_completed: int, deferred_steps: int, errors: list, success: bool, learning_reflection?: str}.

Example: trw_deliver() → {"run_path": "/path/...", "critical_steps_completed": 2, "deferred": "launched", "success": true}

See Also: trw_checkpoint, trw_instructions_sync

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
run_pathNo
skip_reflectNo
skip_index_syncNo
allow_unverifiedNo
unverified_reasonNo
Behavior4/5

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

Since no annotations are provided, the description carries the full burden. It explains synchronous execution of reflect and checkpoint, then asynchronous background work with concurrency safety (overlapping batches skipped). However, it doesn't detail error handling or what happens on failures beyond the output errors field. Still, it covers key behavioral traits well.

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 sections: purpose, use cases, pre-check, behavior, parameters, output, example, see also. Each sentence adds value; no fluff. The length is appropriate given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description provides a detailed output structure with field names and types, plus an example. It covers the essential aspects but could be more explicit about some fields like 'deferred' and 'critical_steps_completed'. Overall, it gives enough context for an agent to understand what to expect.

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?

Despite 0% schema description coverage, the description explains each parameter clearly: run_path (auto-detected), skip_reflect, skip_index_sync, allow_unverified (explicit override), unverified_reason (required rationale). This adds significant meaning beyond the bare schema, though it doesn't elaborate on data types beyond what the schema provides.

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 clearly states the tool's purpose: 'Persist learnings and progress so future sessions inherit this session's work.' It uses a specific verb (persist) and resource (learnings and progress). It also distinguishes from siblings by listing see-also tools and explaining what this tool does differently (e.g., background housekeeping vs trw_checkpoint).

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 provides 'Use when' scenarios: session about to end, milestone reached. Includes a precondition check ('did you record at least one discovery with trw_learn?') and advice to add a learning if not. This gives clear decision support for when to call the tool.

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/wallter/trw-mcp'

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