Server Quality Checklist

Tool Scores

• exploreA
  4.1/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 burden and does so unusually well. It discloses that execution is 'fixed read-only disposable,' that it returns 'provenance-marked worker claims, runtime facts, inferences, and unknowns,' and that it 'implements nothing, cannot delegate, and is never automatic.' This gives an agent a clear safety and side-effect profile.

  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 two efficient sentences with zero filler. Purpose and scope are front-loaded, followed immediately by behavioral disclosures and exclusions. Every clause adds information.

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

  Completeness2/5

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

  This is a complex tool — 13 parameters, nested objects, no output schema, and no annotations — so the description alone is insufficient for correct invocation. It explains the high-level behavior well but does not clarify target vs scope, effortReason requirements, resultDetail choices, computePolicy, or output structure. An agent could select the tool but would struggle to call it correctly.

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

  Parameters2/5

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

  Schema description coverage is only 8%, and the description barely compensates: 'repository, API, or documentation scope' hints at target/scope, but the 13 parameters — including required effortReason — receive no meaningful explanation. The schema itself has no descriptions for most properties, so an agent lacks essential parameter semantics.

  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 uses a specific verb and object phrase: 'Explicitly explore an admitted repository, API, or documentation scope' — so an agent knows exactly what the tool acts on. It also differentiates from siblings by adding 'Implements nothing, cannot delegate, and is never automatic,' which separates it from delegate_task and routing_preflight. This goes beyond a generic restatement.

  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?

  The opening clause gives clear usage context: use this for explicit exploration of an admitted scope. The additonal exclusions — 'cannot delegate' and 'never automatic' — tell an agent when not to expect delegation or autonimous routing. Alternatives are not explicitly named, but the behavior boundaries are strong enough to guide tool selection.

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

• routing_preflightA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It explicitly states 'Creates no worker, batch, worktree, or thread, refuses nothing' – clearly disclosing side-effect-free behavior. It describes the return values (route, deciding signals, structural parallel eligibility) and explains how unknown inputs bias results toward solo. The advisory and non-required nature is also disclosed, giving the agent complete understanding of behavioral traits.

  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 front-loaded with the core purpose in the first sentence. It then flows naturally from usage timing to input guidance to output and interpretation. It is three sentences but dense, with each clause earning its place. Slightly verbose with multiple embedded clauses, but still well-structured and avoids fluff.

  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?

  Despite having 6 parameters and no output schema, the description covers all essential aspects: what the tool does, when to use it, its side-effect-free nature, the input guidance (include seams, mark unknowns), the output format (route, deciding signals, eligibility), and how to interpret results (either requires justification). An agent has enough information to call it correctly without further lookup.

  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 description coverage is 0%, so the description must compensate. It provides a high-level hint: 'Declare the ownership seams you are considering and what they share' – this loosely maps to seams and sharedState/coreOverlap. It also advises leaving fields 'unknown' when unsure. However, it does not explain the semantic meaning of seamSize, integration, or verification individually, leaving some parameters under-documented. The description adds some value but does not fully compensate for the schema gap.

  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 'Cheap deterministic check of whether delegating is structurally sound and economically sensible, before any repository exploration.' This is a specific verb (check) and resource (delegating) with a clear scope and timing. It distinguishes itself from siblings like delegate_task by explicitly stating it creates no worker/batch/worktree/thread, making it clear it is a preflight rather than an execution tool.

  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?

  The description states it is used 'before any repository exploration' and is 'advisory only and never required', clarifying it is a precursor to actual delegation. It also explains when the output suggests staying solo vs. delegating ('either means fixed delegation overhead needs explicit justification, otherwise stay solo'). However, it does not explicitly name sibling tools or state 'use delegate_task instead when you are ready to execute', so the contrast with alternatives is implied rather than explicit.

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

• continue_taskA
  4.7/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 does so thoroughly. It discloses immutability of the original contract, no widening fields, no delegation, no automatic repair, re-running of verification/scope/evidence checks, resultDetail mode semantics, silence while pending, and the allowed report outcomes. This is exceptional transparency.

  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 dense but every clause earns its place, covering action, constraints, mutation semantics, verification behavior, output modes, and communication protocol. The primary action is front-loaded in the first sentence, and the rest provides necessary behavioral guardrails without fluff.

  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?

  Given no annotations, no output schema, and the subtle semantics of continuation, the description is remarkably complete. It explains eligibility constraints, single-use token behavior, immutability, what will not happen, what checks rerun, mode defaults, and when to stay silent versus report. There is little an agent would need to infer on its own.

  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 description coverage is 0%, so the description must compensate. It adds real semantics for the key parameters: 'opaque single-use continuationReference', 'one bounded instruction', and 'handoff is default; compact/full are compatibility modes' for resultDetail. It does not provide exhaustive per-parameter descriptions, but what it adds is meaningful and sufficient for invocation.

  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 names a specific verb ('Continue'), a specific resource ('ONE eligible task'), and critical constraints ('once in the same Luna Codex thread', 'opaque single-use continuationReference'). It is clearly distinguished from siblings by explicitly noting 'Luna cannot delegate', so an agent can tell it apart from delegate_task/delegate_tasks.

  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?

  The description clearly states the context for use: continuing an existing task in the same thread with a continuation reference. It provides exclusions such as 'Luna cannot delegate' and 'continuation never starts automatic repair', which helps differentiate from delegation and repair workflows. It does not name the exact alternative tool names, but the usage context is strong.

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

• delegate_taskA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• delegate_tasksA
  4.9/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It goes far beyond a basic summary by specifying concurrency limits, queueing, retry rules, automaticRecovery defaults, repair scope, integration behavior, completionState semantics, and reporting etiquette. This is exceptional transparency for a complex tool.

  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 long and dense, but the tool is genuinely complex and nearly every sentence adds an operational constraint or decision rule. It is grouped into thematic paragraphs and front-loaded with the primary purpose, but it is still a wall of text rather than a structured, skimmable format.

  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?

  Given the tool's complexity, absence of annotations, and absence of output schema, this description is remarkably complete. It covers selection criteria, operational limits, concurrency and queueing, integration and overlap semantics, retry and recovery behavior, failure handling, result semantics, and even reporting etiquette. An agent has enough context to decide when to call it and how to configure a valid batch.

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

  Parameters5/5

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

  Schema description coverage is only 22%, so the description must compensate, and it does. It explains the behavioral meaning of allowOverlappingScopes:true, integrate=false, resultDetail, automaticRepair, automaticRecovery, and sequential/parallel mode, which the bare schema enums do not provide. It also gives practical guidance like requiring self-contained contracts and concise activityLabels.

  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 states a specific verb and resource: delegate a batch to Luna workers. It also differentiates from the sibling tool delegate_task by explaining that a single task is accepted for compatibility but delegate_task is preferred when no scheduling is needed.

  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?

  The description explicitly says when to prefer delegate_task, and gives clear rules for choosing sequential vs parallel: sequential for dependencies/shared state, parallel only for independent disjoint scopes. It also forbids artificial seams, leaving no ambiguity about when this tool is appropriate.

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