The Korean Today news search

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

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, and the description adds real behavioral context beyond them: members-only articles degrade to metadata only, and supplying lang also pulls an AI summary plus cross-language edition links. It doesn't cover auth or failure modes, 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 short sentences, front-loaded with the primary purpose and then the conditional lang behavior and the members-only caveat. No filler, every clause 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?

With no output schema, the description does the work of previewing returns (full text, metadata, AI summary, edition links), which is exactly what an agent needs. It omits error/fallback behavior when no identifier is provided, a minor gap for a 3-param tool with no required fields.

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 33% – only lang is documented in the schema, and that description is thorough. The description contributes the id-vs-URL lookup modes, but leaves the relationship between the two (mutually exclusive? which wins? what if neither is given) unstated, so it only partially compensates for the bare id/url properties.

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 ('Full text and metadata of one article') and names the two lookup keys (id or URL), which is enough to separate it from siblings like search_articles and latest_articles. It never explicitly contrasts itself with those siblings, so it stops short of a 5.

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?

Usage is only implied: 'by id or URL' tells the agent this is the direct-lookup tool, so search_articles is the implied alternative when no identifier is known. There is no explicit when-to-use or when-not-to-use statement, and no guidance on what happens when neither id nor url is supplied despite zero required parameters.

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 adds only the optional filtering dimensions and does not disclose ordering, pagination, return format, or language fallback behavior.

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?

A single front-loaded sentence with no wasted words. The scope and optional filters are immediately apparent.

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?

The tool is simple, annotations cover safety, and the schema documents two of three parameters well. However, the description does not mention the limit parameter, default language behavior, or any routing from sibling 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 67%, and the schema itself names and explains lang and section in detail. The description repeats that section and language are optional filters but omits the limit parameter and adds no syntax or format meaning 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 resource and scope: most recent articles, optionally by section and language. It is clear what the tool does, but it does not differentiate itself from sibling tools like search_articles or get_article.

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 mentions optional filters but gives no guidance on when to use this tool versus search_articles or get_article. It implies a latest-articles use case but provides no explicit context or exclusions.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds a useful content fact — that languages fall into two groups, one with article editions and one with AI summaries — but says nothing about ordering, the shape of the returned groups, or whether the '87' is a fixed count.

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?

A single short sentence with no filler, front-loaded on the resource. It is efficient, though the elliptical grammar costs a little clarity rather than adding 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?

With no output schema and no parameters, the description must carry the return-value burden alone, and it only partially does: it implies two categories of languages but not how they are represented or ordered. For a trivial read-only enumeration this is adequate, but not fully self-contained.

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 text is expected 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?

The description names the resource (language editions / languages) and hints at a listing, but it is a noun phrase with no verb, so the agent must infer 'returns a list of languages.' It does distinguish the resource from siblings like get_article and list_sections, but the two-clause phrasing ('editions with their own articles' and 'the 87 languages with AI summaries') is ambiguous about what is actually enumerated.

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?

There is no guidance on when to call this versus alternatives, nor any prerequisite or context. Nothing is misleading, but the agent gets no signal about whether this is a discovery step, a config lookup, or a filter for other tools.

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 fully covered structurally. The description's only added context is the shape of the returned data (slugs and article counts), which is useful because no output schema exists, but it says nothing about ordering, counts being live/cached, or empty results.

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?

Seven words, front-loaded, zero filler. It is arguably over-terse rather than wasteful, but nothing in it is redundant.

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-parameter, closed-world, read-only enumeration, the annotations plus the description's note about slugs and article counts give an agent enough to call it and interpret the result. The absence of any statement of ordering or typical section count is a minor remaining 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?

The tool takes zero parameters and the schema is empty, so there is nothing to disambiguate; baseline 4 applies. The description correctly implies no filtering is required to invoke it.

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 is a noun phrase naming the resource (news sections) and its payload (slugs, article counts), so the agent can infer what comes back, but it never states a verb and reads as a caption rather than a purpose statement. It is distinguishable from siblings like list_languages and search_articles only by the resource noun, not by any explicit contrast.

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?

There is no guidance on when to call this versus the siblings (get_article, latest_articles, search_articles). The agent must infer that this is the entry-point enumeration for the section taxonomy.

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 adds the genuinely new behavioral fact that results come back 'newest first' and that non-Korean editions may return translated summaries, but says nothing about pagination or result shape.

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 core purpose, no redundant filler. The second sentence earns its place by giving a language/query hint, though it is slightly dense with two ideas packed together.

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 four parameters, no output schema, and no enum constraints, the description covers the core search behavior and the lang nuance but omits result shape, pagination, and how section/limit interact with the search. It is adequate but leaves gaps the agent must infer.

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 75%, and the lang parameter is already thoroughly documented in the schema (edition codes vs AI summary languages). The description reinforces the lang behavior and adds a query tip ('Korean keywords work best'), but adds little beyond what the schema already says; 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?

States a specific verb+resource ('Full-text search of The Korean Today articles') plus ordering ('newest first'), which lets an agent distinguish it from latest_articles and get_article by inference. It never names those siblings explicitly, so differentiation is implied 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?

Offers a practical selection hint ('Korean keywords work best for the Korean edition; use lang for another edition or to get translated summaries'), which guides parameter choice. However, it gives no explicit when-to-use guidance versus latest_articles (browsing) or get_article (fetching one), so usage is only implied.

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