Morse code translator

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

Beyond the annotations, the description discloses important behavioral details: separator conventions, accent folding, skipped-character counting, accepted decode look-alikes, unknown-code substitution with '#', timing estimation via PARIS rules, and absence of audio. These are exactly the kind of edge cases an agent needs before invoking the tool.

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 front-loaded with the core purpose and then packs in useful edge cases efficiently. It is dense and slightly long, and the web-version link is not essential, but most clauses earn their place given the tool's formatting complexity.

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 tool without an output schema, the description explains the main return-relevant behaviors: encoding includes playing time, skipped characters are counted, and unknown decoded codes become '#'. It does not specify the exact response object shape, but it is complete enough for correct invocation and interpretation.

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?

Although schema coverage is already 100%, the description adds substantial meaning beyond the schema: it defines the expected text/Morse formats, word and letter separators, accent handling, skipped characters, decode look-alikes, unknown-code behavior, and the WPM timing formula. This materially helps an agent prepare correct inputs.

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 and resource: 'Translate text to International Morse code and back.' It immediately establishes bidirectional translation and later clarifies encode/decode/auto behavior, so the tool's role is unambiguous even among many generic text utilities.

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 explains encode, decode, and auto-mode behavior clearly, including what auto mode detects. It does not explicitly state when to choose this tool over alternatives or when not to use it, but no direct sibling alternative exists, so the context is still clear.

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