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

Goes well past the readOnlyHint annotation: explains that the server scans the date window and post-matches the registration number, that empty results mean 'no hit in this window — not a certified clean claim', that it uses a platform service key with no account_link_id, and that each call consumes one token. The idempotency-key lifecycle (save before first request, reuse only to recover a lost response, new key for new execution, distinct from provider idempotency_key) is unusually explicit.

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?

Purpose and the critical date-window constraint are front-loaded, and nearly every sentence adds operational value. The idempotency-key paragraph runs four sentences and could be tightened, and the trailing Korean token-cost note is structurally orphaned.

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 9-parameter read tool with no output schema, the description covers matching logic, empty-result interpretation, auth model, and cost, which is what an agent needs to invoke it correctly. It stops short of describing row contents or what a match record looks like, though the schema's ncrMasterNum reference partially compensates.

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 100%, so the baseline is 3; the description nonetheless adds real meaning by clarifying the sDate/eDate-vs-bizno relationship (bizno is matched against scanned rows, not sent upstream) and the corp_name fallback condition. It does not explain maxPages/numOfRows scanning tradeoffs beyond what the schema already says.

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 ('Look up KISCON construction-firm disclosure rows') and pins the upstream source (data.go.kr 15061362 ConAdminInfoSvc1/GongsiReg), so an agent knows exactly which registry is queried. Sibling differentiation is only implicit — it never names opendata__g2b__sanction or opendata__env__waste_sanction to contrast scope.

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?

Gives concrete operating context: upstream requires sDate/eDate rather than bizno, and corp_name is only a fallback when the row lacks a registration number. It also explains when to reuse vs. mint a new idempotency key and notes the key is unavailable to anonymous calls, but never states when to prefer this tool over the sibling sanction tools.

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