MyFSS

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

Beyond the read-only/idempotent annotations, the description explains truncation semantics, unknown-id errors, fallback to detail-page HTML body, and that parsed=false attachments are excluded from body. It also tells the caller how to continue reading and how max_chars affects the whole response.

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 front-loaded with purpose and structured into Purpose/Usage/Response/Rules sections. It is somewhat long, and truncation/continuation behavior appears in both the Response and Rules sections, but the detail is largely justified because there is no output schema.

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?

There is no output schema, so the description carries the full burden of explaining return fields, truncation flags, error shape, fallback body behavior, and attachment parsing gaps. It is complete enough for an agent to invoke and interpret the result correctly.

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, but the description adds meaningful semantics: ntt_id comes from prior search/list results, offset_chars continues a truncated document, and raising max_chars grows the entire response. The examples map natural-language requests to specific parameter values.

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 states a specific verb and resource: it returns the full document body, specifically parsed HWP attachments converted to markdown. It immediately distinguishes the tool from summary/snippet results by saying those are never quoting grounds.

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?

It gives explicit scenario examples, including reading a found document, continuing a truncated document with offset_chars, and requesting a short prefix with max_chars. It does not explicitly say when to use search_documents/list_recent instead, but the 'found document' framing and ntt_id requirement make the intended workflow clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description goes well beyond by disclosing there is no pagination or total/offset, no snippet because there is no query, and that date sorting means retroactively registered old documents never surface as new. The response object shape is also spelled out field-by-field, which is valuable since no output schema exists.

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?

Bracketed headers ([Purpose], [Usage], [Response], [Rules]) make it front-loaded and scannable, and every line carries information. It is somewhat longer than a two-parameter tool strictly requires, but no sentence is filler.

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, zero-required-parameter read tool with no output schema, the definition covers ordering, filtering, response fields, the absence of pagination, and the key/label asymmetry. Nothing an agent needs to call it correctly is missing.

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% with an enum on board, so the baseline would be 3, but the description adds a genuinely non-obvious constraint: board accepts the English key while the response returns the Korean label, and the response board value must never be fed back as a parameter. That asymmetry is exactly the kind of semantic detail the schema cannot express.

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 first sentence states a specific verb (반환합니다/list) and resource (최신 문서 목록) plus ordering (게시일 내림차순), and the Usage section implicitly separates it from search_documents. An agent can tell this is a query-less browse tool, distinct from get_document and search_documents, without opening the schema.

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?

Three concrete user-utterance-to-parameter mappings (no args → limit=20; sanction_case + limit=10; fsc_press) give the agent worked examples, and the closing rule explicitly routes period/topic narrowing or larger volumes to search_documents. Both when-to-use and the exclusion are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered for free. The description adds genuinely non-schema behavior: invalid values silently yield zero rows instead of an error, topics are exact-match while dept is partial-match, and depts_top25 is truncated so absence from the list does not mean a department does not exist. The only miss is that it omits any note on cost, caching, or freshness of the counts.

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: purpose, then usage, then response shape, then rules, in labeled blocks with no filler sentences. The bracketed section headers and the mixing of Korean prose with English labels make it slightly heavier than a tight two-paragraph form, but every line carries information.

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?

There is no output schema, and the description compensates exactly by spelling out the return object ({topics, natures, boards, depts_top25}) and the meaning of n. Combined with the zero-parameter schema and the annotations carrying the safety profile, an agent has everything needed to call it and interpret the result.

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 takes zero parameters, so the baseline is 4 and the schema has nothing to explain. The description goes further by explaining the semantics of the parameters this list feeds — boards[].key versus boards[].label, verbatim exact-match for topics versus fragment partial-match for dept — which is real added meaning, though it is about a sibling tool rather than this one.

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 first sentence gives a specific verb (returns) and resource (the vocabulary usable in search filters), then enumerates the exact value categories: topics, natures, boards, depts. The [Purpose] block explicitly names the sibling it exists to support — search_documents' topics/nature/board/dept parameters — so an agent can distinguish it from get_document, list_recent, and search_documents without opening a schema.

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?

It states the exact trigger ("어떤 주제로 검색할 수 있어?" → no arguments) and gives the key exclusion: invented values return 0 rows rather than an error, so check here before a futile search. That is an explicit when-to-use plus a when-not-to-guess rule, which is stronger than most definitions.

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

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

Annotations already cover the read-only/idempotent safety profile, and the description goes well beyond them: FTS vs LIKE token-length threshold (AND, rank), default 게시일 DESC ordering with no snippet when query is absent, corpus starting 2010, and the [ … ] snippet marker convention. These are non-obvious retrieval behaviors an agent cannot get from structured fields.

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?

Sectioned into Purpose/Usage/Response/Rules with the core capability front-loaded. Every bullet is operational — examples, response fields, and four hard rules — with no filler prose.

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?

No output schema exists, and the description supplies the full response shape (total/showing/offset/note/results with field list), pagination semantics, and source code meanings. For a 10-parameter, zero-required tool this covers everything needed to call and interpret it.

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, but the description adds real semantics the schema lacks: board is asymmetric (English key in, Korean label out, never feed back), topics/depts are joined strings that must be split, and token length determines search mode. This meaningfully changes how parameters get constructed.

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 a specific verb and resource ('전문검색' of FSS/FSC 회계·공시 자료) and scopes it to 11 boards, immediately distinguishing it from get_document, list_recent and list_tags. An agent can tell what corpus this searches without opening the schema.

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?

Three concrete query-to-parameter examples show when to use keyword search versus pure filter sweeps, and the Rules section routes body retrieval to get_document. It never explicitly states when to prefer list_recent or list_tags instead, so selection against those siblings stays inferred.

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