Technitium MCP

by drmogie

Overview Schema Source Related Servers Discussions Admin

Python

Local

technitium_records

List, add, or delete DNS records in a zone, including A, AAAA, CNAME, MX, TXT, NS, PTR, DNAME, and ANAME entries.

Instructions

List, add or delete DNS records in a zone.

action: list, add or delete. zone: the zone name, for example mogie.io. name: the full record name, for example ha.mogie.io. Leave empty for the zone itself. type: A, AAAA, CNAME, PTR, NS, TXT, MX, DNAME or ANAME. value: the address or target (for MX, the mail server). ttl: seconds (add only). preference: MX only. list runs at once. add needs confirm=true after the user says yes. delete needs confirm=true and confirm_phrase "/api/zones/records/delete". To change a record, delete the old one and add the new one. server: which Technitium server, when this tool has several. list accepts "all". add and delete need one name. Zones belong on the cluster primary.

Input Schema

TableJSON Schema

Name	Required	Default
`ttl`	No
`name`	No
`type`	No	A
`zone`	Yes
`value`	No
`action`	Yes
`server`	No
`confirm`	No
`preference`	No
`confirm_phrase`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Oct 20, 2026
- addedInput schema / properties / server
```
Added value: +{
+  "default": "",
+  "title": "Server",
+  "type": "string"
+}
```
First observedv0.1.0Sep 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the safety burden and does so well: it discloses the confirmation requirement for add/delete, the exact delete confirmation phrase, the fact that deletion is the only way to change a record, and server constraints. It does not discuss permissions, reversibility, or error behavior, which keeps it below 5.

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 content is front-loaded by action and then parameter-like guidance, with no wasted sentences. The telegraphic line-per-field style is efficient for a 10-parameter tool, though slightly fragmented compared with a more cohesive prose description.

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?

An output schema exists, so return-value details are not required, and the description covers the multi-action workflow, mutation safety, and parameter meanings. It is complete enough for an agent to invoke correctly, though it could say more about what happens on partial failures or how list results are shaped.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for 10 parameters, and it does: action, zone, name, type, value, ttl, preference, server, confirm, and confirm_phrase all receive useful meaning beyond the schema. Examples and constraints such as MX preference and empty-name zone behavior are included.

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?

Starts with a specific verb set and resource: 'List, add or delete DNS records in a zone.' The action vocabulary is enumerated immediately, and the tool is clearly distinguishable from siblings like technitium_zones or technitium_resolve.

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?

Gives clear per-action guidance: list runs at once, add requires confirm after user approval, delete requires confirm and a specific confirm_phrase. It also explains that changes require delete-then-add and that server selection is constrained for add/delete. It does not explicitly route against sibling tools, but the action-level guidance is strong.

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

Deploy Server