Skip to main content
Glama

goal_refine

Record a goal's objective after a refinement session to capture what is actually being achieved, so workers can tell whether a feature serves it.

Instructions

Record a goal's objective after a refinement session with the principal. A goal carrying only a name and a priority is a filing label: nothing in it says what is being attempted, so a worker cannot judge whether a feature actually serves it. Do NOT call this mid-discussion — record once, when consensus is reached.

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.
nameYes
actorNo
statusNo
doc_refNoWhere the objective was lifted from — file plus heading, e.g. "docs/feature_tracking.md#go-live-gates-glg". Record it even when the document was thin, so a later reader can tell a lifted objective from an invented one, and so the next pass reads one section instead of re-grepping the whole file.
priorityNoLower is worked first.
non_goalsNoWhat is deliberately excluded. The part people skip and the part that matters: goal drift is rarely someone pursuing the wrong objective, it is someone pursuing a defensible neighbouring one.
objectiveNoWhat is actually being achieved, in the principal's terms, not the code's.
rationaleNoWhy it matters, and what happens if it is not done.
done_meansNoHow anyone can tell the goal is finished rather than merely worked on.
constraintsNoWhat must hold — budget, latency, compatibility.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral disclosure burden. It implies a persistent write that should occur exactly once and explains the state it addresses, but it does not state whether an existing objective is overwritten, whether the goal must already exist, or what response the agent should expect. Those gaps keep it below a 4.

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 three purposeful sentences: one for the action, one for the rationale, and one for the timing rule. It is front-loaded with the core directive and contains no filler.

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 write tool with no annotations and no output schema, the description plus the rich parameter schema is mostly sufficient. An agent understands what to do, when to do it, and what the core fields mean. It falls just short of fully complete because required-name semantics, overwrite behavior, and return behavior remain implicit.

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 73%, and most parameters already carry detailed descriptions in the schema itself. The narrative adds conceptual value about objective versus name/priority, but it does not clarify undocumented parameters such as `name` and `actor`, nor does it compensate for all gaps across the 11-parameter surface.

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 names a specific action and resource: record a goal's objective after a refinement session. The filing-label explanation further clarifies why this is needed and distinguishes it from merely listing or naming goals, so an agent can recognize the intended operation.

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 a clear trigger ('after a refinement session with the principal') and a clear prohibition ('Do NOT call this mid-discussion — record once, when consensus is reached'). It directly addresses the timing risk for this tool, which is strong practical routing even without naming a sibling tool.

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