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) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds useful behavioral context: it returns coordinates, optionally includes facial feature information when use_feature=1, and notes a 3-point charge per call. No contradiction with annotations exists, though error behavior and edge cases are not disclosed.
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, but the Korean sentence largely duplicates the English one. The cost note is useful and placed at the end, yet the redundancy prevents a higher score.
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 should explain the return value shape, and it only says 'coordinates' without describing the format or coordinate system. It also does not mention behavior when no face is found, which leaves meaningful gaps for an agent that must consume the result.
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 fully documents all three parameters. The description only repeats the use_feature=1 behavior and adds no meaning beyond the schema for threshold or image_url, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Detect'), names the resource (faces in an image), and states the output ('return their coordinates'). This clearly identifies what the tool does and distinguishes it from sibling tools like face_blur, which edit images rather than return detection coordinates.
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 when-to-use or when-not-to-use guidance is provided, and no alternative tools are mentioned. The agent must infer applicability from the schema and sibling list instead of being told how to choose between face_detection and related tools such as face_blur or nsfw_detection.
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.
Multiple tools target the same documents with unclear boundaries: identi_card_image1, ocr_identi1, and identity_document_id_card all accept a resident registration card image but differ in verification vs extraction vs masking, which agents will struggle to distinguish. The identi_card1-5 vs identi_card_image1-5 vs ocr_identi1-5 clusters are especially confusing, despite some helpful descriptions.
Naming is highly inconsistent: some tools use verb_noun (check_phone_valid, search_juso, pdf_merge), some are bare nouns (whois, nslookup, ocr, stt), and identity tools use three parallel schemes (identi_card1, identi_card_image1, ocr_identi1, identity_document_id_card) with no clear pattern. No single convention is followed across the toolset.
88 tools is an extreme count for a single MCP server, spanning identity verification, parcel tracking, LLM chat, image generation, PDF conversion, TTS, and network lookups. This is an API marketplace dump rather than a focused toolset, and the number far exceeds any reasonable scope.
The server's scope is unbounded, so it has gaps everywhere: no video transcription shortcut, no PDF splitting, no batch cancellation for images (only TTS), and identity clusters lack clear differentiation between verify/extract/mask workflows. Some subdomains like TTS have a full lifecycle, but overall the coverage is scattered and incomplete for the implied breadth.