lesson_get

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

No annotations are provided, so the description carries the full disclosure burden. 'As-is' (그대로) is a useful note that no transformation occurs, but it says nothing about required permissions, behavior when course_dir or lesson_id does not exist, or error conditions for what is likely a file-backed read.

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?

A single short sentence with the action front-loaded and the usage hint in a trailing parenthetical. Nothing is wasted, though the terse phrasing leaves the tool under-explained rather than over-explained.

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?

With no annotations, no output schema, and 0% parameter coverage, the description should explain the shape of the returned lesson JSON and the meaning of course_dir. It does neither, leaving meaningful gaps for a tool that is the read half of an edit workflow.

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%, so neither course_dir nor lesson_id is documented anywhere. The description only implies that a single lesson is fetched and adds no detail about whether course_dir is a path or slug, nor what lesson_id indexes into.

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 states a specific verb and resource ('레슨 JSON 하나를 그대로 돌려줍니다' — return one lesson JSON verbatim), which lets an agent distinguish it from lesson_save or lesson_validate. It does not name any sibling tool explicitly, so it stops short of full differentiation.

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 parenthetical '(고쳐 쓸 때)' signals the intended context — use this before editing a lesson — which implicitly pairs it with lesson_save. However, no alternatives are named, and there is no guidance on when not to use it or on prerequisite ordering with lesson_validate.

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