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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing beyond that — it does not explain rate limits, auth requirements, or what '상세 정보' includes, so it contributes no behavioral context of its own.

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

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

A single short sentence with no filler, and the identifying parameter is front-loaded. It is efficiently sized for a simple lookup tool, though it is so terse that it conveys little beyond 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 two-parameter read tool with rich annotations and a complete schema, the description is minimally sufficient — the schema handles the customerId fallback and there is no output schema to explain. However, it gives no sense of what fields the returned detail contains, leaving the agent to infer the value of calling it.

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 schema already documents both adId (nccAdId) and the optional customerId with its fallback to NAVER_ADS_CUSTOMER_ID. The description only restates the identifier concept, adding no syntax or format detail beyond the schema, which matches the baseline 3 for fully-documented schemas.

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

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

States a specific verb (조회) and resource (광고 소재) plus the single-record scope ('하나의'), which implicitly separates it from the sibling list_ads. It stops short of explicitly naming that alternative, so it is clear but not fully differentiated.

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 word '단건' (single) plus the required nccAdId implies this is the lookup-by-id tool rather than the listing tool, but there is no explicit statement of when to use it versus list_ads or get_campaign/get_adgroup, and no prerequisites are mentioned.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that (no auth/permission notes, no behavior when the adgroup is missing).

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

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

A single front-loaded sentence with zero waste. It is efficient, though this brevity is what leaves the usage and behavioral gaps.

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 simple annotated read tool the coverage is adequate, but with no output schema the description says only '상세 정보' without indicating what the detail comprises, leaving the return shape entirely unspecified.

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 are already documented, including the customerId fallback to NAVER_ADS_CUSTOMER_ID. The description merely repeats the nccAdgroupId identifier and adds no syntax or format 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?

States a specific verb (조회/retrieve), resource (광고그룹/adgroup) and cardinality (하나의, single), which implicitly separates it from list_adgroups. It does not, however, name or contrast any sibling tool explicitly.

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

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

The singular '하나의' hints at single-record lookup versus a list call, but there is no explicit when-to-use, no prerequisites, and no mention of alternatives such as list_adgroups or get_adgroup_targets.

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, so the safety profile is fully covered. The description adds useful behavioral context by enumerating which targeting categories are returned. It does not, however, say what happens when no targeting is configured (empty result vs. error), which would be genuinely additive.

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

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

A single front-loaded sentence with the verb and resource up front and no filler. The parenthetical enumeration is compact and informative. Not padded, though it does not use the space to add usage or behavioral detail.

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

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

For a 2-parameter read tool with rich annotations but no output schema, the description supplies the key missing piece: what targeting fields the response contains. An agent has enough to invoke it correctly. Optional gaps (empty-targeting behavior, ordering/nesting of results) remain, keeping it from a 5.

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 both parameters carry their own descriptions, including the customerId fallback to NAVER_ADS_CUSTOMER_ID. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb (조회합니다) and a clearly bounded resource (광고그룹에 설정된 타게팅), and it even enumerates the targeting dimensions covered (요일·시간, 지역, 매체, PC/모바일). This makes it easy to distinguish from generic siblings like get_adgroup. It does not explicitly name a sibling it is not, so it falls just 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?

There is no statement of when to use this tool versus alternatives, nor any prerequisite or exclusion guidance. The read-only nature is only inferable from the annotations and the verb '조회합니다'. An agent gets no routing help for the many list_*/get_* siblings.

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, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description contributes nothing beyond the purpose sentence — no note on what happens when the campaignId is unknown, what account context is used, or rate/scope caveats.

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 tight sentence with the identifier front-loaded and zero filler. It is efficient, though with only one sentence there is no structure or prioritization to speak of.

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 simple two-parameter read tool with full annotation coverage and complete schema docs, this is sufficient to invoke correctly. However, with no output schema present, the description could have sketched what '상세 정보' comprises; that omission keeps it at minimum-viable rather than 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 description coverage is 100%, so both parameters (campaignId, customerId) are already documented with format hints, including the fallback to NAVER_ADS_CUSTOMER_ID. The description only echoes nccCampaignId and adds no syntax or constraint detail beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb (조회합니다 / retrieve) and resource (캠페인 하나 / a single campaign) and keys it on nccCampaignId. It is clearly distinguishable from the sibling list_campaigns by virtue of the singular scope, though it never names that alternative 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?

Usage is only implied: the singular '하나의' and the sibling pair list_campaigns/get_campaign make the select-single-record intent inferable. There is no statement of when to prefer this over list_campaigns, no prerequisite or error-condition 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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds nothing behavioral beyond that — no note on what happens when the keywordId is unknown, no permission/account-scoping caveat despite customerId defaulting to an env var.

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

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

A single front-loaded sentence with no filler or redundancy. It is appropriately sized, though it is perhaps too terse to earn a 5 given the gaps noted above.

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 simple one-entity read tool with rich annotations and no output schema, the description is adequate — the agent knows exactly what is fetched and by which key. It lacks only error/not-found behavior, which is a minor omission.

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 keywordId (with an example value) and customerId (with its env-var fallback) are already fully documented in the schema. The description merely restates the lookup key, adding no format or fallback detail beyond it, so the baseline 3 applies.

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

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

States a specific verb (조회) and a singular resource (키워드 하나) with the lookup key (nccKeywordId), so an agent can distinguish it from list_keywords. It stops short of naming the sibling or clarifying scope beyond the singular/plural naming convention.

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: nothing says to call this when you already hold a keywordId, nor points to list_keywords for discovery. The singular phrasing only implies the distinction, which is the weakest form 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds useful context — the hint cap of 5 and that results are independent of ad registration — but says nothing about rate limits, quota, or response shape. Adequate but not rich beyond the annotations.

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 compact sentences: purpose first, then usage condition, then the hint constraint. No filler, and the core capability 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 usefully names what is returned (related keywords and monthly search volume/clicks/competition). Combined with 100% schema coverage and full annotations, an agent has enough to call it correctly; only the response format/pagination is unspecified, which is minor.

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 the schema already documents customerId, showDetail, and hintKeywords. The description's '힌트는 최대 5개' merely restates the schema's maxItems=5, adding no new semantics. Baseline 3 applies when the schema does the heavy lifting.

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 precise verb+resource: retrieves related keywords plus monthly search volume, clicks, and competition level for hint keywords, and names the underlying Keyword Tool API. This clearly distinguishes it from siblings like list_keywords (registered keywords) and get_stats, so an agent can select it without opening the schema.

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 use context ('used for keyword discovery') and a qualifying condition ('can be queried regardless of ad registration status'), which tells the agent this is not limited to registered keywords. It stops short of explicitly contrasting with alternatives such as list_keywords or get_stats, so it lacks explicit when-not 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 readOnly, idempotent, non-destructive, so safety is covered. The description adds operational context beyond annotations: the ID-type-agnostic behavior and the date-source mutual exclusion with an implicit default, which are non-obvious traits.

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 tight sentences, front-loaded with purpose, then the ID-typing rule, then the date rule. No filler, though slightly terse for English-reading agents given the Korean-only text.

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?

Covers the two genuinely ambiguous behaviors (polymorphic ids, mutually exclusive date params with default) for an 8-param read tool. Output format is not described, but the tool is read-only and a consumer can rely on the fields parameter; no output schema exists, so a brief return-shape note would have closed the last 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 100%, so baseline is 3. The description still adds value by describing ids' polymorphic acceptance and the since/until vs datePreset constraint that the schema's individual field descriptions do not state as a cross-field rule.

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 the exact resources covered (캠페인·광고그룹·키워드·소재), making it distinguishable from single-resource sibling getters like get_campaign or get_keyword.

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 resolves a real ambiguity: only one of since+until or datePreset may be set, and omitting both falls back to NAVER's default period. It also clarifies that ids accepts heterogeneous ID types, removing guesswork about mixing campaign/adgroup/keyword/ad IDs.

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, and destructiveHint=false, so the safety profile is covered. The description adds that the tool retrieves extension assets attached to a campaign or adgroup, but does not disclose pagination, rate limits, authentication requirements, or return format 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?

The description is a single, well-structured sentence that front-loads the core action and resource without any wasted words.

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 simple read-only list tool with fully described parameters and annotations covering safety, the description is adequate. It does not explain the return structure, but no output schema exists, and the tool name implies a list. Minor missing detail on possible filtering or pagination.

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%, with both parameters fully documented in the input schema. The description adds no parameter-level semantics beyond what the schema already provides, so the baseline score 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 states the verb '조회합니다' (retrieves) and the resource '확장 소재' (extension assets) attached to a campaign or adgroup, listing examples like phone numbers, location info, and promotional text. It implicitly distinguishes from siblings since no other listed tool handles extension assets, but lacks explicit 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?

There is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. Usage is only implied from the purpose statement.

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 behavior, so the safety profile is covered. The description adds genuine context beyond that: the conceptual role of an adgroup and the scoping effect of omitting campaignId. It omits pagination/return-size behavior for a list 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?

Three short sentences, no waste, with the core action front-loaded. The middle domain-definition sentence earns its place by clarifying the entity.

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?

Adequate for a read-only list tool: annotations cover safety, schema covers all three params with descriptions, and the description covers scoping. Missing only pagination/result-limit guidance, which matters for an unbounded list operation.

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 is 3, but the description adds meaning the schema lacks: the campaignId-omitted default (account-wide) scoping rule. adgroupIds and customerId semantics are left entirely to 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 (조회/광고그룹 목록) and even defines what an adgroup is, so the agent understands the entity. It does not explicitly distinguish itself from get_adgroup or list_campaigns, so it falls short of full sibling differentiation.

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

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

Gives one conditional mode: omitting campaignId returns all adgroups in the account, and campaignId's schema text points to list_campaigns first. However it never says when to use this vs get_adgroup for a single adgroup, nor any prerequisite chain, leaving alternatives implied.

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=true, so the safety profile is fully covered by structured data. The description adds that the read returns title, description, link URL and review status, but does not describe ordering, pagination, or result limits, which is a moderate gap for a list operation.

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 that front-loads the resource, scope, returned fields and status. Every element earns its place with no filler or repetition.

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 simple 2-parameter read tool with full schema coverage, full annotations and no output schema, the description is nearly sufficient. It tells the agent what entity is listed and what data comes back; only list behavior such as pagination or ordering is unstated.

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%, with adgroupId and customerId both documented in the schema, including the fallback to NAVER_ADS_CUSTOMER_ID. The description adds no additional meaning beyond saying the target is an ad group, 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 states a specific verb (조회합니다) and resource (광고 소재 목록) scoped to an ad group, and lists the returned fields (제목·설명·연결 URL) plus review status. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling get_ad, which likely returns a single ad.

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 gives no guidance on when to use this tool versus alternatives such as get_ad or other list_* tools. No prerequisites, no when-not-to-use conditions, and no routing hints are 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered externally. The description adds only the semantic context that ad groups target these channels — nothing about result volume, pagination, or ordering. 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?

Two short sentences with the resource and its enumeration front-loaded, followed by the relational context. No filler, though the second sentence's value is modest given the annotations already frame the operation.

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-only listing tool with 100% schema coverage and full annotations, the description supplies what is needed to call it correctly; no output schema means return details are not required here. The only gap is the absence of sibling differentiation.

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 customerId parameter is fully documented in the schema, including the NAVER_ADS_CUSTOMER_ID fallback. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a clear verb (조회) and resource (비즈채널), and enriches it by enumerating concrete channel types (웹사이트, 전화번호, 네이버 톡, 쇼핑몰). It does not distinguish itself from siblings like list_ad_extensions or list_customer_links, 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 second sentence ('광고그룹이 연결하는 대상입니다') implies the context in which these channels matter, but there is no explicit when-to-use, no when-not-to-use, and no named alternative among the many listing siblings. Usage is inferable but not guided.

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, so safety and idempotency are covered. The description adds useful domain context (what a campaign is, the linkage to list_adgroups) but does not disclose pagination, rate limits, or return format.

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 concise sentences, front-loaded with the core action, then domain definition, then the practical linkage to a sibling tool. 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 simple two-parameter read tool with 100% schema coverage and full safety annotations, the description is nearly complete. It could add a note about whether results are paginated or ordered, but the essentials are covered.

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 the schema fully documents customerId (with the NAVER_ADS_CUSTOMER_ID fallback) and campaignIds (max 100, full list if omitted). The description adds no parameter-level detail beyond what the schema already provides; baseline 3 is appropriate.

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?

Clearly states it retrieves a list of campaigns for an ad account and defines what a campaign is (top-level unit managing ad type and budget). Distinguishes from get_campaign (singular) by scope, though it doesn't explicitly name alternatives.

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 implied by the description's mention that the returned nccCampaignId feeds into list_adgroups, but it does not state explicit when-to-use or when-not conditions, nor name sibling tools directly.

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, openWorldHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing about pagination, result shape, or rate limits beyond what annotations supply.

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 with zero filler, and the core purpose is front-loaded before the cross-tool hint. Appropriately sized for a simple two-parameter list tool.

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 could state what the returned list contains (e.g. customerId/name fields) since that is the key payload an agent needs. It gestures at customerId but leaves the return structure 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 (type filter defaulting to all, customerId defaulting to NAVER_ADS_CUSTOMER_ID) are already documented. The description contributes the cross-tool reuse intent of customerId, but no additional syntax or 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 (조회) and resource (대행사·광고주 간 연결된 광고계정 목록), which is distinct from sibling tools like list_campaigns or get_campaign. It does not explicitly name a sibling to contrast against, keeping it 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 second sentence gives a real workflow cue: the customerId obtained here can be passed to other tools to move across accounts, implying this is a starting/lookup call. However there is no explicit when-to-use or when-not-to-use versus alternatives.

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, openWorldHint, and destructiveHint=false, so safety is covered. The description adds what is returned (bid, status) and what is excluded (impressions, clicks, cost), but does not disclose pagination, rate limits, or output format details; with annotations doing heavy lifting, this is adequate but has clear gaps.

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 with zero waste. The purpose is front-loaded, and the exclusion plus alternative is stated compactly and secondarily.

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 list tool with no output schema, annotations covering safety, and full schema coverage, the description is complete enough: it states scope, returned fields, and the key exclusion, and routes the agent to the right sibling for performance 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?

Schema description coverage is 100%, so both adgroupId and customerId are fully documented in the schema. The description adds no parameter syntax or format details beyond what the schema already provides, so baseline 3 is appropriate.

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: list keywords in an ad group, including bid and status. It distinguishes the tool from get_stats by noting that performance metrics are excluded, so the agent can route correctly without opening other schemas.

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 says performance metrics are not included and directs the agent to use get_stats together. This names the alternative and the condition that selects it, leaving nothing 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety and openness profile is fully covered structurally. The description adds the fallback semantics and a documentation link, but says nothing about auth, rate limits, or how unwrapped paths behave on error. Value beyond annotations is real but modest.

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?

Four short sentences, each doing distinct work: purpose, routing rule, concrete example path, and spec reference. Front-loaded with the core action and free of filler, though the docs URL could arguably be folded into 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?

For an open-world generic GET escape hatch with no output schema, the description supplies the routing rule, a concrete example endpoint, and where to find the full spec. What is missing is any note on error/response shape for arbitrary paths, but annotations and the spec link carry most of the load.

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 each parameter (path, query, customerId) is already documented in the schema, including the path example and CUSTOMER_ID fallback. The description only echoes the /ncc/labels style path example, adding no new syntax or format guidance. Baseline 3 is appropriate.

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 ('전용 툴이 없는 네이버 검색광고 API 엔드포인트를 직접 GET 호출합니다') and immediately positions itself against the sibling set by declaring itself the fallback for unwrapped paths. An agent can distinguish this from list_campaigns / get_stats without opening any schema.

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 gives both the when ('/ncc/labels 처럼 아직 감싸지 않은 경로용') and the when-not with named alternatives ('전용 툴(list_campaigns, get_stats 등)이 있으면 그쪽을 쓰세요'). Routing between this tool and its siblings is fully specified.

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