신청내역 조회

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

Annotations already declare readOnlyHint=true, and the description reinforces this with '저장하지 않는다' while spending its words on non-obvious behavior: the implicit 6-month lookback window and the status-code semantics. It does not discuss pagination limits or result volume, which is a modest remaining gap for a list tool.

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?

Front-loaded with the resource and returned fields, then defaults, then status mapping, then the delete/withdraw use case — each sentence carries information. Minor waste in restating the read-only nature, and the sentence about 'progress 는 목록 아이콘 기준' refers to a field that is not a parameter, which briefly muddies an otherwise tight description.

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?

With 7 optional parameters, no output schema, and a broad open-world read, the description compensates well by enumerating the returned column set and the status vocabulary. Missing only pagination guidance and any note on how many results to expect when the default 6-month window is large.

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, and the description mostly matches what the schema already says (defaults for fromYmd/toYmd, empty statuses = all). It does add real value by mapping statuses values to Korean labels and numeric codes (approving=결재중(200) etc.), which the schema's undocumented enum does not provide, plus an applType example; that slightly exceeds baseline but does not cover keyword/applType interaction.

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?

Names the specific screen/tab (「신청 > 신청내역」) and enumerates the exact columns returned (신청일시, 신청서 유형, 진행상태, APPL_ID, 신청내용, 대상자), so an agent knows precisely what this returns rather than guessing from the opaque name 'jade_applications'. It falls short of 5 because it never distinguishes itself from the closely-named sibling jade_recent_applications, leaving overlap unresolved.

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 conditions and defaults: empty period means 6 months back to today, empty statuses means all, and it explicitly states the tool is also the way to find APPL_IDs for deletion or withdrawal (routing toward jade_prepare_delete_applications). No exclusion or negative guidance is offered, e.g. when to prefer jade_recent_applications instead.

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