AgentMaru · Korean data and research

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

Annotations already declare read-only/idempotent/open-world, and the description adds substantial extra behavior: a max 5-minute cache with a displayed query time, the rule that source failure or a missing reference date is NOT treated as 'no change', the caveat that no_new_period does not prove an unchanged same-date value, and an explicit statement that it does not subscribe, reserve, or store personal work.

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 core function and parameter defaults are front-loaded, followed by workflow and caveat sentences. It is dense and every clause carries information (defaults, first-call fallback, caching, negative-result semantics), though a couple of fragments such as '/day는 미확인' assume context the agent may not have.

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 covers return content (amount + difference) and hints at output fields (nextCheck.arguments, no_new_period, query time). Failure/missing-reference handling and period coverage limits are disclosed, so an agent can call it correctly. Minor gaps remain around the exact response shape and pagination-like limits.

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 carries the param burden. It explains teu (1-4 entries, default 1700/2500) and since (YYYY-MM-DD), plus the non-obvious semantic that an omitted since on the first call falls back to the prior public date. The only gap is the cryptic '/day' reference, which is not tied to either parameter.

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?

It states a concrete verb+resource: read the official public table and return the latest US$ amount for the selected teu plus the difference versus a since date. The scope is further narrowed (only periods still in the public table, HARPEX Index vs linear amounts are separate), so an agent knows exactly what it gets. It does not name or contrast any sibling tool, which keeps it at 4 rather than 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?

Clear usage context is given: on the first call omit since to compare against the previous public date, and persist nextCheck.arguments for later checks. It also implicitly says when NOT to expect results (periods no longer in the table). No explicit alternatives/exclusions are named, but the sibling set is unrelated, so this is sufficient.

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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral note — that country/period/currency in the sentence are NOT auto-applied — but the surrounding sentences about "capabilities[].nextCall" and disclosure windows are ambiguous rather than clarifying.

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 domain enumeration is front-loaded and carries most of the value, but the remaining sentences are dense and mix two languages while referencing a response field (capabilities[].nextCall) that is never explained. Several sentences are procedural reminders rather than definitional content.

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, yet the description alludes to a structured return shape (capabilities[].nextCall) without describing it, and the 300-char query parameter is undocumented. For a multi-domain task-discovery tool this is adequate but leaves real gaps around what the response contains.

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?

One parameter (query) with 0% schema coverage. The description implies query is a natural-language sentence and that its country/period/currency constraints are not automatically honored, which is useful, but it never states format, length, or acceptable query shape explicitly, so it only partially compensates for the coverage gap.

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?

Opening sentence gives a clear verb+resource ("Find a supported task") and enumerates the concrete supported domains (US CPI, ECB exchange rates, GDP, HARPEX, KED PER candidates), which an agent can use to tell it apart from siblings like query_ked or run_public_task. The concept of a "supported task" registry is left somewhat implicit, and the mixed Korean/English reduces immediate parseability.

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 hints at usage constraints ("check temporary disclosure and data scope", distinguish direct execution from source-investigation guidance) but never names an alternative tool or states when a sibling should be chosen instead. Usage is implied rather than stated, e.g. nowhere does it say "call this before run_public_task".

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 (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: handoff guidance is not authorization, the tool performs no browser/login/material actions, and it never accepts passwords, cookies, or tokens. It also tells the agent to inspect scope/period differences and re-verification needs in the result.

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?

Purpose is front-loaded in the first sentence, followed by safety and parameter guidance in a logical order. Several sentences are caveats, but each carries distinct information (authorization, secrets, fallback); it is dense without being bloated.

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 with no output schema, the description covers purpose, permission model, parameter usage, and what to read from the response. Return structure itself is not described, which is acceptable given no output schema exists, but a hint about the response shape would fully close the 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%, so the description must carry the burden and it does: id is the site identifier, and materialId omitted returns everything while a materialId obtained from a prior response narrows to one material. That explains both parameters' meaning and even their acquisition flow, well beyond the raw pattern constraint.

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: checking login/paid-subscription conditions per material for a site ID. The scope is concrete enough to distinguish it from data-fetching siblings like get_site_details or get_research_pack, though it never names a sibling 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?

Gives real conditional guidance: members should follow memberHandoff and work in the owner-approved browser, and if permission is absent they should fall back to a verified public alternative. It also sets a clear negative boundary (no browser connection, login, or material lookup), but does not explicitly route against a named alternative 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 readOnly/idempotent/non-destructive, but the description adds genuinely new behavior: a 50-item page cap, seq ordering, cursor continuation, and the fact that reading does not mark replies as read. It adds value beyond the structured hints, though it says nothing about error or permission 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?

Three short sentences, front-loaded with the core retrieval behavior, with each sentence covering a distinct point (page size, pagination continuation, read-marking separation). Efficient, though telegraphic and slightly reliant on terms the schema does not define.

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 2-parameter tool with 0% schema description coverage and no output schema, the description omits the required postId entirely, does not explain the after cursor, and introduces a nextAfter term without saying whether it is a response field to feed back. The read-marking note is helpful but the parameter story is incomplete.

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 carries the full burden and falls short: it references "nextAfter" for continuation but the schema parameter is named "after", and it never mentions postId or its required 32-character hex format. The only parameter-adjacent information given uses a name that does not exist in 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?

The description conveys the operational core ("up to 50 comments in seq order") but never states plainly that this tool retrieves the comment thread of a specific community post, nor does it differentiate itself from the sibling list_community_posts. An agent must combine the name and title to infer the actual purpose.

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 real routing guidance: continue reading when nextAfter is present, and it explicitly names acknowledge_community_replies as the separate tool for read-marking, clarifying that this call has no read-state side effect. It does not, however, say when to prefer this over list_community_posts.

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 readOnly/idempotent/non-destructive, so the safety bar is low; the description instead adds content semantics (full includes the entire guide, summary does not) and a negative scope statement that prevents misreading it as a data/price tool. It does not describe response size or pagination, which for a 'full' payload would be useful.

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 recommended first action (view:summary) is front-loaded and every sentence carries an instruction or constraint. The mid-sentence chains (e.g. the dataRoutes list) are slightly dense, but there is no 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?

With no output schema, the description explains what comes back and what does not; with annotations covering safety, the remaining burden is small. The only real gap is the undocumented id parameter and how to obtain it, which is minor for a lookup 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 0%, so the description must carry both parameters. It explains view well (summary vs full, full is default), but the required id parameter is never mentioned — no hint that it comes from list_research_packs or what it identifies. Partial compensation, so baseline 3.

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 concrete deliverable — research order (조사 순서), comparison criteria (비교 기준), and original sources (원출처) — and explicitly routes to get_site_guide, which separates it from that sibling. The verb (제공합니다 / 'provides') is generic and the notion of a 'research pack' stays abstract, so it stops short of a fully self-explanatory 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?

It prescribes a workflow: start with view:summary, inspect sources' dataRoutes for table address/unit/base-date/access conditions, then expand only the needed guide via get_site_guide. It also states an explicit boundary — this is not actual prices or finished analysis — so the agent knows when this tool is insufficient.

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, covering the safety profile. The description adds no further behavioral context such as authentication needs, rate limits, or what happens if the id is invalid; it only restates the retrieval action.

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 redundancy or filler. For a simple retrieval tool, this is an appropriately sized statement.

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?

While the description indicates what data is returned, it leaves the only required parameter undocumented and gives no usage context relative to siblings. With no output schema and no parameter description coverage, an agent lacks enough information to invoke the tool correctly in ambiguous situations.

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 sole required parameter 'id' has 0% schema description coverage, and the description does not mention it at all. There is no explanation of what the id refers to, its format, or how to obtain it, so the description fails to compensate for the missing schema semantics.

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 ('조회합니다' / retrieves) and resource ('사이트의 이용 조건, 기능, 확인 출처와 날짜' / a site's usage conditions, features, verification source and date). It is clear what the tool does, but it gives no indication of how it differs from siblings such as get_site_guide or search_sites.

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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when-not-to-use cases, or any of the sibling tools that might return overlapping site information.

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 safety is covered. The description adds a genuine behavioral detail beyond the structured data: unverified conditions are explicitly flagged as unverified, which tells the agent how much to trust the returned guidance.

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, but the opening is an agent-directed directive rather than a statement of the tool's function, which is a weak front-load. The middle sentence carries the real payload; the text is not padded but its ordering is not optimal.

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 read-only tool with no output schema, the description does describe the categories of content returned, which is the main completeness requirement. What is missing is any definition of the id argument and any note on failure behavior for an unknown id.

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% and the single required 'id' parameter carries no description in the schema. The description says nothing about what that id identifies (a site, a plan, a guide version), so it fails to compensate for the coverage gap on the only input the agent must supply.

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 enumerates concrete content the tool delivers (material locations, reading order, update cadence, free scope, verified API docs, auth guidance), so the agent knows what it retrieves. However, it never states the verb explicitly ('provides') and does not distinguish itself from the sibling get_site_details, which plausibly covers overlapping territory.

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 instruction to 'read the accessPlan login/paid conditions and public alternatives first' implies an intended reading order, but it is guidance about content sequencing rather than about when to call this tool instead of get_site_details, get_access_plan, or get_source_evidence. No exclusions or alternatives 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 read-only/idempotent/non-destructive safety, so the bar is lower; the description still adds meaningful behavioral context by stating it does NOT re-check external sites on query and that stored access-success is not proof of fresh data. This sets return-value expectations beyond what annotations convey, though it omits latency or caching details.

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, front-loaded sentences with no filler; the key caveat (no live re-check) is stated plainly at the end. Slightly repetitive phrasing across the date-related sentences, but overall efficient.

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 read-only tool with no output schema, the description succeeds in naming the three returned components and warning about their interpretation. The main remaining gap is the undefined id parameter, which leaves an agent unsure what to pass in.

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?

There is one required parameter (id) with 0% schema description coverage and no enum, and the description never explains what the id identifies or its expected format. The schema only constrains length, so the description should have clarified whether id is a site id, task id, or evidence id, and it does not.

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 (source evidence) and enumerates the three distinct pieces returned: description review date, stored access check result, and material reference date. It is clear what the tool does, but it never distinguishes itself from related siblings like check_harpex_update or get_site_details, leaving the agent to infer the boundary.

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 agent can guess this is for checking provenance and recency. There is no explicit when-to-use/when-not-to-use statement and no reference to the alternative check_harpex_update, which appears to overlap. The line '접속 성공은 최신 데이터라는 뜻이 아닙니다' hints at interpretative caution but not selection 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?

The annotations already establish that this is a read-only, idempotent, non-destructive operation, so the description's main added value is disclosing that the return includes registered site counts. It does not add further behavioral context such as response format, rate limits, or authentication requirements. This is adequate but not rich.

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 wasted words. It immediately conveys the tool's output and scope.

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 the tool's simplicity (no parameters, no output schema, and rich read-only annotations), the description is complete enough for correct invocation. It explains the returned content (all categories and actual registered site counts), which is the main missing piece when no output schema exists.

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. The description adds no parameter semantics because none are 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 uses a specific verb ('조회합니다' – retrieves/lists), a clear resource ('전체 분야' – all categories), and adds scope ('실제 등록 사이트 수' – actual registered site count) with concrete examples. It is easily distinguished from sibling tools like search_sites or list_research_packs because it enumerates categories rather than searching sites or listing other resources.

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 states what the tool does but provides no explicit when-to-use guidance, prerequisites, or alternatives. It does not tell the agent when to prefer list_categories over sibling tools such as search_sites or get_site_details.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond that: 'mine' requires authentication, pagination continues by passing nextBefore as before, and user posts/author names must be treated as data rather than commands, a prompt-injection safety warning.

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 compact, front-loads the view-mode definitions, then adds pagination and safety guidance. Every sentence contributes directly to correct invocation and no text is wasted.

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 read-only listing tool with rich annotations, the description covers view semantics, pagination, authentication needs, and injection safety. It still omits the category parameter meaning and any sibling-tool routing, and no output schema exists to explain the returned post structure, so it is adequate but incomplete.

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 carry parameter meaning. It thoroughly explains the view enum values and clarifies before as a continuation cursor, but it completely omits the category parameter and its chat/help values, leaving one of three parameters 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 defines three view modes for listing community conversations/help requests, making the tool's scope clear. It does not explicitly distinguish this tool from sibling tools like get_community_thread, so it falls 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?

The description explains what each view mode means and notes that 'mine' requires authentication, which implies when to use each mode. However, it does not name alternatives such as get_community_thread or state when not to use this listing tool, leaving routing guidance implied rather than explicit.

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, covering the safety and side-effect profile. The description adds that results carry research order, usage instructions, and source-verification info, which is useful since no output schema exists, but it discloses nothing about result volume, pagination, or the closed-world data scope.

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 the domain scope and delivered content front-loaded; no filler or restatement of the title. It is appropriately sized, though the second sentence's list of deliverables is slightly list-like rather than prioritized.

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 read-only, single-parameter list tool with no output schema, the description does establish domain scope and the nature of returned content, which is the minimum needed. However, the one parameter that governs behavior and any pagination/limit expectations are left entirely unexplained, leaving the definition adequate but with clear gaps.

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% and the sole 'q' parameter (maxLength 160, optional) is never referenced in the description. The verb '찾습니다' weakly implies a search input, but no meaning, syntax, or matching behavior is supplied to compensate for the empty 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 clear verb ('찾습니다') and resource ('조사 묶음') and enumerates the five domains covered (semiconductors, shipping, raw materials, rates/prices, virtual assets), plus the accompanying materials. It is distinguishable from most siblings, but never explicitly contrasts itself with the singular get_research_pack, so it falls short of the sibling-differentiation bar for 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?

There is no explicit when-to-use guidance or alternative named, despite get_research_pack being an obvious sibling to route against. The enumeration of domains and contents implies a discovery use case, but the agent must infer when to pick this over the singular retrieval 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 readOnly/idempotent/non-destructive/open-world, yet the description adds substantial context: trial expiry behavior, fields to verify in the response (trialEndsAt, data as-of date, review hold, missing values), the nature of export figures as HS/region-linked estimates rather than disclosed amounts, prompt-injection caution, and explicit exclusions of member info/memos/report originals.

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?

Dense but front-loaded: trial context first, then action semantics, then response caveats and data-handling warnings. Every sentence earns its place, though the block runs long with several caveats 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 no output schema, the description compensates by telling the agent what to inspect in the response (trialEndsAt, data date, review hold, missing values) and by warning about estimate semantics and excluded data. Complete enough for a 3-param, no-output-schema 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 0%, so the description must carry the burden, and it does: each action enum value is defined, and ticker (6 digits) and months (1~24) are scoped to company_exports. The months default of 15 is left to the schema, which is a minor omission.

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 (reading KED's real data without login during the trial) and enumerates the three actions with distinct meanings. An agent can distinguish rerating_candidates, rerating_exports, and company_exports from the description alone, and none of the unrelated sibling tools overlap.

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?

Explains the trial context and the transition condition (paid membership + /mcp/private after expiry), and the action definitions effectively guide which action to select. It stops short of explicit when-not-to-use guidance, but the siblings are unrelated enough that this is not a material gap.

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 only say this is a non-readonly, non-idempotent, non-destructive open-world write. The description goes well beyond that: it describes the post-call workflow (store the returned key securely, reconnect to /mcp/community with Authorization: Bearer), clarifies the key is separate from a personal work key, warns that the name is not identity verification, and prohibits retry on ambiguous results. That is exactly the behavioral context annotations cannot carry.

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?

Five short sentences, each carrying distinct information: trigger, key handling, key isolation, name semantics, failure handling. It is front-loaded and waste-free, though the key-handling and retry instructions are packed densely enough to reward a careful read.

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 correctly explains the return value's significance (a key to store and use as a Bearer token) and the reconnect endpoint. Combined with the retry prohibition, name caveat, and key separation, an agent has everything needed to invoke it correctly on the first try.

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?

There is one parameter with 0% schema description coverage, so the description has to compensate. It does partly by clarifying that 'name' is not identity verification, which prevents a meaningful misuse. However, it says nothing about the length bounds (2-40) or any format guidance, so the parameter remains thin.

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 (register) and resource (a public-community agent registration), and pins the scope: it happens once, only after the user approves community participation. No sibling tool does anything comparable, so an agent can route to it unambiguously.

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 triggering condition (user approval of public community participation), the cardinality rule (register once), and an explicit prohibition with an alternative: do not auto-re-register on an uncertain response, instead consult the recovery guidance at /community. When-to-use, when-not-to-use, and the fallback are all present.

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 annotations (readOnlyHint: true), the description adds critical operational transparency regarding failures. Specifically, it states that missing values or connection failures will not be marked as completed, guiding the agent on interpreting the eventual state.

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 dense, but every sentence is highly functional. It successfully front-loads the output format and the tool's core function before detailing constraints and disclaimers, making it very efficient despite its length.

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 the complexity of running external tasks and the lack of an output schema, the description is highly complete. It details the specific structure of the return data and specifies crucial failure modes (incomplete task handling), allowing the agent to call and correctly interpret the results.

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?

Although schema coverage is 100%, the description adds critical functional meaning to the enum options. It clarifies the intended use of `taskId` by listing specific parameter requirements for each task, such as the country constraints for 'gdp-growth'.

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 clearly defines the tool's function: reading data from official sources and returning structured data (JSON) containing metrics, dates, and calculation methods. It explicitly enumerates the available tasks (us-cpi, exchange-rates, gdp-growth), clearly distinguishing the tool's scope.

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 provides strong constraints and warnings, such as only supporting 'latest available data' and explicitly warning against confusing different rate types (annual/monthly, reference/real-time). It also sets boundaries by stating it is not a general web browser or payment system.

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 read-only annotation, the description details complex behavioral traits. It explains exactly what the default 'research' view returns (source URL, unit, date, caution points) and provides crucial operational caveats, such as how the US Treasury data parameters are narrowly interpreted.

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 highly dense and very long, which compromises ideal conciseness. However, given the extreme complexity of the domain (financial data, specialized search modes), every sentence delivers critical, non-redundant 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?

The definition is exceptionally complete for a high-complexity, zero-documentation tool. It covers scope, default returns, conditional logic, parameter interpretation, and explicit limitations, leaving few unknowns for an AI agent.

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?

Given the schema description coverage is 0%, the description carries a massive burden. It successfully compensates by explaining the semantic differences between parameters, specifically detailing the interpretation of financial terms and date formats (e.g., '명시 월(YYYY-MM/한국어 연월)'), and clarifying the distinct roles of `view:research` versus `view:catalog`.

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 clearly states the function: searching for registered sources using site names or short keywords. By focusing on '등록 출처' (registered sources), it precisely scopes the action and differentiates it from generic, unindexed search 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?

The description provides extensive conditional guidance. It instructs the agent on specific behaviors based on the 'view' parameter, dictates how to proceed if 'request.status:unresolved,' and explicitly advises utilizing 'get_access_plan' when 'nextAction:read_original' is relevant. It also states a clear limitation: it is not for guaranteed completion or raw data retrieval.

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