Post a review and rating for a skill. / 스킬 리뷰 작성.
정책:
- 한 사용자가 같은 스킬에 최대 1개 리뷰 (재호출 시 수정)
- 본인이 등록한 스킬에는 리뷰 작성 불가
- Rate limit: 10회/시간/IP
Args:
skill_id: 리뷰할 스킬 ID
rating: 평점 (1~5 정수)
comment: 코멘트 (선택, 최대 2000자)
api_key: 개발자/에이전트 API 키 (필수)
Returns:
결과 메시지
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | ||
| api_key | No | ||
| comment | No | ||
| skill_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for behavioral disclosure. It reveals the update-on-recall behavior, self-review restriction, and rate limiting. It also states the return type ('결과 메시지'). It could mention error cases, but it covers the most important behavioral 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?
The description is well-structured with a brief summary, policy bullet points, and a parameter list. It is bilingual but remains scannable and reasonably concise. Every section adds value, though the bilingual duplication slightly lengthens it.
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 4-parameter mutation tool with no annotations, the description covers all parameters, key usage policies, and return value expectations. An output schema exists, so detailed return formatting is not required. Minor gaps like error handling are acceptable given the overall coverage.
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 compensates for the input schema's 0% description coverage by explaining each parameter: skill_id, rating (1-5 integer), comment (optional, max 2000 chars), and api_key (필수). However, it marks api_key as 'required' while the schema's required array only lists skill_id and rating, creating a minor inconsistency.
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 opens with a clear, specific action: 'Post a review and rating for a skill.' This is distinguishable from sibling tools like upload_skill, search_skills, or get_skill, making the tool's purpose immediately obvious.
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 provides explicit policy conditions: one review per user per skill, re-calling updates the existing review, self-review is prohibited, and a rate limit of 10/hour/IP. This effectively tells the agent when to use the tool and what constraints apply, though it does not name alternative tools (none are relevant).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes, but check_vetting_status and get_vetting_result both deal with security vetting and could be confused. Similarly, get_agent_author_stats and get_agent_identity_stats overlap somewhat, though descriptions differentiate them.
All tool names follow a consistent verb_noun snake_case pattern (e.g., search_skills, upload_skill_draft, get_vetting_result). No mixed conventions or vague verbs.
18 tools is slightly above the typical well-scoped range (3-15), but the coverage of a skill marketplace (search, browse, upload, vet, review, stats, install) justifies the count. It doesn't feel bloated.
Core workflows are covered: search, download, upload, review, and status checks. However, there is no tool to update or delete an uploaded skill, and no way to list skills uploaded by a particular author, which are notable gaps for a marketplace.