평생요금제닷컴 알뜰폰 요금제 (Korea MVNO plans)

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 bar is low; the description usefully adds what is actually compared (post-discount price, 24-month total) for each plan type. It omits default behavior when no filters are supplied (0 required params), which is the main undisclosed trait.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core comparison, then usage, then filters. Dense and Korean-idiomatic with no filler, though the tier enumeration is slightly list-heavy for the payload it carries.

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, so the description must carry return-value burden; it names two metrics (post-discount price, 24-month total) but not the result shape, tier-by-tier grouping, or behavior with zero filters. Adequate for invocation, incomplete for predicting output.

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 80% and already documents most fields, but the description maps all five filters to plain-language dimensions (network carrier, 5G, unlimited voice, post-exhaustion speed, free USIM), reinforcing how each narrows results. It adds interpretation rather than syntax, so it stays above the baseline-3 floor.

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 (평생 할인·정가 요금제 vs 기간 할인 요금제) scoped to explicit data tiers (1/5/10/15/30/70/100GB). An agent can tell what it produces, though it never names a sibling tool like search_plans or price_index to draw the boundary 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 a clear first-choice condition, and the filter list (통신망·5G·통화 무제한·소진 후 속도·유심 무료) shows how to narrow. No when-not condition or named alternative is given, so it stops short of full 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds valuable behavioral context by listing the rich set of data returned (fees, tethering, SIM costs, price history, etc.), which helps the agent know what to expect from the call.

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 purpose and followed by the actionable hint about where to get the id. The first sentence is a dense list of returned fields, but each item earns its place by informing the agent about output contents; there is no wasted wording.

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 simple one-parameter signature, full schema coverage, and annotations that cover safety behavior, the description is complete. It compensates for the absence of an output schema by enumerating what data is returned and explains how to obtain the required 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 100% and the single id parameter is well defined with a format example (e.g., joytel-617). The description adds meaning by specifying that the id should come from search or search_plans results, which is not stated in the schema and clarifies the value's origin.

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 (Fetch) and resource (one plan by id), then enumerates the returned data fields. It also directly names the sibling tools that produce the required id (search, search_plans), making it clearly distinguishable from search-style 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?

Explicitly tells the agent to insert an id obtained from search or search_plans results, which provides clear context for when to use this tool. It does not state when not to use it or list alternative tools, but the intended workflow is unambiguous.

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 behavior-relevant context beyond that: it discloses the composition of the returned carrier records and notes that the SIM guidance is the carrier's verbatim source text, a useful provenance detail.

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 dense sentence with the scope ('per MVNO carrier') front-loaded and no filler. The bulleted field list is compressed into one line, which is efficient but slightly cryptic without punctuation separating concepts.

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 explaining return content, and it enumerates the per-carrier fields adequately for a zero-parameter read-only listing. It stops short of stating list size or relationship to sibling tools, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already communicates.

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

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

The description makes clear this returns MVNO-carrier-level information (plan counts, network, cheapest lifetime plan, support phone, SIM guide), which separates it from the plan-search siblings like search_plans or cheapest_by_data. It is a noun-phrase enumeration rather than an explicit verb+resource statement, but the resource and its scope are unambiguous.

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 seven sibling price/search tools, no prerequisites, and no exclusions. The agent must infer usage purely from the return-field list.

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 fully covered by structured data. The description usefully expands on what is computed (medians vs maximums, per-network breakdowns, filtering conditions), but says nothing about aggregation time window, data freshness, or output shape. With annotations carrying the behavioral burden, a 3 is appropriate.

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 carries the metric inventory, followed by a short clause of example questions. Every element earns its place and there is no padding. The metric enumeration is dense but relevant given no output 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?

With no parameters and no output schema, the description must convey what comes back; it does so by listing the returned statistics (인상액 중앙값·최대값, 망별 최저가, 조건별 요금제 수). Read-only annotations remove the need to discuss side effects. Minor gap: no sense of scope or recency of the underlying data.

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 — there is no argument syntax for the description to explain and nothing the schema could leave ambiguous. No parameter-level value is added or missing.

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

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

Names a specific resource (알뜰폰 요금 통계) and enumerates the exact aggregate metrics it produces: 기간 할인 인상액 중앙값·최대값, 통신망별 최저가·중앙값, 조건별 요금제 수. That is far more than a restatement of the title. It stops short of 5 because it never distinguishes itself from overlapping siblings like price_index or plan_price_history, so an agent cannot rule those out from this text 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?

Provides concrete trigger questions ('기간 할인 끝나면 얼마 올라?', '0원 요금제 함정', '망별 평균 요금'), which effectively tells the agent which user intents map here. It gives no exclusions and does not name the alternative statistics tools to use instead, so it stays at 4 rather than 5.

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 establish the safety profile (readOnlyHint, idempotentHint, non-destructive), so the description is not burdened with that. It does add genuine behavioral context beyond the annotations: the data is refreshed daily from the official homepage and coverage begins at a 'record start date'. However, it never clarifies how far back the history goes or whether the series has gaps, which matters for a time-series tool.

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 compact sentence with the resource named first and the provenance/coverage caveat in a parenthetical. No filler sentences, and nothing important is buried.

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 single-parameter read tool with no output schema, the description conveys the essentials: what is returned conceptually (dated monthly prices for one plan), the data source, and the update cadence. The remaining gap is the undocumented id format, which is minor given the tool's simplicity.

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 weight. It does imply the lone 'id' parameter identifies a single plan ('요금제 하나의'), which adds real meaning over the bare string type, but it gives no format, source, or validity guidance for that identifier.

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 resource and scope: the dated monthly-price record for a single plan, sourced from daily checks of the official site. An agent can tell this is a per-plan historical price series, though it does not distinguish itself from close siblings like recent_price_changes or price_index.

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 obvious alternatives (recent_price_changes, price_index, cheapest_by_data). The only implicit cue is 'one plan', which hints at single-plan lookups, but no exclusions or comparative guidance are given.

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, idempotent, non-destructive read, so the safety profile is covered. The description adds that the index reports median and minimum values per month/data tier, but says nothing about the time span covered, refresh cadence, or output shape, which matters more given there is no output schema.

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 core content (what the index compares) stated first and the use case second. Every clause carries information and 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?

For a zero-parameter index tool, the description conveys what is measured and when to reach for it, and the annotations cover the rest of the safety profile. The remaining gap is return-value behavior (time range, granularity, format), which is not covered by an output schema and is only partially implied.

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 no-parameter tool applies. The description correctly implies the query is unfiltered by any argument, consistent with 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?

The description names a specific resource (MVNO price index) and states precisely what it aggregates: monthly median and minimum lifetime-plan prices compared per data tier. This is far more than a restatement of the name, but it never explicitly distinguishes itself from the sibling plan_price_history or recent_price_changes.

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 a concrete usage condition — trend questions such as 'are MVNO prices rising?' — which tells the agent when this tool applies. However, it offers no exclusions and does not name the alternative tools (plan_price_history, recent_price_changes) that could be confused with 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?

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds real value by disclosing provenance ('daily comparison of official homepage records'), which tells the agent how fresh the data is, but it says nothing about return shape, pagination, or what happens when no changes are found.

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 dense sentence that front-loads the time window and resource, then the returned fields, then provenance. No filler, though the embedded defaults/max duplicate the schema rather than earning their place.

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

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

For an 8-parameter read tool with no output schema, the description does sketch the returned fields (changed date, before/after price), which partly compensates. But it leaves the direction/limit interaction, empty-result behavior, and the overlap with plan_price_history unexplained.

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 88%, so the schema already documents nearly every parameter, including the days range and default. The description merely restates 'N days (default 7, max 60)' and adds no syntax or interpretation beyond the schema.

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

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

States a specific verb+resource: plans whose monthly fee rose or fell within the last N days, plus the changed date and before/after prices. Clear on its own, but it never distinguishes itself from the sibling plan_price_history, which sounds closely related.

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 when-to-use guidance, no exclusions, and no routing to alternatives such as plan_price_history or price_index. The only clarifying sentence explains data provenance (daily homepage comparison), not usage conditions.

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, but the description adds real substance on top: which condition tokens it parses (data GB, price ceiling, network, 5G, unlimited calls, free SIM, tethering, bundling, data sharing, no-conditions, carrier, lifetime/period/first-come), that data comes from carrier official pages, and that it also returns a 기간할인 comparison with post-discount price and 24-month total. Return format and result-count limits are still unspecified.

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 paragraph, front-loaded with the core purpose and then progressively adding parsing scope, return behavior, and examples. Dense but every clause earns its place; the parenthetical condition list is long yet informative rather than 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?

There is no output schema, so the description carries the return-value burden, and it does describe the main payload (matching plans plus a 기간할인 comparison with total 24-month cost) and the id-to-fetch handoff. For a single-parameter NL search tool this is nearly complete, with only result shape/ordering 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 coverage is 100% and the single parameter is just labeled '한국어 검색어', so the schema alone conveys little. The description adds genuine meaning by showing that the parameter accepts free-form Korean natural language and by enumerating the condition patterns and example phrasings the parser understands.

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: natural-language search over Korean MVNO (알뜰폰) plans, sourced from carrier official sites. It clearly distinguishes itself from fetch (which it says handles detail lookup), but does not differentiate itself at all from the sibling 'search_plans', leaving the agent to guess which search entry point to use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit context for use (drop a plain Korean query in as-is) plus five concrete example queries covering carrier, data, price cap, 5G, unlimited-call and first-come-limited cases, and names fetch as the follow-up for details. It stops short of stating when NOT to use it or how it relates to search_plans.

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 safety (readOnlyHint=true, destructiveHint=false, idempotent, and openWorldHint=false indicating a bounded dataset). The description adds genuine context beyond them: the data source (carrier official homepage), refresh cadence (checked 5 times a day), and that each result carries source evidence, verification timestamp, official address, and periodComparison. This provenance/freshness detail is real added value.

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 and scope are front-loaded, followed by defaults and return composition in dense but ordered clauses; every sentence carries information. It is marginally over-packed, but nothing reads as 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 21 optional filters and no output schema, the description responsibly covers the defaults, the alternate sorts, and a sketch of the result payload (evidence, verification time, address, periodComparison), which is the main thing the missing output schema would otherwise supply. Individual filter semantics are left to the thorough schema, which is acceptable.

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 95%, which alone sets the baseline at 3, and the description largely restates schema content (the sort=data/total24 and default lifetime/fee semantics are already documented per-parameter). It adds little parameter meaning the schema does not already carry.

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 (검색/find) and resource (알뜰폰 요금제, MVNO plans) with a clear scope (set conditions by field). It is distinguishable in general terms but never names or contrasts with the likely-overlapping siblings search and cheapest_by_data, leaving an agent to infer which search entry point fits.

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 conveys useful default behavior (기본은 평생 할인·정가 요금제, 월 요금 낮은 순) so an agent knows the baseline query, but there is no when-to-use/when-not guidance and no explicit routing against alternatives like search, cheapest_by_data, or price_index. Usage is implied rather than stated.

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 safety is covered. The description goes beyond them by disclosing the shape of the result: original official-event quotations plus retention months, payout timing, and caution conditions. That is valuable output-content context, though it omits any note on result size or ordering.

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 dense sentence front-loads the core concept (plans that net positive) before the supplementary detail about quoted event text and conditions. It is well-structured, though the run-on length makes it slightly heavy for one sentence.

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 explaining what the result contains (event quotes, retention months, payout timing, cautions), and annotations cover the safety profile. The gap is that it never clarifies the boundary against the many pricing siblings, which is the main thing an agent still needs.

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% (mno enum, brand substring, limit 1~50 default 25, minNet, excludeReferral), so the schema already carries parameter meaning. The description adds nothing about how these filters interact or what defaults apply, so baseline 3 is correct.

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

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

The description states a specific resource and concept: a table of MVNO plans where event gifts (Naver Pay, vouchers, points) exceed the retention-period monthly fee plus SIM cost, i.e. plans that net positive. That is far more specific than a generic 'list plans' tool. However, it never distinguishes itself from pricing siblings like cheapest_by_data, price_index, or search_plans, so an agent must 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 tool is for finding plans where gifts outweigh costs. There is no explicit 'use this when…' statement, no exclusions, and no named alternative for related questions (e.g. plain cheapest price lookups), so the agent has to infer when this beats the price-focused siblings.

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