Add Micro custom domain

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

Beyond annotations, the description discloses a non-obvious behavioral detail: the tool only registers the hostname and returns proof that the user must publish externally. The word “normalized” also hints at input processing. No contradiction with annotations.

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 tightly written sentence with no filler. Every phrase adds meaning: single hostname, normalization, DNS ownership proof, and the required publication step.

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?

The core operation is clear, but the description omits the relationship to micro_domain_verify and leaves “normalized” undefined. While schema and output schema cover some gaps, the DNS workflow context is incomplete for a tool sitting next to verify/remove siblings.

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 hostname parameter has no schema description, and the description partially compensates by saying “one normalized hostname.” However, it does not explain the required DNS format or constraints, and the optional path parameter is not mentioned in the description. With 50% schema coverage, this is only partial compensation.

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?

Uses a specific verb (“Register”), names the resource (“one normalized hostname”), and specifies the output (DNS ownership proof). This distinguishes it from related domain tools like micro_domain_verify and micro_domain_remove even though it does not name them.

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 when-to-use or when-not-to-use guidance and no mention of the related domain tools. “Must be published” hints at a follow-up step, but it does not say to use micro_domain_verify after publishing, nor when to prefer this tool over list/remove/verify.

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