url_similarityCompare two web pages and judge how similar they are. 입력한 두 사이트 페이지의 유사 여부를 분석해 유사도 결과를 반환합니다. 피싱·복제 사이트 판별 등에 활용할 수 있습니다. [호출당 5포인트]
| Name | Required | Description | Default |
|---|---|---|---|
| url1 | Yes | 비교할 첫 번째 페이지 URL | |
| url2 | Yes | 비교할 두 번째 페이지 URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, signaling a safe read operation. The description adds extra context about the cost ('5 points per call') and the analysis purpose, which is useful. However, it does not disclose how the similarity is computed, what factors are considered, or the return format. With annotations covering the safety profile, the description provides marginal but not rich behavioral detail, hence a 3.
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 relatively concise and front-loaded with the action. It includes both English and Korean versions that say essentially the same thing, creating some redundancy. The cost note is an extra but useful detail. It is not as tightly structured as the top-tier example, but it is far from verbose, earning a 4.
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?
Given the tool's simplicity (2 parameters, 100% schema coverage, clear annotations), the description covers the essential purpose and use case. However, it does not specify the output format (e.g., similarity score range, boolean) despite having no output schema. It also omits any limitations or special cases. This is a noticeable gap, making the description minimally viable but not 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 input schema has 100% coverage, with clear descriptions for both parameters ('비교할 첫 번째 페이지 URL' and '비교할 두 번째 페이지 URL'). The description adds nothing beyond restating that two pages are compared. Since the schema already does the heavy lifting, a baseline 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 clearly states the tool's function: 'Compare two web pages and judge how similar they are.' This is a specific verb (compare) with a specific resource (web pages) and a clear outcome (similarity result). It also distinguishes itself from sibling tools like image_similarity by focusing on web pages, and from url_html/url_screenshot by performing analysis rather than content retrieval. The additional use case (phishing/clone site detection) reinforces its purpose.
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 a clear usage context: 'can be used for phishing/clone site detection, etc.' This gives the agent a concrete scenario for when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, which would make it a 5. The guideline is more specific than a vague implication, earning a 4.
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 clearly distinct purposes; even within families like identi_card1-5 vs identi_card_image1-5, the text-input vs image-input distinction is clear. However, the sheer number of tools and some near-synonyms (e.g., ocr_identi1 vs identi_card_image1) could cause occasional misselection, but descriptions mitigate this.
Naming follows a loose verb-first pattern (check_, crawl_, download_, draw_, etc.) but includes significant deviations: bare nouns (bank_code, location, whois), numbered variants (identi_card1, identi_card_image1), and mixed prefixes (ocr_, identity_, etc.). The inconsistency is noticeable but still readable and predictable within functional clusters.
80 tools is far above the typical 3-15, but the server is a broad API aggregator covering many independent domains (banking, ID verification, media conversion, search, LLM, etc.), so the high count is somewhat justified. Still, the sheer number makes the toolkit feel unwieldy and hard to navigate, placing it at the high end of acceptable.
Within its stated purpose as a general-purpose utility API, the toolset covers a wide array of common task families: identity document verification (text and image), OCR field extraction, media conversion, web/search, domain/IP lookup, and LLM chat. Most operations have both get and act variants (e.g., set/get watermark, parcel_tracking/auto), with few obvious dead ends for typical use cases.