archive.md MCP & Data Hub

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

No annotations are provided, so the description carries the full disclosure burden, and it says only that records are returned. It does not state whether the call is read-only (implied but not declared), how the fact/lineage data is structured, whether missing or uncited articles return empty or error, or any auth/rate constraints — all of which matter for a tool with zero annotation coverage.

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 well-formed sentence with no filler and the resource definition front-loaded. It is efficient rather than padded; the shortfall is under-specification, not verbosity.

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 annotations, no output schema, and 0% parameter coverage, the description should explain the input contract and the shape of the returned fact/lineage records. As written it leaves the critical ambiguity between the two optional parameters and the response structure entirely unaddressed.

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 0%, so the description must compensate and does not. It references only 'slug', leaving keyword_or_slug completely undefined in both schema and description, and with zero required parameters it gives no guidance on whether the two are alternatives, whether both may be passed, or which takes precedence.

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 ('검증 팩트(F-xx)와 1차 공식 출처 계보') scoped to an article slug, which an agent can distinguish from siblings like get_fact or search_verified_facts. It stops short of explicitly contrasting itself with those siblings, but the level of specificity is high.

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 phrase '특정 아티클 슬러그가 인용한' implies the trigger (you have an article slug and want its cited facts), but there is no explicit when-to-use, when-not, or named alternative among the seven siblings such as search_verified_facts or get_fact. Selection between this and the fact-lookup tools is left entirely 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?

No annotations exist, so the description carries the full burden. It discloses that this is a read (조회) that returns both the fact record and the primary-source excerpt, which is genuine behavioral content. It says nothing about auth requirements, rate limits, or not-found behavior for an invalid ID/slug.

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 filler; the resource and lookup key come first. The ID examples are the only slightly distracting insertion, but they are useful, not wasteful.

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 one-parameter lookup with no output schema and no annotations, the description is largely sufficient: it identifies the input formats and states that the returned content includes the fact record and source excerpt. More detail on ID-not-found handling or the shape of the returned record would close the 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?

Schema coverage is 0% — the id parameter is only typed as a 2-100 char string. The description compensates well by specifying the accepted formats: permanent fact IDs with concrete examples (F-01, F-39) or a slug, which the schema alone does not convey. It stops short of stating whether ID and slug are mutually exclusive.

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 (단일 팩트 레코드), plus the retrieval key (영구 팩트 ID or 슬러그) and the additional payload (1차 출처 원문 발췌). This clearly separates it from the search_* siblings, though no sibling is named explicitly.

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 single-record-by-ID framing implies lookup rather than search, and the ID examples (F-01, F-39) help the agent supply the right input. However, it never states when to prefer this over search_facts or search_verified_facts, nor any prerequisite for having an ID/slug already in hand.

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?

With no annotations present, the description carries the full burden and it delivers the single most decision-relevant detail: unauthenticated calls return only public/canon records, while internal/draft entries appear only when an internal_read scope API key is presented. That is a genuine access-control trait rather than a restatement of the name. It stops short of covering response shape, pagination, or error behavior, which keeps it off 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 compact sentences with zero filler, and the resource definition is front-loaded before the visibility rule. Efficient and well-ordered, though it is short enough that space remained for a parameter hint.

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, no annotations, and four undocumented parameters, so the description needed to do much more than it does. It covers visibility/auth well but leaves the caller without any guidance on parameter meaning or return shape for a tool whose id-vs-slug fields invite mistakes.

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?

All four parameters (slug, series_id, series_slug, entity_type) have 0% schema description coverage and the description explains none of them, including the ambiguity between slug, series_id, and series_slug. The mention of a '4.8 schema' refers to the lore data model, not to input parameters, so it does not compensate.

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 (조회합니다 / retrieve) and a specific resource (official lore / worldview settings for original series, 4.8 schema), which is distinguishable from the fact/source siblings at a glance. What it lacks is an explicit contrast with get_fact or search_facts, the nearest neighbors, so the agent must infer the boundary itself.

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 statement of when to reach for this tool instead of get_fact, search_facts, search_verified_facts, or search_content, and no discussion of prerequisites or exclusions. The only conditional information is about credentials, which is a behavior rather than a selection rule.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says only that the catalog is '공개' (public) and says nothing about ordering, return format, result limits, or pagination, so an agent cannot tell what the response looks like or how large it may be.

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?

One sentence, front-loaded with the resource and scope, with no filler. It is efficient, though this efficiency comes at the cost of necessary detail.

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 (one optional enum parameter and no output schema), so the definition is adequate on purpose alone. It is still incomplete for an agent that needs to know the shape of the returned catalog entries and whether the result set is paged or capped.

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 0% for the single 'kind' parameter, but the description compensates partly by naming the three catalog categories (데이터셋, MCP 서버, 전문 에이전트), which map to the enum values data, mcp_server, and agent. It never says explicitly that 'kind' filters the results or what the 'all' default does, so it misses full 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 (조회/queries) and a specific resource (the archive.md hub catalog of public datasets, MCP servers, and expert agents), so the agent knows exactly what it returns. It does not name or differentiate itself from any sibling tool, but the sibling set (search_facts, get_article_sources, etc.) is different enough that confusion is unlikely.

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 about when to use this tool instead of the search_* or get_* siblings, no prerequisites, and no exclusions. The only clue is the verb '조회', which implies browsing rather than searching; the agent must infer the rest.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it only states that public facts are returned and names the change types. It does not disclose ordering, pagination behavior, rate limits, or other operational constraints, which leaves important behavioral details unspecified for a feed-style listing.

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 a single front-loaded sentence with no redundant wording. Every element contributes to defining the scope and change types, making it appropriately concise.

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 listing tool with no output schema and no annotations, the description should provide more context about return format, pagination, and parameter behavior. It covers the broad purpose and change categories, but it is not complete enough to tell an agent how to call the tool reliably.

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 0%. The description explains `since` as the basis time after which changes are returned, but it does not describe the `limit` parameter at all, nor does it specify the format of the `since` timestamp. It adds meaning to one parameter but leaves the other undocumented.

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 and resource: it returns a public fact change-history feed, with scope defined as entries after `since`. It does not explicitly distinguish itself from sibling tools such as search_facts or search_verified_facts, so it falls short of full sibling differentiation.

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 time-based scope and the change categories (new, revised, expired) imply that this is for recent-change monitoring, but no explicit when-to-use guidance or alternatives are stated. An agent must infer that this is for change feeds rather than searching or fetching individual facts.

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?

With no annotations provided, the description carries the full disclosure burden, yet it says nothing about result shape, pagination, default/max result counts, or whether an empty query returns everything. The one genuinely useful disclosure is '발행된' (published), which implies only published items are indexed. That single implicit filter is not enough for a 4-parameter search tool with zero annotation coverage.

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 enumerating the content types with no filler or repetition. It is efficient, though the brevity is partly the source of the coverage gaps rather than a virtue in itself.

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, no annotations, and 0% parameter description coverage mean the description should do far more: query matching semantics, category meaning, result ordering, and pagination are all absent. For a unified search tool with an enum type switch and no required params, an agent cannot predict behavior from this text alone.

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 0%, so the description must explain the four parameters, but it only loosely gestures at the `type` enum by listing content kinds. It says nothing about what `query` matches, what `category` refers to, or the behavior of `limit` (default 10, max 50), leaving the agent to read the raw 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?

The description pairs a specific verb (통합 검색) with a clearly enumerated resource set — published blog reports, original web novels, webtoons, and video episodes — so an agent knows exactly what corpus is covered. It never names a sibling tool to differentiate itself from, but the content-metadata scope separates it implicitly from the fact-oriented siblings like search_facts and search_verified_facts.

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 statement of when to use this tool versus the type-specific siblings (get_article_sources, list_catalog, search_facts), and no guidance on prerequisites or typical query phrasing. Only a weak implication of usage arises from the word 통합 (integrated), which hints at cross-type search but leaves the agent to infer it.

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?

With no annotations at all, the description carries the full burden, and it does disclose a genuinely non-obvious behavioral trait: unauthenticated callers see only active/expired facts, while draft facts require an internal_read scope API key. That is exactly the kind of access-control disclosure an agent needs. What's missing is any statement about pagination, result ordering, or output shape, 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, both dense with substance, with the scope and evidentiary standard front-loaded and the access caveat second. No filler, though the second sentence packs two distinct ideas (default visibility and the internal_read escalation) into one 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 5-parameter tool with 0% schema coverage, no annotations, and no output schema, this is only partially sufficient: the auth model and domain scope are covered, but as_of and limit are undocumented anywhere, and the absence of a sibling differentiation against search_verified_facts leaves a real routing 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 0%, so the schema documents none of the 5 parameters; the description partially compensates by naming keyword, domain, and status and by enumerating the status values active/expired/draft. It says nothing about as_of (an unusual point-in-time parameter that needs explanation) or limit (bounds 1–50, default 10), leaving two of five parameters entirely opaque.

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 a precisely scoped resource: fact records F-01~F-44 cross-verified against primary official Korean sources, across four named domains. It does not, however, distinguish itself from the sibling search_verified_facts, whose name suggests an overlapping purpose, so an agent cannot confidently pick between them from the description alone.

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: the description tells you what dimensions you can search by (키워드·도메인·상태), but it never states when to reach for this tool instead of search_verified_facts, get_fact, or list_catalog. The auth-dependent visibility note is helpful context, but it is not routing 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?

No annotations are provided, so the description must carry the behavioral burden, yet it only says the tool is an alias. It does not disclose read-only behavior, result shape, limits, pagination, or whether it differs from search_facts in any way.

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 single sentence is concise and front-loaded, but it is undersized for a tool with three undocumented parameters and no annotations. There is no wasted text, but there is also no useful structure.

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 annotations, no output schema, and 0% schema description coverage, the description is far too sparse. The alias relationship provides some context, but it does not explain parameters, behavior, or return values.

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 0% for three parameters, and the description adds no meaning for query, limit, or domain. An agent gets no guidance on what these parameters do beyond their bare types and defaults.

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 says this is a backward-compatible alias of search_facts, which identifies the sibling relationship but does not state the specific verb/resource or what a verified fact is. An agent can infer the purpose only by knowing search_facts.

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 no explicit when-to-use or when-not guidance and does not say whether an agent should prefer search_facts over this alias. The only implied usage is backward compatibility.

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