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

With no annotations, the description carries the burden. It discloses the important behavioral traits that this is a state-mutating operation and that confirm must be set after user consent, which is genuinely useful. It omits reversibility, interaction/precedence between minutes and enable, and any auth/permission requirements.

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 lines, front-loaded with the overall action, then one line per parameter, ending with the confirm rule. No filler. The terseness borders on leaving gaps, but every sentence earns its place.

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?

An output schema exists so return values need not be explained, and the param meanings are present. Still missing for a mutation tool with zero annotations: what the two modes do when combined, whether changes take effect immediately, and any scope/permission caveats.

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 0%, so the description must supply all param meaning. It does cover all three: minutes (pause duration), enable (permanent switch), and confirm (set true after asking the user). It adds no types/defaults/ranges, but the semantic intent of each parameter is clear.

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?

States a specific verb (turn on/off/pause) and a specific resource (ad blocking), with the three operating modes spelled out (temporary pause, permanent enable, permanent disable). It does not explicitly differentiate itself from siblings like technitium_settings_set, but the resource is unambiguous.

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 implies usage through the mode breakdown and adds a real workflow rule, 'Ask the user first, then set confirm=true.' However, it never states when to prefer this over sibling tools like technitium_settings_set, nor what happens if minutes and enable are supplied together.

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?

With no annotations, the description carries the full burden and does substantial work: it separates read from write behavior, defines a two-tier confirmation protocol, enumerates risky operation classes (delete, restore, import, port/listener changes, user disabling, password changes), and states the token is injected automatically and must not be passed. It omits error/refusal behavior when confirm is missing and says nothing about response truncation.

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 core purpose, then the confirmation model, then the discovery pointer. Sentences are dense but each adds a distinct constraint. The paragraph is slightly long and packs token/password handling into a trailing line rather than integrating it with the params discussion.

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?

An output schema exists, so return-value explanation is not required, and the description covers the two things an agent genuinely needs for a generic endpoint caller: the confirmation/auth model and where to look up per-endpoint parameters. The unaddressed max_chars parameter is the main incompleteness.

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 description coverage is 0%, so the description must compensate and it partially does: confirm, confirm_phrase, and params (via 'never guess parameters' and the endpoint_help pointer) are given real meaning. However max_chars is never mentioned, so truncation behavior is undocumented, and endpoint is only illustrated by example rather than explained.

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 states a specific verb and resource: calling any Technitium API endpoint, with a concrete example path (/api/dashboard/stats/get). It does not, however, distinguish this catch-all tool from the many dedicated siblings (technitium_stats, technitium_zones, technitium_blocking), so an agent has no explicit signal about when the generic caller is preferred over a purpose-built wrapper.

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 clear operative conditions: reads execute immediately, mutations require confirm=true plus user consent, and risky operations require confirm_phrase set to the exact path, with the risky categories enumerated. It also routes parameter discovery to technitium_endpoint_help. It stops short of saying when to use this tool versus the dedicated sibling tools, which is the one clear guidance gap.

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?

No annotations are provided, so the description carries the burden, but this is a low-risk read-only introspection tool whose behavior is largely implied by 'Show'. It does disclose what is returned (the parameter set for one endpoint), yet says nothing about error behavior for an unknown path or whether any prerequisites/auth apply.

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?

A single tight sentence with the purpose front-loaded and an inline example that earns its place. Nothing is wasted, though it is minimal to the point of leaving useful routing context unsaid.

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?

An output schema exists, so return-value detail is legitimately omitted, and the one parameter is simple. However, for a discovery tool sitting alongside technitium_endpoints and technitium_call, the description omits the routing context that would make it 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?

The schema coverage is 0% (the single 'path' parameter has no description), so the description must compensate. It does add real meaning by clarifying that 'path' is an endpoint API path and showing the expected format ('/api/settings/set'), but it stops short of stating whether a full URL, leading slash, or query string is accepted.

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?

States a specific verb and resource ('Show every parameter for one endpoint') plus a concrete example path, so the agent knows it is a per-endpoint introspection tool. It does not explicitly distinguish itself from the sibling technitium_endpoints (which presumably enumerates endpoints), so sibling differentiation is left implicit.

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 when-to-use statement, no mention of the obvious workflow (inspect with this tool, then invoke via technitium_call), and no comparison against technitium_endpoints. The example path hints at usage but no condition or alternative is stated.

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?

No annotations are provided, so the description carries the full burden, and it does disclose the meaningful safety-tier semantics ('read runs at once; change and destructive need the user's yes'), which is real behavioral context. It stops short of stating that this tool itself is a safe read-only lookup and says nothing about result size or pagination.

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?

Purpose is front-loaded in the first line, followed by tight per-parameter and safety notes with no filler. Every line earns its place, though the one-line-per-clause layout is slightly terse rather than fully integrated.

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 only two optional string parameters, an existing output schema (so return values need no explanation), and no annotations to reconcile, the description covers what an agent needs to invoke it. It is missing only explicit sibling routing, which is secondary for a simple discovery 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 description coverage is 0%, so the description must compensate and it does: both parameters are explained with what they match (path/title for query, group name for group) plus concrete examples. The only gap is that matching semantics (substring vs exact) and default/empty behavior are left implicit.

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 opens with a specific verb+resource ('Find Technitium API endpoints') and states the visible output (parameters and safety level), so the intent is unmistakable. It does not, however, explicitly distinguish this discovery tool from siblings like technitium_endpoint_help or technitium_call, so it falls short of a 5.

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 only implied: the agent can infer this is a search/lookup step done before invoking an endpoint, but there is no explicit when-to-use or routing to the alternatives (technitium_endpoint_help vs technitium_call). The examples for query/group help the invocation but not the selection decision.

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?

With no annotations, the description carries the full burden: it discloses that the flush is cache-wide and gated behind user confirmation, which are useful traits. However, it omits whether the action is reversible, its effect on in-flight/following queries, and any permission requirements for a state-changing operation.

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?

Two short sentences with no filler, and the destructive action plus its gating instruction are both front-loaded. Every clause earns its place.

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?

An output schema exists, so return values need not be described, and the single parameter is explained. For a destructive, annotation-free tool the description could say more about impact after flushing, but nothing needed to invoke it correctly is missing.

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 description coverage is 0%, so the schema alone leaves 'confirm' unexplained. The description compensates by defining both the workflow (ask the user) and the value to send (confirm=true), which is enough for an agent to set the single flag correctly.

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?

States a specific verb and resource ('Clear the whole DNS cache') with an explicit scope qualifier ('whole'), so an agent knows it is not a selective/per-zone purge. It does not differentiate from siblings, but none of the listed siblings is a competing cache-clear operation, so the differentiation gap is minor.

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?

'Ask the user first, then set confirm=true' gives a clear precondition for invocation. There is no need for when-not guidance or alternatives since no sibling performs an overlapping operation, so this is clear context without 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?

With no annotations, the description carries the full burden and does well: it discloses that list runs immediately without confirmation, that add requires confirm=true after user assent, that delete requires confirm=true plus the literal confirm_phrase '/api/zones/records/delete', and that ttl/preference are action- and type-scoped. It stops short of stating whether deletes are recoverable or what errors/return values look like.

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 action summary, then a scannable one-line-per-parameter block, then the confirmation workflow. No filler sentences; every line earns its place.

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 9-parameter multi-action tool with an output schema (so return values need no explanation), the description covers parameters, confirmation gating, and the delete-then-add update pattern. Minor gaps remain: it never states which params are required per action, and it doesn't point to technitium_endpoint_help for edge cases.

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 description coverage is 0% and there are 9 parameters, so the description must compensate entirely — and it does, defining action, zone, name, type (including the full enum list A/AAAA/CNAME/PTR/NS/TXT/MX/DNAME/ANAME, which the schema lacks), value, ttl, preference, confirm and confirm_phrase with formats and examples. This is meaning the agent cannot get from 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?

Opens with a specific verb triad plus resource: 'List, add or delete DNS records in a zone.' An agent can tell it operates on records rather than zones or endpoints, though it doesn't explicitly name sibling tools like technitium_zones. The three actions it multiplexes are enumerated, so the purpose is unambiguous.

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?

Gives concrete operational routing: 'To change a record, delete the old one and add the new one,' and ties confirm/confirm_phrase to add versus delete. It doesn't name alternative sibling tools or state when to prefer technitium_resolve or technitium_zones, but the intra-tool when-to-use guidance is clear.

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?

With no annotations, the description must carry the behavioral burden and does disclose two useful traits: 'It only reads' (read-only) and 'a cached answer can be returned' (stale-result caveat). However, it omits permission requirements, failure behavior for non-existent names (NXDOMAIN), and timeout/rate behavior.

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?

Short and front-loaded: purpose, then the server parameter, then behavioral caveats. The line breaks and sentence fragments are slightly choppy but nothing is padded or redundant.

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?

An output schema exists, so return values need not be described. Still, for a 3-parameter resolver with no annotations and 0% schema coverage, the description leaves the 'type' parameter and error semantics uncovered, so it is only minimally sufficient.

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 0%, so the description must compensate. It does well on 'server' (this-server default vs. an explicit DNS address) and gives an example value for 'name', but the 'type' parameter (default A) is never mentioned, leaving record types such as AAAA/MX/CNAME unexplained.

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?

States a specific verb and resource: 'Look up a name to test DNS', with a concrete example (ha.mogie.io). It is clearly a resolution/lookup tool, distinguishable in intent from siblings like technitium_flush_cache or technitium_blocking, though no sibling is named explicitly.

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?

Implies the use case ('to test DNS') and explains the default vs. alternate server choice, but gives no when-not guidance or explicit routing to alternative tools for related tasks (e.g. cache flushing after changing records).

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?

No annotations are provided, so the description carries the full burden. 'Read' implies a non-mutating operation, which is useful, but the description says nothing about the sensitivity of the returned data (server settings may include credentials/tokens), required permissions, or that no filtering is possible. For a zero-parameter getter this is adequate but thin.

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?

A single four-word sentence with no waste, and the purpose is front-loaded. It is efficient, though so terse that it borders on under-specification for a settings retrieval tool.

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?

An output schema exists, so return values need not be described, and with zero parameters the surface area is small. The only real gap is the absence of any usage context relative to settings_set, but the tool is simple enough that this is a minor omission.

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 tool takes no parameters and the schema has 100% description coverage, so there is nothing for the description to clarify. Baseline 4 applies for a parameterless tool.

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?

States a specific verb (Read) and resource (all server settings), making the operation immediately clear. It does not differentiate itself from the sibling technitium_settings_set or note its scope relative to other technitium_* tools, so it falls short of a 5.

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 when-to-use guidance, no mention of prerequisites, and no reference to the sibling technitium_settings_set or other alternatives. The agent must infer that this is the read counterpart to settings_set.

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?

With no annotations, the description carries the full burden and does so well: it discloses the two-stage confirmation gate, the exact confirm_phrase value for sensitive fields, and a read-before-write user-facing workflow. It stops short of stating whether changes are reversible or take effect immediately, but the destructive-risk surface is clearly gated.

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 core action and the partial-update rule, then the safety workflow. Every sentence carries a distinct instruction and none is filler, though the sequencing is dense and slightly run-on.

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 mutation tool with no annotations and an opaque free-form settings object, the description supplies the confirmation protocol, the sensitive-field escalation, and a discovery path for valid keys. An output schema exists so return values need no explanation. Remaining gap is the absence of any statement on effect timing or reversibility.

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 description coverage is 0%, so the description must compensate, and it does: confirm is tied to user approval, confirm_phrase is tied to a specific set of sensitive settings, and the settings object is illustrated with a concrete example plus a pointer to the help endpoint for valid names. The settings value space remains open-ended, which the help-endpoint pointer partially mitigates.

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?

States a specific verb and resource ('Change server settings') and clarifies the partial-update semantics ('Send only the settings that should change'), which is the key distinction from the sibling technitium_settings_get. It does not explicitly name the sibling it complements, but the operation is unambiguous.

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?

Explicit workflow: check names via technitium_endpoint_help on /api/settings/set, read settings first, tell the user what will change, then obtain confirm=true. It also names the elevated-risk settings (port, listener, DoH/TLS, recursion, forwarder) that require the confirm_phrase. Both when-to-use and prerequisites are stated.

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?

With no annotations provided, the description must carry the full behavioral burden. It implies a read-only retrieval of dashboard statistics but does not confirm read-only safety, mention permissions or rate limits, or describe any side effects. The behavioral profile is left largely to inference.

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 two short, front-loaded lines with no filler. The second line earns its place by enumerating period options, though the overall terseness leaves important usage context unaddressed.

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?

Given one simple parameter and an existing output schema, the description covers the core return content and valid period values. However, without annotations, it should do more to state the read-only nature and when to prefer this tool over siblings; it is adequate but not 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 description coverage is 0% and the sole 'period' parameter has no enum in the schema. The description compensates by listing the accepted values (LastHour, LastDay, LastWeek, LastMonth, LastYear), which is materially useful, though it omits the default value and any format details.

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 resource ('dashboard numbers') and lists categories (queries, blocked, cached, top charts), but uses a noun phrase rather than a specific verb like 'retrieve' or 'get'. It does not explicitly differentiate from siblings such as technitium_blocking or technitium_resolve, leaving purpose inferable but not crisply stated.

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?

No guidance is given on when to use this tool versus alternatives like technitium_endpoints or technitium_call. The period value list is parameter detail, not usage context, so the agent receives no routing help.

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?

No annotations are provided, so the description carries the full disclosure burden. It does reveal the dual listing behavior (zones vs records), a genuine trait beyond the schema, but says nothing about auth, limits, or output shape; the latter is partly excused by the existing output schema.

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?

Two short sentences, zero filler, and the primary purpose is front-loaded ahead of the conditional behavior. Nothing could be cut without losing meaning.

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 optional-parameter read tool with an output schema, the essentials are present. The main gap is the absence of any routing to the records sibling or note about name formatting, both minor for this complexity level.

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 description coverage is 0%, so the description must compensate, and it does explain the functional effect of supplying "zone" (switching the listing target). It does not give the expected name format or whether the value must match an existing zone exactly.

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 states a specific verb and resource ("List DNS zones") and clarifies the alternate mode when a zone is supplied. It implicitly separates itself from the sibling technitium_records, though it never names an alternative tool to make the routing explicit.

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?

"Give a zone name to list its records instead" tells the agent the condition under which behavior changes, which is effectively when-to-use-the-param guidance. It stops short of naming technitium_records or stating exclusions relative to other siblings.

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