Loading ToolBench
MCP server for Windows DNS Policy Manager — exposes DNS server/zone/record queries and policy management to AI agents
This MCP server exposes 16 DNS configuration read-only tools via STDIO. While tool naming follows verb_noun conventions (dns_get_*, dns_export_*) and descriptions are present, there are significant gaps in schema completeness, parameter documentation, and output structure. The server is entirely read-only (all tools are READ_ONLY risk), which limits the need for destructive operation handling, but parameter schemas are incomplete for most tools. Descriptions are brief (typically 10 - 25 words) but lack actionable context about when to use each tool, dependencies, and output structure. Input schemas show parameter names and types for some tools (server, serverId, credentialMode), but many lack descriptions or format constraints. No output schemas are documented in the code, making it difficult for LLMs to plan downstream operations. Error handling guidance is absent from tool descriptions. Overall, this is a typical community DNS management tool with basic definitions but missing production-grade documentation and structure.
Check if the PowerShell bridge is running and reachable
Export full DNS server configuration as structured data (may be slow — up to 60s)
Get DNS query block list (enabled, blocked domain list)
Get DNS cache settings (max TTL, max negative TTL, size, pollution protection)
Get DNS diagnostic/event logging configuration (queries, answers, packets, log file)
Get EDNS (Extension Mechanisms for DNS) settings
Get DNS over HTTPS (DoH) configuration (requires Windows Server 2025+)
Missing output schemas for all tools. Tool descriptions state what they retrieve (e.g., 'DNS server configuration', 'DNS query statistics') but do not document the fields, types, or structure of returned objects. LLMs cannot plan downstream operations or extract specific fields without knowing the response structure.
Parameter descriptions are missing or minimal. The input schema for dns_get_server_settings shows three parameters (server, serverId, credentialMode) with brief descriptions, but lacks details on valid formats, constraints, or when to use each. For example: Is serverId a Windows Server GUID? Can server be an FQDN or only an IP? What are valid credentialMode values (CurrentUser, NetworkService, etc.)?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
Get DNS forwarder configuration (IP addresses, use root hint, timeout)
Get Global Names Zone (GNZ) configuration
Get DNS recursion configuration (enabled, timeout, retries, secure response)
Get root hint servers (may be slow — up to 45s)
Get Response Rate Limiting (RRL) settings (responses/sec, errors/sec, window, prefix lengths)
List Response Rate Limiting (RRL) exception rules
Get DNS scavenging configuration (state, interval, refresh, no-refresh, last scavenge time)
Get DNS server configuration (round-robin, bind secondaries, listening IPs, version)
Get DNS server query statistics
Tool descriptions lack actionable context. Descriptions like 'Get DNS server query statistics' and 'Get DNS cache settings' are too terse (10 - 20 words). They do not explain WHEN the LLM should call each tool, what questions they answer, or dependencies. For example: 'Use dns_get_cache_settings to diagnose slow queries; run before dns_get_statistics to correlate cache hit rate with query load.' Dependencies like 'dns_get_root_hints may take up to 45s' are mentioned but buried in the tool name rather than the description.
No error handling guidance in tool descriptions. Descriptions do not state what happens if a server is unreachable, credentials are invalid, or a Windows Server version does not support a feature (e.g., DNS over HTTPS requires Windows Server 2025+). LLMs have no recovery guidance.
credentialMode parameter not enumerated. The parameter appears in 14 tools but has no enum constraint or valid value list in descriptions. Valid values might be 'CurrentUser', 'NetworkService', 'Explicit', etc., but LLMs must guess or the tool must validate at runtime.
Redundant parameter triplet (server, serverId, credentialMode) repeated across 14 tools. This suggests the server expects the same parameters for every query, but does not document which to use (server name vs serverId), whether they are mutually exclusive, or why both are needed. A composition pattern (e.g., connection context set once, then reused) would be cleaner.
Tool descriptions mention side effects or special behaviors inline (e.g., 'may be slow, up to 45s' for dns_get_root_hints, 'may be slow, up to 60s' for dns_export_server_config) without clear guidance on when the LLM should expect delays or how to handle timeouts. Should these tools be called asynchronously, or should the description recommend calling them only when necessary?