한국일보 뉴스 (Hankookilbo)

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

Annotations already cover read-only/non-destructive/open-world, and the description adds genuinely non-obvious behavior: the horoscope body is NOT returned and must be read from item.url at the Hankyoreh original. The Korea-time default is also useful context. No error/empty-result behavior is described, keeping it below 5.

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?

Three sentences, front-loaded with the usage triggers, then the return-scope caveat, then the date default. Every sentence carries information; only the URL caveat is somewhat verbose.

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 an output schema present, return fields need not be explained, and the description still proactively sets expectations that the body lives behind item.url — critical because the tool name implies it returns horoscope content. Nothing essential for calling it correctly is missing, though the relation to get_mbti_horoscope is unstated.

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 schema already documents the single optional date parameter, its YYYY-MM-DD format and the today-in-Korea default. The description only restates that same information, adding little beyond the schema.

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+resource ('그날의 운세' 조회) and clarifies the surprising part of the contract: it returns only title/publish date/original URL, not the horoscope text itself. It indirectly separates itself from get_mbti_horoscope via '띠별 운세', but never names that sibling, so the differentiation is only implied.

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 trigger phrasings ('오늘의 운세', '오늘 운세 알려줘', '띠별 운세') and states the default (today, Korea time) plus how to override. It does not say when to prefer get_mbti_horoscope instead, so a sibling-choice edge case is left to inference.

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?

Beyond the readOnly/destructive annotations, the description discloses the key behavioral constraint: the tool does NOT return the horoscope body, only the title, publish date, and original link, and the text lives solely at item.url on the 한국일보 site. That is the non-obvious fact an agent needs before calling; only pagination/result-count behavior is left unexplained.

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?

Three tight sentences, front-loaded with the usage trigger, then the return-shape caveat, then the date parameter. No filler, though the return-shape sentence is somewhat verbose about where the body lives.

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 an output schema present, the description doesn't need to enumerate return fields, yet it usefully warns the body is absent — the biggest failure mode for this tool. The only missing piece is explicit routing versus the sibling horoscope tool.

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 description coverage is 100% and the schema already states YYYY-MM-DD plus the default of today (Korea time). The description repeats that same information in Korean without adding format edge cases or timezone subtleties, so it is baseline value only.

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 gives a specific verb+resource: it fetches the MBTI-based horoscope article (title, publish date, link) rather than the horoscope text. It clearly scopes the tool to MBTI horoscopes via example queries, but never names the sibling get_daily_horoscope, so the agent must infer how the two horoscope tools differ.

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?

Concrete trigger phrases ('MBTI 운세', '오늘 내 MBTI 운세', 'ENFP 운세') make the intended invocation context unambiguous, and the default-to-today behavior is stated. It stops short of explicit exclusions, e.g. when to prefer get_daily_horoscope over this tool.

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=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds only the pagination affordance ('page_num 으로 다음 페이지를 더 가져올 수 있습니다'), with nothing about result volume caps or what happens past the last page.

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?

Two short sentences: trigger examples first, paging hint second — front-loaded and waste-free. The list of four near-synonymous Korean phrases is slightly redundant but serves as retrieval vocabulary.

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 zero-required-parameter, read-only listing tool with full schema coverage and an output schema, the description covers ordering and paging adequately; return values need not be explained. The only real gap is disambiguation from the many sibling news-listing tools.

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 description coverage is 100% and both parameters are documented there, including 'page_num' starting at 1 = newest. The description restates the paging behavior without adding format, limits, or clamping details beyond the schema, so the baseline 3 applies.

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 makes clear this returns articles in reverse-chronological publication order ('최근 발행 순서대로 기사를 볼 때'), which is a specific ordering contract, not just 'news'. However, it never names or contrasts the crowded sibling set (list_top_headlines, list_timely_news, list_most_read_news, list_popular_news), so the ordering distinction must be inferred.

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 anchors usage to concrete user phrasings ('최신 기사', '방금 올라온 뉴스', '오늘 새 기사'), which is a strong trigger signal for an agent routing a request. It gives no explicit when-not or alternative-tool guidance, so exclusions are left implicit.

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 a safe read-only, open-world, non-destructive operation, so the bar is lower. The description still adds meaningful behavior: it returns two bundles at once (꼼꼼히 본 plus 많이 본), which an agent would not infer from the annotations or empty schema. No detail on item count or ordering, keeping it below a 5.

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 what is returned, then the usage/exclusion clause. The quoted phrase list is repetitive but serves a real disambiguation purpose for a Korean-language intent match, so it mostly earns its place.

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 an output schema present, the description needn't explain return structure, and it correctly focuses on which bundle is fetched versus the sibling tool. Adequate for a zero-parameter read tool; minor gaps like item count or ordering are not blocking.

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 there is nothing for the description to disambiguate; baseline 4 applies. No parameter-related claims are made or needed.

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 resource (한국일보's '꼼꼼히 본 뉴스' bundle) with a clear retrieval verb and explicitly distinguishes it from list_popular_news. The parenthetical notes it also returns '많이 본 뉴스', so an agent knows exactly what comes back.

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 user phrasings that select this tool ('꼼꼼히 본', '정독할 만한 기사', '많이 본 + 꼼꼼히 본 같이 보여줘') and an explicit exclusion routing general popularity/ranking requests to list_popular_news. Both when-to-use and when-not-to-use are covered.

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 this as a read-only, non-destructive, open-world tool. The description adds meaningful behavioral context by explaining that results are ranked by view count and by contrasting this with editorial recommendation behavior, though it does not discuss freshness windows or ranking details beyond that.

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 the core routing rule and alternative tools, and every part is relevant. It is slightly repetitive in restating that this is the view-count-based popularity ranking, but the redundancy reinforces a subtle sibling distinction rather than derailing the agent.

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?

Given that annotations cover safety behavior, the input schema fully documents parameters, and an output schema exists, the description supplies the remaining critical context: ranking basis, section vs whole-site scope, and sibling routing. Nothing essential for correct invocation 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 description coverage is 100%, so the schema already documents page_size, section_cd, and exclude_section_cd thoroughly. The description adds a useful example for section_cd='politics' and clarifies whole-site exclusion behavior, but it mostly recaps what the schema already provides and does not address page_size.

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 resource and ranking basis: view-count-based popular news, with optional section scoping. It explicitly distinguishes this tool from list_recommended_articles and list_most_read_news, so an agent can route popularity queries without inspecting sibling schemas.

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 default-use guidance for popularity queries and names the alternatives by condition: use list_recommended_articles for editorial recommendations and list_most_read_news only when the user specifically asks for '꼼꼼히 본 뉴스'. This is clear when-to-use and when-not-to-use guidance.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context: the returned list is editorial recommendation rather than view-count popularity and has no ranking value, which is not captured by annotations alone. It does not discuss rate limits or auth, but those are not essential here.

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?

Three tightly written sentences front-load the use case, then the semantic distinction, alternative tool, and prerequisite. Every sentence carries useful routing or clarification 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?

For a simple read-only list operation with annotations and an output schema, the description covers purpose, selection conditions, alternative tool, and section-code prerequisite. Return values are handled by the output schema, leaving no critical gap.

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 description coverage is 100%, so both section_cd and page_size are already documented. The description repeats the list_sections check for section_cd but does not add syntax, constraints, or page_size behavior beyond the schema, making the baseline 3 appropriate.

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: retrieving editorially recommended/read-worthy articles for a given section. It explicitly distinguishes itself from popularity-based siblings by naming list_popular_news, so an agent can select it 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?

Gives explicit when-to-use ('특정 분야... 물을 때 사용합니다'), when-not-to-use ('많이 본/핫한/인기' → list_popular_news), and a prerequisite for obtaining the section code via list_sections. The routing conditions are fully specified.

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=true and destructiveHint=false, so safety is covered; the description usefully adds that this is a reference/enumeration lookup whose output feeds other tools' parameters. It does not say whether the value set is static or could change, which is the one behavioral fact still missing, so it falls short of a 5.

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?

Two sentences, purpose front-loaded before the usage triggers, with zero filler. The ten-value enumeration is informative but somewhat long and overlaps with what the output schema already declares, keeping it just short of a 5.

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?

Zero parameters, an output schema that carries the return shape, and annotations that cover the safety profile — the description only needed to say what it fetches and when to call it, and it does both. Nothing an agent needs to invoke this correctly is absent.

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 by rule. The description's enumeration of codes adds meaning about what the tool yields rather than about inputs, which is appropriate here and needs no further compensation.

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 names a specific verb (가져옵니다 / fetch) and resource (분야(섹션) 코드와 한글 분야명), and enumerates the exact code values returned, so the agent knows precisely what comes back. It also names the two sibling tools that consume these codes (list_popular_news, list_recommended_articles), distinguishing it from the other list_* news tools.

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 explicit trigger conditions ('어떤 분야가 있어?', '뉴스 카테고리 목록', or checking a section code) and implicitly defines when-not-to-use by pointing to the tools that take these codes as input. An agent can decide between this and the article-listing siblings without inference.

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=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds useful provenance — the results come from homepage time-slot curation rather than query-matched search — but says nothing about result volume, freshness, or whether the set changes through the day.

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?

Two sentences, front-loaded with the trigger phrases an agent would match against, followed by the return behavior. The four quoted example queries are somewhat redundant with each other but each adds a distinct surface form worth matching.

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?

An output schema exists, so return-value explanation is not required, and the zero-parameter call needs no calling conventions. What remains thin is the definition of what '시간대별 큐레이션' actually selects — how the time slot is determined and how results differ from the popular/latest siblings — which an agent would need in order to choose confidently.

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 parameter baseline applies and there is nothing for the description to disambiguate. Schema coverage is 100% with an empty properties object, leaving no parameter gap to compensate for.

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 the resource (time-of-day curated news from the homepage) and the intent (recommendations matched to the current time slot), which separates it from list_latest_news or list_most_read_news. The verb is descriptive rather than crisp ('반환합니다'), and it never names the sibling it displaces, so differentiation is implied rather than explicit.

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?

Four concrete user phrasings ('지금 읽을 만한 뉴스 추천', '뭐 볼 만한 거 없어?', '출근길/점심/퇴근길에 볼 뉴스') map directly to invocation contexts, which is strong trigger guidance. There is no explicit when-not or alternative-tool routing, so an agent must infer that latest/most-read/popular siblings cover non-time-based requests.

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 safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), but the description adds the non-obvious behavioral fact that ordering is editorial weight rather than traffic — a ranking semantic an agent could not infer from structured fields. It stops short of stating the time window implied by '오늘' or how many items are returned.

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?

Two sentences, zero filler: the routing trigger comes first, the exclusion second. The example phrasings earn their space because they map directly to how an agent would match a user utterance.

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 an output schema present, return values need no explanation, and the safety profile is annotation-covered. The only real gap is the freshness/time window behind '오늘' (same-day only? rolling 24h?), which an agent calling a headline tool would reasonably want.

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 there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter hints are present.

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 resource (편집부가 가장 비중 있게 배치한 머리기사) and immediately disambiguates it from a superficially similar sibling (list_popular_news). An agent can distinguish this from list_most_read_news or list_popular_news without opening any 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?

Gives concrete trigger phrasings ('오늘 주요 뉴스', '지금 헤드라인', '메인 뉴스 뭐야') plus an explicit exclusion rule routing '많이 본' queries to list_popular_news. Both the when and the when-not are named.

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 readOnly/openWorld/non-destructive, and the description adds genuinely new behavioral context: only metadata (title, link, date, section) is returned, with no article body or AI summary, and full text lives only at item.url. It doesn't discuss result ordering or rate limits, but the return-shape disclosure is the important part.

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?

Three sentences, front-loaded with the use case before the return-shape caveat. Every sentence is relevant, though the final sentence about 확인할 수 있습니다 is somewhat redundant with the preceding 'no body text' clause.

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 two-parameter read-only search tool, the description covers what it does, when to use it, what it returns, what it deliberately does not return, and where to get the full content. Nothing needed to invoke or interpret 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?

With 100% schema description coverage, both query and limit are already documented with examples in the schema. The description reinforces that queries are interpreted by context and meaning, which clarifies the retrieval model, but adds no syntax, formatting, or constraint detail beyond what the schema states.

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 gives a specific verb+resource ('뉴스를 찾는다') and scopes it to semantic/topic retrieval with example questions. It implicitly separates itself from the list_* siblings by emphasizing meaning-based search, but it never names those alternatives, so differentiation is inferred rather than stated.

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 clear triggering contexts via quoted user phrasings ('요즘 왜 이슈야', '배경이 뭐야'), which is strong positive guidance. It stops short of saying when NOT to use it or pointing to list_latest_news for plain recency browsing.

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