Validates lesson JSON and saves it to lessons/NN.json, overwriting files with matching IDs. Ensures only error-free lesson definitions are persisted.
레슨 JSON을 검사하고, 오류가 없으면 lessons/NN.json으로 저장합니다(같은 id면 덮어씀). lesson = {"id": 1, "group": "...", "title": "...", "sub": "...", "ops": [...]}
| Name | Required | Description | Default |
|---|---|---|---|
| lesson | Yes | ||
| course_dir | 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 disclose two valuable traits — the validation gate and that an existing file with the same id is overwritten — but says nothing about what happens on validation failure, whether it returns errors, or what the file path pattern NN resolves to. Overwrite is disclosed, but overall coverage for an unannotated mutation tool is thin.
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?
Two short lines, with the operation and the overwrite caveat front-loaded and the object shape as a compact reference. No wasted prose, though the schema example is bare.
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 two-parameter mutation tool with no annotations, no output schema, and an untyped nested object, the description covers the shape of lesson but omits course_dir semantics and any return/error behavior. Adequate to start, incomplete for correct invocation.
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% and the lesson parameter is a free-form nested object, so the inline key list (id, group, title, sub, ops) adds real value beyond the schema. However, course_dir — a required parameter — is completely unexplained, leaving half the parameters undocumented.
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?
States a concrete two-step verb sequence (validate then save) on a specific resource, plus the destination path 'lessons/NN.json'. It doesn't name lesson_validate or explain how it differs, so sibling differentiation is only implicit in the validate-then-save phrasing.
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 conditional 'if there are no errors, save' implies when the tool proceeds, but there is no explicit when/when-not guidance and no mention of the sibling lesson_validate as the check-only alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.