list_standard_loading_time

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

No annotations are provided, so the description carries the full burden. It transparently states the source (odcloud), that it returns all 11 records, and the naming discrepancy that could mislead. For a read-only list operation, this is sufficient behavioral disclosure. It doesn't describe return format, but that's minor for a simple master list.

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 and front-loaded: it opens with the core purpose and record count, then adds the critical naming caution. No wasted words, and the structure guides the agent efficiently.

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 simple, parameterless list tool, the description covers the essential context: what the data is, how many records, the source, and the naming caveat. It also routes the agent to the correct sibling for related but different data. The only missing piece is the output fields, but with no output schema, that gap is acceptable for a master list.

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?

The tool has zero parameters, so there is nothing for the description to explain. The schema coverage is trivially 100% and the baseline for 0 params is 4. The description correctly omits parameter details, which are nonexistent.

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 clearly states the tool's purpose: it lists the standard loading time master data (11 items) and returns all of them. It further clarifies the misleading registration name on data.go.kr, so an agent understands exactly what the data represents (standard working times by cargo type). This distinguishes it from the sibling search_loading_time_adjustment which handles adjustment history.

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 states a when-not condition: it directs the agent to use search_loading_time_adjustment for adjustment history. While it doesn't explicitly say 'use this when you need the master list', the purpose statement implies that. The guidance is clear and points to the relevant alternative.

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