_ _ _ _ ____ _ _ _ _ ____ _
| | | | \ | | _ \| | | | | | | _ \| |
| | | | \| | |_) | |_| | | | | |_) | |
| |_| | |\ | __/| _ | |_| | _ <| |___
\___/|_| \_|_| |_| |_|\___/|_| \_\_____|Аналитика URL для ИИ-агентов и разработчиков. 16 инструментов MCP. 25 сигналов. 7 измерений.
Дайте вашему ИИ-агенту возможность «видеть» URL-адреса. Unphurl анализирует любой URL по 7 измерениям (поведение при перенаправлении, имитация бренда, возраст домена, SSL/TLS, обнаружение припаркованных доменов, структура URL, обогащение DNS) и возвращает структурированные сигналы с настраиваемой оценкой риска от 0 до 100. Это сигналы, а не вердикты. Ваш агент сам решает, что с ними делать.
Работает с Claude Code, Claude Desktop, Claude Cowork, ChatGPT desktop, Cursor, Windsurf и любым инструментом, совместимым с MCP.
Каждый новый аккаунт получает 20 бесплатных кредитов на проверку. Большинство запросов бесплатны. Известные домены (Tranco Top 100K) и ранее проанализированные домены возвращают кэшированные результаты бесплатно. Вы платите только тогда, когда неизвестный домен проходит полный цикл анализа.
Пакет | Кредиты | Цена | За проверку |
Starter | 100 | $9 | $0.090 |
Standard | 500 | $39 | $0.078 |
Pro | 2,000 | $99 | $0.050 |
Scale | 10,000 | $399 | $0.040 |
Разовая покупка, без подписок. При обычном использовании 95-99% URL обрабатываются бесплатно.
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"
}
}
}
}ИИ может создать его для вас. Просто попросите: "Sign up for Unphurl." Инструмент signup работает без API-ключа. После регистрации добавьте ключ в конфигурацию MCP и перезапустите инструмент.
Просто общайтесь со своим ИИ:
"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"
Никаких команд для запоминания. Никакого синтаксиса для изучения. Ваш ИИ сам управляет вызовами инструментов.
Каждая проверка возвращает сигналы по 7 измерениям:
Измерение | Что это дает |
Поведение при перенаправлении | Полная цепочка (до 10 переходов), обнаружение сокращателей, причины остановки |
Имитация бренда | Анализ Левенштейна + гомоглифов по 150+ брендам |
Аналитика домена | Возраст, регистратор, срок действия, коды состояния, серверы имен (через RDAP) |
SSL/TLS | Проверка рукопожатия в реальном времени через edge-сеть Cloudflare |
Обнаружение припаркованных доменов | 4-уровневая проверка: страницы регистратора, продажа, пустой контент, парковочные сервисы |
Структура URL | Длина, глубина пути, количество поддоменов, энтропия, обнаружение IP, закодированные символы |
Обогащение DNS | Наличие записи MX (может ли домен получать электронную почту?) |
Каждый сигнал — это бизнес-аналитика. Возраст домена показывает, насколько давно существует компания. Отсутствие записи MX означает, что они не могут получать электронную почту. Истекающие домены могут указывать на то, что бизнес закрывается. В сочетании с возможностью вашего ИИ обрабатывать данные массово и выводить их в электронные таблицы, это становится легким инструментом для комплексной проверки (due diligence).
Инструмент | Что делает | Авторизация |
| Создать новый аккаунт, получить API-ключ | Нет |
| Повторно отправить письмо с подтверждением (лимит 3/час) | Да |
| Проверить один URL по всем 7 измерениям | Да |
| Пакетная проверка до 500 URL (автоматически обрабатывает асинхронный опрос) | Да |
| Список ваших пользовательских профилей оценки | Да |
| Создать или обновить профиль оценки с пользовательскими весами | Да |
| Удалить профиль оценки | Да |
| Показать все 25 сигналов оценки с весами по умолчанию | Нет |
| Проверить баланс кредитов на проверку | Да |
| Просмотреть статистику использования и количество пороговых значений | Да |
| Показать доступные пакеты кредитов и цены | Нет |
| Купить кредиты (возвращает URL Stripe Checkout) | Да |
| Просмотреть историю недавних проверок 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."
Ваш ИИ получает пакетные результаты, фильтрует их по оценке и выводит списки. Никакого кода, никаких скриптов.
Разные задачи требуют разных весов. Боту безопасности важна имитация бренда. Инструменту для холодных рассылок важны припаркованные домены и отсутствие записей 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."
Unphurl внутри чата с ИИ сочетается со всем, к чему имеет доступ ваш агент:
Электронные таблицы: Чтение экспорта из CRM, пакетная проверка каждого URL, запись результатов обратно с оценками риска
Веб-скрейпинг: Скрейпинг страницы партнеров конкурента, проверка каждой ссылки на работоспособность
Документы: Генерация брендированного PDF-отчета об аудите на основе результатов
Запланированные задачи: "Check my critical URLs every Monday morning"
Положительный баланс кредитов требуется для всех проверок, даже для бесплатных запросов.
Известные домены (google.com, amazon.com и т.д.): бесплатно, мгновенно.
Кэшированные домены (недавно проанализированные кем-либо): бесплатно, мгновенно.
Неизвестные домены (первичный анализ): 1 кредит за каждый.
Пакетные проверки списывают кредиты авансом за неизвестные домены. Если кредитов недостаточно, вы получите сводку с точным количеством необходимых кредитов.
За неудачные проверки кредиты возвращаются автоматически.
Навык check-url-safety учит ваш ИИ проактивно проверять 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)
Hosted MCP для Claude Cowork (без локальной установки): 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.