_ _ _ _ ____ _ _ _ _ ____ _
| | | | \ | | _ \| | | | | | | _ \| |
| | | | \| | |_) | |_| | | | | |_) | |
| |_| | |\ | __/| _ | |_| | _ <| |___
\___/|_| \_|_| |_| |_|\___/|_| \_\_____|AI 에이전트 및 개발자를 위한 URL 인텔리전스. 16개의 MCP 도구. 25개의 신호. 7가지 차원.
AI 에이전트에게 URL을 볼 수 있는 눈을 제공하세요. Unphurl은 7가지 차원(리다이렉트 동작, 브랜드 사칭, 도메인 연령, SSL/TLS, 파킹 감지, URL 구조, DNS 강화)에서 모든 URL을 분석하고, 구성 가능한 0-100점의 위험 점수와 함께 구조화된 신호를 반환합니다. 판결이 아닌 신호를 제공하며, 이를 어떻게 활용할지는 에이전트가 결정합니다.
Claude Code, Claude Desktop, Claude Cowork, ChatGPT desktop, Cursor, Windsurf 및 모든 MCP 호환 도구와 함께 작동합니다.
모든 신규 계정은 20개의 무료 파이프라인 확인 크레딧을 받습니다. 대부분의 조회는 무료입니다. 알려진 도메인(Tranco 상위 10만 개) 및 이전에 분석된 도메인은 비용 없이 캐시된 결과를 반환합니다. 알 수 없는 도메인이 전체 파이프라인을 통과할 때만 비용을 지불합니다.
패키지 | 크레딧 | 가격 | 확인당 비용 |
스타터 | 100 | $9 | $0.090 |
스탠다드 | 500 | $39 | $0.078 |
프로 | 2,000 | $99 | $0.050 |
스케일 | 10,000 | $399 | $0.040 |
일회성 구매이며 구독료는 없습니다. 일반적인 사용 시 URL의 95-99%는 무료로 처리됩니다.
Related MCP server: contrastapi
.mcp.json 파일에 추가하세요(Claude Code, Claude Desktop, Claude Cowork, ChatGPT desktop, Cursor, Windsurf 또는 모든 MCP 호환 도구):
{
"mcpServers": {
"unphurl": {
"command": "npx",
"args": ["-y", "@unphurl/mcp-server"],
"env": {
"UNPHURL_API_KEY": "uph_your_key_here"
}
}
}
}AI가 대신 계정을 생성할 수 있습니다. 그냥 이렇게 물어보세요: "Sign up for Unphurl." signup 도구는 API 키 없이도 작동합니다. 가입 후 MCP 구성에 키를 추가하고 재시작하세요.
AI에게 말만 하세요:
"Check https://suspicious-domain.xyz"
"Batch check all URLs in this spreadsheet"
"Create a scoring profile called 'lead-qual' that weights parked domains at 30 and no MX record at 20"
"Check my credit balance"
외울 명령어는 없습니다. 배울 문법도 없습니다. AI가 도구 호출을 처리합니다.
모든 확인 결과는 7가지 차원의 신호를 반환합니다:
차원 | 설명 |
리다이렉트 동작 | 전체 체인(최대 10홉), 단축 URL 감지, 중단 사유 |
브랜드 사칭 | 150개 이상의 브랜드에 대한 Levenshtein + 호모글리프 분석 |
도메인 인텔리전스 | 연령, 등록기관, 만료일, 상태 코드, 네임서버 (RDAP 경유) |
SSL/TLS | Cloudflare 엣지에서의 실제 핸드셰이크 검증 |
파킹 감지 | 4단계 검사: 등록기관 페이지, 판매 중, 빈 콘텐츠, 파킹 서비스 |
URL 구조 | 길이, 경로 깊이, 서브도메인 수, 엔트로피, IP 감지, 인코딩된 문자 |
DNS 강화 | MX 레코드 존재 여부 (도메인이 이메일을 수신할 수 있는지 여부) |
모든 신호는 비즈니스 인텔리전스입니다. 도메인 연령은 기업의 신뢰도를 나타냅니다. MX 레코드가 없다는 것은 이메일을 수신할 수 없음을 의미합니다. 만료되는 도메인은 비즈니스가 종료될 수 있음을 시사합니다. AI의 대량 처리 및 스프레드시트 출력 기능과 결합하면 가벼운 실사 엔진이 됩니다.
도구 | 기능 | 인증 |
| 새 계정 생성, API 키 획득 | 아니오 |
| 인증 이메일 재전송 (시간당 3회 제한) | 예 |
| 7가지 차원 모두에서 단일 URL 확인 | 예 |
| 최대 500개 URL 일괄 확인 (비동기 폴링 자동 처리) | 예 |
| 사용자 지정 점수 프로필 목록 확인 | 예 |
| 사용자 지정 가중치로 점수 프로필 생성 또는 업데이트 | 예 |
| 점수 프로필 삭제 | 예 |
| 기본 가중치가 적용된 25개 점수 신호 표시 | 아니오 |
| 파이프라인 확인 크레딧 잔액 확인 | 예 |
| 사용 통계 및 점수 임계값 카운트 보기 | 예 |
| 사용 가능한 크레딧 패키지 및 가격 표시 | 아니오 |
| 크레딧 구매 (Stripe 결제 URL 반환) | 예 |
| 최근 URL 확인 기록 보기 | 예 |
| 점수 증폭을 억제하는 신뢰할 수 있는 도메인 목록 확인 | 예 |
| 신뢰할 수 있는 허용 목록에 도메인 추가 (요청당 최대 100개) | 예 |
| 신뢰할 수 있는 허용 목록에서 도메인 제거 | 예 |
"Check these 500 URLs. Give me two lists: the clean ones (score under 25) and the flagged ones (score 50 or higher). Export both as CSV."
AI가 일괄 결과를 가져와 점수별로 필터링하고 목록을 출력합니다. 코드나 스크립팅은 필요 없습니다.
작업마다 필요한 가중치가 다릅니다. 보안 봇은 브랜드 사칭에 관심이 많고, 콜드 이메일 도구는 파킹된 도메인이나 누락된 MX 레코드에 관심이 많습니다.
"Create a profile called 'cold-email' that weights parked at 30, no_mx_record at 20, and domain_age_7 at 25. Then batch check my lead list using that profile."
AI 채팅 내의 Unphurl은 에이전트가 액세스할 수 있는 다른 모든 도구와 결합됩니다:
스프레드시트: CRM 내보내기 파일을 읽고, 모든 URL을 일괄 확인한 후 위험 점수와 함께 결과를 다시 기록
웹 스크래핑: 경쟁사의 파트너 페이지를 스크래핑하고 모든 링크의 상태 확인
문서: 결과로부터 브랜드화된 PDF 감사 보고서 생성
예약 작업: "매주 월요일 아침마다 내 중요 URL 확인"
무료 조회를 포함한 모든 확인 작업에는 양수의 크레딧 잔액이 필요합니다.
알려진 도메인(google.com, amazon.com 등): 무료, 즉시 처리.
캐시된 도메인(누군가 최근 분석한 도메인): 무료, 즉시 처리.
알 수 없는 도메인(최초 분석): 1크레딧 차감.
일괄 확인 시 알 수 없는 도메인에 대해 크레딧이 미리 차감됩니다. 크레딧이 부족하면 필요한 정확한 크레딧 양이 요약되어 표시됩니다.
실패한 파이프라인 확인은 자동으로 환불됩니다.
check-url-safety 스킬은 AI가 URL을 따르거나 추천하기 전에 요청받지 않아도 사전에 확인하도록 가르칩니다.
Claude Cowork 또는 Claude Desktop: 그냥 물어보세요: *"Install the Unphurl URL safety skill."
Claude Code, Cursor 또는 기타 개발 도구:
# Global (all projects)
cp node_modules/@unphurl/mcp-server/skills/check-url-safety.md ~/.claude/skills/
# Or for a specific project
cp node_modules/@unphurl/mcp-server/skills/check-url-safety.md .claude/skills/Unphurl은 확인당 $0.04-$0.09의 비용이 듭니다. 웹사이트 링크 감사는 15분이 소요되며 50-100 크레딧을 사용합니다. 감사당 $150-$500의 비용을 청구하세요.
서비스 아이디어: 링크 상태 감사, 리드 목록 검증, SEO 백링크 감사, 뉴스레터 링크 모니터링, 공급업체 심사 보고서, 브랜드 보호 모니터링, 인플루언서 심사.
CLI: npx unphurl (npm)
Claude Cowork용 호스팅 MCP (로컬 설치 불필요): mcp.unphurl.com
REST API: api.unphurl.com
웹사이트: unphurl.com
시각적 가이드: unphurl.com/getting-started-guides
MIT
Add one or more domains to this account's trusted allowlist.
Allowlisted domains suppress the compound signal and brand impersonation floor in scoring. The full pipeline still runs — all signals remain visible so you can monitor trusted domains for SSL expiry, parking, or other changes.
Submit the registrable domain only (e.g. partnerco.com). Subdomains and full URLs are rejected. Adding partnerco.com covers sub.partnerco.com and all other subdomains automatically.
Maximum 1,000 domains per account. Maximum 100 domains per request. Duplicates are silently skipped.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Registrable domains to add (e.g. ['partnerco.com', 'trustedvendor.io']). Subdomains and full URLs are rejected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It explains the effect on scoring, that duplicates are silently skipped, the domain format requirements, and that all signals remain visible (monitoring continues). This is comprehensive and leaves no ambiguity about the tool's 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 description is concise, with each sentence serving a purpose. It is front-loaded with the primary action, followed by effect, format requirements, and limits. No unnecessary words or repetitions.
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 (one parameter, no output schema), the description covers all necessary information: purpose, effect on scoring, domain format, coverage of subdomains, limits, and duplicate handling. It is complete for an AI agent to understand when and how to use it.
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 already describes the 'domains' parameter well. The description adds value by explaining that adding a registrable domain covers all subdomains automatically and that subdomains/full URLs are rejected. This extra context goes beyond the schema's description, warranting a score above the baseline of 3.
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 purpose: 'Add one or more domains to this account's trusted allowlist.' It specifies the action, the resource (allowlist), and the effect (suppressing compound signal and brand impersonation floor). It also distinguishes itself from sibling tools like list_allowlist and remove_from_allowlist by focusing on addition.
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 good guidance on domain format (registrable only) and limitations (max 100 domains per request, 1,000 total). It implicitly indicates when to use this tool (to add domains) but does not explicitly contrast with sibling tools or give 'when not to use' advice. However, for a simple add operation, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View recent URL check history. Shows what URLs have been checked, their scores, phishing status, and whether each check was free or used a pipeline credit.
Results are paginated. Use page and limit parameters to navigate. Default is 20 results per page, maximum 100.
History is retained for 90 days. Account-level stats (total credits, balance) never expire.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| limit | No | Results per page, max 100 (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full behavioral burden. It discloses pagination behavior, data retention (90 days), and distinguishes between history and account-level stats. Missing details on sorting order or rate limits, but sufficient for a read-only history tool.
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?
Three concise paragraphs: first states purpose, second covers pagination, third covers retention. No fluff, every sentence adds value. Front-loaded with the core purpose.
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?
No output schema, but description explains return fields (URLs, scores, phishing status, credit usage). Also covers pagination and retention. Missing details on filtering or sorting, but overall adequate for a list endpoint.
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?
Both parameters (page, limit) are fully described in the input schema with defaults and constraints. The description repeats schema info without adding new semantics. With 100% schema coverage, baseline 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 clearly states 'View recent URL check history' and lists specific fields (scores, phishing status, credit usage). It implicitly differentiates from sibling tools like check_url (single check) and get_stats (aggregate stats).
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?
Mentions pagination and parameter usage but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Context from sibling names helps but description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a single URL for security and data quality signals. Returns a risk score (0-100), detailed signal breakdown, and metadata.
Unphurl analyses URLs across seven dimensions: redirect behaviour, brand impersonation, domain intelligence (age, registrar, expiration, status codes, nameservers via RDAP), SSL/TLS validity, parked domain detection, URL structural analysis (length, path depth, subdomain count, entropy), and DNS enrichment (MX records). The score is calculated from these signals using either default weights or a custom scoring profile.
Higher scores mean more suspicious. The score is a signal, not a verdict. You decide the threshold based on the use case.
Billing: Most lookups are free. Known domains (Tranco Top 100K like google.com, github.com) return instantly with score 0 at no cost. Previously analysed domains return cached signals at no cost. Only unknown domains that run through the full analysis pipeline cost 1 pipeline check credit. The response's meta.pipeline_check_charged field tells you whether this check consumed a credit.
Use the "profile" parameter to score results with custom weights. For example, a "cold-email" profile might weight parked domains heavily while ignoring brand impersonation. Use list_profiles to see available profiles, or show_defaults to see all signal weights.
If the account has zero credits and the URL requires a full pipeline check, returns a 402 error with a link to purchase more credits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to check (must be http:// or https://) | |
| profile | No | Name of a custom scoring profile to use (optional). If omitted, default weights are used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and thoroughly discloses behavioral traits: seven analysis dimensions, scoring mechanism, billing logic (free for known/cached, cost for unknown), error conditions (402 when out of credits), and the nature of the score as a signal, not a verdict.
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 lengthier than average but well-structured: main purpose first, then detailed breakdown, billing, profile usage. Every sentence adds value. Could be slightly more concise, but the structure is logical and front-loaded.
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 complexity and lack of output schema, the description is highly complete. It explains inputs, behavior, billing, and output (risk score, signal breakdown, metadata with pipeline_check_charged field). The agent has enough information to use the tool correctly.
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 covers both parameters (url and profile) with 100% coverage. The description adds significant context: url must be http/https, profile is optional and custom scoring profiles can be listed via list_profiles, with an example usage ('cold-email' profile).
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 checks a single URL for security and data quality signals, returning a risk score and breakdown. It distinguishes itself from sibling tool 'check_urls' by emphasizing 'single URL', and provides specific details about signals, scoring, and billing.
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 gives clear context on when to use this tool (for checking a single URL) and when to consider using a profile (referencing list_profiles and show_defaults). It also explains billing conditions and potential error. However, it does not explicitly contrast with the sibling 'check_urls' for batch processing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check multiple URLs in a single batch. Returns results for all URLs, handling async processing automatically.
Each URL is analysed across seven dimensions: redirect behaviour, brand impersonation, domain intelligence (age, registrar, expiration, status codes, nameservers via RDAP), SSL/TLS validity, parked domain detection, URL structural analysis, and DNS enrichment. Known and cached URLs return results immediately. Unknown URLs are queued for pipeline processing. This tool automatically polls for results until all URLs are complete or the 5-minute timeout is reached. You don't need to manage polling or job tracking.
If the timeout is reached before all results are complete, returns whatever is available with a clear message indicating which URLs are still processing. The user can check results later via check_history.
Maximum 500 URLs per call. For larger datasets, call this tool multiple times with chunks of up to 500 URLs.
Billing: Same as check_url. Known and cached domains are free. Only unknown domains running through the full pipeline cost 1 credit each. The summary shows pipeline_checks_charged (the actual number of credits consumed). If you don't have enough credits for the unknowns in the batch, the entire batch is rejected with a 402 error telling you exactly how many credits are needed.
Duplicate URLs in the list are automatically deduplicated (processed once, charged once). Invalid URLs get individual error status without rejecting the batch.
Use the "profile" parameter to score all results with custom weights.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | List of URLs to check (maximum 500 per call) | |
| profile | No | Name of a custom scoring profile to use for all URLs (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully covers behavioral traits: async processing, automatic polling, timeout handling with partial results, billing details (free for cached, credits for unknown, rejection if insufficient), and deduplication. No contradictions or omissions.
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 long but well-structured with a clear overview first, then detailed sections. Every sentence adds value, though some redundancy could be trimmed slightly. The front-loading of purpose is effective.
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 no output schema and no annotations, the description is remarkably complete. It covers input constraints, processing behavior, edge cases (timeout, invalid URLs), billing, and follow-up via check_history. Nothing essential 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?
Input schema has 100% coverage, but the description adds significant meaning: explains how URLs are processed, that duplicates are deduplicated and charged once, and that profile parameter scores results with custom weights. This goes beyond the schema's basic descriptions.
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 checks multiple URLs in a single batch. It explicitly distinguishes from the sibling 'check_url' by being a batch version, thus eliminating ambiguity.
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 comprehensive usage guidance: maximum 500 URLs per call, chunking for larger datasets, automatic polling with 5-minute timeout, duplicate handling, and error recovery via check_history. It also suggests when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a custom scoring profile. Profiles are sparse overrides: only specify the weights you want to change. Everything else keeps its default value.
If a profile with this name already exists, it is updated with the new weights (full replacement, not merge).
Weights are points, not percentages. Each weight is the number of points that signal adds to the score when it fires. They don't need to total 100. A profile with weights totalling 90 is conservative (max possible score is 90). A profile with weights totalling 130 is aggressive (multiple signals quickly push to the cap of 100). The threshold the agent sets for action matters more than the weight totals.
Use show_defaults to see all 25 signals with their default weights and descriptions before creating a profile. Use check_url or check_urls with the "profile" parameter to score results with this profile.
Maximum 20 profiles per account. Profile name "default" is reserved.
Common profiles:
Cold email: weight parked (30), chain_incomplete (25), ssl_invalid (15) higher. Lower brand_impersonation (10).
Security bot: keep brand_impersonation high (40), increase domain_age_7 (30), redirects_5 (25).
Lead gen: weight parked (35), http_only (20), chain_incomplete (20) for dead business detection.
SEO audit: weight redirects_5 (30), chain_incomplete (30), parked (25) for link quality.
See the Unphurl API documentation for all 19 use case weight examples.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Profile name (lowercase alphanumeric and hyphens only, 1-50 chars, e.g. 'cold-email', 'security-bot') | |
| weights | Yes | Custom weights for scoring signals. Only include signals you want to override. Available signals: brand_impersonation (default 40), domain_age_3 (35), domain_age_7 (25), domain_age_30 (15), domain_age_90 (5), ssl_invalid (10), http_only (5), redirects_3 (10), redirects_5 (25), chain_incomplete (15), parked (10), compound (10), brand_impersonation_floor (80), url_long (3), path_deep (3), subdomain_deep (3), subdomain_excessive (5), domain_entropy_high (5), url_contains_ip (10), encoded_hostname (5), tld_redirect_change (5), js_fragment_redirect (25), expiring_soon (10), domain_status_bad (15), no_mx_record (5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: full replacement on update, max 20 profiles, reserved name 'default', weights are points not percentages, and scoring implications.
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 clear sections and front-loaded purpose. Slightly long but every sentence adds value; could be slightly more concise but still effective.
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 complexity (nested weights, no output schema), the description covers all necessary context: behavior, constraints, usage with other tools, and examples. Complete for agent decision-making.
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%, but the description adds significant value by explaining weights as points, their effect on scoring, and giving concrete profile examples. Enhances understanding beyond 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 clearly states the tool creates or updates a custom scoring profile, defines what a profile is (weights for signals), and distinguishes from sibling tools like delete_profile and list_profiles.
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?
Provides explicit guidance: use show_defaults to preview signals, use check_urls with profile to score, clarifies sparse overrides and update behavior. Also includes common profile examples and refers to API docs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a custom scoring profile. This is permanent. Any future check requests using this profile name will fall back to default weights.
Use list_profiles to see your current profiles before deleting.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the profile to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses permanence and fallback behavior. Lacks info on permissions or idempotency, but for a simple delete operation this is sufficient.
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 concise sentences, no fluff, critical information front-loaded and structured logically.
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 low complexity (1 param, no output schema), the description covers all needed aspects: action, permanence, consequence, and usage tip.
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?
Input schema already describes the 'name' parameter with pattern. Description adds value by hinting at existence check via 'list_profiles'.
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?
Clearly states 'Delete a custom scoring profile' with permanence emphasized. Distinguishes from siblings like 'create_profile' and 'list_profiles'.
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 advises to use 'list_profiles' before deleting and explains the consequence (fallback to defaults). Provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your pipeline check credit balance. Shows credits remaining, total purchased, total used, and lifetime free lookups count.
Credits are consumed only when unknown domains run through the full analysis pipeline. Known domains (Tranco Top 100K) and cached domains (previously analysed by any Unphurl customer) are always free.
If credits_remaining is 0, you can still check known and cached domains for free. To check unknown domains, purchase more credits using the "purchase" tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains credit consumption conditions (only for unknown domains) and free cases (known/cached domains). It also mentions lifetime free lookups count. With no annotations, this provides adequate behavioral 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, well-structured with front-loaded main purpose. Every sentence adds value without 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 simple tool with no parameters and no output schema, the description covers all relevant aspects: what data is returned, when credits are consumed, and ties to the 'purchase' tool for further action. It feels 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 zero parameters, so the description does not need to add parameter information. The baseline score for no-parameter tools is 4.
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 that the tool checks the pipeline check credit balance and lists the specific data shown (credits remaining, total purchased, etc.). It distinguishes itself from sibling tools by explicitly mentioning the 'purchase' tool for buying credits.
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 when to use the tool (to check balance) and when not (if credits_remaining is 0, known/cached domains are still free). It also directs to the 'purchase' tool for unknown domains, providing clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show available pipeline check credit packages and pricing. Returns all packages with credit counts and prices.
Packages (one-time purchase, no subscription):
Starter: 100 credits for $9 ($0.09 each)
Standard: 500 credits for $39 ($0.078 each)
Pro: 2,000 credits for $99 ($0.0495 each)
Scale: 10,000 credits for $399 ($0.0399 each)
Most URL lookups are free (known domains and cached domains). Credits are only consumed when an unknown domain runs through the full analysis pipeline. In typical use, 95-99% of URLs resolve free.
This tool does not require an API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explains what the tool returns (packages, credit counts, prices) and provides insight into credit consumption behavior (most lookups free). This adds valuable behavioral context beyond the empty 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?
Description is well-structured with a summary sentence followed by a bulleted list of packages. It is somewhat lengthy but every sentence provides useful information. Could be slightly more concise but remains 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?
The description fully covers the tool's purpose and output (package list with credits and prices) without needing an output schema. It also includes practical details about credit consumption, making it complete for a simple listing 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?
No parameters exist, and schema coverage is 100%. The description adds no param info, but baseline for zero-param tools is 4. It appropriately states the tool needs no API key.
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?
Description clearly states the tool shows available credit packages and pricing. It lists specific packages with counts and prices, making the purpose unambiguous. No sibling tool overlaps this functionality.
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?
Description explains this is a read-only information tool and notes that most lookups are free, giving context for when to use it. It also clarifies no API key is needed. While it doesn't explicitly state when not to use it, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View your account usage statistics. Shows total URLs submitted, breakdown by gate (Tranco lookups, cache lookups, pipeline checks), free rate percentage, score threshold counts, and credit balance.
Use this to understand your usage patterns: how many of your checks resolved free (known or cached domains) vs paid pipeline checks, and how many URLs scored above key thresholds.
This is useful for:
Checking if your scoring profile is flagging the right proportion of URLs
Understanding your cost efficiency (higher free rate = more value per credit)
Reporting usage metrics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description clearly indicates read-only operation ('View'), though it could explicitly state it's non-destructive.
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?
Concise, front-loaded with purpose, then details, then use cases; every sentence adds value.
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?
Fully describes what the tool does, what it returns, and when to use it; no missing context given lack of output schema.
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?
No parameters in schema, so description does not need to add meaning; baseline of 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?
The description clearly states 'View your account usage statistics' and enumerates specific metrics, distinguishing it from siblings like get_balance and get_pricing.
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 lists use cases (understanding usage patterns, cost efficiency, reporting) and implies when to use via contrast with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all domains on this account's trusted allowlist.
Allowlisted domains suppress the compound signal and brand impersonation floor in scoring. The full pipeline still runs — all signals remain visible for monitoring. Use this to see which domains are currently trusted.
Returns the list of domains, current count, and the 1,000-domain limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that allowlisted domains suppress compound signal and brand impersonation floor, and that the full pipeline still runs. No annotations provided, so description carries full burden; lacks details on auth, rate limits, or side effects.
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?
Three sentences that are concise and front-loaded with purpose. Every sentence adds value without 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 simple list tool with no parameters and no output schema, the description covers what it returns (list, count, limit) and the effect of allowlisting. No obvious gaps.
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?
No parameters, so schema coverage is 100%. Baseline for 0 parameters is 4; description adds no extra parameter info but none is needed.
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?
Clearly states it lists all domains on the trusted allowlist, distinguishing it from siblings like add_to_allowlist and remove_from_allowlist.
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 says 'Use this to see which domains are currently trusted,' providing clear context for use. Does not explicitly mention when not to use, but purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all custom scoring profiles on this account. Returns profile names and their custom weight overrides.
Profiles are named weight sets that change how Unphurl scores URLs. Different use cases need different scoring. A cold email agent cares about dead domains. A security bot cares about phishing. Profiles let one account serve multiple use cases.
Profiles only override specific weights. Any signal not specified in a profile uses the default weight. Use show_defaults to see all 25 signals and their default weights.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that profiles only override specific weights and that unspecified signals use defaults, clarifying the behavioral semantics of the output. It does not mention ordering, pagination, or limits, but for a simple list tool, this is adequate.
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 three paragraphs, with the first sentence being a clear purpose statement. The second paragraph provides beneficial context about use cases, and the third adds an important behavioral note. While slightly verbose, every sentence adds value and it is well-structured.
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 has no parameters and no output schema, the description fully explains what it does (list profiles) and what it returns (names and weight overrides). It also provides sufficient context about how profiles work and where to find default weights, making it complete for the tool's complexity.
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 has zero parameters, so the baseline is 4. The description adds no parameter information beyond the schema (which is empty), but this is not needed. The conceptual explanation about profiles and weight overrides provides context for the tool's 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?
The description clearly states the tool 'list all custom scoring profiles' and specifies the output: 'profile names and their custom weight overrides.' It distinguishes itself from siblings by explaining profiles are custom weight sets for different use cases, and explicitly mentions 'Use show_defaults to see all 25 signals and their default weights,' differentiating from that sibling.
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 context on when to use profiles (for different scoring needs) and explicitly advises using 'show_defaults' to see default weights. However, it does not explicitly state when not to use this tool or contrast with other list tools like 'list_allowlist'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purchase pipeline check credits. Returns a Stripe Checkout URL that the user must open in a browser to complete payment.
The AI cannot complete the payment. Tell the user to open the URL in their browser, complete the Stripe checkout, and then confirm they've paid. Credits are added to the account automatically once Stripe confirms payment.
After purchase, use get_balance to verify credits have been added.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | Package to purchase: pkg_100 ($9, 100 credits), pkg_500 ($39, 500 credits), pkg_2000 ($99, 2000 credits), pkg_10000 ($399, 10000 credits) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool returns a URL (not direct credit addition), that payment requires user action, and that credits are added upon Stripe confirmation.
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?
Three sentences covering purpose, AI responsibility, and post-purchase action; no unnecessary words.
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?
Covers the complete flow: input, output, user action, and verification step, despite no output schema.
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 already fully describes the package enum with prices; description adds value by explaining the URL return and user action steps.
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?
Clearly states it purchases credits and returns a Stripe URL, distinguishing from sibling tools like get_balance and get_pricing.
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 instructs the AI to tell the user to open the URL and later confirm payment, and suggests using get_balance to verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove one or more domains from this account's trusted allowlist.
Once removed, those domains resume normal scoring on the next check. Use list_allowlist to see what is currently on the list before removing.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Registrable domains to remove (e.g. ['partnerco.com']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the effect: domains resume normal scoring. It does not mention permissions or reversibility, which is acceptable for a straightforward removal action.
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 sentences with no extraneous words, front-loaded with the action and intended effect.
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 tool with one parameter and no output schema, the description fully covers purpose, effect, and a usage tip. No gaps.
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% with a clear description of the 'domains' parameter. The tool description adds no further semantics beyond the schema, earning the baseline score.
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 verb 'Remove' and the resource 'domains from this account's trusted allowlist,' distinguishing it from siblings like 'add_to_allowlist' and 'list_allowlist.'
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 advises using 'list_allowlist' before removal, providing clear context. It lacks explicit 'when not to use' but is adequate for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resend the email verification link for an existing Unphurl account.
Use this when a user signed up but their verification link expired (links are valid for 24 hours) and they need a new one. The user's API key won't work until their email is verified.
For security, the response is always the same regardless of whether the email exists, is already verified, or was rate limited. This prevents account enumeration.
Rate limited to 3 requests per email per hour.
This tool does not require an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address of the account that needs verification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses rate limiting (3 per hour per email), security measure (uniform response to prevent enumeration), and that no API key is required. These traits are not in annotations (none provided).
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?
Six sentences, each serving a distinct purpose: purpose, usage, security, rate limit, no API key. No unnecessary words, well front-loaded.
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?
Covers all necessary aspects for a tool with one parameter and no output schema: purpose, when to use, rate limits, security, authentication requirement. No gaps.
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 description for the email parameter is already adequate. The main description does not add additional parameter-level details 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?
Clearly states verb 'Resend', resource 'email verification link', and context 'existing Unphurl account'. Distinguishes from sibling tools like signup or check_url.
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 says 'Use this when a user signed up but their verification link expired' and mentions that API key won't work until verified. Lacks explicit when-not-to-use, but covers key usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show all 25 scoring signals with their default weights and descriptions. This is the baseline scoring that applies when no custom profile is specified.
Use this to understand what each signal means and how much it contributes to the score before creating custom profiles. Profiles are sparse overrides on top of these defaults.
This tool does not require an API key. The defaults are hardcoded and always available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses no API key required, hardcoded defaults always available, which is good for a read-only tool. No annotations provided, so description carries full burden.
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?
Three short, front-loaded sentences with no redundancy; every sentence adds value.
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?
Adequately covers purpose, usage context, and constraints for a parameterless tool; no output schema, but explanation of returned data suffices.
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?
No parameters; schema coverage 100%. Description adds meaning by specifying output content (25 signals, weights, descriptions) beyond 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?
Description explicitly states 'Show all 25 scoring signals with their default weights and descriptions', clearly distinguishing from sibling tools like create_profile or check_url.
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?
Advises using before creating custom profiles and explains profiles are sparse overrides, but lacks explicit when-not-to-use or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Unphurl account. Returns an API key (shown once, store it securely).
After signup, the user must check their email and click the verification link. The API key won't work for URL checks until the email is verified. Verification link expires after 24 hours. If the link expires, use the "resend_verification" tool to request a new one.
The account starts with 20 free pipeline check credits so the user can test with real URLs. Known domain lookups (google.com, github.com, etc.) and cached domain lookups are always free. To check more unknown domains through the full analysis pipeline, the user can purchase credits via the "purchase" tool.
Once the user has their API key, they need to add it to their MCP server configuration as UNPHURL_API_KEY.
This tool does not require an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address for the account | ||
| first_name | Yes | First name (used for personalized emails) | |
| company | No | Company name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: account creation, email verification within 24 hours, free credits, and the need to configure the API key. No hidden effects.
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 logical flow and each sentence adds value, though slightly lengthy. Could be tightened slightly.
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?
Covers the full signup workflow, including verification, credits, and configuration. Lacks error response details but sufficient for an account creation 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 description coverage is 100%, so the description adds little beyond the schema. It provides context but no new parameter-level details.
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 'Create a new Unphurl account' and details the return of an API key. It implicitly distinguishes from siblings like resend_verification and purchase by explaining post-signup actions.
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 instructs to use resend_verification if the verification link expires and purchase for credit top-ups. Also notes that this tool does not require an API key, implying other tools do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.3add_to_allowlistcreate_profile1 field changedInput schema / properties / weights / descriptionPrevious value: -"Custom weights for scoring signals. Only include signals you want to override. Available signals: brand_impersonation (default 40), domain_age_3 (35), domain_age_7 (25), domain_age_30 (15), domain_age_90 (5), ssl_invalid (10), http_only (5), redirects_3 (10), redirects_5 (25), chain_incomplete (15), parked (10), compound (10), phishing_floor (80), url_long (3), path_deep (3), subdomain_excessive (5), domain_entropy_high (5), url_contains_ip (10), encoded_hostname (5), tld_redirect_change (5), expiring_soon (10), domain_status_bad (15), no_mx_record (5)."New value: +"Custom weights for scoring signals. Only include signals you want to override. Available signals: brand_impersonation (default 40), domain_age_3 (35), domain_age_7 (25), domain_age_30 (15), domain_age_90 (5), ssl_invalid (10), http_only (5), redirects_3 (10), redirects_5 (25), chain_incomplete (15), parked (10), compound (10), brand_impersonation_floor (80), url_long (3), path_deep (3), subdomain_deep (3), subdomain_excessive (5), domain_entropy_high (5), url_contains_ip (10), encoded_hostname (5), tld_redirect_change (5), js_fragment_redirect (25), expiring_soon (10), domain_status_bad (15), no_mx_record (5)."list_allowlistremove_from_allowlistv0.1.4check_historycheck_urlcheck_urlscreate_profiledelete_profileget_balanceget_pricingget_statslist_profilespurchaseresend_verificationshow_defaultssignupScored across 16 tools
Tools are mostly distinct: check_url vs check_urls are clearly singular/batch, and profile management tools (list_profiles, create_profile, delete_profile, show_defaults) have clear boundaries. However, check_url/check_urls share descriptions almost verbatim verdicts (intentional but could confuse agents), and allowlist tools vs profile tools address different concepts though both modify scoring.
Tool names follow a consistent verb_noun (or imperative short) pattern: check_url, list_profiles, create_profile, get_balance, add_to_allowlist. Minor deviations: 'show_defaults' (rather than list_defaults) and 'signup' (rather than sign_up or create_account) are outliers, but overall the pattern is predictable.
With 16 tools, the count is slightly above the ideal 3-15 range but still reasonable given the breadth of functionality (auth, URL checking, billing, profiles, allowlists, history). Each tool serves a distinct purpose, and none feels redundant enough to trim, so it's borderline but acceptable.
The server covers the core lifecycle: signup/verification, URL checking (single/batch), billing (purchase, balance, pricing), profile management (CRUD plus defaults), allowlist management (CRUD), and history/stats. Missing operations include password reset or account deletion, but those are minor and not core to the URL-checking domain. The gaps are workaround-able (e.g., no explicit profile export, but not essential).
Pay-per-call safety checks for AI agents: screen a crypto address or URL before you transact.
Live web checks for AI agents: sitemaps, robots.txt, URL status, broken links, feeds, citations.
Pay-per-call APIs for AI agents: web scraping, DNS/email checks, classification, trading risk.
Clean Markdown and AI-readability scoring for any URL. Built for AI agents.