Feranor Resilience

Domain Resilience Check, Batch

domain_check_batch_v1

Read-onlyIdempotent

Runs the full resilience check on up to 100 domains in a single call and returns the same scored report for each one: TLS certificate, security headers, DNS redundancy, response time, with every individual finding. Use it to audit a portfolio, to rank a list of vendors, or to re-check a fleet after a config rollout. A domain that cannot be reached is returned with its own error rather than failing the batch, and it is still charged, because the crawl was attempted. Do not use it for a single domain: domain_check_v1 is simpler and costs the same for one. Private, internal and localhost hostnames and IP addresses are rejected. Price: $0.01 per domain, dropping to $0.005 from 100 domains, up to 100 per call. One payment covers the whole batch (x402, USDC on Base). No signup, no API key.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domains`	Yes	Bare domain names, apex or subdomain, for example ['example.com', 'www.example.org']. Between 1 and 100 entries. Scheme, path, port and query string are ignored if present. Duplicates are removed before billing.

Output Schema

TableJSON Schema

Name	Required	Description
`results`	No	One entry per distinct domain, in no guaranteed order.
`evaluated`	No	Number of distinct domains actually evaluated. This is the billed quantity.
`requested`	No	Number of domains in the request, before de-duplication.
`succeeded`	No	How many produced a full report. The rest carry an error field.
`evaluatedAt`	No	UTC timestamp of the batch.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the safe read-only annotations, the description discloses important behaviors: unreachable domains return their own error but are still charged, private/internal/localhost hostnames are rejected, and pricing/payment details. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficient and well-structured: first the core action, then example use cases, then edge cases, then pricing/payment. Every sentence conveys necessary information without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description doesn't need to spell out return values. It covers error handling, restrictions, pricing, and usage guidance, making it complete for a batch tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents the domains parameter thoroughly (bare domain names, 1-100 entries, scheme/path ignored, duplicates removed). The description adds billing cost per domain and clarifies batch behavior, adding value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a full resilience check on up to 100 domains, listing the specific checks (TLS certificate, security headers, DNS redundancy, response time) and explicitly distinguishes itself from the single-domain sibling domain_check_v1.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives use cases (audit a portfolio, rank vendors, re-check after config rollout) and an explicit exclusion: 'Do not use it for a single domain: domain_check_v1 is simpler and costs the same for one.' This provides clear when-to-use and alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Feranor Resilience tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a distinct purpose: domain_check_v1 vs domain_check_batch_v1 differ by number of domains, domain_check_score_v1 vs domain_check_v1 differ by detail level, and the batch variants mirror this. text_scan_v1 and text_purge_v1 are clearly complementary (detect vs fix). No two tools overlap in function.

Naming Consistency5/5

All tool names follow the pattern <noun>_<verb>_v1, with optional _score and _batch modifiers. The naming is perfectly consistent and predictable, making it easy to infer the tool's behavior from its name.

Tool Count4/5

Six tools is within the ideal range, but the server mixes two unrelated domains (domain resilience and text sanitization). While each sub-domain is well-covered, the combined focus makes the server feel slightly less coherent than a single-purpose toolkit.

Completeness5/5

The domain tools cover single/batch and score/detailed variants, providing a complete workflow for resilience assessment. The text tools cover scanning and fixing, which is a complete workflow for that sub-domain. No obvious gaps exist in either area.

Resources

Need Help?