DomChecker

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context beyond this: it queries a live registry rather than a dictionary, normalizes arbitrary input forms, converts Cyrillic to punycode, and defines fallback behavior when no zone is supplied. It does not cover rate limits or exact return shape, but the added context is substantial.

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 front-loaded with the core purpose and remains compact. Each sentence earns its place by adding operational detail: supported zones, accepted input formats, normalization rules, and no-zone fallback behavior.

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 one-parameter, read-only availability check, the description covers purpose, input normalization, zone coverage, and fallback behavior well. The main missing piece is the exact return format or error behavior, which is more important here because no output schema exists.

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%, so the schema already documents the single domain parameter. The description still adds value beyond the schema by explaining accepted input forms (URLs, any casing/format, Cyrillic), automatic stripping of extraneous parts, punycode conversion, and the no-zone behavior that checks .ru and popular zones.

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 specific task: determine whether a domain is free or taken via a real registry query, not a dictionary. It names the resource and scope, but does not explicitly differentiate from the sibling check_domains tool, which likely handles multiple domains.

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 is implied by the purpose, and the description gives useful input conditions such as any zone being accepted and the no-zone fallback behavior. However, it does not state when to use this tool versus alternatives like check_domains or whois_domain, nor does it give exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior: a 50-name cap and the fact that overflow items are reported in the response rather than silently dropped. It still doesn't say what the result contains or how the check behaves, so it is useful but not rich.

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?

Three tight sentences, front-loaded with the scope (batch, up to 50) before the when-to-use guidance and the overflow note. Almost no filler, though 'То же самое' spends the opening clause on a back-reference instead of stating the operation.

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 two-parameter read-only tool with no output schema, the description covers scope, limit, usage and overflow handling. The gap is that it never states what the check returns or what 'the same thing' refers to, leaving the core result semantics to inference from the sibling 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 coverage is 100%, with both `domains` and `only_available` documented in the input schema, so the baseline is 3. The description reinforces the 50-item limit and the overflow behavior but adds nothing about the filter parameter 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 makes clear this is the batch form ('сразу для списка, до 50 имён за вызов') and contrasts it with one-by-one checking, which lets an agent distinguish it from the sibling check_domain. However, it never says what 'check' actually determines (availability, registration, DNS), so a reader must infer the resource semantics from check_domain or the only_available parameter.

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?

It gives explicit triggering guidance: 'Зовите его, когда доменов больше одного', and it claims the batch approach is noticeably faster than checking 'по одному', which implicitly routes single-domain calls to check_domain. The alternative is described by behavior rather than by tool name, so the routing is clear but not fully explicit.

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

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

Annotations already state that this is a read-only, idempotent, non-destructive operation. The description adds real value beyond them: the response comes from a public resolver (Cloudflare, with Google as fallback) and reflects that resolver's cache, so a fresh zone edit is visible only after TTL, and NXDOMAIN means the name does not exist. The one gap is that it does not describe the response shape, but the freshness and error semantics are above the annotation baseline.

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?

Three compact sentences, front-loaded with the most useful content (record types plus SPF and DMARC). There is no filler; the only minor weakness is that the opening is a bare list rather than a clear statement of the action.

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 single-parameter tool with rich annotations, this covers record types, the SPF and DMARC check, resolver and cache behavior, and the NXDOMAIN case. Since there is no output schema, the one thing missing is a note on how results are returned such as grouping by record type or values only.

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%: the only parameter is documented, with an example (mail.example.ru). The description adds that the input is exactly one name, a domain or subdomain, which reinforces the single-name scope but adds little 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 names the exact record types returned (A, AAAA, CNAME, MX, NS, TXT, SOA, CAA), so the tool's purpose is clear. It also adds the SPF/DMARC presence check, but never distinguishes this tool from check_domain or whois_domain, leaving the agent to infer the split.

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 gives no guidance on when to use this tool rather than check_domain or whois_domain, and it states no preconditions or exclusions. The closest it comes is describing the behavior around NXDOMAIN and TTL, which is informational rather than routing guidance.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), it discloses that a human reads submissions and that repeating the same complaint does not create a new record but increments a counter — a genuine non-obvious side effect. It does not say what a successful submission returns, but there is no output schema, so that gap 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?

Front-loaded with the scope disambiguation in capitals, then usage triggers, then content requirements, then the repeat-complaint behavior. Every clause carries information an agent needs; nothing is padding.

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 4-parameter tool with full schema coverage and annotations covering the safety profile, the description supplies the missing usage and content guidance. The only unaddressed point is what the agent gets back on success, which is minor given the absence of an output schema.

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%, so the baseline is 3; the description earns an extra point by adding real meaning — it tells the writer what 'body' must contain (tool name, what was called, what was expected, what came back), reinforcing the schema's terse field hints.

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 opening line names the resource precisely — feedback about this server — and explicitly excludes the domain-focused scope of its siblings (check_domain, whois_domain, dns_records). An agent can immediately tell this is the meta/feedback channel rather than a lookup tool.

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?

It enumerates concrete triggers: a tool behaved contrary to its description, a parameter or response field was missing, a refusal came without a reason, or the description was unclear. The 'not about domains' clause acts as an explicit exclusion, routing domain issues to the sibling tools.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false), and the description adds value beyond that: default filtering to live items and the fact that triage is performed by a human in a panel. It also hints at the response content (other people's notes plus human replies), though it says nothing about ordering, volume, or pagination of the returned list.

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?

Four short sentences, each doing distinct work: what it returns, when to call it, what the default filter is, and what it cannot do. The purpose is front-loaded and there is no 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 three-optional-param read tool with full schema descriptions and annotations covering safety, nothing an agent needs to call it correctly is missing: purpose, sibling routing, default scope, and the mutation boundary are all stated. There is no output schema, but the description sufficiently signals that results include other users' notes and human replies.

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%, so all three parameters are already documented, including the enum values and the 'по умолчанию живые' default. The description only echoes that default and adds no syntax or interaction detail for q or tool, 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 first sentence names the resource (сообщения/замечания о сервере) and adds scope (their state), which is a specific listing behavior, not a restatement of the name. The second sentence explicitly contrasts it with the feedback_add sibling, so an agent can pick between the two without reading either schema.

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?

It gives an explicit trigger ('ЗОВИТЕ ПЕРЕД feedback_add, если не уверены, что о таком ещё не писали'), which is exactly the when-to-use guidance an agent needs, and names the alternative. It also states an exclusion boundary: status changes and deletions are not possible here because a human handles acceptance in the panel.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety needs no repeating. The description does add value beyond them by disclosing the return shape (a document with a link) despite no output schema, but it says nothing about behavior for nonexistent/invalid domains or about cost/latency of the open-world call.

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?

One short clause, front-loaded with the resource and the output form; there is no filler whatsoever.

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 single-parameter read with full annotation coverage and no output schema, the description gives the essential missing piece — that the result is a citable document with a link. Only the boundary with whois_domain/site_facts and error behavior are absent.

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% and the single parameter 'id' is documented as 'домен', so the schema does the work. The description does not clarify the expected domain format (with/without scheme or subdomain), so it adds nothing beyond the schema — baseline 3.

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 says it returns one domain in detail as a document with a link, which conveys the resource and output shape, but the verb is implied rather than stated (the name 'fetch' is generic) and it never distinguishes itself from close siblings like whois_domain, check_domain or site_facts.

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?

'для цитирования в ответе' hints at the usage context — use it when you need a citable detail card — but there is no explicit when-not guidance and no named alternative for the narrower lookups the sibling tools cover.

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

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

The annotations already establish that the operation is safe and repeatable (readOnlyHint, idempotentHint, destructiveHint=false). The description adds non-obvious behavior: a bare name with no zone fans out into checks across popular zones (.ru, .com, .net, .org), which tells an agent to expect multiple results per input. It does not explain the response shape or which 'прочих' zones are covered.

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?

Four short sentences with no filler, and the most important constraint ('Имена НЕ придумывает') comes before the hand-off to check_domains. Every sentence carries information the agent needs.

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?

Because there is no output schema, the description should ideally say what comes back: availability status, error, or zone results. Instead, the zone list is left vague with 'и прочих', and the return values are unaddressed. Suitable for a simple read tool but not fully complete.

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%, so the baseline is 3, but the description adds real meaning beyond the schema: a zone-less input is interpreted as a name to try in several popular zones, so the agent knows one input can produce multiple checks. It is slightly at odds with the schema wording ('домен, несколько доменов через пробел'), which suggests a domain list rather than arbitrary text.

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 gives a concrete verb+resource: 'Достаёт доменные имена из произвольного текста и проверяет каждое'. It also distinguishes itself from the similar sibling check_domains by stating that it checks exactly what is named and that invented variants belong in check_domains.

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 makes it clear that this tool is for raw text input and that check_domains is the destination for a hand-built list of variants, including the exclusion 'Имена НЕ придумывает'. It does not address the other related siblings (check_domain, whois_domain, dns_records), so the guidance is clear but only partial.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), yet the description adds genuinely new behavioral context: every fact carries a tone label (obychno/vnimanie) plus an explanation, and the server explicitly does not issue a verdict or scan for malware. Those caveats shape how an agent should interpret and relay the output. It stops short of describing completeness or failure behavior for unresolvable domains.

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?

It runs to three sentences and is front-loaded with the purpose, then the output shape, then the limitation. Every sentence carries information, though the mixed-script typo in 'тон obychno' slightly hurts readability of the return-value explanation.

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?

With no output schema, the description must convey what comes back, and it does: a set of labeled facts, each with a tone and an explanation. Combined with the explicit scope limits, an agent has enough to call it and interpret results, though it says nothing about behavior on unresolvable or malformed domains.

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?

There is a single parameter with 100% schema description coverage, including example input formats (shop-example.ru or https://www.shop.ru/), so the schema carries the load. The description adds nothing about the domain argument itself, which matches the baseline 3 for a fully documented single parameter.

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 names a specific resource (facts about a site, by domain) and enumerates exactly which facts are returned: domain age, registrar, owner privacy, HTTPS certificate, hosting network, SPF/DMARC. That is far more than a restatement of the name. What it lacks is differentiation from close siblings such as whois_domain, dns_records and check_domain, which visibly overlap with parts of this output.

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 intended context is implied ('for evaluating an unfamiliar site'), along with an explicit boundary on what the result should not be used for (no final fraud/honesty conclusion). However, no alternative tool is named and no condition for choosing this over whois_domain or dns_records is given, so the agent must infer sibling routing on its own.

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

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

Annotations already declare read-only, idempotent, open-world behavior, so the description does not need to repeat that. It adds meaningful context: data comes from RDAP or WHOIS, results are cached for up to an hour, owner disclosure varies by registry, and TLD-specific field semantics are explained.

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 front-loaded with the core purpose and contains no filler. It is dense and parenthetical-heavy, making it slightly harder to scan, but every clause carries useful 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?

With no output schema, the description does a good job explaining the returned fields, data source, caching, and privacy caveats. It could mention error or not-found behavior, but it is otherwise complete for a simple read-only lookup.

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 single domain parameter is fully documented in the schema, so the baseline is 3. The description adds TLD-specific interpretation of returned fields but does not add input-format or validation guidance 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 states that this returns a registry record for a single domain and enumerates the main fields. It is distinguishable from broad search tools, but it does not explicitly differentiate itself from sibling tools like check_domain or check_domains.

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?

There is no explicit guidance on when to use this tool instead of check_domain, check_domains, or other siblings. Usage is only implied by the phrase 'registry record about one domain' and the listed fields.

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