전문 도구 실행

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. What the description fails to add is the behavior that actually matters for a dispatcher: what happens when tool_name is unknown or params don't match the target tool's schema, and what the response looks like (the sub-tool's output, presumably).

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 line with no padding, which is good, but here the brevity comes at the cost of under-specification rather than discipline — the dispatch contract is not explained at all.

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 an open-world meta-dispatcher with a free-form nested params object and no output schema, the description should at minimum say how to discover valid tool_name values and how errors are surfaced. Neither is present, so an agent must guess before it can invoke this correctly.

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 coverage is 100% and both parameters are described in the schema, so the baseline of 3 applies. The description restates the same two fields and adds nothing about the crucial constraint that the params object must conform to the signature of whichever tool tool_name selects — a nested-object semantic the schema cannot express.

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?

"[메타] 전문도구를 이름(tool_name)과 인자(params)로 실행" states the verb (execute) and the resource (a specialized tool), plus the dispatch mechanism. However, it never says what a "전문도구" is in this server's context or points to discover_tools as the source of valid names, so the agent cannot map it against nine siblings on the description alone.

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?

There is no statement of when to call this dispatcher instead of calling search_law, legal_research, get_law_text, etc. directly, and no mention of discover_tools as the prerequisite for obtaining a valid tool_name. The only guidance is implicit in the word "[메타]".

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