Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Technitium Safe MCP perform a DNS A lookup for example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A focused, read-only MCP server for bounded reachability checks and explicit DNS lookups against allowlisted Technitium DNS servers. Alpha: tests are synthetic; compatibility with a live Technitium deployment is not certified.
Requires Python 3.11+, uv, and dig.
uv sync --extra test
export TECHNITIUM_SAFE_SERVERS=primary=dns-primary.example.invalid
uv run technitium-safe-mcpThe process speaks MCP over stdio and does not load .env. Server aliases/hosts and probe ports are allowlisted configuration.
Related MCP server: unifi-safe-mcp
No Technitium API or mutation is exposed. Server count, port count/range, DNS names/types, subprocess duration, and output bytes are bounded. DNS names cannot begin with option syntax, and dig receives a fixed argument vector without a shell. Audit data is bounded but includes queried names; protect it accordingly. See security design.
uv run --extra test pytest
uv run python -m compileall -q src tests
uv buildMIT © 2026 Ben Gauger.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| server | No | primary | |
| record_type | No | A |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0dns_lookupserver_healthScored across 2 tools
The two tools, server_health and dns_lookup, have clearly distinct purposes: one checks server status, the other performs DNS resolution. There is no overlap or ambiguity between them.
Both tool names follow a consistent lowercase_with_underscores pattern, using noun compounds ('server_health', 'dns_lookup'). The style is uniform and predictable, though a verb_noun pattern is not used, consistency is maintained.
With only 2 tools, the server is at the borderline of being too thin. While the tools are functional, they represent a minimal surface that may not justify a standalone MCP server for meaningful use.
For a DNS-related server, the tool surface is severely incomplete. Only health checking and basic DNS lookup are provided, with no support for managing zones, records, DNSSEC, or other essential DNS operations. This leaves major gaps for any typical DNS administration workflow.
Signed internet telemetry, read-only: DNS, TLS, WHOIS, reachability. Every record Ed25519-signed.
Unlock the power of DNS lookups with our DNS Lookup service using Google DNS-over-HTTPS. Whether
DNS lookups, health reports, SSL certs, security scans, GEO scoring, uptime checks
Premium test server verified via DNS-TXT.
