Feranor Resilience

Domain Resilience Score

domain_check_score_v1

Read-onlyIdempotent

Free. Returns the overall resilience score out of 100 for a public web domain, plus the score of each category and how many findings each one raised. Use it to triage: to rank a list of domains, to confirm a domain is healthy, or to decide whether the detailed report is worth pulling. It tells you which categories are weak and how many issues they hold, but not what the issues are. For the individual findings and the prioritised remediation list, use domain_check_v1. Free, no payment required.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes	Bare domain name, apex or subdomain, for example 'example.com' or 'www.example.com'. Scheme, path, port and query string are ignored if present. IP addresses and private or localhost hostnames are rejected.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No
`score`	No	Weighted resilience score out of 100.
`domain`	No	Domain that was actually evaluated, after normalisation.
`success`	No
`categories`	No	Per-category score and finding count. Finding details are not included.
`evaluatedAt`	No	UTC timestamp of the evaluation.
`measuredCategories`	No	Number of categories that could actually be measured. Compare two domains only when this matches.
`detailsAvailableVia`	No	Name of the tool returning the full findings behind these scores.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds useful behavioral context: it returns scores and findings counts but not the actual issues, and states it's free. This goes beyond annotations by clarifying limitations and output scope.

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

Conciseness4/5

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

The description is well-structured and front-loaded: it starts with 'Free' and the core result, then usage, then limitations, then alternative tool. However, 'Free' appears twice ('Free.' and 'Free, no payment required'), a slight redundancy. Still appropriately sized and organized.

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?

The tool is simple (one parameter, output schema exists), and the description fully covers what it returns, when to use it, what it doesn't do, and which alternate tool to use. It is self-sufficient for an agent to select and invoke correctly, with no major gaps given the strong schema and annotations.

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

Parameters3/5

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

Schema description coverage is 100%, with the domain parameter already fully described (accepted formats, rejected IPs). The description adds no new parameter semantics, only uses the word 'domain' without further detail. Baseline 3 applies since schema does the heavy lifting.

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's function: 'Returns the overall resilience score out of 100 for a public web domain, plus the score of each category and how many findings each one raised.' It distinguishes itself from sibling domain_check_v1 by noting it doesn't provide individual findings, and the single-domain scope is implicit in contrast to batch siblings.

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 provides when to use: 'Use it to triage: to rank a list of domains, to confirm a domain is healthy, or to decide whether the detailed report is worth pulling.' It also directs to domain_check_v1 for detailed findings, giving clear alternative usage.

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?