한국 낚시 지수 — 지점별 대상어종, 물때 시간대, 파고·수온·풍속과 종합 판정. 갯바위/선상 구분. "오늘 어디 낚시 갈만한가"에 답한다.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYYMMDD. 생략하면 오늘(KST) | |
| kind | No | "갯바위"(기본) 또는 "선상" | |
| limit | No | 최대 건수 (기본 10, 최대 50) | |
| place | No | 지점명 일부 (예: "가거도", "여수"). 생략하면 전국 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what data the tool returns and implies a read-only query operation ('answers' a question), but it does not explicitly state that it performs no mutations, require no authentication, or have any side effects. The absence of such explicit disclosure is a minor gap, but the nature of an 'index' tool suggests non-destructive behavior.
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?
The description is concise, two sentences, and front-loads the core purpose and key outputs. It avoids fluff and is well-structured. It could be slightly more structured by separating the purpose from the details, but it is efficient and readable.
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?
Given the tool is a query with four optional parameters and no output schema, the description provides a solid overview of what the result will contain (species, tides, wave, temp, wind, overall judgment, and type distinction). It does not specify the exact response format, but for a simple lookup tool this is sufficient. The absence of annotations is compensated by the clear scope and expected outputs.
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 100%, so all four parameters (date, kind, limit, place) are already documented in the schema. The description does not add any additional meaning about parameter usage, formats, or relationships. It meets the baseline but does not go beyond what the schema provides.
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 ('answers where should I go fishing') and resource (Korea fishing index), and enumerates the data it provides (target species, tidal times, wave height, water temp, wind speed, overall judgment). It clearly distinguishes from sibling indexes by focusing on fishing, but it does not explicitly name an alternative or contrast with them, so it falls short of a perfect 5.
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 phrase '오늘 어디 낚시 갈만한가' (where should I go fishing today) gives an implied usage context, but the description does not state when not to use it, what alternatives exist (e.g., beach or scuba indexes), or any prerequisites. Usage guidance is present but only implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.