hub

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantive behavior beyond them: it is a LOOKUP against cached words, hits return source=dictionary, misses return a single reconstruction flagged approximate=true, and coverage grows as words are cached. This is exactly the kind of outcome-shaping detail an agent needs.

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 lossy-romanization rationale and fallback behavior. Dense but efficient; the parenthetical asides are justified, though the em-dash nesting is slightly heavy.

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 needn't be explained, yet the description still conveys the source/approximate distinction that governs interpretation. For a single-parameter lookup tool, nothing material 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 100% and the parameter's own description already explains the lossy romanization and source values. The tool description adds only the 'several may match one ambiguous key' nuance, so it largely repeats the schema — baseline 3 is appropriate.

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 (find the real Old English word(s) whose ASCII spelling matches) and explicitly names its inverse, anglo_romanize, so the agent can distinguish it from that sibling without opening either schema.

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?

Clearly establishes the direction of use relative to anglo_romanize and explains the dictionary-vs-reconstruction outcome, giving strong context. It stops short of explicit when-not guidance or naming other alternatives, but the inverse framing is unambiguous.

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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely useful behavior beyond them: the return is Markdown plus structuredContent, and the agent must switch on result.category ('nominal' | 'verbal' | 'not_found') before reading the body. It also discloses the content source/license. It does not cover rate limits or failure/auth conditions, and part of the return-shape detail is already carried by the 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?

Front-loaded with the action, then the usage condition, then the return contract. Dense but every sentence carries distinct, load-bearing information with no filler.

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 two-param read tool with full schema coverage, annotations, and an output schema, the description supplies the routing condition and the category-switch consumption guidance. Nothing material an agent needs to call and consume 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 100%, so the baseline is 3, but the description adds real meaning by explaining that both parameters originate from a search result's 'inflection handle', which is not stated in the schema's per-field descriptions.

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 (Fetch) and resource (full declension/conjugation table for a lemma), and specifies the exact identifier pair (entry_id + word_class from a search result's inflection handle). It distinguishes itself from the sibling search tools by scoping itself to already-identified lemmas.

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?

Explicitly states the condition for use ('only when a search ran without inline forms or left a match un-expanded') and names the alternative behavior (a default search already returns tables inline). This is a textbook when/when-not routing statement to anglo_search.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description still adds value beyond them: it guarantees the output is always ASCII, names what is dropped (macrons, dotted ġ/ċ) and folded (þ/ð, æ, ƿ, œ), and rules out dictionary lookup or network calls.

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 the transform rule front-loaded and the constraint ('always ASCII') trailing; every clause earns its place. Minor waste from repeating the schema's own examples in the parenthetical.

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 annotations carry the safety/idempotency profile. The description covers what the transform does, which characters change, the direction of the mapping, and the constraints, leaving nothing an agent needs in order to invoke it correctly.

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?

With one parameter at 100% schema description coverage, the baseline is 3. The description largely restates the schema text (same þing→thing, wæter→waeter examples, same letter foldings) rather than adding syntax or format meaning the schema lacks.

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 ('Reduce Old English orthography to its primary ASCII spelling') and the worked examples (þing→thing, wæter→waeter) fix the direction of the transform, so an agent can tell it apart from the inverse sibling anglo_deromanize without opening either schema.

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 clear selection context: it is for 'an ASCII-keyboard downstream' and is a 'pure local transform: no dictionary lookup, no network', which implicitly steers lookup needs toward the search/deromanize siblings. It stops short of naming an explicit alternative or a when-not condition, so it falls just under the top band.

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?

Annotations already cover safety (readOnly/idempotent/non-destructive/openWorld), and the description adds substantial beyond-schema behavior: server-side caching, politely paced live upstream fetches, rate limiting with retry advice, automatic lemma resolution via cached paradigms, and licensing/provenance. This is exactly the extra context annotations cannot carry.

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 modes, then caching/rate-limit notes; every sentence carries information. Slightly verbose and somewhat duplicative of the schema's own parameter descriptions, but not padded.

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 read-only search with an output schema, the description covers return format (Markdown plus structuredContent matching outputSchema), mode behavior, caching, rate limits, and provenance. Nothing an agent needs 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: inflected queries resolve to a lemma, special letters become optional once paradigms are cached, multiword 'eng' queries work, and max_forms trades upstream fetches for latency. It stops short of full per-parameter detail but clearly exceeds 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?

States a specific verb (look up), resource (an Old English word on Wiktionary), and output (senses plus full declension/conjugation tables), and explicitly contrasts with the sibling anglo_get_inflections. An agent can distinguish it from anglo_get_inflections and anglo_romanize without opening any schema.

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 explicit mode selection (search_language='ang' vs 'eng'), states that include_forms=true avoids a follow-up anglo_get_inflections call, tells the agent to use include_forms=false for a cheap screen, and prescribes the retry behavior on rate-limit errors. When-to-use and alternatives are both covered.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds useful non-obvious behavior: the host field is for reference only and tools must still be called through this hub by their listed names.

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?

Three sentences, front-loaded with the resource and its contents, then the trigger, then the argument and host caveat. Dense but no sentence is filler.

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 still explains the shape of each entry (host) and how to act on the results. It fully equips an agent to call and use this 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 coverage is 100%, and both the enum values and the description are fully documented in the schema, so the description adds no parameter detail beyond it. It does clarify the meaning of the id as 'the prefix before the first underscore', which is marginal added value. Baseline 3 applies.

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 resource (an index of every Valksor dictionary reachable through the hub) and the exact content returned (current tool and prompt names). It is immediately distinguishable from every sibling, which are all language-prefixed research operations.

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 a clear trigger condition — call this to discover or re-check names, e.g. after an 'unknown tool'/'unknown prompt' error. It does not name alternative discovery paths, but for a hub index tool there is no real alternative to exclude.

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?

Annotations declare readOnly/idempotent, and the description adds value beyond them: the return contract (Markdown plus structuredContent {"result": <paradigm>}), the discriminator to switch on (result.category with its four values), and the important provenance caveat that tables are engine-generated rather than attested.

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?

Three tight sentences: purpose and handle sourcing first, then the gating condition, then the return contract. Dense but every clause carries information; the em-dash asides are mildly heavy but not wasteful.

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 two-param read tool with full schema coverage and an output schema, the description supplies exactly the missing pieces: the precondition for calling it, the structuredContent shape, and the category switch. Nothing an agent needs to invoke and interpret it is absent.

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 100%, so the baseline is 3, but the description adds meaning by framing the two parameters jointly as a 'search result's inflection handle' and implying both must come from the same search match. Field-level syntax (numeric id, class vocabulary) is left to 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?

States a specific verb and resource: fetch the declension/conjugation paradigm for a word keyed by a search result's inflection handle (entry_id + word_class). It is clearly distinct from interslavic_search, which produces those handles, and from the transliterate/romanize siblings.

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?

Explicitly constrains usage: 'Use this only when a search ran without inline forms or left a match un-expanded — a default search already returns each match's table inline.' This tells the agent both when to call it and when the sibling search already covers the need.

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?

Adds substantial context beyond the annotations: fully offline bundled snapshot, per-client-IP rate limiting, Markdown plus structuredContent output matching the outputSchema, inflected-form resolution to headword, and reverse English-gloss search. The annotations already establish read-only, idempotent, and closed-world behavior, and the description is fully consistent with them.

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-loads the core purpose and key behavior in the first paragraph, then gives terse operational and licensing notes. It is efficient for the tool's complexity, though the content-reuse licence sentence is metadata rather than invocation guidance.

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 the output schema covering return structure and annotations covering safety, the description supplies the remaining operational context: offline snapshot, rate limits, input form/script behavior, and search_language modes. This is complete enough for an agent to call correctly.

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 100%, so the schema already documents all four parameters in detail. The description reinforces query flexibility and search_language='eng' behavior, but adds no syntax or constraints beyond what the schema provides, so the baseline 3 is appropriate.

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: looking up an Interslavic word and returning its translation matrix plus declension/conjugation table. It clarifies scope and behavior for both query languages, but does not name nearby sibling interslavic_get_inflections in the main description to differentiate search from dedicated inflection retrieval.

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 implied as a dictionary search, and the description explains search_language='eng' vs default isv. However, it does not explicitly say when to prefer this tool over interslavic_get_inflections or the transliteration siblings, nor when not to use it. The include_forms parameter description mentions avoiding a follow-up call, but the main description lacks routing guidance.

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?

Annotations already declare readOnly, idempotent, non-open-world, non-destructive, so safety is covered. The description adds substantially beyond that: it discloses exact-lookup semantics (not guessing), that both spellings are stored per entry, and the failure mode (empty candidates for unknown words or ambiguous script). That failure-mode disclosure is exactly the kind of non-obvious behavior annotations cannot convey.

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-loads the core operation, then the bidirectional behavior, then the exact-lookup caveat and failure mode. Four sentences, each carrying distinct information with no repetition; the size is proportionate to a tool whose main risk is caller misuse (multi-word input, expecting guesses).

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?

Output schema exists, so return values need not be explained, and they aren't. For a 2-param read-only transliteration tool, the description covers input constraints, behavior, the override, and the failure mode, leaving no evident gap an agent would need to fill.

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 100%, so the schema documents both params, calling for a baseline of 3. The description adds value by defining `text` as ONE word (not a phrase, no tokenization) and by stating the edge-case return for `target` auto-detection, which goes beyond the schema's prose. It does not add further syntax detail for `target`, so not a 5.

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 (transliterate), resource (one Interslavic word), and scope (Latin↔Cyrillic, single word not phrase). The parenthetical '(not a phrase — the lookup does not tokenize)' and the explicit contrast with 'deromanize tools' sharply distinguish it from siblings like anglo_romanize and slavonic_transliterate.

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?

Explicitly states the auto-detect behavior and the `target` override condition ('or pass target to force it'). It also names the class of alternative it is NOT like ('the lossy deromanize tools') without naming a specific sibling, which is clear context but without a precise 'use X instead when Y' pointer.

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?

Beyond the readOnly/idempotent/openWorld annotations, it discloses the lossiness of romanization, the two distinct result modes (source=dictionary vs source=reconstruction, approximate=true), that reconstruction is a guess rather than attested, and that caching causes non-deterministic results over time. This is exactly the behavioral context annotations cannot carry.

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 and the inverse relationship to latgalian_romanize, then the lookup-vs-reconstruction behavior. Efficient, though the lossiness details slightly duplicate the parameter schema description.

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 and the annotations cover the safety profile, yet the description still conveys the essential return semantics (dictionary hit vs approximate reconstruction). Nothing an agent needs to call this 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?

With only one parameter and 100% schema description coverage, the schema already documents the input, its ASCII constraint, the multiple-match possibility, and the recovery limitations. The description restates this material rather than adding meaning beyond the schema, so the baseline 3 applies.

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 ('Find the real Latgalian word(s) whose romanization matches'), and explicitly positions itself as the inverse of the sibling `latgalian_romanize`. An agent can distinguish it from latgalian_search and latgalian_romanize without opening a schema.

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?

Explains the operating context clearly: it is a lookup against the dictionary cache, with reconstruction as fallback, and notes coverage grows so results may change. It does not explicitly say when to prefer a sibling such as latgalian_search over this tool, so it falls short of full when/when-not guidance.

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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real context beyond that: dual return format (Markdown plus structuredContent), the result.category discriminant ('nominal' | 'verbal' | 'not_found') to switch on before reading the body, and the CC BY-SA source provenance.

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-loads the action and scope, then the usage rule, then return details; every clause carries information. Slightly dense with stacked parentheticals, but no filler sentences.

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 an output schema present, the description needn't restate returns, yet it still points the agent to the result.category discriminant. Invocation, usage constraints, and return handling are all covered for a 2-param read-only 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 100% and both parameters are already documented in the schema. The description restates the entry_id + word_class pairing as an 'inflection handle' from a search result, which frames the concept but adds little beyond the schema's own descriptions.

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 (Fetch) and resource (declension/conjugation inflection tables) for a lemma identified via an entry_id + word_class handle. It also bounds scope explicitly (nominals vs verbs, positive AND negative), making it clearly distinct from the romanize/deromanize/search siblings.

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 an explicit when/when-not rule: use 'only when a search ran without inline forms or left a match un-expanded,' because 'a default search already returns each match's table inline.' It names the alternative (search) and the condition that routes to it.

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?

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so safety is covered. The description adds genuine behavioral context beyond that: it is a pure local transform, performs no dictionary lookup or network access, and always emits ASCII. It does not detail failure behavior on empty or unsupported input.

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 sentences, front-loaded with the purpose before the mechanics. Each sentence carries information (purpose, mapping pointer, return shape, execution profile), though the parenthetical examples are slightly redundant phrasing rather than new content.

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 the brief note about Markdown plus structuredContent is sufficient and return values need no elaboration. For a single-parameter, local, read-only transform the description covers purpose, execution profile, and output shape adequately; only edge-case behavior is left unstated.

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 100% and there is a single parameter, so the schema itself carries the semantics (including the full letter-mapping table). The description usefully points the agent to the `text` parameter doc, but adds no mapping detail of its own beyond what the schema already states.

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 a specific verb and resource (romanize Latgalian orthography to ASCII) and states the downstream consumer (TTS, search box), which is unusually concrete. It doesn't explicitly name or contrast with the sibling latgalian_deromanize, so the direction is only inferred from the verb. Clear, but short of full sibling differentiation.

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 a clear use case — converting Latgalian for an English-trained downstream such as voice/TTS or a search box — which tells the agent when this tool is appropriate. It stops short of stating exclusions or explicitly routing the agent to latgalian_deromanize for the inverse operation.

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?

Annotations already declare readOnly/idempotent/openWorld, and the description adds genuinely new behavior: server-side caching, polite upstream pacing, rate-limit errors with a retry instruction, automatic lemma resolution via cached paradigms, dual Markdown+structuredContent output, and a CC BY-SA attribution obligation.

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 result, and each sentence carries operational information. However, the 'eng' mode and caching behavior are explained in both the description and the schema, so there is some redundancy that slightly dilutes efficiency.

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 an output schema present, return values need not be re-explained; the description still covers caching, rate limits, retry guidance, licensing, and the lemma-resolution behavior. Nothing an agent needs 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 100%, so the schema already carries the parameter semantics; the description largely restates them. It adds only marginal detail, such as warning that high max_forms on cold queries is slow, which the schema also notes. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (look up) and resource (a Latgalian word on Wiktionary) and enumerates the return payload (senses plus declension/conjugation tables). It also distinguishes itself from sibling latgalian_get_inflections by noting that tables are returned inline so no follow-up call is needed.

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?

Explicitly documents the two modes via search_language ('ltg' direct lookup vs 'eng' reverse translation search) and when to prefer each. It names the alternative tool (latgalian_get_inflections) and gives a when-not condition (set include_forms=false for a cheap screen instead of pulling full tables).

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?

Annotations already declare readOnly/idempotent/openWorld/destructive=false, so the safety profile is covered. The description adds real behavioral value: the dual Markdown + structuredContent return and the instruction to switch on result.category ('nominal' | 'verbal' | 'not_found') before reading the body, plus the CC BY-SA attribution. Not a full 5 since the return shape is also declared in outputSchema.

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?

Strongly front-loaded: purpose, then usage constraint, then return/reading guidance. Every sentence carries weight, though the closing attribution adds a touch of length without aiding invocation.

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 annotations covering safety, an outputSchema covering the return shape, and 100% schema coverage on params, the description supplies everything else an agent needs: when to use it and how to interpret result.category. Nothing material 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 100%, so both parameters are already documented in the schema. The description reinforces that entry_id + word_class come from a search result's inflection handle but adds no syntax, format, or edge-case detail beyond the schema — baseline 3 applies.

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 ('Fetch the full declension... or conjugation... table for a lemma') and scopes it to the handle (entry_id + word_class). It clearly distinguishes the nominal vs verbal case, so an agent knows exactly what it retrieves.

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 explicitly states the condition to use it ('only when a search ran without inline forms or left a match un-expanded') and the condition not to ('a default search already returns each match's table inline'). This directly routes the agent relative to the latin_search sibling.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely new operational context: results are cached server-side and the analysis comes from an external Perseids Morpheus service. It also declares the return shape (Markdown + structuredContent). 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?

Front-loaded with the core action and the output contents, followed by the routing hint. Every sentence carries information (output shape, caching, service source), though the return-format and provenance sentences could be compressed.

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 an outputSchema present, the description need not explain return values, and it still notes Markdown + structuredContent. Annotations, a fully documented single param, and the external-service note leave little an agent needs missing; only the unaddressed latin_get_inflections alternative keeps it from being fully 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 100% and the single 'word' parameter is already well documented in the schema (examples, macron note, length bounds). The description only restates 'one inflected Latin form' and adds no syntax or format detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 a specific verb+resource (analyze one inflected Latin form) and enumerates the output (lemma(s) plus grammatical reading: person, number, tense, mood, voice, case). It explicitly carves out territory from latin_search. It does not address the latin_get_inflections sibling, which is the most overlapping tool, so sibling differentiation is incomplete.

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 states exactly when this tool is the right pick ('when you want the morphology itself') and names the alternative with the condition that selects it ('for the dictionary entry, latin_search already resolves inflected queries on its own'). This is explicit when-to-use plus a named alternative.

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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but the description goes well beyond them: server-side caching with politeness toward live upstream, rate limiting with retry guidance, automatic lemma resolution via cached paradigms or Morpheus, and a CC BY-SA 4.0 attribution/share-alike obligation. These are all operational facts an agent could not recover from the annotations or 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?

Front-loads the core action and return shape, then layers the eng-mode, resolution, caching/rate-limit and licensing details in descending order of importance. Every sentence carries information, but the caching/rate-limit/license block is dense enough that the definition reads longer than strictly needed for selection.

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 two-mode, cached, rate-limited tool with a declared output schema, the description covers the mode split, the lemma-resolution behavior, the fetch-cost model and the outgoing result format. Since an outputSchema exists, it correctly need not enumerate return fields, and nothing an agent needs 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 100%, so the schema already carries the full meaning of query, max_forms, include_forms and search_language, including the single-word constraint, macron optionality and the 0–12 table budget. The description restates the inflected-form-is-resolved behavior but adds no syntax or default detail the schema lacks. Baseline 3 is correct when the schema does the heavy lifting.

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 a Latin word up on Wiktionary and return its senses plus full declension/conjugation tables') and immediately qualifies it with 'attested content, not invented', telling the agent what class of result to expect. The eng-mode sentence extends rather than muddies the purpose. An agent can distinguish this lookup tool from a pure lemmatizer or inflection fetch without opening a schema.

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?

Clearly frames when each mode applies: any Latin form (including inflected) works and is auto-resolved to its lemma, while search_language='eng' reverses the direction to find Latin equivalents of an English word. It gives an operational caveat for rate-limit errors ('wait a few seconds and retry'). It never explicitly names latin_get_inflections or latin_lemmatize as alternatives, nor states when NOT to use this tool, so it falls short of a 5.

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?

Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely novel behavior: it is a cache lookup, misses yield a single approximate reconstruction ('a guess, not attested'), and coverage grows so an identical query may later return a dictionary hit. That volatility disclosure is exactly the kind of context structured fields cannot carry.

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-loads the core purpose, then layers in lookup semantics and the reconstruction caveat in logically ordered sentences. Dense but every sentence carries weight; minor tightening possible around the source=reconstruction explanation.

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 no explanation, yet the description still clarifies the source=dictionary vs source=reconstruction distinction and the approximate=true flag. For a one-parameter lookup with rich annotations, nothing an agent needs 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?

With a single parameter and 100% schema description coverage, the schema already documents format, length bounds, and the source/approximate return semantics. The description reinforces the inverse-direction framing but adds no syntax or format detail beyond what the schema provides, so the baseline 3 is appropriate.

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 ('Find the real Livonian word(s) whose pronunciation-romanization matches this clean-ASCII input') and explicitly frames itself as the inverse of `livonian_romanize`, which cleanly distinguishes it from that sibling.

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 clear context for when to reach for it (the reverse direction of romanize, resolving romanized input back to orthography). It does not, however, compare against the other siblings like `livonian_search`, so the routing guidance is good but not complete.

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?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses output modality (Markdown vs structuredContent), shape of both, table composition (case × number, mood/tense, negation auxiliary folding), and operational traits: server-side caching, rate limiting with a retry instruction, and CC BY-SA licensing. This is exactly the extra context annotations cannot carry.

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 purpose and the never-a-first-call warning before the return-format detail. Dense and mostly waste-free, though the second sentence restates the 'not a first call' point at some length and the output-format sentence is heavy with parentheticals.

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 two-parameter read tool with an output schema, annotations, and full schema coverage, the description covers everything an agent needs: provenance of the handle, fallback semantics, return shape, and error/rate-limit behavior. Nothing material 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 coverage is 100% and each parameter is already documented with examples, so the baseline is 3. The description adds the crucial provenance detail that both values come from a search result's inflection handle, tying the parameters to their only valid source.

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 (Fetch) and resource (full declension/conjugation table) and pins the input to a search result's inflection handle (entry_id + word_class). It is immediately distinguishable from livonian_search, livonian_romanize and livonian_deromanize.

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?

Explicitly states when to use it ('only when a search ran without inline forms, or to fetch a match a broad search left un-expanded') and when not to ('Never a first call', 'calling this afterwards just re-fetches what you have'). It also names the upstream tool that produces the handle, which is the alternative an agent might otherwise reach for.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value beyond them: it declares the transform is pure and local (no dictionary lookup, no network) and that output is always ASCII. It does not address edge behavior such as exceeding the 4000-char maxLength or non-Livonian input, which keeps it from a 5.

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?

Three sentences, front-loaded with the transformation, then the consumer, then the execution profile. Every sentence carries distinct information and nothing is redundant with the schema or annotations.

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 an outputSchema present and 100% parameter coverage, the description doesn't need to explain return values, and it correctly confines itself to purpose, audience, and the pure-local-transform contract. It is nearly complete; only failure/edge behavior (length overflow, non-Livonian characters) is left unstated.

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 100% and the `text` parameter doc already carries the full mapping table, so the schema does the heavy lifting. The description only cross-references that doc ('See the `text` parameter doc for the exact letter mappings') rather than adding new parameter semantics, which is the textbook baseline-3 case.

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: 'Strip Livonian orthography down to clean, pronounceable ASCII.' Combined with the direction of transformation (Livonian → ASCII), an agent can immediately separate this from livonian_deromanize, the inverse sibling, without opening a schema.

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 names the intended consumers ('an English-trained downstream (a voice/TTS, a search box)'), which implies when to reach for it. However, it never explicitly states when NOT to use it or names livonian_deromanize as the alternative for the reverse direction, so the routing guidance is only implied.

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?

Annotations already cover safety (readOnly/idempotent/non-destructive), yet the description adds substantial behavioral context beyond them: server-side caching, rate limiting with retry advice, truncation of inflection tables to handles on broad queries, and CC BY-SA licensing/attribution. Return shape (Markdown plus structuredContent) is also disclosed.

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 grounding rationale, and each sentence carries real information (default behavior, screening workflow, caching, licensing). Slightly long, and the parenthetical licensing/attribution note is tangential to tool invocation, but there is no filler.

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 an output schema declared, the description need not detail return values, yet it still tells the agent the format and that one call usually suffices. Combined with the caching/rate-limit guidance and sibling routing, an agent has everything needed to call this correctly on the first attempt.

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 100% so the baseline is 3, but the description adds cross-references to the query/search_language docs and explains the default inline-table behavior and its interaction with max_forms and include_forms, which the schema states only per-parameter. It stops short of restating query syntax itself, deferring to 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?

States a specific verb and resource ('Look a word up in the real Livonian–Estonian–Latvian dictionary') and defines the bidirectional scope: meaning→Livonian headword, or Livonian word→sense/POS/examples. It also distinguishes itself from the sibling livonian_get_inflections by naming it as the fallback for non-expanded tables.

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 when-to-use guidance, including the screening workflow ('set include_forms false ... to SCREEN several candidate words ... before spending forms on the one you pick') and the alternative for fetching remaining tables (livonian_get_inflections). It also covers the retry case on rate-limit errors.

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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered; the description adds genuinely new behavioral context: dual Markdown + structuredContent output, the {"result": <paradigm>} shape, the need to switch on result.category before reading the body, and source/license attribution. It stops short of noting rate limits or failure modes beyond not_found, but the additions are substantive.

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, then the usage constraint, then the return contract and license. Dense but every clause carries information; the parenthetical asides make it slightly harder to scan than a strictly linear sentence would be.

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 two-parameter read tool with full annotation coverage, a complete schema, and a declared output schema, the description supplies the missing link (how to obtain the handle, what the response category means). Nothing essential is absent.

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 100%, so the baseline is 3, but the description adds provenance meaning the schema lacks: both parameters come from a search result's 'inflection handle', tying entry_id/word_class to a prior tool call rather than leaving them as bare strings.

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 (fetch) and resource (declension/conjugation tables for a lemma), names the identifying inputs (entry_id + word_class), and covers both nominals and verbs including mediopassive. An agent can distinguish it from norse_search immediately.

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 when-to-use condition: 'Use this only when a search ran without inline forms or left a match un-expanded', plus the exclusion that a default search already returns tables inline. This routes the agent away from redundant calls.

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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, but the description adds substantial context they cannot: server-side caching, first-time upstream fetches with politeness pacing, rate limiting plus retry advice, and the attestation guarantee that content is real rather than invented. The CC BY-SA 4.0 attribution obligation is a genuine usage constraint worth disclosing.

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 purpose and the lemma-resolution behavior are front-loaded, and each sentence carries information (modes, caching, rate limits, licensing). It is dense and slightly long, but nothing is filler or tautological.

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 an output schema present, return values need not be spelled out, yet the description still notes Markdown plus structuredContent. Combined with both search modes, caching, rate-limit handling, and attribution, an agent has everything needed to invoke it correctly.

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 100% and the parameter descriptions already explain inflected-form resolution, optional diacritics once cached, the max_forms cost tradeoff, and the include_forms behavior. The prose largely restates this (any form works, lemma resolution is noted in the result), so it meets the baseline without adding much that the schema lacks.

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 precise verb and resource ('Look an Old Norse word up on Wiktionary') and names exactly what comes back ('senses plus full declension/conjugation tables'), including the reverse English-to-Old-Norse mode. It is clearly distinguishable from siblings such as norse_get_inflections, which it explicitly says it makes unnecessary.

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 states when to use each mode (search_language='non' vs 'eng'), when to turn include_forms off ('cheap screen of which entries exist') and why to leave it on ('no follow-up norse_get_inflections'). It also gives explicit recovery guidance for the rate-limit case ('wait a few seconds and retry').

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuine context: the return is Markdown plus structuredContent of shape {"result": <payload>} and the agent must branch on result.category ('descendants' | 'not_found'), plus a source/license note. Some of this overlaps the output schema, but the category-branching advice is actionable and not in the 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?

Purpose and the key routing constraint are front-loaded in the first two sentences, and the trailing sentences carry real payload-shape and licensing information. Sentences are dense and long, but each clause earns its place; no filler.

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 an output schema present, the description need not explain return values, yet it goes further by naming the result.category discriminant the caller must switch on. Parameter, safety, routing, and licensing concerns are all covered, leaving no gap for an agent.

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 100% and both parameters are already documented in detail, including the leading-asterisk tolerance and part-of-speech examples. The description only restates the composite 'descendant handle (entry_id + word_class)' concept, so baseline 3 is appropriate — no meaningful meaning is added beyond 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?

The description states a specific verb ('Fetch the full descendants payload') and resource (etymology, glosses, reflex tree for a lemma identified by a descendant handle). It explicitly distinguishes itself from the sibling scythian_search by noting that a default search already returns payloads inline, so an agent can route correctly without opening either schema.

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 an explicit when-to-use ('only when a search ran without inline payloads or left a match un-expanded') and a when-not ('a default search already returns each match's payload inline'). This is unambiguous routing guidance tied to the sibling tool's behavior.

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?

Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses server-side caching, politely paced live upstream fetches, rate limiting with an explicit retry-advice ('wait a few seconds and retry'), and the CC BY-SA 4.0 attribution obligation. It also explains the ASCII-to-diacritic folding behavior and that the result reports the resolution.

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-loads the core action and payload in the first sentence, then layers the eng-mode variant, output format, caching/rate-limit caveats, and license in short paragraphs. A few points (eng-mode lookup, descendants payload) restate schema material, but nothing is truly wasted.

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 an output schema present, the description needn't explain return values, and annotations already carry the safety profile; the description covers the remaining gaps an agent needs — caching, rate limits, retry, folding semantics, and licensing. Nothing required to call 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 coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning: it clarifies that search_language changes what the query word itself means (lemma vs English gloss) and that ASCII input is folded to the reconstruction's diacritics with the resolution echoed back. It does not touch max_forms, leaving that entirely to 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?

States a specific verb and resource ('Look a Proto-Scythian lemma up on Wiktionary') and precisely enumerates the payload (senses plus full descendants, etymology, reflex tree down to Ossetian and Khotanese). The scope ('the full descendants payload' in one call) implicitly separates it from the sibling scythian_get_descendants, which only pieces out part of that payload.

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 clear mode-selection guidance: default 'xsc' looks a reconstructed lemma up directly, while search_language='eng' reverses the lookup via gloss matching and returns matching lemmas plus expanded entries. It does not, however, name a when-not condition or explicitly route the agent to the sibling tool for a narrower fetch.

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?

Beyond the readOnly/idempotent/openWorld annotations, it discloses that this is a cache lookup rather than a computed inverse because transliteration is lossy, what each result source means (attested vs reconstructed), that reconstructions lack Glagolitic/liturgical marks, and that coverage grows over time (a repeated query may change tier). This is unusually rich behavioral context.

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 purpose and the inverse-relationship, then the failure-mode explanation. Dense but every sentence carries needed information; slightly long for a single-parameter 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 explained, and the description still covers the two result modes, their approximate flag, and the coverage-growth caveat, which is everything an agent needs to call it correctly.

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 100% and the parameter's own schema description already covers the lossy-recovery caveats and the multiple-match ambiguity, so the tool description adds little beyond structured data. Baseline 3 applies.

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+resource ('Find the real Church Slavonic word(s) whose scientific-Latin transliteration matches this input') and explicitly frames itself as the inverse of the sibling `slavonic_transliterate`, so an agent can distinguish it from `slavonic_search` and `slavonic_get_inflections` without opening a schema.

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?

Names the direction of use relative to the sibling transliterate tool and clearly describes the two outcome branches (dictionary hit vs failed lookup). It does not spell out explicit conditions for preferring any of the other siblings, but the context 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: the return medium (Markdown plus structuredContent), the discriminator to switch on (result.category of nominal/verbal/not_found) before reading the body, and the CC BY-SA 4.0 source of the content.

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, then the usage restriction, then the return contract; every sentence carries information. The trailing attribution line is boilerplate but justifiable for a CC BY-SA source, costing little.

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 an output schema present the description need not re-explain return values, yet it supplies the category discriminator and the inline-vs-explicit routing rule. Annotations, schema, and description together leave no gap for correct invocation of this two-parameter read 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 100% and both property descriptions already state that the values come from a search result's inflection handle, with examples. The description restates the same entry_id + word_class pairing without adding format, edge-case, or derivation detail beyond the schema, so the baseline of 3 applies.

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: fetch the full declension (nominals) or conjugation (verbs) table for a given lemma. It also scopes the input domain to a lemma identified by a search result's inflection handle (entry_id + word_class), which cleanly separates it from slavonic_search and the transliteration siblings.

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 an explicit when-not: 'Use this only when a search ran without inline forms or left a match un-expanded — a default search already returns each match's table inline.' That names the alternative behavior (inline tables from slavonic_search) and the exact condition that selects this tool.

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?

Annotations already declare readOnly/idempotent/openWorld/destructive, and the description adds substantial beyond-schema behavior: server-side caching, polite upstream pacing, rate-limit errors that should be retried after a wait, the Markdown + structuredContent return shape, and CC BY-SA attribution obligations. This is exactly the extra context annotations cannot carry.

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?

Core purpose and the two modes are front-loaded in the first sentence, and the caching/rate-limit/licensing caveats are correctly deferred to a second paragraph. The first paragraph is dense and slightly repetitive about inflection resolution, keeping it from a 5.

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 and the description correctly avoids re-explaining return fields, only noting Markdown plus structuredContent. Combined with the mode semantics, caching behavior and retry guidance, an agent has everything needed to call this correctly.

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 100%, so the schema already documents query, max_forms, include_forms and search_language thoroughly. The description restates the same mode semantics and inflection-resolution behavior rather than adding new parameter meaning, so baseline 3 applies.

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 (look up) and resource (Old Church Slavonic word on Wiktionary) plus the exact return payload (senses, declension/conjugation tables). It also distinguishes the two operating modes and names slavonic_get_inflections as the follow-up it makes unnecessary, so an agent can tell it apart from siblings.

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 explicit context for 'chu' vs 'eng' queries and states that include_forms=true means no follow-up call to slavonic_get_inflections is needed, which routes the agent well. It does not mention when to prefer the transliterate/detransliterate siblings, so it stops short of full when/when-not coverage.

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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely non-structured behavior: liturgical marks (titlos, accents, breathings) are dropped, late spellings are folded, and the transform is purely local with no dictionary lookup or network call, plus the response shape. It does not discuss limits such as the 4000-character cap or failure behavior on mixed-script input.

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 sentences, front-loaded with the verb and an illustrative example, then the transformation behavior, then the return format. Little waste, though the closing sentence about Markdown and structuredContent partially restates what the declared outputSchema already conveys.

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-parameter, deterministic local transform with an output schema and full annotation coverage, the description supplies everything needed to call it correctly: input scope, scripts accepted, preprocessing behavior, and side-effect freedom. The only gap is routing guidance among the sibling tools, which leaves a small ambiguity for an agent choosing between transliterate and detransliterate.

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 100% and the single 'text' parameter is already well documented, so the baseline is 3. The description goes slightly beyond the schema by showing an actual input-to-output mapping and confirming that both Cyrillic and Glagolitic scripts are accepted within the same argument.

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 (transliterate), a specific resource (Church Slavonic, Cyrillic or Glagolitic), and the target convention (scientific Latin as used by Wiktionary), with a concrete worked example (богъ → bogŭ). The directionality is explicit, which cleanly separates it from the slavonic_detransliterate sibling even without naming it.

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 gives an implicit use case — liturgical text copied from a source or lyrics sheet works as-is — but never states when to prefer this tool over slavonic_detransliterate or the search/inflection siblings, and offers no exclusions or prerequisites. Usage is inferable from the transformation direction rather than spelled out.

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