Skip to main content
Glama
Cloady

Cloady

Official
by Cloady

Check Dns

checkDns
Read-only

Retrieve the DNS targets a custom domain must use, and check a host to confirm current pointing and whether another app holds it.

Instructions

The addresses a custom domain must point at and, with host, whether it already does and whether another app holds it. Public: no token needed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "checkDns"
  }
}

Input Schema

NameRequiredDescriptionDefault
hostNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new context beyond them: the tool is public and requires no auth token, and it discloses that it can reveal whether a domain is already held by another app — a meaningful side-effect-adjacent detail.

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?

A single dense sentence plus a short auth note — tightly sized with no filler. The grammar is slightly elliptical ('The addresses a custom domain must point at...'), which costs a bit of immediate readability but not accuracy.

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?

For a one-optional-parameter read-only tool with no output schema, the description covers both call modes and their qualitative results plus the auth requirement. Missing only the concrete shape of the returned addresses (A/AAAA/CNAME) and hostname format, which are minor for this complexity.

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 0% for the single `host` parameter, but the description does explain its semantics: passing it switches the tool from returning target addresses to checking actual pointing plus third-party ownership. That is real meaning beyond the bare `{"type":"string"}` schema, though format expectations (bare hostname vs URL) are unstated.

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

Purpose4/5

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

The description states a specific resource (the DNS target addresses a custom domain must point at) and a specific conditional behavior (with `host`, verifying current pointing and detecting ownership by another app). It is clear what the tool does, though the verb is implicit and it never distinguishes itself from the similarly named sibling `checkDomains`.

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

Usage Guidelines3/5

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

The phrase 'with `host`' implies a usage mode (omit for target addresses, supply for verification), and 'Public: no token needed' tells the agent it can be called unauthenticated. However, there is no explicit guidance on when to prefer this over `checkDomains`, `getWhois`, or `listDnsRecords`, leaving the sibling choice to inference.

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

Deploy Server

Other Tools