Web Check MCP server provides OSINT reconnaissance tools for websites and domains via the Web Check API, enabling:
Listing available checks and groups (webcheck_list_checks)
Probing API health (webcheck_health)
Running parallel multi-check bundles with customizable groups (e.g., quick, security, server, quality, heavy, all) or individual checks (webcheck_run)
Performing specific checks: SSL certificate chain (webcheck_ssl), DNS records (webcheck_dns), HTTP headers (webcheck_headers), WHOIS data (webcheck_whois), and a security preset bundle (webcheck_security) covering SSL, TLS, HSTS, HTTP security, firewall, DNSSEC, security.txt, threats, and block-lists.
All tools are read-only, support configurable timeouts, custom API base URLs, and payload truncation. The server includes automatic fallback to public API bases, environment variable configuration (e.g., WEB_CHECK_BASE_URL, WEB_CHECK_TIMEOUT), and (targeting v0.4.0) reliability features such as retry with exponential backoff, circuit breaking, TTL-based caching, token-bucket rate limiting, and input validation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Web Check MCP Run security and SSL checks on example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Agent wrapper for Lissy93/web-check — 31 OSINT checks as MCP tools + CLI.
Gap verified 2026-07-25: no public MCP/SDK/Hermes skill existed for this API. This package fills it.
8 MCP tools: webcheck_run, webcheck_ssl, webcheck_dns, webcheck_security, webcheck_headers, webcheck_whois, webcheck_list_checks, webcheck_health
31 OpenAPI checks from upstream (ssl, dns, headers, ports, firewall, whois, …)
Presets: quick | security | server | quality | heavy | all
Parallel fan-out + payload truncation (agent-context safe)
Zero pip deps — Python 3.10+ stdlib only
STDIO JSON-RPC with initialize handshake + tool annotations (readOnlyHint + openWorldHint)
Related MCP server: OSINT Tools MCP Server
Two public bases are tried automatically:
Base | Status |
| 200 OK — more open, Cloudflare front |
| 200/429 — may challenge datacenter IPs |
Set WEB_CHECK_BASE_URL explicitly to skip probing. Fallback auto-enables when base starts with https://web-check. and can be forced via WebCheckClient(fallback=True).
No key, no auth.
For heavy load or offline use:
docker run -d --name web-check -p 3000:3000 lissy93/web-check
export WEB_CHECK_BASE_URL=http://127.0.0.1:3000/apiOr compose (upstream + thin MCP image):
docker compose up -d web-check
# MCP stdio still launched by host; see Dockerfile ENTRYPOINTUpstream Go rewrite xray-web/web-check-api is early WIP — prefer Node/Docker image for full endpoint parity.
# from repo root
pip install -e .
# or: python3 -m pip install web-check-mcp
# Manifest
python3 -m src.server --manifest
# List checks
python3 -m src.server list --group quick
# Health probe
python3 -m src.server health
# Run quick recon (needs live API)
python3 -m src.server run example.com --group quick
# Single check
python3 -m src.server check ssl example.com
# MCP STDIO (Claude Desktop / Hermes / Cursor)
python3 -m src.server --stdiofrom src.client import WebCheckClient
client = WebCheckClient(base_url="http://127.0.0.1:3000/api")
print(client.run("example.com", group="quick"))
print(client.check_one("ssl", "example.com")){
"mcpServers": {
"web-check": {
"command": "python3",
"args": ["-m", "src.server", "--stdio"],
"cwd": "/absolute/path/to/web-check-mcp",
"env": {
"WEB_CHECK_BASE_URL": "http://127.0.0.1:3000/api"
}
}
}
}After pip install web-check-mcp:
{
"mcpServers": {
"web-check": {
"command": "web-check-mcp",
"args": ["--stdio"],
"env": {
"WEB_CHECK_BASE_URL": "https://web-check.as93.net/api"
}
}
}
}Official registry metadata lives in server.json (io.github.AMEOBIUS-space/web-check-mcp). Publish with mcp-publisher after the next PyPI release that includes the mcp-name marker above.
Tool | Description |
| Catalog of endpoints / groups |
| Probe API base reachability |
| Parallel multi-check (default group= |
| Certificate chain |
| DNS records |
| Security preset bundle |
| HTTP headers |
| Domain WHOIS |
Env: WEB_CHECK_BASE_URL, WEB_CHECK_TIMEOUT, WEB_CHECK_MAX_WORKERS, WEB_CHECK_MAX_CHARS.
python3 -m pytest tests/ -vAll network paths mocked — no live API required for CI.
These features are available on
main. The latest published package remains v0.3.0; the v0.4.0 release and MCP Registry namespace migration are tracked in #45.
Retry Logic - Auto-retries transient failures (5xx, connection errors) with exponential backoff (1s, 2s, 4s). Configure: WEB_CHECK_MAX_RETRIES (default: 3)
Circuit Breaker - Protects failing APIs. Per base_url tracking, opens after 5 failures, auto-recovers after 60s, fails fast when open.
Input Validation - Validates URLs, check names, groups, timeouts. Clear error messages instead of exceptions.
Caching - TTL-based cache reduces redundant API calls. Configure: WEB_CHECK_CACHE_TTL (default: 300s). Stats in health endpoint.
Rate Limiting - Token bucket protects API. Configure: WEB_CHECK_RATE_LIMIT (default: 1.0 req/s). Burst: 10 requests.
Variable | Default | Description |
|
| API base URL |
|
| Request timeout (seconds) |
|
| Parallel workers |
|
| Max payload size |
|
| Retry attempts |
|
| Cache TTL (seconds, 0=disabled) |
|
| Requests per second |
Self-host Web Check API: docker run -p 3000:3000 lissy93/web-check
Set WEB_CHECK_BASE_URL: Point to your instance
Enable caching: Configure WEB_CHECK_CACHE_TTL
Configure rate limiting: Adjust WEB_CHECK_RATE_LIMIT
Monitor health endpoint: Use cache/rate stats
Use Docker: Non-root user, healthcheck included
MIT. Upstream Web Check © Alicia Sykes, MIT.
Not affiliated with Lissy93; thin agent-facing client only.
Fetch DNS records for a domain via Web Check /dns.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL or domain (https:// added if missing) | |
| timeout | No | Per-request timeout seconds | |
| base_url | No | Web Check API base (default env WEB_CHECK_BASE_URL or https://web-check.as93.net/api) | |
| max_chars | No | Truncate each check payload to this many JSON chars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only the endpoint path (/dns) but no additional behavioral context such as rate limits or response structure. No contradiction exists.
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 a single, direct sentence that front-loads the action and target. It contains no redundant information and wastes no words, making it easy for an agent to parse quickly.
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 straightforward read-only DNS fetch, the description with a fully covered schema and strong annotations is sufficient. The only minor gap is that it does not hint at the type of DNS records returned (e.g., A, MX, TXT), but the tool name and purpose make this inferable.
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 all four parameters (url, timeout, base_url, max_chars) are fully documented in the schema. The description does not need to repeat parameter details; it remains consistent with the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch), the resource (DNS records for a domain), and the specific endpoint (/dns). It distinguishes itself from sibling tools like webcheck_ssl or webcheck_whois by naming the exact data type.
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?
Usage context is implied: this tool is for fetching DNS records. However, it does not explicitly mention alternatives or when not to use it, leaving the agent to infer based on sibling names. It lacks explicit 'use this for DNS, use webcheck_ssl for certificates' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch HTTP response headers via Web Check /headers.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL or domain (https:// added if missing) | |
| timeout | No | Per-request timeout seconds | |
| base_url | No | Web Check API base (default env WEB_CHECK_BASE_URL or https://web-check.as93.net/api) | |
| max_chars | No | Truncate each check payload to this many JSON chars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the API endpoint context but no further behavioral details such as rate limits, redirect handling, or response format. It does not contradict the annotations.
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 a single, efficient sentence that front-loads the verb and resource. Every word earns its place, with no redundancy or filler.
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, read-only tool with fully documented parameters and clear safety annotations, the description is sufficient. It could mention return format or potential errors, but the tool name and schema provide most necessary context, making it complete enough for this scenario.
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?
All four parameters are fully described in the input schema (100% coverage), so the description does not need to add parameter details. It adds no additional meaning beyond what the schema provides, but that is acceptable given the schema's thoroughness.
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 ('Fetch') and the specific resource ('HTTP response headers'), plus the exact API endpoint ('/headers'). This distinguishes it from sibling webcheck tools like webcheck_ssl or webcheck_dns, which target different resources.
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 no explicit when-to-use or when-not-to-use guidance, nor any comparison to alternatives. The intended usage is implied by the tool name and resource, but the lack of explicit exclusions or references to sibling tools leaves it to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probe whether the configured Web Check API base URL is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | Per-request timeout seconds | |
| base_url | No | Web Check API base (default env WEB_CHECK_BASE_URL or https://web-check.as93.net/api) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context by indicating a network 'probe' for reachability, which complements the readOnlyHint=true and destructiveHint=false annotations. However, it does not disclose what happens on failure (e.g., error response, status codes) or any side effects. Since annotations already cover safety, the description adds moderate value but lacks deeper behavioral details.
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 a single, clear sentence that front-loads the action ('Probe') and resource. There is no redundant or filler content, making it highly concise and 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?
For a simple health-check tool with full schema coverage and annotations indicating a safe, read-only operation, the description is sufficient to convey the core action and expected outcome. While there is no output schema to clarify the return format, the nature of a reachability probe implies a boolean or status result. A small gap exists in not describing error behavior or return details, but overall it is complete for the tool's simplicity.
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 provides full descriptions of both parameters (timeout and base_url), including defaults and environment variable fallback. The tool description itself adds no additional meaning to the parameters, so with 100% schema coverage, the baseline score of 3 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 the tool's purpose with a specific verb ('Probe') and resource ('the configured Web Check API base URL'), and it explicitly focuses on reachability. This distinguishes it from sibling tools like webcheck_run or webcheck_ssl, which perform specific checks rather than a general health probe.
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 implies this is a preliminary connectivity check for the API base URL, especially given sibling tools like webcheck_list_checks and webcheck_run. However, it does not explicitly state when to use this tool instead of others, nor does it mention any exclusions or alternative tools. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Web Check endpoints/groups (ssl, dns, headers, ports, …).
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Optional preset: quick|security|server|quality|heavy|all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context beyond the resource being listed, but for a simple listing tool, no additional side-effect disclosure is necessary. It is consistent with the annotations.
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?
A single, front-loaded sentence that succinctly conveys the tool's purpose. Every word earns its place, with no filler or redundant information.
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 listing tool with good annotations and one well-documented parameter, the description sufficiently conveys its function and output type (a list of endpoints/groups). A slightly richer note about the output format or intended use would push it to 5, but it is 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 input schema already provides complete documentation for the single optional parameter 'group' (with a description of valid presets). The description adds no further parameter semantics, so the baseline of 3 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 uses the specific verb 'List' and clearly identifies the resource as 'available Web Check endpoints/groups', with examples (ssl, dns, headers, ports). This clearly differentiates it from the sibling tools that actually perform checks rather than listing them.
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 implies that this tool is for discovering available endpoints/groups, but it does not explicitly state when to use it relative to alternatives (e.g., before running a specific check) or when not to use it. Usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one or more Web Check jobs against a URL (parallel fan-out). Prefer group=quick for recon; avoid heavy (screenshot/ports/traceroute) unless needed.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL or domain (https:// added if missing) | |
| group | No | Preset group if checks omitted: quick|security|server|quality|heavy|all | quick |
| checks | No | Explicit check names (e.g. ssl, dns, headers). Overrides group. | |
| timeout | No | Per-request timeout seconds | |
| base_url | No | Web Check API base (default env WEB_CHECK_BASE_URL or https://web-check.as93.net/api) | |
| max_chars | No | Truncate each check payload to this many JSON chars | |
| max_workers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and non-destructive, and the description adds behavioral context about parallel fan-out and heavy-check avoidance. There is no contradiction with the annotations.
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, front-loaded with the core action, and every clause adds practical value. No filler or repetition of schema/annotations.
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 seven-parameter tool with no output schema, the description omits what the return payload looks like or how errors/timeouts are handled. It covers purpose and usage well but leaves result behavior implied.
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 86%, so the baseline is 3. The description adds value by connecting group=quick to reconnaissance and naming example heavy checks (screenshot/ports/traceroute), going beyond what the schema alone states.
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 uses a specific verb and resource ('Run ... Web Check jobs against a URL') and highlights 'parallel fan-out', clearly distinguishing it from sibling single-check tools. The action and target are unambiguous.
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 to prefer group=quick for recon and avoid heavy checks unless needed. While it does not name sibling tools as direct alternatives, it gives clear when-to-use and when-to-avoid direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Security bundle: ssl, tls, hsts, http-security, firewall, dnssec, security-txt, threats, block-lists.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL or domain (https:// added if missing) | |
| timeout | No | Per-request timeout seconds | |
| base_url | No | Web Check API base (default env WEB_CHECK_BASE_URL or https://web-check.as93.net/api) | |
| max_chars | No | Truncate each check payload to this many JSON chars | |
| max_workers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral details such as how the bundle aggregates results, execution order, concurrency, or error handling. For a multi-check tool, this is a significant gap.
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 a single sentence that efficiently lists the bundled security checks. It is front-loaded with 'Security bundle' and avoids unnecessary words. While minimal, it serves its purpose without waste.
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 (multiple checks) and lack of an output schema, the description is under-specified. It does not explain how results are structured, whether responses aggregate all checks or are separate, or how to interpret failures. More context is needed for an agent to confidently rely on this 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 80%, with url, timeout, base_url, and max_chars documented. The tool description does not add parameter meaning beyond the schema. The undocumented max_workers parameter remains unexplained in both the schema and description, keeping the score at baseline.
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 identifies the tool as a 'Security bundle' listing specific checks (ssl, tls, hsts, etc.), which distinguishes it from individual sibling tools like webcheck_ssl and webcheck_dns. It lacks an explicit verb like 'runs' or 'checks', but the intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to prefer this bundle over individual security tools, nor does it mention any trade-offs or prerequisites. This is a missed opportunity given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch SSL certificate chain for a URL via Web Check /ssl.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL or domain (https:// added if missing) | |
| timeout | No | Per-request timeout seconds | |
| base_url | No | Web Check API base (default env WEB_CHECK_BASE_URL or https://web-check.as93.net/api) | |
| max_chars | No | Truncate each check payload to this many JSON chars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds minimal behavioral context beyond the endpoint name; it doesn't mention response format, truncation, or potential errors. With annotations covering safety, the additional value is modest.
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 a single, direct sentence that immediately states the tool's purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only fetch tool with complete schema coverage and annotations declaring safety, the description sufficiently covers the tool's purpose. It doesn't detail output structure, but the return value ('SSL certificate chain') is implied, and the schema handles parameter details.
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 all four parameters described in the schema. The description does not add parameter-specific semantics beyond what the schema already provides, so a 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 the action ('Fetch'), the resource ('SSL certificate chain'), and the target ('for a URL'). It also specifies the mechanism ('via Web Check /ssl'), which distinguishes it from sibling tools like webcheck_dns or webcheck_headers.
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 implies the use case—checking SSL certificate information for a URL—and is clearly distinct from siblings. However, it does not explicitly state when to use it over alternatives or mention any exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHOIS / domain registration data via Web Check /whois.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL or domain (https:// added if missing) | |
| timeout | No | Per-request timeout seconds | |
| base_url | No | Web Check API base (default env WEB_CHECK_BASE_URL or https://web-check.as93.net/api) | |
| max_chars | No | Truncate each check payload to this many JSON chars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint false, covering the safety profile. The description adds the endpoint path ('/whois') and the data type, but does not disclose additional behavioral traits such as rate limits or error behavior. This is consistent with annotations, with minimal added 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 a single concise phrase that front-loads the key information. It is efficient, but slightly terse; a full sentence with a verb would improve clarity without sacrificing brevity.
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 simple nature of the tool, the schema covers parameters and annotations cover safety, but the description omits any mention of the return format or behavior of the truncation parameter. It is minimally complete but could provide more context.
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 descriptions for url, timeout, base_url, and max_chars, so the schema fully documents parameters. The description does not add additional parameter semantics 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?
The description clearly identifies the tool as providing WHOIS/domain registration data via the Web Check /whois endpoint, distinguishing it from sibling tools like webcheck_dns or webcheck_ssl. However, it lacks an explicit verb (e.g., 'retrieves'), which prevents a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives in the sibling set. The description simply states what it does, leaving the agent to infer usage context.
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.0webcheck_dnswebcheck_headerswebcheck_healthwebcheck_list_checkswebcheck_runwebcheck_securitywebcheck_sslwebcheck_whoisScored across 8 tools
The specific check tools (ssl, dns, headers, whois) are clearly distinct, but webcheck_run and webcheck_security overlap with them by design as generic and bundled operations. The descriptions clarify intended use cases, so agents can select appropriately, though run's generality introduces some redundancy.
All tools share the webcheck_ prefix and snake_case, but the suffixes mix nouns (ssl, dns) and verb/noun phrases (list_checks) or bare verbs (run). This is consistent enough to predict purpose, but not a uniform verb_noun pattern.
At 8 tools, the set is well-scoped for a web check service: discovery, health, specific checks, a generic runner, and a bundle. Each tool serves a purpose without bloat.
The tool surface covers the full workflow: discover available checks via list_checks, verify API health, run individual checks (ssl, dns, headers, whois), execute arbitrary jobs via run, and get the security bundle. The generic run tool compensates for missing specific wrappers, making the set complete.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Free MCP server: 32 security & developer API tools -- WHOIS, DNS, CVE checks, IP reputation.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
