Record expert reviews by capturing final status, rationale, and reviewer alongside AI drafts to separate human judgment and build training data.
전문가 판단을 기록합니다. target: 가설 ID(P07-H04)·ALIGNMENT·8D 코드(D03) 등. AI 초안과 최종 판단을 분리 보관하며, 누적 기록은 향후 학습 데이터가 됩니다.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| case_id | Yes | ||
| reviewer | Yes | ||
| ai_status | No | ||
| rationale | Yes | ||
| final_status | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does usefully disclose a non-obvious behavior — AI draft and final judgment are stored separately, and records accumulate into future training data — which clarifies the ai_status/final_status split. It says nothing about permissions, overwrite semantics, error behavior, or what the call returns.
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 with no filler, and the core action plus the target-example clarification are front-loaded. The density is appropriate, though it spends more words on the training-data rationale than on the undocumented parameters.
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 6-parameter, 5-required mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers only one parameter's semantics. An agent could not reliably populate reviewer, rationale, or final_status from this definition, leaving a substantial gap.
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 6 parameters, so the description must compensate. It clarifies only 'target' with example value formats (P07-H04, ALIGNMENT, D03); case_id, reviewer, rationale, ai_status, and the critical final_status are left entirely undocumented in both schema and description.
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 names a specific verb and resource ('전문가 판단을 기록합니다' — records expert judgment) and gives concrete examples of the target domain (hypothesis IDs, ALIGNMENT, 8D codes), so an agent knows what this writes. It does not distinguish itself from the near-sibling record_outcome, which is a real ambiguity in this tool set.
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?
No when-to-use, when-not-to-use, or alternative-tool guidance is given. The reader must infer from the target examples alone that this is for human/expert verdicts rather than AI-generated ones; nothing routes the agent between this and record_outcome or save_case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.