Trace citation relationships for a Korean court precedent: outgoing statute/case references, later citing cases, constitutional decisions, and signals of no citations, citations, or possible changes.
판례 한 건의 인용 관계를 본다: 참조조문·참조판례(나가는 참조), 그 사건번호를 본문에 담은 후속 판례(들어오는 인용), 관련 헌재결정, 그리고 '후속 인용 없음/인용됨/변경 가능성' 신호와 근거.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| depth | No | ||
| caseNo | No | ||
| include | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read, so the bar is lower. The description usefully discloses the return categories and that a status signal ('후속 인용 없음/인용됨/변경 가능성') comes with its basis, but says nothing about depth semantics, result limits, or how the const depth=1 constrains output.
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 front-loaded sentence with a colon-enumerated breakdown of outputs; dense but every clause carries content. Slightly heavy as one sentence, but nothing is wasted.
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 output schema, the description does well to describe the return structure, which is its main strength. However, for a 4-parameter tool at 0% schema description coverage, the ambiguity between 'id' and 'caseNo' and the unexplained 'depth' leave an agent without enough to construct a correct call in all cases.
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 0%, so the description must carry the load. It effectively documents the three values of the 'include' parameter (outgoing/incoming/constitutional map directly to the Korean categories), but the distinction between 'id' and 'caseNo' and the role of 'depth' remain unexplained.
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 specific verb and resource ('판례 한 건의 인용 관계를 본다' — view the citation relationships of a single precedent) and then enumerates exactly what the trace covers: outgoing references, incoming citations, Constitutional Court decisions, and the citation-status signal. This is distinct from siblings like citation_audit or source_search, so an agent can route correctly.
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?
Usage is implied by the enumerated outputs — you would call this to inspect a single precedent's citation network — but there is no explicit when-to-use statement, no when-not-to-use, and no named alternative among the many siblings. Adequate but leaves the agent to infer the trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.