Skip to main content
Glama
sleepunit-agents

loom

by sleepunit-agents
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

harness_init

Scaffold a harness manifest from a template when missing, and optionally install or repair a managed loom block in a target file.

Instructions

Scaffold a harness manifest at /harnesses/.md from the template (see stack spec v1 §4.7). Call this when identity() reports a missing manifest for the current harness. Idempotent: skip-exists by default; overwrite: true replaces.

When target is supplied, also writes a loom-managed block (bounded by markers with an embedded line) into that file — typically the project CLAUDE.md. Re-runnable: the block is left unchanged when already present and intact ("no-change"), reinstalled when missing or corrupted ("created" / "updated"). Pass an absolute path or a path relative to the current working directory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesHarness name (e.g. "claude-code", "codex", "gemini-cli")
targetNoPath to the dotfile to inject the managed loom block into (e.g. an absolute path to CLAUDE.md / AGENTS.md / GEMINI.md). When omitted only the harness manifest is scaffolded.
overwriteNoReplace existing manifest (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / target
      Added value: +{
+  "description": "Path to the dotfile to inject the managed loom block into (e.g. an absolute path to CLAUDE.md / AGENTS.md / GEMINI.md). When omitted only the harness manifest is scaffolded.",
+  "type": "string"
+}
  2. First observedv0.4.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and meets it: idempotency, skip-exists default, overwrite semantics, exact loom marker syntax, and re-run behavior for intact vs missing/corrupted blocks are all disclosed. It also clarifies path resolution for the target parameter.

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 information-dense without fluff: first sentence states the core action, second gives the trigger, and a separate paragraph layers the optional target behavior. Every sentence carries actionable detail such as statuses and path rules, and the structure mirrors the tool's two operating modes.

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?

The description covers main action, optional target behavior, idempotency, marker boundaries, and path syntax, which is sufficient for a moderately complex tool with no output schema. It does not explicitly describe the return value shape or what happens if the target file is absent, but the quoted statuses imply the observable outcomes.

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% and the schema already names parameters well; the description adds meaningful context for target (managed block, markers, re-run behavior, path resolution) and overwrite (default false replaces). It adds less beyond the schema for name, but the overall parameter guidance is solid.

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 uses a specific verb 'Scaffold' with a concrete resource and destination: a harness manifest at <contextDir>/harnesses/<name>.md from the template. It also identifies the triggering condition (identity() reports a missing manifest), which distinguishes the tool from maintaining or describing existing harness state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a clear when-to-use trigger: call when identity() reports a missing manifest, and explains the overwrite option for existing manifests. It does not name alternatives or explicitly state when to use update/harness_describe instead, but the invocation condition is unambiguous enough for correct selection.

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