Delegate a bounded task to a Luna worker

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

With no annotations provided, the description carries the full behavioral disclosure burden and does so thoroughly. It reveals that the worker cannot see the conversation or delegate, automaticRepair allows at most one conservative same-thread repair, the runtime reruns declared checks and reconciles edits, PASS returns a text-only VERIFIED_COMPLETE handoff, and failure/blocked results expand with evidence. It also states worker claims are not authoritative and the parent owns nonautomatic actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place for a 20-parameter delegation tool. It is front-loaded with the core contract, then proceeds through submission requirements, runtime behavior, and agent etiquette. There is no filler and no repetition of schema enums.

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

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

For a tool with no output schema, the description explains result types, handoff behavior, failure expansion, and verification semantics well. It covers when to delegate and what the worker can and cannot do. It is slightly less complete on explicit routing among sibling tools and on a few top-level parameters, but overall it gives an agent enough to invoke the tool correctly.

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

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

Schema description coverage is only 10%, but the description compensates for the most important parameters: it tells the agent to provide a self-contained objective, effortReason, acceptanceCriteria, verificationCommands, changeIntent, and honest scopes; it clarifies activityLabel should be concise and only for repository-unavailable context; and it explains the behavior of automaticRepair and the default resultDetail=handoff. Some parameters such as contextCapsule, previousAttempts, and timeoutSeconds are left to schema inference, which keeps this from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Delegate ONE substantial, bounded executable seam to gpt-5.6-luna.' It also distinguishes itself from sibling tools by emphasizing this is a single-seam delegation, not a multi-seam or parallel operation, and lists allowed task categories. The parent/worker ownership split further clarifies what this tool is for.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: 'Keep small, simple, or tightly coupled work solo' and 'Delegate only when ownership, isolation, context, verification, latency, coordination risk, quality, and current parent-conditional credit economics beat fixed overhead.' It also tells the agent to remain silent while pending and to report only meaningful state changes. This is strong operational guidance, even though it does not name sibling tools explicitly.

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