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

Annotations declare readOnlyHint=false with destructiveHint=false, and the description explains why: each call consumes one token, creates an XBOSS job, and stores the result, so the call is explicitly "not purely read-only" even though it looks like a fetch. It also covers anonymous accessibility and idempotency-key recovery semantics for lost responses, all beyond what the annotations state. Minor deduction for the ambiguous phrase "not available to anonymous taste calls," which leaves the anonymous/auth boundary unclear.

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 purpose is buried behind an opening credential sentence, and roughly half the text is reusable idempotency boilerplate rather than tool-specific information. The bilingual split also produces redundancy, with the Korean portion partly restating the read-only caveat, and the "taste calls" typo adds noise.

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 3-parameter tool with full schema coverage, annotations, and no output schema, the description covers auth, cost, side effects, and key semantics adequately. What it leaves out is what an agent most needs for an attachments endpoint: whether the response is attachment metadata or downloadable content, and how it relates to the files__download sibling.

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 would be 3, but the description adds real meaning for request_idempotency_key: reuse the same key with the same arguments only to recover a lost response, use a new key for a new execution, and omitting it makes a repeat call a new request. It also clarifies that a provider-specific idempotency_key is a different field that must not be altered, which prevents a likely confusion.

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?

"Get institution notice attachments" states a specific verb and resource, and the required pst_sn parameter confirms it operates on a single post. It does not differentiate itself from the sibling detail/list tools or clarify whether it returns attachment metadata or file content (files__download exists as a separate tool), so an agent can identify the resource but not the exact output shape.

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 establishes that no credential or login is required, which is useful context for choosing this call, and it warns that a token is consumed per call. However, it never says when to use this instead of institutions.detail or files.download, nor does it state any preconditions beyond obtaining pst_sn from institutions.list.

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