Kollus

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

Beyond the annotations, the description discloses that this is the only write tool, that the ticket is genuinely submitted to an external party, that the requester email is auto-assigned from the linked account and cannot be supplied, that Freshdesk credentials live server-side, that the rate limit is 5 tickets per hour, that CC is capped at 7, and that the created ticket id and status are returned. These are exactly the facts an agent needs before committing a real external side effect.

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 trigger condition and the consent requirement are front-loaded, and the remaining paragraphs are organized by topic (identity, body content, limits, auth). It is longer than strictly necessary, with some redundancy such as repeating the CC maximum of 7 that the schema already enforces.

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 non-idempotent, open-world write tool with six parameters and no output schema, the description covers the trigger, prerequisites, required user consent, identity handling, rate limits, authentication, and the shape of the success response. Nothing an agent needs to call it safely 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 coverage is 100%, so 3 is the baseline, but the description adds meaning the schema does not: it explains that the reply email cannot be passed as input at all, that the name value should be elicited from the user rather than invented, and what content makes a good body (symptoms, reproduction steps, content keys, error messages). It does restate the CC cap of 7 and the rate limit already implied by the schema.

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

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

The description states a specific verb and resource (create one support ticket on the Catenoid Freshdesk desk, POST /api/v2/tickets) and explicitly distinguishes itself from all siblings by noting it is the only write tool among them. An agent can tell immediately that this is not a docs or VOD lookup tool.

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 an explicit trigger condition (only when the answer cannot be found in indexed docs, specs, samples, guidance, or anti-patterns, or when the user explicitly wants to contact the PE team) plus a hard precondition (a linked Kollus account is required) and a mandatory pre-call step (confirm subject, body, and name with the user and obtain consent).

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 and the description's real contribution is the negative-space list: DRM policy details, callback URL, playback expiry, subtitle tracks and encoding profiles are NOT returned. That is genuinely useful for an agent deciding whether this tool answers its question. However, it does not say what happens on a missing/inaccessible key (only that wrong region yields 401) nor whether a tombstoned or untranscoded item still returns a body, which matters for a lookup tool with 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?

Purpose is front-loaded and the not-included list earns its space, but the response-field enumeration is a long inline run of field names that could be compressed, and the region paragraph restates what the schema already says about defaults and ambiguity. Dense but with real redundancy against structured fields.

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

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

For a two-parameter read with no output schema, the description supplies the return-value inventory and the explicit exclusions, so an agent knows what it will and won't get back. Remaining gap is error/empty-case behavior (nonexistent key, still-transcoding item) on a tool where the annotation set is otherwise 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 both parameters are richly documented, so the schema carries most of the weight. The description still adds meaning not present in the schema: the account-level region always wins over the 'region' argument and mixed regions per account are impossible, which changes what passing 'region' actually does. The upload_file_key vs media_content_id vs content_id disambiguation is largely duplicated from 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?

Opens with a specific verb+resource in one line ('특정 영상 1건의 메타데이터를 조회한다') and pins it to the endpoint GET /media-contents/{upload_file_key}. It explicitly contrasts with the sibling list_media_contents ('응답 필드는 list_media_contents 항목과 같은 구조'), so an agent can separate single-item fetch from list without opening either 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 concrete use cases (트랜스코딩 실패·암호화 여부·파일 속성 1차 확인) and an explicit fallback: if upload_file_key is unknown, start from list_media_contents. Region selection adds an escalation rule — decide from user context, ask the user when ambiguous, never guess — plus the exclusion case where account-registered region overrides the argument.

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 readOnly/idempotent annotations it discloses a 5-minute response cache, that a wrong-region call yields 401, and that an account-registered region overrides the region argument so regions cannot be mixed. These are operational traits an agent cannot infer from the schema or 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?

Front-loads purpose, then constraints, then the sibling reference, then a labeled 'Region 선택' block. Dense but well organized; some repetition of date limits already present in the schema descriptions costs it a point.

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 ranked-list tool with no output schema, the definition covers scope, limits, caching, pagination and region selection. It stops short of describing what the ranked response contains (fields per video), a minor remaining gap.

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

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

Schema coverage is 100%, so the schema already carries parameter documentation; the description reinforces the date window and pagination semantics. It adds one genuinely new rule not present in the schema — that the account-registered region always takes precedence over the region argument — which earns it above the 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?

Names a specific verb and resource (영상별 시청 순위 조회) and even the underlying endpoint GET /statistics/content-rank. It explicitly distinguishes itself from the sibling get_statistics_summary_daily by scoping that one to account-wide daily time series.

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?

States the retrieval window constraints (within the last year, max 3 months per query), names the alternative tool for a different need, and gives an explicit decision procedure for the region argument including 'confirm with the user when ambiguous, never guess'.

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?

Goes well beyond the readOnly/idempotent annotations: response is cached for 5 minutes, the 1-year/3-month window limits, the account-registered region always overrides the region argument (region is fixed per account, no mixing), and a wrong-region call yields 401. These are exactly the operational constraints an agent needs before invoking.

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?

Front-loaded with purpose, then returns, then exclusions, then constraints — a sensible ordering with no filler sentences. It is dense and information-heavy for one paragraph, but nearly every clause carries operational value; the region explanation is somewhat redundant with the schema 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?

No output schema exists, and the description compensates by describing the return shape (period totals plus a daily_data[] time series with named fields and units). Combined with the limits, caching, and region precedence notes, nothing needed to call this correctly 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not convey: region is fixed per account and the account-level region silently overrides the passed argument, and the period arguments must be split when exceeding 3 months. The region resolution pointer to kollus://guidance/regions is repeated from the schema but the precedence rule is genuinely new.

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?

Specific verb+resource (daily statistics summary) with the exact endpoint stated, and it enumerates the returned metric families (transfer, traffic, storage, transcoding, visitor) with units. It explicitly excludes play-count/watch-time fields and names the sibling get_statistics_content_rank for those, so the agent can distinguish it from siblings without opening a 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 concrete when-to-use rules: date range must be within the last year, max 3 months per call with long ranges split into 3-month chunks, and play-count requests must be routed to get_statistics_content_rank. It also states that group_by-style distributions (device/region/cdn) are unsupported by the REST API, preventing a wasted attempt.

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 goes further by spelling out exactly what each mode returns (folder paths with recursive document counts versus id/title/description plus immediate subfolders). That return-shape disclosure is especially valuable because no output schema exists, and it clarifies that ids are kollus:// resource URIs rather than opaque handles.

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 the no-path default come first, followed by the path-specific behavior, then the id/resource follow-up and the exclusion. Every clause earns its place, though the stacked parentheticals make individual sentences dense and slightly harder to scan than necessary.

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-optional-parameter read tool with no output schema, the description covers everything an agent needs: both return modes, the shape of returned fields, how to follow up on an id, and what content is out of scope. No annotation or schema gap is left unaddressed.

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

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

Schema description coverage is 100% and the single path parameter is already documented in detail, including the "/" and "dev-guide/vod" examples and the optional kollus:// prefix. The description restates that meaning accurately but adds no syntax or edge-case detail beyond the schema, 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 names a specific action and resource: traversing the index of Kollus guides, error-code dictionary, supplementary guides, and anti-pattern docs as a folder tree. It also distinguishes the two operating modes (no path = full folder map; specific path = documents in that folder), so an agent can separate this browsing tool from search_docs or get_content_detail without opening 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?

It gives clear call patterns: omit path or pass "/" for the whole map, pass a folder path for a local listing, and read the returned id as an MCP resource when the body is needed. It also states an explicit scope exclusion (no OpenAPI specs or sample code), but never names a sibling tool such as search_docs as the alternative for keyword lookup, so routing guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint/openWorldHint, yet the description still adds real context: wrong-region calls return 401, an account-registered region always overrides the region argument (region is fixed per account and cannot be mixed), and category_key switches the underlying endpoint. What is missing is anything about result volume or pagination limits beyond what the schema states.

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 content is useful but the anti-pattern warning is a long preamble that pushes the actual purpose statement into the second block, so the definition is not front-loaded by what the tool does. The region and category_key rules are also restated from the schema, adding some redundancy to an already multi-paragraph description.

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 14-parameter read-only list tool with no output schema, the description covers filtering, region selection, sibling handoffs, and the upload_file_key-to-get_content_detail chaining, which hints at response shape. It stops short of describing the returned list envelope or pagination totals, which an agent must infer.

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 explains all 14 parameters, including region and category_key. The description adds only the region decision policy ('사용자 컨텍스트로 결정, 모호하면 확인', account region overrides) and the endpoint branching for category_key, which is modest added meaning over 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 and resource ('Kollus 계정의 VOD 영상(콘텐츠) 목록을 페이지 단위로 조회한다') and disambiguates the two backing endpoints depending on category_key. It also explicitly hands off adjacent jobs to siblings: single-item lookup to get_content_detail, daily traffic stats to get_statistics_summary_daily, per-video play counts to get_statistics_content_rank.

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 anti-use case (polling/setInterval/refetchInterval for CMS or DB mirroring) with the resource to consult instead, then lists concrete recommended scenarios (one-off query, backfill at ops start, user-triggered refresh, debugging). Alternatives for adjacent needs are named by tool, not 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 cover safety (readOnly, idempotent, non-destructive, closed world), and the description adds real context on top: the return fields (title, section, snippet, resource_uri, relevance_score), the round-trip fetch pattern, and the token-cost tradeoff between snippet search and single-document retrieval. It does not discuss ranking or pagination behavior, which keeps it below 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?

Three sentences, front-loaded with the search scope, then return fields, then the follow-up fetch pattern. Dense and mostly earned, though the nested parentheticals make it slightly heavy for what it conveys.

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, and the description compensates by naming the result fields and the resource_uri fetch path. Combined with the fully documented schema, an agent has what it needs, with only result ordering and result-set sizing 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%, so baseline is 3, but the description adds workflow meaning: resource_uri may be fed from a prior search result or a list_docs_index id, and doing so returns the full body with query ignored. That explains how the two parameters interact rather than restating their definitions.

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 set (search Kollus guides, OpenAPI specs, sample code, error-code dictionary by keyword query) and lists the exact result fields. It also distinguishes itself from list_docs_index by describing the two-step search-then-fetch flow, so an agent can route correctly without opening either 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 states the second mode: when the document is already identified, pass resource_uri (or a list_docs_index id) instead of doing a keyword search, and notes that this avoids pulling 20 snippets. It lacks a clear when-not-to-use statement versus browsing tools, but the mode selection guidance is concrete.

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 the description adds behavior well beyond them: wrong-region calls return 401, the account's registered region overrides the region argument and cannot be mixed, and the response embeds channels[] summaries. It also discloses pagination behavior (default 100, usually one call suffices, check pagination.total to continue).

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 critical anti-pattern warning is correctly front-loaded and the text is sectioned by concern, which helps. However, the region paragraph and the pagination paragraph substantially duplicate what the region and per_page schema descriptions already say, so several sentences do not add information beyond structured fields.

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 describing the response shape (per-category fields plus channels[] and pagination.total/current_page). For a read-only, zero-required-parameter listing tool, an agent has everything needed to call it correctly and to iterate pages.

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 baseline is 3; the description nonetheless adds real meaning about region selection (decide from user context, confirm when ambiguous, account region wins, 401 on mismatch) and about parent_category_key returning all descendants versus the full tree when omitted. The page/per_page guidance largely restates the schema, so it is not fully additive.

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 ("Kollus VOD 카테고리 트리를 조회한다 (GET /categories)") and enumerates the returned fields (key, name, parent_key, level, children_exist, position, channels[]). The hierarchy semantics (parent_key=null means top-level, level indicates depth) let an agent distinguish this tree-listing call from flat listing siblings such as vod_channel_list.

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

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

It states an explicit prohibition (no polling/setInterval/refetchInterval for CMS or DB sync) and redirects to kollus://anti-patterns/cms-admin-site, then lists four recommended one-shot use cases. What is missing is any explicit routing against sibling tools (e.g., vod_channel_list for channel-focused needs), so the alternative-selection half of the guidance is 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?

Beyond the readOnly/idempotent annotations, the description discloses that account-registered region always overrides the region argument (mixing not allowed), that a wrong-region call returns 401, and the pagination behavior for >100 channels. It also flags that count_of_contents excludes unregistered library content, which is a non-obvious data caveat.

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?

Paragraphs are clearly front-loaded by topic (prohibition, purpose, response fields, recommended uses, paging, region) and each block earns its place, including the long response-field enumeration that substitutes for a missing output schema. It is slightly verbose, with the paging and per_page behavior restated in both the description and the schema, but nothing is misleading or padded.

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 five optional params, no output schema, and no sibling that covers channels, the description carries the full burden and does: it enumerates response fields, explains paging, and resolves the region decision. Nothing an agent needs to invoke it correctly 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 coverage is already 100%, yet the description still adds meaning the schema cannot: why per_page defaults to 100 (channels are typically under 100), how to page using pagination.total once exceeded, and the precedence rule that makes the region argument advisory rather than authoritative. It also explains region selection by user context (Japanese console/credentials → jp).

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 with the underlying endpoint (GET /channels), and disambiguates the concept from Live API broadcast channels and from library-level content in list_media_contents. An agent can tell exactly what entity this lists and why counts may differ from the sibling content tool.

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 when-to-use cases (one-off structure discovery, startup mapping backfill, user-triggered single lookups, debugging) and explicit when-NOT-to-use with a named anti-pattern and a redirect resource (kollus://anti-patterns/cms-admin-site) before calling. Region decision rules and the 'ask the user when ambiguous' rule are also 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: no pagination, the full list is returned in one response, and profiles change infrequently because they are set at account setup. It also discloses the region precedence rule (the account-registered region always overrides the region argument, fixed per account) which is not in the annotations or schema. The only missed item is return ordering/edge behavior when zero profiles exist.

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?

Front-loaded with the verb and resource, then structured return fields, a bulleted use-case list, a frequency/response note, and a region block — easy to scan. It is somewhat long and the region section duplicates schema text, costing a point, but every other sentence carries actionable 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 parameterless read-only list tool with no output schema, the description supplies the return shape (the profile fields), response sizing (all rows, no pagination), why the tool exists, and the region caveat. An agent has everything needed to decide to call it and to interpret the result without opening anything else.

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 both parameters carry enums with descriptions, so the schema does the heavy lifting. The description's region paragraph largely restates the schema's guidance (default kr, ask the user when ambiguous, see kollus://guidance/regions) and adds only the account-region precedence note, while the order parameter is never mentioned in the description at all. 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?

Opens with a specific verb+resource: listing encoding/transcoding profiles registered to the service account, and pins the underlying endpoint (GET /media-profiles). It also enumerates the profile fields returned (container_format, video_codec, bitrate, resolution, is_default_preset, etc.), so an agent knows exactly what this resource is and can distinguish it from siblings like list_media_contents or get_content_detail.

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 two explicit use cases: resolving profile_key required by the pass-through upload API, and auditing account-level profile settings for quality debugging. It also states a negative boundary — that which profile was applied to a specific video cannot be determined here or in get_content_detail — which prevents a plausible misfire. Region selection guidance is included with the instruction to ask the user when ambiguous.

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