oss_unit_complete

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

With no annotations, the description carries full burden — and it does disclose two significant behaviors: a hard rejection path that returns a missing-symbols list, and an automatic side effect that creates unknowns when the target grade is unmet. That side effect is exactly the kind of contextual info that earns credit. What is missing is whether completion is reversible, what the returned payload looks like beyond the failure case, and what permissions or preconditions govern success.

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?

Three short sentences, front-loaded with the core action before the failure and side-effect clauses. Nothing is padded. It is arguably too terse for the complexity of the operation, but not wasteful.

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 state-transition/mutation tool with no annotations, no output schema, and four undocumented parameters, the description covers only failure semantics. It leaves the agent guessing about the required summary text, the meaning of agent, and what a successful return looks like — significant gaps for a tool that also auto-creates records.

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 0% across four parameters, including the required project_id, unit_id, and summary. The description mentions none of them — not what summary should contain, not what agent defaults to or does. With zero schema help, the description must compensate and instead says nothing.

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?

"단위 완료" (complete a unit) names the action and resource, and the follow-up clauses sketch two gating behaviors. But it never says what a 'unit' is in this system or how this differs concretely from siblings like oss_unit_next, oss_unit_renew, or oss_unit_context. Purpose is inferable, not stated with precision.

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 rejection rule ("검토 안 된 심볼이 있으면 거부") implicitly tells the agent this is the terminal step after symbol review, which is useful usage context. However, there is no explicit when-not guidance, no mention of prerequisites such as claim review state, and no routing to alternatives such as oss_unknown_record when the call is rejected.

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