Wellknown

Audit a domain's agent discoverability

audit_domain

Check whether AI agents can find and trust a domain. Probes all four ARD advertisement paths (/.well-known/ai-catalog.json, the Agentmap directive in robots.txt, , and DNS records), validates any catalog found against the official JSON Schema plus additional spec rules, queries live ARD registries to see whether the domain is actually returned, and checks the MCP directories. Returns a scored report with concrete remediation steps.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain to audit, e.g. notion.so. URLs are accepted and reduced to the host.
`competitors`	No	Up to 3 competitor domains to compare against.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does a strong job: it discloses all four probing paths, validation against JSON Schema, registry queries, and MCP directory checks, plus the return format (scored report). It omits details like whether the tool is read-only or any rate limits, but all actions are inherently read-oriented, making the behavior clear.

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 a single dense sentence that efficiently lists all major actions, but its length and run-on structure could be improved by splitting into two sentences. Every phrase contributes valuable information, so it is not wasteful, but front-loading is slightly less crisp than ideal.

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

Completeness4/5

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

The description covers the tool's full scope: all advertisement paths, validation, registry lookup, and MCP directory checks, plus the output as a scored report with remediation steps. Given the tool's complexity and absent output schema, this is reasonably complete, though it could mention any operational constraints like network timeout or required permissions.

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 coverage is 100% with descriptive parameter definitions (e.g., domain example, competitors limit). The description adds no additional parameter-specific detail beyond the schema, so it reaches the baseline for full coverage.

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 uses a specific verb 'Check' with a clear resource ('domain's agent discoverability') and enumerates the four advertisement paths it probes, which thoroughly distinguishes it from siblings like generate_catalog and validate_catalog.

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

Usage Guidelines4/5

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

The description establishes a clear context for use ('Check whether AI agents can find and trust a domain') and lists the audit activities. However, it does not explicitly name alternative tools or stipulate when to use this over validate_catalog or search_registry, but the specific scope and output report make the intended usage evident.

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

All Wellknown 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.5/5.0

Disambiguation5/5

Each tool has a clearly distinct responsibility: audit_domain checks a live domain's discoverability and trust across ARD paths, while validate_catalog checks a static document against schema rules. search_registry and get_capability follow the classic query-versus-fetch-by-ID pattern. No two tools would plausibly compete for the same call.

Naming Consistency5/5

Every tool follows a strict lowercase snake_case verb_noun pattern: audit_domain, generate_catalog, get_capability, search_registry, validate_catalog. The two catalog-related tools use distinct leading verbs (generate vs. validate) that reinforce their different purposes rather than confusing them.

Tool Count5/5

At 5 tools, the server is lean and well-scoped, sitting squarely in the ideal 3-15 range. Each tool maps to a distinct stage of the ARD lifecycle—search, fetch, generate, validate, audit—with no redundancy or bloat.

Completeness5/5

The toolset covers the full agent workflow end-to-end: search and get for discovery, generate and validate for authoring, and audit for trust assessment. There are no dead ends or fabricated outputs, as generate_catalog explicitly returns underivable fields as a to-do list, and the domain doesn't obviously require update/delete or registration tools.

Resources

Need Help?