Skip to main content
Glama

goal_refine_batch

Refine multiple project goals in a single batch by reading the source document once, drafting all objectives, and recording doc references while raising unresolved questions as gates.

Instructions

Refine several goals in one call. Drafting is derivable from each goal's own documentation, so the expensive part is the handful of genuine decisions, not a sitting per goal. Read the source document ONCE and slice it by heading — re-reading it per goal is the same file four times. Draft the lot, record the lot with doc_ref so the next pass has a pointer instead of a search, and raise the questions that remain as gates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoDirectory identifying the project and the tree. Defaults to this session's working directory, which in a git worktree is that worktree.
actorNo
goalsYes
conferralNoRequired. ONE conferral and ONE peer call for the whole batch — not one per goal, which multiplies the wall clock by the batch size and asks a worse question each time. The pair argues about the SET of objectives — whether they overlap, whether one swallows another — and that argument does not decompose into one review per goal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

No annotations are present, so the description carries the full burden, and it delivers: it states the tool will read the source document once, slice it by heading, draft all goals, record doc_refs for future passes, and raise unresolved questions as gates. This goes well beyond a generic 'refine' and discloses real side effects and workflow traits. It does not cover reversibility or return values, but for a drafting/refinement tool this is substantive disclosure.

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 appropriately sized and front-loaded with the core purpose. The middle sentence about the 'expensive part' and 'not a sitting per goal' is somewhat rhetorical but still earns its place by justifying the batching pattern. Overall, every sentence adds either instruction or context without excessive bloat.

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

Completeness3/5

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

The schema descriptions, especially for conferral, are rich and fill many gaps. However, the top-level schema marks only goals as required while the conferral description insists it is required—an internal inconsistency the agent must resolve. The main description also leaves the source document unparameterized, and there is no output schema, so return behavior is completely unspecified.

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 50%, with actor having no description at all. The main description adds useful semantics for doc_ref—'a pointer instead of a search'—and for the batch behavior of the goals array. However, it does not clarify cwd, actor, or how the 'source document' mentioned in the description maps to any actual parameter, leaving some semantic gaps.

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 opening sentence 'Refine several goals in one call' is a specific verb+resource statement, and it clearly distinguishes this from the sibling goal_refine by emphasizing the batch nature. The rest of the description reinforces the purpose by outlining the workflow: read once, slice by heading, draft all, record doc_refs, and raise remaining questions as gates.

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 provides clear context for when to use the tool—when several goals need refinement and the source document can be read once—and it explains the efficiency rationale. It does not explicitly name goal_refine as the single-goal alternative or list exclusions, but the batching guidance is strong enough to route an agent appropriately. The conferral parameter description adds the key guideline of one peer call per batch.

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