face_detectionDetect faces in an image and return their coordinates. 이미지 파일에서 얼굴을 인식해 해당 좌표를 반환합니다. use_feature=1 입력 시 얼굴 특징 정보를 함께 반환합니다. [호출당 3포인트]
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | 다운로드 가능한 https URL (허용 형식: image/jpeg, image/png, image/webp, image/bmp) (최대 50MB) | |
| threshold | No | 얼굴 추출 민감도 (범위: 0 ~ 0.9, 기본값 0.5, 높을수록 정확한 얼굴만 추출) | |
| use_feature | No | 얼굴 특징 정보 포함 여부 (포함: 1, 미포함: 0, 기본값 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, covering safety. The description adds the cost per call (3 points) and notes that use_feature=1 returns face feature info, which is useful beyond annotations. However, it does not describe other behaviors like error handling or limitations, so it adds only moderate 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 description is concise and front-loaded with the primary purpose. It includes both English and Korean versions of the same content, which is slightly redundant but acceptable. The cost note is placed at the end, keeping the main action clear.
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 tool with all parameters documented and no output schema, the description covers the essentials: what it detects, the optional feature, and cost. It could optionally describe the format of the returned coordinates (e.g., bounding boxes), but that is not critical for 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%, with each parameter already documented (e.g., threshold sensitivity, use_feature flag). The description mentions the effect of use_feature but essentially restates the schema, so it adds little new meaning to the parameters.
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 tool detects faces and returns their coordinates, which is a specific verb and resource. It distinguishes from siblings like nsfw_detection or image_similarity by its unique focus on face detection, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the sibling tools (e.g., nsfw_detection for inappropriate content, image_similarity for image matching). There are no conditions, prerequisites, or exclusions provided, leaving the context of use implicit.
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.
Each tool has a clearly distinct purpose: video thumbnail extraction, face detection, image similarity, NSFW detection, video-to-audio conversion, and word cloud generation. There is no overlap between any two tools, so agents can easily select the correct one.
All tool names use snake_case, but the pattern is mixed: most are noun-based (face_detection, image_similarity, nsfw_detection, word_cloud) while extract_video_thumbnail starts with a verb and video_to_mp3 is a conversion style. This inconsistency makes the naming slightly less predictable.
With 6 tools, the count is well within the typical 3-15 range and feels well-scoped for a media processing toolkit. Each tool adds a distinct capability without being redundant or overwhelming.
The server covers a variety of media operations (video, image, audio, text) but lacks common vision tasks like OCR, object detection, or image classification that one might expect from a 'Vision' server. The set feels like a collection of standalone utilities rather than a complete domain coverage, though no critical gaps cause agents to fail.