AI Skill Store

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

Beyond the static annotations (readOnlyHint, idempotentHint), the description discloses concrete behavioral outcomes by listing the exact summary statuses the tool returns (e.g., 'claimed, expired, agent_verify_email_sent'). This is crucial operational context.

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 tool definition is well-structured, utilizing clear headings (Purpose, Usage, Args, Returns) to segment information. The content is dense and highly efficient, leaving no room for ambiguity.

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

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

The definition is extremely complete. It covers the lifecycle of the draft, the exact required input, the context for invocation, and the resulting possible states, making it fully self-sufficient for an AI agent.

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

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

The description specifies the precise origin of the claim_token—that it must be the token returned by 'upload_skill_draft'. While the schema covers the type, the description adds essential provenance context.

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

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

The description clearly states the purpose as checking the status of a draft skill using a specific claim_token. It is clearly differentiated from sibling tools like 'upload_skill_draft' by its read-only nature and checking function.

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

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

It provides highly explicit usage guidance, outlining three detailed scenarios ('사용 시점') where the tool should be invoked, such as verifying user claim completion or checking for 30-day expiration.

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 the safety profile (readOnly, idempotent, open-world), so the bar is lower, and the description adds real value: it discloses the API-key authentication requirement and the owner-only access restriction. It could say more about polling behavior or whether status is terminal, but the auth constraint is the key missing piece and it is present.

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 opening sentence is front-loaded and useful, but it is immediately duplicated in Korean, and the Args/Returns block largely restates what the fully-described schema and output schema already convey. Content is short overall, but a meaningful share of it does not earn its 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 a two-parameter read-only status check with full schema descriptions and an output schema, the description covers the prerequisite workflow (upload_skill), the auth requirement, and the owner restriction. Nothing an agent needs in order 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 baseline would be 3, but the description adds meaning beyond the schema: it notes version_id may be either the version_id or the vetting_job_id returned by upload_skill, a nuance the schema does not state. The owner-only note on api_key reinforces the schema's wording rather than adding new constraints.

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: 'Check the security vetting status of an uploaded skill version,' which an agent can distinguish from upload_skill or get_vetting_result at a glance. It does not, however, explicitly contrast itself with the close sibling get_vetting_result (status vs. detailed result), leaving that boundary to inference.

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 clear usage context: version_id must come from a prior upload_skill result, and the caller must be the skill owner. It stops short of explicit exclusions or naming an alternative tool for retrieving full vetting results, so it is clear context without 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?

With annotations already declaring readOnlyHint=false and openWorldHint=true, the description goes further by warning that it writes a file and overwrites a same-named file in save_dir. It also says the result is a saved path or an error message, and that an empty save_dir uses a temp directory. Missing are notes on permissions or failure modes, but the overwrite disclosure is valuable context 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?

The first English sentence is front-loaded and useful, but the rest is duplicated bilingually and the Args/Returns sections largely restate the schema and output schema. The Korean translation doubles the length without adding new information for an agent that already has 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 a three-parameter tool with an output schema and full annotation coverage, the definition covers what matters: it writes a file, can overwrite, converts per platform, and defaults to a temp dir. The explicit Returns section is redundant given the output schema, but nothing an agent needs in order to call 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 description coverage is 100%, so the schema already documents all three parameters, including the skill_id UUID format and platform enum. The description's Args section restates those parameters in Korean and English but adds no syntax or format detail beyond the schema; the platform list is also slightly shorter than the schema's.

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 first sentence states a specific verb and resource ('Download a skill package and save it to the local filesystem') and adds the file-write behavior. It implicitly separates itself from get_skill by emphasizing the saved file, but it never names or contrasts a sibling explicitly.

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

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

The description explains conditional parameter behavior (set 'platform' for a converted package, leave empty for the original) but gives no guidance on when to call this versus get_skill, get_install_guide, or upload_skill. 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 readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered by structured data. The description adds the scope of the stats (uploads, claims, attribution history) but nothing about freshness, auth requirements, or failure modes for an unknown author name.

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 purpose is front-loaded in the first line and the text is short. The bilingual restatement and a Returns section that duplicates the existing output schema are minor waste, but nothing 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?

With one fully documented parameter, read-only/idempotent annotations, and an output schema covering the return fields, the description is sufficient to call the tool correctly. Only the sibling differentiation (identity vs. author stats) is missing.

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

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

Schema description coverage is 100% for the single parameter, so the schema already documents agent_name with the same example ('claude-sonnet-4-6'). The description merely restates it in Korean and English, adding no semantics beyond the schema; 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 names a specific verb and resource ("Get contribution stats for an agent author") and enumerates what is covered: uploads, claims, attribution history. It does not differentiate itself from the similarly named sibling get_agent_identity_stats, which is the main ambiguity an agent would face.

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 statement of when to use this tool versus alternatives such as get_agent_identity_stats, and no prerequisites or exclusions are given. Usage is only inferable from the purpose sentence itself.

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

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

Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is covered. The description adds modest value by noting it is a public query and by naming contact_email_verified as part of the response, but offers no detail on access restrictions 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?

The bilingual English/Korean duplication repeats the same information, and the explicit Args/Returns blocks are somewhat padded for a single-parameter tool. The core intent is front-loaded, but there is avoidable redundancy.

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?

An output schema exists so the detailed Returns list is not strictly necessary, and structural coverage is adequate. The critical missing piece is differentiation from get_agent_author_stats, which leaves the definition incomplete for correct tool selection in this crowded sibling set.

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 parameter already documents that agent_name must match the X-Agent-Author header with an example. The description's Args section merely restates "에이전트 이름 (X-Agent-Author 와 동일)", adding no meaningful semantic detail 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?

The description states a specific verb+resource ("get identity stats for the calling agent - claim success rate, claimed/expired counts") and adds a Korean restatement about querying Drafts uploaded by a specific agent_author. However, these two framings conflict (calling agent vs. arbitrary agent_author), and it never distinguishes itself from the near-identical sibling get_agent_author_stats, leaving the agent unsure which to pick.

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 and no mention of the closely named sibling get_agent_author_stats. The only hint is that it is a "공개 조회" (public query), which implies read-only usage but doesn't tell the agent when this tool is preferred over its sibling.

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 and openWorldHint=true, so the safety profile is covered. The description adds only that the return is a step-by-step guide string, which is redundant with the existing output schema and says nothing about formatting, platform fallbacks or whether guidance depends on vetting state.

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

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

The tool purpose is front-loaded in one clean sentence, but the bilingual restatement and a full Args/Returns block duplicate content already in the schema and output schema, adding length without new 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 two-parameter read-only tool with full schema coverage, an output schema and complete annotations, the description covers what the tool returns and which dimensions it varies along. Only the default-platform behavior and post-discovery usage context are left implicit.

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

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

Schema description coverage is 100% and the platform enum values are enumerated in the schema itself, so the description's Args block restates rather than adds. It does not explain the default platform behavior (OpenClaw) or when a specific platform should be chosen over the default — 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 resource ('Get step-by-step installation instructions') plus the scope ('for a skill on a specific platform'). This clearly separates it from siblings like get_skill (skill metadata), download_skill (fetching files) and list_platforms (enumeration).

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 by the tool's name and purpose — an agent can infer it is for obtaining setup steps after finding a skill, but there is no explicit 'use when', no prerequisites (e.g., must the skill already be vetted/downloaded?) and no mention of alternatives such as download_skill or validate_compatibility.

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 openWorldHint, so safety is covered. The description adds genuinely non-structured context: the list is derived from aggregated zero-result queries, meaning freshness and demand are real signals rather than static catalog data. It stops short of saying how often the aggregation refreshes.

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 purpose is front-loaded, which is good, but the entire description is duplicated in English and Korean and then followed by an Args section that re-states the three schema parameters verbatim. Those sentences do not earn their place against already-structured data.

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?

An output schema exists, so return values need not be explained, and the parameter space is fully covered by the schema. Combined with annotations covering the read-only profile, the definition is sufficient to call the tool correctly; only the follow-up workflow (where the built skill gets uploaded) is left implicit.

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

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

Schema description coverage is 100%, and the Args block simply restates days, limit and type with their defaults — the schema is actually tighter (1-365, 1-100 vs '최대 365'). No semantics 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 first sentence states a specific verb and resource ('Get the list of most-wanted skills that haven't been built yet') and the following Korean line explains the data's origin: an aggregation of zero-result search queries. That provenance detail makes the tool unmistakable against siblings like search_skills or list_categories.

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 tells the agent what to do with the output — 'Agents can build these to fill community demand' and that uploading such a skill would meet immediate download demand, which implicitly points to upload_skill. It gives clear context but never names an alternative tool or a when-not-to-use condition.

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, and openWorldHint=true, so safety and repeatability are covered. The description adds only that the result is a JSON string with vetting status — no rate limits, auth requirements, or not-found behavior for an unknown skill_id, which is a real gap for an open-world lookup.

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 purpose sentence, then compact Args/Returns sections. The Korean restatement doubles the length of the opening sentence without adding information, which is the only real waste.

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 an output schema present, the description needn't detail return values, and annotations cover the safety profile; the parameter is fully documented. What's missing is only sibling disambiguation, which is a moderate rather than blocking gap for a single-parameter read tool.

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

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

Schema coverage is 100% and the schema itself specifies the UUID format with an example, so the description need not repeat it. The description's '(search_skills 결과의 skill_id)' adds the useful provenance note but nothing about format or validation, so 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 resource ('Get detailed info for a specific skill') and enumerates the payload: description, platforms, version history, author, vetting status. This clearly separates it from list-style siblings like search_skills, though it never names get_skill_schema or get_vetting_result, which could also return skill-scoped data.

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 Args section implies the workflow prerequisite ('skill_id from search_skills results'), which is a genuine usage hint. However there is no explicit when-to-use/when-not guidance and no routing advice versus siblings such as get_skill_schema, get_vetting_result, or check_vetting_status, so the agent must infer the boundary.

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, openWorldHint=true, and idempotentHint=true, so the safety and repeatability profile is covered. The description adds useful context by enumerating what the returned schema includes: interface spec, input/output schemas, permissions, and capability tags.

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 short and front-loaded with the core action and return contents. The bilingual duplication adds some token overhead, but the structure remains clear and the repeated content appears intentional for multilingual callers.

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

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

The tool has one required parameter fully described in the schema, an output schema, and annotations covering the safety profile. The description complements these by summarizing the returned schema contents, leaving little missing for correct invocation.

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 itself explains that skill_id is the UUID returned by search_skills with a concrete example. The description only restates the parameter as 'skill_id: 스킬 ID,' adding no details beyond the schema, which is the expected baseline when the schema already does the work.

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

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

The description states a specific verb and resource: getting the full invocation schema for a skill, including interface spec, input/output schemas, permissions, and capability tags. This clearly distinguishes it from sibling tools like get_skill or search_skills, which retrieve skill data rather than invocation metadata.

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 purpose implies when to use it—when an agent needs the schema required to invoke a skill—but there is no explicit guidance on when to choose this over sibling tools such as get_skill or search_skills. The usage context is understandable but not sharply delimited.

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

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

The description goes significantly beyond structured data by explaining the polling workflow (re-call if is_done=false), the expected duration (seconds to tens of seconds), and the specific contents of the response (is_done flag, findings array).

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 definition is necessarily detailed due to the tool's complex nature (polling, dual authentication methods, language requirements). However, it uses clear structural elements (lists, headings, bolding) to remain highly navigable despite the length.

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

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

It is exceptionally complete. It covers the 'what', the 'how' (polling), the 'when' (duration), and the 'who' (auth requirements) for this specific workflow.

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?

While schema coverage is 100%, the description is vital in explaining the operational semantics of the authentication parameters. It clearly dictates that `api_key` and `claim_token` are alternatives and specifies which user roles can use which token, adding necessary context beyond simple strings.

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 tool clearly states its purpose: getting the detailed security vetting report. It specifies the core input, the `vetting_job_id`, and explicitly frames it as a polling mechanism for upload/draft responses.

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

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

It provides excellent guidance by stating this is the 'official recommended path' (공식 권장 경로) for agents to receive results via HTTP, implicitly guiding usage over other potential status-checking methods.

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 openWorldHint=false, so the safety profile is covered. The description adds only that the return is a category list string, which is largely redundant with the existing 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, front-loaded with the purpose, with a brief return note. The bilingual duplication adds minor redundancy but no real waste.

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 zero-param read tool with rich annotations and an output schema, the description is sufficient to call it. It stops short of explaining how the returned category names connect to other tools such as search_skills filtering, which would have made it fully 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?

The tool takes zero parameters, so there is nothing to document beyond that; the baseline for a no-param tool applies. Nothing in the description misleads about inputs.

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: 'List all available skill categories' on a named store. An agent immediately knows what it returns. However, it does not differentiate itself from the closely related sibling list_platforms, which is a similar enumeration 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?

There is no guidance on when to call this versus search_skills or list_platforms, nor any mention of prerequisites or follow-up usage. The usage is only implied by the word '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 readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety behavior is fully covered structurally. The description adds only that the payload is a platform-name string list; it says nothing about ordering, stability, or auth requirements, and the bilingual line adds no behavioral information.

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

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

The core purpose and value examples are front-loaded in one sentence, which is good structure. The duplicated Korean restatement and the 'Returns' block are filler that add no information beyond the name and the 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?

For a parameterless enumeration tool with an output schema and full annotation coverage, the description is sufficient to call it correctly. The only real gap is that it never says what to do with the returned platform identifiers.

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 and the description correctly implies no input is needed, so there is nothing for parameter semantics to miss. Baseline 4 applies.

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

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

States a specific verb+resource ('List all supported platforms') and enumerates concrete example values (ClaudeCode, Cursor, CodexCLI...), so an agent immediately knows what it gets back. It does not explicitly distinguish itself from siblings like list_categories, though the resource name makes the difference inferable.

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 statement, no mention of alternatives, and no note that the returned identifiers are the valid input for sibling tools such as validate_compatibility. Usage is only implied by the parenthetical enumeration of platform values.

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 declare this is a non-read-only, idempotent, open-world mutation; the description adds concrete value on top with a 10/hour/IP rate limit and the self-review prohibition. It does not discuss reversibility or deletion of reviews, which keeps it from 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?

Front-loaded with the purpose, then policy constraints, then args. The bilingual title line ('/ 스킬 리뷰 작성') is a mild redundancy, but overall the structure is tight and scannable.

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 an output schema present, the description needn't detail return values, and the policy block covers the key operational constraints for a 4-parameter mutation tool. Only minor gaps remain around failure modes and reversibility.

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 rating bounds, comment length, api_key handling, and skill_id format. The description's Args block mostly restates these (1~5 integer, optional comment up to 2000 chars) rather than adding new meaning.

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 ('Post a review and rating for a skill') and clarifies the upsert semantics ('creates, or updates your existing review'). An agent can tell exactly what this tool does 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?

The policy block gives clear when-to-use and when-not context: one review per user per skill, re-calls update rather than duplicate, and self-registered skills are off-limits. No sibling alternative exists for reviewing, so lacking an explicit alternative reference is acceptable.

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 non-read-only, open-world, non-idempotent, non-destructive behavior. The description adds important context beyond annotations: the API key is not issued immediately and requires email verification, which is central to understanding the tool's side effects and follow-up flow.

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 front-loaded with the key behavior, but the English and Korean text substantially duplicate each other, and the Args/Returns blocks repeat information already fully present in the schema and 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?

For a two-parameter registration tool with full schema coverage and an output schema, the description is mostly complete: it explains the email verification requirement and delayed API key issuance. It could still mention duplicate-account handling or what happens if verification is not completed.

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 both parameters in detail. The description restates username constraints and the email verification purpose, but adds no new syntax or edge-case semantics 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?

The description states a specific verb and resource: 'Register a developer account on AI Skill Store.' It is immediately distinguishable from sibling tools, which are mostly read/upload/vetting utilities rather than account creation.

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 as the onboarding step needed before obtaining an API key, but the description does not explicitly say when to use this versus alternatives, whether an account may already exist, or what prerequisites are required beyond email verification.

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, so the safety bar is covered. The description adds behavior beyond that: agent-mode results are sorted by popularity, and the sort/category filters are silently ignored in that mode — a non-obvious trait worth knowing. It does not cover pagination or empty-result behavior.

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

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

The English/Korean bilingual duplication roughly doubles the length without adding information, and the Args block repeats the input schema almost verbatim. The core mode-selection rule is front-loaded, which saves it from a lower score, but there is clear redundancy.

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 7-parameter, all-optional search tool with a full output schema and read-only annotations, the description covers modes, filtering precedence, and trust ordering adequately. Nothing critical for correct invocation is missing, though the unused-parameter behavior could be stated more bluntly.

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 every parameter is already documented with examples and defaults in the schema. The description's Args block largely restates that content, adding only the trust ordering hint (verified > community > sandbox). Baseline 3 is appropriate 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 specific verb+resource ("Search skills on AI Skill Store") and explains the two search modes and their ordering semantics. It doesn't explicitly contrast with siblings like get_skill (single-skill fetch) or list_categories, so the differentiation is implicit rather than stated.

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

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

Gives real routing guidance: use 'capability' or 'platform' for agent-optimized popularity-sorted search, and notes that category/sort apply only when capability/platform/min_trust are NOT used — a genuine mutual-exclusion rule. It stops short of naming sibling tools or when to prefer get_skill over a search.

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 non-readOnly, openWorld, non-idempotent, non-destructive, so the bar is lower; the description still adds real context — API-key prerequisite, the mutual exclusivity and priority of the two modes, and that the result carries version_id, vetting_job_id and poll_url (i.e. upload triggers async vetting). It does not cover failure/overwrite behavior for an existing skill name.

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 two mode blocks are well organized and front-loaded, but the content is duplicated bilingually and the closing 'Args:' section largely restates the schema descriptions verbatim (including api_key, file_path, files), which is wasted space given 100% coverage.

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 an output schema, full parameter descriptions and annotations in place, the description supplies the remaining decision logic (which mode, which sibling). Minor gaps remain on auth acquisition (only pointed to register_developer inside the schema) and on how the vetting job must subsequently be polled via check_vetting_status.

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 individual parameter meaning is already covered. The description adds genuine structure the schema cannot express: the grouping of params into Mode A vs Mode B and the 'only one, JSON mode wins' rule, which is the main semantic an agent needs.

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 ('Upload a skill package to AI Skill Store') plus the precondition (API key). It also names the sibling it is not — 'upload_skill_draft' — so an agent can route between the two 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 gives the when-not condition ('If no API key, use upload_skill_draft instead') and explains that tool's advantage (no account, later bulk claim by human owner). It also declares Mode A as 'recommended for agents' and resolves the conflict case ('both provided → JSON content mode wins').

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 far beyond the annotations: discloses that only AI-approved submissions are kept and caution/pending/rejected are immediately deleted, that results land in sandbox tier with claim_status='draft', and that a human owner must claim it to enter the community path. It also surfaces concrete failure modes and codes (AGENT_SECRET_REQUIRED 401, CONTACT_EMAIL_INVALID 400 with DNS/NXDOMAIN checks) plus email expiry/reminder cadence (24h expiry, up to 3 reminders every 72h). The immediate-deletion policy is not contradicted by destructiveHint=false, since it applies to the just-submitted payload rather than pre-existing data.

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?

Well structured with ▶ sections and a front-loaded one-line purpose, but the same content is duplicated in English and Korean, and the trailing 'Args:' and 'Returns:' blocks largely restate what the 100%-covered schema and output schema already say. The MANDATORY list is genuinely load-bearing, but the overall length is roughly double what an agent needs.

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-auth write tool with a human-in-the-loop handoff, everything an agent needs is present: credential lifecycle, rejection policy, error codes, claim flow, and the instruction to surface claim_url/instruction verbatim rather than paraphrasing. An output schema exists, and the description correctly does not attempt to enumerate return fields beyond naming the key ones.

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 earns above that by adding lifecycle meaning the schema cannot convey — agent_secret must be persisted from the first response and reused on every later upload with the same agent_author, and one verify click bulk-claims all drafts for that author. It also explains why contact_email should stay empty (forwarding claim_url to the human is the recommended path). Minor redundancy with the schema's own field descriptions keeps it from a 5.

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 plus its differentiator: 'Upload a skill without an API key (zero-friction)' and 'Draft 모드로 스킬 업로드', which separates it from the authenticated `upload_skill` sibling. The draft/sandbox end-state and claim_token return are stated up front. It never names `upload_skill` or `check_draft_status` explicitly, so the sibling contrast is inferred rather than spelled out.

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/when-not rules: leave contact_email empty if the user's email is unknown (forward_claim_url scenario, '권장'), only set it when the user explicitly provided a real address, use claim_token only when adding a version to an existing draft, and use agent_secret from the second upload onward. It also states what NOT to do ('에이전트가 대신 claim 을 완료하려 하지 말 것', '자동 재시도 금지'), which is the strongest form of usage 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 and openWorldHint, so the safety profile is covered. The description adds the evaluation basis (requirements python/packages and platform_compatibility) which is genuinely useful, but the Returns block largely restates what the output schema already provides and nothing is said about failure modes or cost of the check.

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 purpose is front-loaded, which is good, but the description is bilingual-duplicated (English sentence immediately repeated in Korean) and the Args block re-lists five parameters already fully documented in the schema, adding length without adding information.

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

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

With an output schema present and 100% schema coverage, the description only needs to frame the check and its inputs, which it does. The remaining gap is minor: no statement of what an incompatible result means for the follow-up action (e.g., proceed to download_skill anyway or not).

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 baseline is 3. The description's Args block largely mirrors the schema, and it actually omits a key behavior the schema documents: that empty values skip the OS/Python/platform checks, and the defaults for optional fields.

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 ('Check if a skill is compatible with a specific platform') and positions it in the workflow ('before downloading'), which implicitly separates it from download_skill. It never names a sibling explicitly, so differentiation is inferred rather than declared.

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?

'before downloading' gives a clear timing context for when to call it, and the mention of requirements/platform_compatibility clarifies the use case. There are no explicit exclusions (e.g., when to skip it, or what to do if the result is incompatible) and no named alternative tool.

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