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 already cover readOnly/openWorld/idempotent/destructive, so the safety profile is handled. The description adds real operational context: two return forms (Markdown + structuredContent), and instruction to switch on result.category ('nominal' | 'verbal' | 'not_found') before reading the body, which is non-obvious behavioral guidance beyond 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?

Front-loads the purpose, then the when-to-use constraint, then return shape, then license. Slightly dense (Gutenberg-era contested duals parenthetical), but every sentence carries information an agent needs. No waste.

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?

Despite having an output schema, the description still adds the category-switch guidance and the dual return medium, which are the non-obvious bits. Combined with full param coverage and clear use-condition, an agent has everything needed to call this correctly and to route to it versus anglo_search.

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% — both entry_id and word_class are documented in the schema with examples and (for word_class) a full enum. The description restates 'entry_id + word_class' without adding format/syntax meaning beyond the schema, so 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 (fetch) and resource (declension/conjugation table for a lemma identified via inflection handle), and enumerates what the table covers (nominals incl. pronouns' dual, verbs). Distinguishes itself from anglo_search by requiring an inflection handle rather than a query.

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 says '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 is a clear when-to-use/when-not-to-use discriminator against the sibling 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 declare readOnly/openWorld/idempotent/non-destructive, yet the description adds substantial context beyond them: server-side caching, politely paced live upstream fetches, rate limiting with retry advice, automatic lemma resolution via cached paradigms, and CC BY-SA licensing/attribution requirements. That is exactly the behavioral detail 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 scope, then tiers into eng-mode, return shape, caching/rate-limit, and license. Efficient overall, though the return-format sentence partly duplicates the output schema and could be trimmed.

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 lookup tool with an output schema (so return values needn't be explained), the description covers both query modes, form expansion, caching, rate limits, and licensing. An agent has everything needed to call it and interpret failures 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 schema descriptions are themselves very detailed, restating the any-form/lemma-resolution and eng-mode semantics. The description adds little beyond what the schema already provides, 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 (look up) and resource (an Old English word on Wiktionary) and immediately names its output (senses plus declension/conjugation tables). It also distinguishes itself from the sibling anglo_get_inflections by noting no follow-up call is needed, so an agent can tell the tools apart 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?

Gives clear usage context: any inflected form resolves to its lemma, search_language='eng' switches to reverse lookup, and include_forms=false is the cheap screen. It cites the anglo_get_inflections alternative implicitly, but does not explicitly say when NOT to use this tool versus the other anglo_* or *_search siblings.

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 already cover the safety profile (readOnly, idempotent, openWorld=false, non-destructive), and the description adds genuine context beyond them: the provenance caveat that tables come from the official morphology engine and are 'not attested', plus guidance to switch on result.category before reading the body. Return-shape detail partially overlaps the existing output schema, so this stops short of 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?

Four tight sentences, front-loaded with the action and immediately followed by the exclusion condition. No filler, and the return-shape/category caveat is placed after the routing guidance where it is needed.

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 rich annotations, a full output schema, and 100% parameter description coverage, the description supplies everything an agent needs to decide to call it and how to interpret the response. 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%, so both parameters are already documented individually; the baseline would be 3. The description adds a small but real layer by framing entry_id + word_class jointly as the 'inflection handle' from a search result, telling the agent the two values are consumed as a pair rather than independently.

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 ('Fetch the full declension (noun/adjective) or conjugation (verb) table') and scopes it to a word identified by a search result's inflection handle. It is clearly distinguishable from the sibling interslavic_search, which produces those handles.

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-not guidance is given: '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.' The agent is told both the trigger and the reason the tool is usually unnecessary, which is exactly the routing information needed.

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 offline bundled snapshot behavior, per-client-IP rate limiting, source attribution/licensing caveat, inflected-query resolution noting, and that results come as both Markdown and structuredContent. This is exactly the value-add layer 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, then behavior, then operational constraints; each sentence contributes. Slightly dense and repeats some search_language detail already in the schema, but no wasted 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 only signal the return shape, which it does (Markdown + structuredContent). Combined with rate-limit, offline, and licensing notes, an agent has everything needed 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%, so the baseline is 3; the description still adds operational meaning — that 'eng' returns Interslavic equivalents with expanded entries, and that include_forms governs expanded entries for eng queries. It largely restates the schema's enum semantics, but the cheap-screen guidance for include_forms is genuine added value.

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 ('Look an Interslavic word up in the bundled community dictionary') plus the scope of the return value (translation matrix + full inflection table). It also distinguishes its behavior from siblings by ruling out a follow-up call to interslavic_get_inflections.

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 conditions are given: any form and either script resolves; search_language='eng' switches to reverse lookup; include_forms=false gives a cheap existence screen; max_forms adjusts the per-call cap. It also names the alternative (interslavic_get_inflections) and states it is unnecessary by default.

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, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the return format (Markdown plus structuredContent), the need to switch on result.category ('nominal' | 'verbal' | 'not_found') before reading the body, and the CC BY-SA 4.0 source. Slight redundancy with the declared outputSchema 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?

Front-loaded with the core action and scope, and every sentence carries information (scope, output shape, category switch, license). The nested parentheticals make it dense but not wasteful; it could be marginally tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description need not explain returns, yet it usefully highlights the category discriminator and the Markdown/structuredContent duality. With both params documented and safety covered by annotations, an agent has everything needed 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 both parameters are well documented in the schema, so the baseline is 3. The description adds meaning by framing entry_id + word_class as an 'inflection handle' sourced from a search result, giving provenance for the values that the schema alone does not fully convey.

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') plus the exact resource (full declension for nominals, conjugation for verbs, positive and negative) for a lemma identified by a search result's inflection handle. It also implicitly distinguishes itself from latgalian_search by noting the search's inline-form behavior, so an agent can tell the two apart.

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 scopes when to use it ('only when a search ran without inline forms or left a match un-expanded') and when not to (a default search already returns each match's table inline). This is a clear when/when-not statement rather than an implied usage.

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?

Beyond the readOnly/idempotent/openWorld annotations, it discloses server-side caching, live-upstream pacing, rate limiting with retry guidance, the CC BY-SA 4.0 attribution obligation, and that output is Markdown plus structuredContent. This is unusually complete 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-loads the core behavior (lookup + tables) before the eng-mode and caching details, and every sentence carries information. It is dense and slightly long, 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?

With an output schema present and annotations covering the safety profile, the description still supplies everything an agent needs: modes, caching, rate-limit handling, licensing, and the relationship to the sibling inflection 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% so the baseline is 3, but the description adds semantics the schema doesn't stress: that diacritics are optional once a paradigm is cached and that eng queries accept multiword entries. It also ties max_forms/rate-limit cost together rather than just restating 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) and resource (Latgalian word on Wiktionary), plus two distinct modes (ltg direct lookup, eng reverse translation). It explicitly distinguishes itself from the sibling latgalian_get_inflections by noting forms come inline in one call.

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: any inflected form works, eng mode for reverse lookup, include_forms=false for a cheap existence screen, and max_forms for per-call expansion. It also names the alternative workflow (no follow-up latgalian_get_inflections) and prescribes retry behavior 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/non-destructive/openWorld, so safety is covered. The description adds real behavioral context beyond that: the not_found case and the need to switch on result.category before reading the body, plus the Wiktionary source/license. It omits any rate-limit or caching behavior, keeping it short of 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?

Front-loaded with the core action and the when-to-use caveat; every clause carries information. The final attribution line is required but the middle sentences are dense and could be tightened slightly.

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 restate return values, yet it still gives the consumption pattern (switch on result.category) and the not_found branch. Combined with annotations covering the safety profile, nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds provenance semantics beyond the schema by defining the pair as a 'search result's inflection handle (entry_id + word_class)', telling the agent where the values come from rather than just their types.

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/conjugation table) and clarifies the nominal-vs-verbal split, so the agent knows exactly what it returns. It is clearly distinguishable from latin_search and latin_lemmatize among its 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 says when NOT to use it: '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 routes the agent away from redundant calls without inference.

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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description goes beyond them by disclosing the return shape (Markdown plus structuredContent matching the outputSchema), server-side caching, and the backing service (Perseids Morpheus). It does not mention rate limits, failure modes for unknown forms, or ambiguity handling.

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 core action before the routing note, the return format, and the caching detail. Every sentence carries information; the ellipsis in '(person, number, tense, mood, voice, case…)' is slightly loose 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?

With a rich output schema and full annotations, the description only needs to cover the purpose, routing, and any non-structured behavior — it does all three (return format, caching, backend service). The only gap is behavior on invalid or ambiguous forms, which an agent might still want to know.

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%: the schema documents the single 'word' parameter with a regex pattern, length bounds, examples and a note that macrons are optional. The description adds only the generic phrase 'one inflected Latin form', which does not go 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?

The description names a specific action and resource: analyze a single inflected Latin form to produce lemma(s) plus a grammatical reading, and it lists the reading components (person, number, tense, mood, voice, case). It clearly differentiates itself from latin_search, but says nothing about latin_get_inflections, which is arguably the more confusable sibling given the name mismatch (lemmatize vs. get_inflections).

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 the tool ('when you want the morphology itself') and names an explicit alternative plus the condition that selects it ('for the dictionary entry, latin_search already resolves inflected queries on its own'). No exclusion is given relative to latin_get_inflections, so the routing guidance is good but not exhaustive.

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, and the description adds substantial context beyond them: server-side caching, polite paced live upstream fetches on cold queries, an explicit rate-limit retry instruction ('wait a few seconds and retry'), and CC BY-SA 4.0 attribution obligations. That is exactly the extra behavioral context annotations do not 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 action and return shape, then layers mode behavior, caching/rate-limit notes and licensing. Dense but every sentence adds operational value; the third paragraph is slightly long but earns its place with the retry and attribution 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?

An output schema exists so return values need not be explained, yet the description still notes Markdown plus matching structuredContent. Combined with caching, rate-limit handling, license terms and both search modes, an agent has everything needed to call this correctly and interpret failures.

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: macrons are optional ('amo'/'amō'), inflected forms resolve to a lemma and the result names it via search_method/resolved_lemma, and max_forms is tied to per-table upstream fetches on cold queries. These go beyond the schema's field-level text.

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 — look a Latin word up on Wiktionary and return senses plus full declension/conjugation tables — and explicitly scopes it as 'attested, not invented'. It also covers the reverse English→Latin mode, distinguishing it from siblings like latin_get_inflections and latin_lemmatize which it implicitly supersedes (automatic lemma resolution, inline paradigms).

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 conditional guidance: include_forms=false for a cheap existence screen, max_forms to bound expansion, and search_language='eng' for reverse lookup. It names latin_get_inflections as the alternative a follow-up would otherwise require. It stops short of explicit when-not-to-use conditions against siblings like latin_lemmatize.

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?

Goes well beyond the annotations by disclosing return shape (Markdown tables per word class, not-found message), server-side caching, rate limiting with retry guidance, license/attribution requirements, and label normalization. The annotations already cover read-only/idempotent safety, so this adds genuinely new operational 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 core action and the negative guidance, then moves to return format and operational notes. Dense but every sentence carries usable information; the parenthetical license and normalization notes are slightly parenthetical clutter but still earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't restate the return contract, yet it usefully bridges it by naming result.category values ('nominal' | 'verbal' | 'not_found') to switch on. Prerequisite, non-first-call constraint, failure behavior, and rate limits are all covered.

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 description still adds provenance: both params come from a search result's 'inflection handle' and must be passed together, which is meaning the schema alone doesn't convey. It does not restate the accepted digit-string or enum codes, so it stays complementary rather than duplicative.

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 table) and pins the scope precisely: 'the exact case, number, tense, not a guessed ending.' It is clearly distinguishable from livonian_search, which produces the handle this tool consumes.

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 ('only when a search ran without inline forms, or to fetch a match a broad search left un-expanded'), explicit when-not ('Never a first call', 'calling this afterwards just re-fetches what you have'), and it names the prerequisite source (livonian_search results) for the handle values.

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 read-only/idempotent/open-world safety, but the description adds substantial behavior beyond them: server-side caching (repeat queries free), upstream rate limiting with explicit retry-after-a-few-seconds guidance rather than immediate re-issue, sequential polite pacing on cold broad queries, and CC BY-SA attribution. Return format (Markdown plus structuredContent per outputSchema) 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 purpose and grounded-content guarantee, then usage, then cost/rate behavior. Dense and mostly waste-free, though it partially restates the schema's own include_forms/max_forms wording and is longer than strictly necessary for an agent that still must open the parameter docs.

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 enumerate return fields, and it still tells the agent the two output forms, the caching/rate-limit lifecycle, the fallback tool for unexpanded tables, and the licensing constraint. Nothing material for correct invocation 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 the description defers to the parameter docs, but it still adds real semantics the schema alone wouldn't convey: why queries must be a single content word, that the dictionary matches one attested lemma so phrases silently fail, that matching is bidirectional, and that inflected Livonian forms auto-resolve to a lemma with a signal in the result. The max_forms 'limits upstream fan-out, not just response size' note likewise explains the cost tradeoff.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — look up a word in the real Livonian–Estonian–Latvian dictionary and return attested content. It also clarifies the bidirectional capability (meaning→headword, Livonian word→sense/POS/examples), which cleanly separates it from livonian_get_inflections, anglo_search, and other sibling lexicons.

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 when one call suffices (full inflection tables returned inline by default) and names the alternative for the remaining cases (handles fetched later via livonian_get_inflections). It also gives a concrete screening strategy — set include_forms=false to check several candidates cheaply before spending forms on one.

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). Beyond that, the description discloses the return surface (Markdown plus structuredContent) and the not_found outcome the agent must branch on, which is genuinely useful behavioral context 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?

Front-loads the action, then the gating condition, then the return shape — a sensible order. It is dense with parenthetical asides and the license line is arguably marginal, but no sentence is 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?

Given an outputSchema exists, the description need not explain return values, yet it briefly flags the category switch agent should branch on. Combined with the usage gate and parameter provenance, 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%, so the baseline is 3, but the description adds provenance semantics the schema lacks: entry_id + word_class come as a pair from a search result's inflection handle and must be used together. It doesn't document enum values or the pattern beyond what the schema already gives.

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?

Names a specific verb (fetch) and resource (full declension/conjugation tables) and specifies the exact key (a search result's inflection handle) needed to identify the target. It is clearly a follow-up to the norse_search sibling, so an agent can tell which tool owns the lookup vs. which owns the table.

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?

States an explicit when-to-use and when-NOT-to-use rule: call this only when a search ran without inline forms or left a match un-expanded, because a default search already returns the table inline. That routing condition is exactly what an agent needs to avoid 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?

Beyond the annotations (readOnly/idempotent/openWorld/destructive=false), the description discloses server-side caching, polite paced upstream fetches with rate limiting and retry advice, lemma-resolution behavior for inflected queries, and CC BY-SA 4.0 attribution obligations. These are exactly the operational traits an agent cannot infer from structured fields.

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 layered with mode, caching and licensing details, so an agent can stop reading once it has what it needs. It is somewhat long and the license/attribution sentence, while useful, is the least essential element.

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 spelled out; the description nonetheless notes Markdown plus structuredContent. Combined with mode switching, caching, rate-limit and resolution behavior, nothing an agent needs to invoke 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?

Schema description coverage is 100%, so all four parameters are already documented in the schema and baseline is 3. The description reinforces some semantics (inflected queries resolved to lemma via cached paradigms, eng-mode translation blocks) but adds little that isn't already in the parameter 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?

The description opens with a specific verb+resource and scope: 'Look an Old Norse word up on Wiktionary and return its senses plus full declension/conjugation tables', then qualifies the content as attested and the coverage as including mediopassive voice. It also carves out the 'eng' reverse-lookup mode, so an agent understands both behaviors of the tool without opening the 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?

Clear context is given for the two modes ('With search_language=\'eng\' the query is an English word instead') plus operational guidance on caching/rate limits ('on a rate-limit error, wait a few seconds and retry'). What is missing is an explicit when-to-use/when-not statement against the sibling norse_get_inflections (the 'no follow-up' note lives only in the include_forms param text, not the main description).

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), so the bar is lower. The description adds substantial context: return format (Markdown + structuredContent), response shape, the result.category switch ('descendants'|'not_found'), and licensing. Missing explicit auth/rate-limit notes, keeping it just below top.

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 purpose, then usage constraint, then return shape. Every sentence earns its place. Slightly dense but no filler; could be marginally tighter.

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 2-param read tool with an output schema, annotations, and 100% schema coverage, the description covers provenance, use conditions, return shape, and the category discriminator. Nothing an agent needs 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 baseline is 3, but the description adds genuine meaning: it clarifies that entry_id + word_class come from a 'search result's descendant handle', which ties the parameters to their provenance beyond the schema's field-level docs.

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 ('Fetch the full descendants payload') and enumerates what it contains (etymology, glosses, reflex tree). Clearly distinguishes itself from the sibling scythian_search by naming search results as the input handle source.

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 payloads or left a match un-expanded') and when not to ('a default search already returns each match's payload inline'). This is exactly the routing guidance an agent needs.

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 readOnly/idempotent/non-destructive/openWorld, and the description still adds real operational context: server-side caching, live upstream fetches on first-time queries with proactive politeness pacing, rate limiting with a concrete retry instruction, and the CC BY-SA 4.0 attribution obligation. That is substantive disclosure beyond what structured fields provide.

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 direct-lookup default are front-loaded, and each following sentence carries a distinct payload (eng mode, return format, caching/rate limits, license). It is dense and somewhat prosey — the etymology/reflex-tree clause repeats the schema's own wording — but nothing 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 values need not be explained, and the description still covers what an agent needs before calling: both query-language modes, folding behavior for ASCII input, caching and rate-limit backoff, and licensing constraints on reuse. Nothing material is missing for a read-only, open-world search 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%, so the schema already documents query, search_language, max_forms, and include_forms in detail. The description restates the ASCII-folding behavior ('tigri' finds *tiɣri') and both lookup modes, which is useful framing but largely repeats schema text rather than adding new semantics, so it sits at the baseline.

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 first sentence names a specific verb and resource ('Look a Proto-Scythian lemma up on Wiktionary') and specifies exactly what comes back (senses plus the full descendants payload down to Ossetian and Khotanese). It also flags the second mode (search_language='eng' reverse lookup) and explicitly names the sibling it replaces the need for ('no follow-up scythian_get_descendants'), so an agent can separate it from the other *_search tools.

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 the alternate mode applies ('With search_language=eng the query is an English word instead'), when the cheap path applies, and what to do on a rate-limit error (wait a few seconds and retry). It stops short of saying when to prefer this tool over the parallel language search tools or when to call scythian_get_descendants directly, so routing between siblings is only partly 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?

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 readOnlyHint/idempotentHint/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely non-annotated behavior: the return format (Markdown plus structuredContent), the {'result': <paradigm>} shape, and the instruction to branch on result.category ('nominal' | 'verbal' | 'not_found') before reading the body. It loses a point only because part of the return detail is restated from the declared 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 core purpose, followed by usage constraint, then return handling and license. Every sentence carries information and the ordering is logical; it is slightly dense 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?

With an output schema present the description need not detail return values, yet it usefully flags the category switch and not_found case, covers when to invoke, and includes attribution/licensing. 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?

Schema description coverage is 100%, and the schema already explains both entry_id (Wiktionary page title / Cyrillic lemma from the inflection handle) and word_class (part-of-speech section). The description only restates the parameters as an 'inflection handle (entry_id + word_class)' pairing, adding little beyond the schema. 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 and resource ('Fetch the full declension (nominals) or conjugation (verbs) table for a lemma'), and distinguishes the tool from its search siblings by noting that a default search already returns tables inline. An agent can tell exactly what it retrieves and when it differs from slavonic_search 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 an explicit when-to-use ('only when a search ran without inline forms or left a match un-expanded') and a when-not ('a default search already returns each match's table inline'). It also states the prerequisite source of the inputs (a search result's inflection handle), so the agent knows this is a second-step tool, not a first entry point.

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 annotations (readOnly/openWorld/idempotent), disclosing server-side caching, polite paced upstream fetches, rate limiting with a concrete recovery ('wait a few seconds and retry'), and CC BY-SA 4.0 attribution obligations. These are real operational traits an agent could not infer from structured fields.

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 then the eng-mode variant, caching/rate-limit notes, and licensing. Dense but every sentence carries information an agent needs — the only mild bloat is restating the eng-mode behavior that also appears in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is unnecessary; the description instead covers modes, caching, error recovery, and licensing. For a 4-param lookup tool with rich annotations and an output schema, nothing an agent needs 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 description coverage is 100%, so the schema already documents all four parameters thoroughly (including max_forms pacing and include_forms semantics). The description reinforces search_language='eng' behavior and the lemma-resolution guarantee but adds little syntax or meaning the schema lacks; 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+resource ('Look an Old Church Slavonic word up on Wiktionary') and names exactly what it returns: senses plus full declension/conjugation tables. It also distinguishes itself from the sibling slavonic_get_inflections by noting tables come back INLINE with 'no follow-up slavonic_get_inflections.'

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: any inflected form works and resolves to a lemma, and search_language='eng' switches to reverse lookup. It also advises include_forms=false for 'a cheap screen of which entries exist.' However it never explicitly states when to prefer the sibling slavonic_get_inflections or slavonic_transliterate, so the routing guidance is implicit rather than 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?

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.