인터넷트렌드 맛보기 (InternetTrend Try)

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds information annotations cannot carry: the fixed monthly publication schedule and that each call consumes one unit of a trial quota, which materially affects invocation decisions.

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 with the core action and cadence front-loaded, then the empty-month behavior, then the quota cost. Nothing wasted, though the quota sentence is slightly cryptic about what a 'trial quota' is.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description is the only source of return-shape information; it characterizes the content only loosely as 'change-signal commentary' and doesn't say how many issues or what fields come back. Adequate for calling the tool, but thin on what the response looks like.

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 baseline would be 3. The description goes beyond the bare 'YYYY-MM' schema by defining the special semantics of an empty month (returns the publication list), which is the only non-obvious parameter behavior; the agent param's benefit is already stated 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?

States a concrete verb and resource (returns the monthly AI insight / change-signal commentary) and pins the publication cadence to the 3rd of each month. It does not name a sibling (e.g. get_industry_brief) to contrast with, which keeps it below 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 does imply two modes — passing a month fetches that issue, omitting month returns the list of published months — which is genuine usage guidance. However, it never says when to pick this over get_industry_brief or get_data_status, so alternatives are 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context that annotations cannot express: the call does not consume the "맛보기" (trial/preview) quota, and it returns reasons alongside status. It stops short of explaining what drives each status, hence not 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 tight sentences: purpose and return content first, the quota exemption second. Nothing is wasted and the key information is front-loaded.

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 carries the burden of describing the return value, and it does so by naming the three status levels and the accompanying reasons. Combined with rich annotations and fully documented optional parameters, an agent has everything needed to call it, though the meaning of the individual status values is left implicit.

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 parameters (code, include_ok) are fully documented in the schema. The description only adds "리포트별", implying the default granularity is per-report, which is marginal value — baseline 3 is appropriate when the schema already carries the parameter detail.

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 ("리포트별 데이터 상태...와 사유를 돌려줍니다") and even enumerates the three status values, so an agent knows exactly what comes back. It does not name a sibling tool or explicitly contrast itself with get_totals/get_ai_insights, so it falls just 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?

"인용 전에 확인" clearly states the trigger context — call this before citing/reporting figures — which is actionable usage guidance. It offers no when-not conditions or named alternatives, but for a pre-check tool the single condition is the meaningful one.

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 bar is lower; the description adds genuinely new behavior: a hard top-20 cap and consumption of one trial-quota unit. It does not describe the response shape or pagination, but the quota disclosure is the kind of operational cost an agent needs.

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 return content, then the quota cost. No filler. Slightly compressed for a tool whose range semantics (month window) are only conveyed via the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A read-only, closed-world retrieval tool with no output schema; the description covers what is returned (top 20 percentage shares) and the cost, and the schema covers date bounds and the report code. Complete enough to invoke correctly without further prose.

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 code, from, to, and agent are all documented in structured fields with examples and defaults. The description adds no parameter meaning beyond the schema, which is the correct baseline when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (돌려줍니다) and resource (전체 업종의 구성비 상위 20개), and enumerates the breakdown dimensions (검색엔진 · AI 플랫폼 · 브라우저 · 운영체제 · 유입 경로). This clearly separates it from get_time_pattern and get_totals, though siblings are never 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?

Provides a usage-relevant anchor (끝난 월 기준) and a cost signal (맛보기 한도를 1회 씁니다), which an agent can weigh before calling. However, it never states when to prefer this over get_time_pattern, get_totals, or get_industry_brief, so the routing decision stays 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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the call burns one sample ('맛보기') quota, which affects call budgeting. It does not describe pagination or volume limits, but for a single-record read that is minor.

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 what is returned, followed by the parameter pointer and the quota cost. No filler; slightly dense with parenthetical enumeration but 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 carries the burden of describing the return payload and does so by naming the specific sections returned plus a data-status field. Combined with full schema coverage and annotations, an agent has enough to call it correctly; only the sibling-routing guidance 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 all five parameters are already documented, including the from/to defaults and the category-over-nunchi_industry precedence. The description's only parameter note ('category 는 list_reports 의 categories 번호') restates what the schema already says, adding no new 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?

States a specific verb+resource ('업종 하나의 끝난 월 시장 기준선') and enumerates the returned components (top-5 platform share, time/day peaks, sample size, data status). It is clear what it does, but it does not explicitly distinguish itself from overlapping siblings such as get_distribution, get_time_pattern, and get_totals that cover similar slices.

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?

Provides a useful routing hint by tying `category` to `list_reports` categories, and warns that the call consumes one sample quota. However, it never states when to prefer this bundled baseline over the more granular sibling tools, so the agent must infer the choice.

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, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: calling it does not spend the 맛보기 quota, which matters for an agent deciding whether to invoke it repeatedly during onboarding.

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: the payload is front-loaded and the quota caveat follows immediately. No filler, no restating of the title.

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 informational tool with an optional parameter and no output schema, the description covers what is returned and the key quota behavior, which is sufficient to call it correctly. The only soft gap is that '시작 방법' (starting method) overlaps with get_signup_link without explaining the division of labor.

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% and the single optional 'agent' parameter is fully documented in the schema, including the incentive that naming the caller raises the daily limit. The description contributes nothing about the parameter, so the baseline of 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 uses a specific verb (돌려줍니다/returns) plus the resource: the features, limits, and starting method for each usage tier (맛보기, 무료 회원, 기업 시스템 연동). That tells an agent exactly what comes back. It does not, however, contrast itself with near neighbors such as get_signup_link or request_enterprise_contact, which also touch on onboarding and tier upgrades.

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 'call this when…' statement or named alternative. Usage is only implied by enumerating the tier names, which an agent must infer means plan/pricing questions. The caveat that it does not consume the 맛보기 quota hints at when it is safe to call, but stops short of 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 declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds two facts annotations cannot convey: signup happens in the user's browser, and calling this tool does not consume the trial quota. That quota detail is exactly the kind of context an agent needs before offering the link.

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?

It is three short sentences, and the main return value is front-loaded. Each sentence adds a distinct fact: the return contents, who performs the signup, and the quota impact. Nothing is wasted, though it is slightly terse.

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 must explain the return value, and it does: the signup address and MCP connection method. It also covers who performs signup and the quota side effect. It does not describe the shape of the response, but for a simple zero-required-parameter read, this is nearly complete.

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%, and the 'agent' parameter is fully described in the schema, including the daily-limit benefit. The description never mentions the parameter or that it is optional, so it adds nothing beyond the schema. That makes 3 the correct baseline.

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 concrete verb and resource: it returns the free signup (Google login) URL plus instructions for connecting this MCP. That is more specific than the title alone. It does not explicitly contrast itself with the nearby 'get_plan_options' sibling, 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?

The description implies the usage situation: a user who wants to sign up or connect, and it clarifies that the user completes signup in a browser. It never states when not to call this tool or which sibling to use instead, such as list_reports or get_plan_options, so usage remains inferred.

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 genuinely new behavioral context: the result is anchored to the last completed month, it carries a comparison baseline (1-year average), and it burns one trial-quota unit — the latter is a cost constraint no annotation conveys.

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: the return payload first, then the code legend, then the quota cost. The most important information is front-loaded and no sentence is filler, though the code legend could be visually separated from the comparison clause for faster scanning.

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 sketch the return shape (hour/weekday distributions plus 1-year delta) and the temporal scope, which is what an agent needs before calling. It stops short of stating granularity, units, or whether the delta is percentage or absolute.

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 to/from/agent parameters are already documented in the schema, so the real gap is the bare `code` enum — the description closes it by mapping 1010/1020/3010/3020 to visit-hour, visit-weekday, order-hour and order-weekday. It adds nothing for the remaining parameters, which is acceptable since the schema handles them.

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: it returns hour-of-day (0-23) and weekday distributions plus the delta against a trailing 1-year average, scoped to the last completed month. That is clear enough to act on, but it never contrasts itself with the sibling get_distribution, which an agent may reasonably confuse with this.

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 four code values are enumerated with their meaning, which implies which code to pick for a visit-time vs order-weekday question, and the trial-quota cost gives a reason to be sparing. There is still no explicit when-to-use / when-not guidance and no routing to or away from get_distribution or get_ai_insights.

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, non-destructive, closed-world behavior, so the bar is lower. The description adds two things the annotations do not: the data window ('끝난 월까지' – up to the last completed month) and the cost of calling it ('맛보기 한도를 1회 씁니다'), which is genuinely useful for budgeting calls.

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 with the return content front-loaded and the quota cost appended as a caution. Nothing is repeated and no sentence could be removed without losing 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 no-parameter, no-output-schema aggregate tool with strong annotations, the description covers what is returned, the time boundary, and the call cost. It is slightly short on how it differs from get_data_status and whether it is the recommended first call to gauge whether a dataset is large enough for other analyses.

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 single optional 'agent' parameter is fully documented in the schema, including its quota incentive. The description adds no parameter-level information, so the baseline of 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 gives a specific verb and resource: it returns cumulative visit/order counts plus monthly totals through the last completed month, and labels the purpose as sample-size verification. An agent can tell this is an aggregate-counts tool, though it never names the sibling it should prefer over (e.g. get_data_status or get_distribution).

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 parenthetical '표본 규모 확인용' implies the use case, and the quota warning gives a reason to be sparing, but there is no explicit when-not-to-use guidance or named alternative among the many sibling get_* tools. The agent must infer selection from context alone.

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, and non-destructive, so the safety bar is low. The description still adds two non-obvious facts: the call does not consume trial quota, and some returned reports are flagged as under data inspection.

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: what is returned, a cost caveat, then the call-ordering instruction. Front-loaded and every sentence carries distinct 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 takes on the burden of describing the return payload and does so by enumerating the main fields. It doesn't cover ordering or whether the list is paginated/complete, which is a minor gap for a zero-param listing call.

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 and the schema is trivially complete. Baseline 4 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 concrete verb (returns) and resource (reports) and enumerates what comes back: code, name, type, queryable period, and reports under data inspection. It's clearly a discovery/metadata tool, though it never names a sibling to contrast with.

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?

"Call this first before using other tools" gives explicit ordering guidance that an agent can act on directly. There are no when-not conditions or named alternatives, but for a bootstrap tool the forward guidance is the relevant part.

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=false, idempotentHint=true, destructiveHint=false), the description discloses the non-obvious two-phase dry-run/commit behavior and makes the user-consent gate a hard precondition — exactly the kind of behavioral context annotations cannot express. It is also consistent with idempotentHint, since the confirm flow is safe to retry with identical arguments.

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 purpose in the first clause and then the protocol, with zero filler. Every sentence carries operational weight: what is submitted, what the first call returns, and the consent condition for the second call.

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 necessary work of stating what the first call returns (the pending submission content) and what gates the second call. The only gap is what the committed submission yields (confirmation state, expected follow-up/email), which an agent may want to report back to the user.

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 carries field-level meaning and the baseline is 3. The description adds genuine value by explaining the relational semantics of confirm_token and the consent boolean — that the token comes from the first call's return value and that the second call must reuse identical arguments — which the schema alone only hints at.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (접수/submit an enterprise-usage inquiry) and immediately enumerates the covered sub-cases (bulk lookup, system-integration API key, data provision). No sibling tool (all get_*/list_*/skill_* read operations) does anything comparable, so an agent can distinguish this submission tool at a glance.

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 explicitly prescribes the call sequence: first call without confirm_token returns only a preview, that preview must be shown to the user verbatim, consent (including privacy consent) must be obtained, and only then may the same arguments plus confirm_token be sent. Both the when and the when-not (do not call with confirm_token before consent) are spelled out.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no statement about what the body looks like (markdown, steps, sections), what happens on an unknown or missing skill_id, or any size/truncation 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 short sentence with no padding, but terse to the point of under-specification; brevity here is not the same as efficiency since nothing is front-loaded beyond the basic action.

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 parameter documentation, the description carries the burden of explaining the return value and the identifier's origin, and it does neither. For a content-retrieval tool this leaves an agent guessing about the response shape.

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 single parameter skill_id has no description in either the schema or the prose. The description never says the ID must come from skill_list, which is the main thing an agent needs to use this parameter correctly.

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 (돌려줍니다 / returns) and a specific resource (one procedure document's body). The phrase "한 편의 본문" implicitly distinguishes it from skill_list, which returns a listing rather than content, though it never names that sibling.

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?

No guidance on when to call this versus skill_list or the other get_* tools. An agent must infer that it needs a skill_id obtained elsewhere, and nothing explains when body retrieval is appropriate.

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 context the annotations do not carry — that calling it does not consume the '맛보기' (trial/preview) quota — which is genuinely useful for an agent budgeting calls. It does not describe the shape of the returned list, 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 identity of the resource, then the ordering constraint, then the quota note. No filler or repetition of the title.

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, read-only list tool with full annotation coverage, the description covers what it is, when to call it, and a behavioral quirk. The one gap is that it never says what the list entries contain (names, descriptions, identifiers), and there is no output schema to compensate — an agent must call it blind to learn the return shape.

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; the baseline for a parameterless tool applies. No param-level claims are made, but 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 identifies a concrete resource — the list of procedures (skills) available on this server — which is clearly distinct from the sibling skill_get that presumably fetches a single procedure. The verb is nominal ('목록입니다') rather than an explicit 'list', and the description never names skill_get as the contrast, so the differentiation is inferable 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?

'수치를 인용하기 전에 먼저 부르십시오' gives an explicit precondition for calling the tool, which is real routing guidance. However it offers no when-not condition and does not point to the sibling skill_get for follow-up detail, so it stops short of full alternative coverage.

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