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 hard limits (200 terms, 20000 characters), the exact matching algorithm ('whole-word, longest term first, left to right, deterministic'), and output escaping ('XML-escaped'). Gaps remain around what happens when a lexicon entry supplies both ipa and alias (precedence), and what is emitted for an entry with only a term — behaviours that materially change output.

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 dense sentence that front-loads the operation, limits, matching rules and output form in a sensible order — little waste. It is a long run-on with a stray trailing comma, and the phrase 'Pronunciation lexicon to SSML phoneme and sub tags' partly restates the title before the real content begins.

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 stateless text-transform tool with no output schema and no annotations, the definition supplies the operation, both input limits, the matching semantics, the emitted markup and the escaping guarantee — everything needed to call it correctly and predict the result. The only omission is ipa/alias precedence, which is a narrow edge case.

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 50%; the two undocumented-in-schema parameters (text, lexicon) are exactly the two the description explains, adding meaning beyond maxLength by describing lexicon entries as 'each an IPA string or a spoken alias'. The other two parameters (lang, wrapSpeak) already have schema descriptions, though the description never mentions them, nor the caseSensitive default it implies via 'whole-word' matching.

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: 'Applies your pronunciation lexicon ... to a text ... and returns SSML 1.1' with the exact output form named ('<phoneme alphabet="ipa">' / '<sub alias>'). The scope is narrow and unambiguous enough that an agent can tell immediately whether this is the tool it needs.

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 a clear use context ('for an agent preparing text for a text-to-speech engine') and an explicit exclusion ('It does not guess pronunciations'), which tells the agent not to use it to derive pronunciations. It stops short of naming an alternative tool or saying what to do when a term has neither ipa nor alias, so no explicit routing is provided.

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