get_construction_progress

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

With no annotations, the description carries the behavioral disclosure burden and does well: it discloses that gu_name and min_amount are filtered client-side after retrieval, that 0 progress values should be displayed as '미입력', and that source attribution is mandatory when citing results. It could mention pagination or rate limits, but the disclosed behaviors are meaningful and non-obvious.

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 a compact paragraph that front-loads the core purpose, then adds filtering behavior, display conventions, and citation requirements. Every sentence adds relevant operational context, though a minor typo ('담당자' appears as '담당자') and slight redundancy with schema descriptions prevent a perfect score.

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 tool with no annotations and no output schema, the description covers the key operational needs: what is returned, how filtering works, how to handle zero values, and the mandatory source citation. It could be more complete about result ordering, API metadata, or error behavior, but the core information needed to invoke and interpret results is present.

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 input schema already provides 100% parameter descriptions, including the client-side filtering notes for gu_name and min_amount. The tool description adds little parameter-level meaning beyond restating that search is keyword-based and that filtering happens client-side. Baseline 3 is appropriate because the schema does the heavy lifting.

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 it searches Seoul construction progress data by business name and ordering agency keyword, and enumerates the specific fields returned (progress rates, amounts, responsible parties, location). It does not explicitly distinguish itself from sibling tools like search_construction_projects, but the emphasis on progress-specific fields makes the purpose reasonably clear.

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 gives useful context about client-side filtering for gu_name and min_amount, but it provides no guidance on when to use this tool versus the sibling tools such as search_construction_projects or search_construction_work_by_district. There are no explicit exclusions or alternative-selection criteria.

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