search_loading_time_adjustment

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

No annotations are provided, so the description carries the full burden, and it delivers: total record count (35,967), source (odcloud), the naming discrepancy, the critical behavior that filters apply as partial matches only within the current page (not server-side across all records), and the per_page maximum of 1000. It stops short of describing result record fields or pagination metadata, but the behaviors that affect correct invocation are disclosed.

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?

Four tight blocks with zero waste: purpose front-loaded, then the critical naming warning, then filters, then the per_page cap. Every sentence earns its place, and the most important caveat (who this tool is not) appears immediately after the purpose.

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 paginated search tool with 5 optional parameters and no output schema, the description covers the calling semantics well: what is returned, which filters apply, their partial-match scope, and page size limits. It lacks a description of the returned record shape, but that gap is attributable to the missing output schema rather than a description deficiency.

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?

With 0% schema description coverage, the description compensates well: it maps station to 조정역, reason to 조정사유 with concrete example values, region to 조정지역본부, and sets the per_page bound at 1000. It adds the partial-match filter semantics beyond what the schema provides, though it does not specify the expected value format (e.g., station codes vs names).

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+resource ('적하시간 조정 이력 페이지 조회' — loading time adjustment history page lookup) and distinguishes itself from sibling list_standard_loading_time with an explicit naming warning: the data.go.kr registered name is 'standard loading time' but this tool returns adjustment history, while the master is list_standard_loading_time. This removes any ambiguity between the two tools.

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 description explicitly routes the agent: use list_standard_loading_time for master/standard data, and this tool for adjustment history. It also enumerates the available filters (station, reason, region) with example reason values, and warns that filtering is partial-match within the received page, which is essential for correctly interpreting results.

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