Language assistant for Slovenian, Croatian and Serbian languages. Checking phrase correctness, ortography check (Slovenian only), text simplification, word forms, similar words, ...
Scored across 9 tools
The three text-oriented tools (check_orthography, check_text, normalize_text) could initially be confused, but the descriptions draw clear boundaries: rule-based punctuation/capitalization findings vs. lexical evidence of misspellings/repetition vs. returning normalized text with a change log. There is residual overlap (missing diacritics appears in both check_text and normalize_text, and unnatural verb+noun pairs is an option in check_text that duplicates check_pairing), and lookup_word vs. get_forms requires reading carefully to separate lexicon lookup from inflection tables.
All nine tools use snake_case with a leading verb (check_*, explain_rule, find_expression, get_forms, lookup_word, normalize_text, suggest_replacements), a fully predictable pattern. The verb choices are meaningfully varied rather than sloppy, so an agent can guess the shape of a name before reading its description.
Nine tools is well within the sweet spot and each covers a distinct language-service capability (rule checking, lexical checking, normalization, inflection, lookup, idioms, replacements, rule explanation, collocation). No tool looks like filler or a redundant wrapper around another.
The surface covers a coherent lifecycle for language assistance: analyse text, justify with rules, normalize, look up words, inflect, find idioms, and substitute words. The main gaps are explicit scope limits rather than omissions — grammar/agreement and comma-after-embedded-clause are declared unchecked, and there is no cross-lingual lookup/translation tool despite the server spanning Slovenian, Croatian and Serbian.
Slovenian only. Orthography findings after Slovenski pravopis 2001, each with the rule's
§ number, a paraphrase of the rule, the text, a suggested replacement and character offsets:
commas before subordinate and adversative clauses, ne + verb written apart, words written
together or apart, s/z and k/h, capitals, spacing around punctuation, dashes, dates,
abbreviations. kind says how sure a finding is: mechanical (the rule decides), heuristic
(usually right), lexical (decided from the lexicon and corpus counts). Not checked: comma
after an embedded clause, grammar, loanword spelling.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Slovenian text, up to 20,000 characters | |
| rules | No | Rule ids to apply (see explain_rule); default: the rules measured reliable |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered; the description adds genuinely new behavioral context: the confidence taxonomy (mechanical vs heuristic vs lexical, with lexical decided from lexicon and corpus counts) and the coverage limits. It also previews the shape of a finding (rule §, paraphrase, text, replacement, offsets), which is somewhat redundant with the existing 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 hard constraint ('Slovenian only') followed by the rule source and the finding shape; every clause carries information. The dense semicolon-chained enumeration is efficient but costs a little parseability, so not 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?
For a two-parameter, read-only tool with an output schema and full schema coverage, the description supplies exactly the missing pieces: language precondition, rule authority, confidence semantics, and explicit non-coverage. An agent can decide whether to call it and interpret results without further documentation.
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%: `text` (Slovenian, ≤20,000 chars) and `rules` (ids, default = rules measured reliable, see explain_rule) are both documented in the schema. The description adds no syntax or format detail beyond that, 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 resource (orthography findings) with an explicit authority (Slovenski pravopis 2001) and enumerates the phenomena covered — commas, ne + verb, s/z and k/h, capitals, spacing, dashes, dates, abbreviations. The 'Not checked' list (embedded-clause commas, grammar, loanword spelling) further sharpens the boundary, though no sibling tool (check_text, check_pairing) is named directly.
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?
'Slovenian only' sets a hard precondition and the closing 'Not checked' sentence tells the agent when this tool will not answer. The `rules` parameter description routes to explain_rule for rule ids, giving one concrete alternative path. It never explicitly says which sibling to use instead for grammar or embedded-clause commas, so it stops short of full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is a word pairing natural? For a two-word phrase: whether the corpus pairs them, how
strongly, and the words that usually take each one's place (napraviti odluku ->
donijeti). For one word: its usual partners. Catches word-for-word translations.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | Yes | sl Slovenian, hr Croatian, sr Serbian; auto picks the language whose lexicon knows most words | |
| word | No | Or one word, to list the words it typically goes with | |
| limit | No | ||
| phrase | No | Two words to check together, e.g. 'napraviti odluku' | |
| partner_pos | No | With `word`: only partners of this part of speech |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds real behavioral value by saying the result reports whether the corpus pairs the words, how strongly, and which words normally substitute. It stops short of describing thresholds or scoring semantics, but the essentials are 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?
Three short sentences, question front-loaded, mode-specific details following, no filler. Every clause carries information about purpose, inputs, or output.
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 it still sketches them. Purpose and both input modes are covered; only edge behavior (both word and phrase set, limit semantics) is left implicit, which is a minor gap for a read-only checker.
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 80% and the schema already documents lang, word, phrase, and partner_pos, so the baseline is 3. The description reinforces the phrase/word mode split and gives a concrete phrase example, but adds nothing about limit or how the two input modes interact if both are supplied.
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 check — whether a word pairing is natural — and splits it into two concrete modes (two-word phrase vs. single word) with an illustrative example ('napraviti odluku' -> donijeti). That makes it distinguishable from lookup_word or get_forms, but it never explicitly contrasts itself with those 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?
It clearly states the two usage contexts: pass a two-word phrase to validate collocation, or a single word to list its usual partners. The closing line 'Catches word-for-word translations' gives the motivating scenario, though it never says when to prefer a sibling tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Proofreading evidence for a text: words found in neither the corpus nor the lexicon (misspelled or invented), known misspellings, missing diacritics, rare words, a word repeated three or more times within 60 words, and optionally unnatural verb + noun pairs. Returns findings with character offsets, not a corrected text. Grammar (agreement, case after prepositions) is not checked.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | Yes | sl Slovenian, hr Croatian, sr Serbian; auto picks the language whose lexicon knows most words | |
| text | Yes | Up to 20,000 characters | |
| pairings | No | Also flag verb + noun pairs the corpus does not use (slower) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is read-only, idempotent, and closed-world. The description adds useful behavioral context beyond annotations: it clarifies that results are findings with character offsets rather than corrected text, and that grammar agreement/case are out of scope. It does not need to repeat return structure because an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and check list, then closes with two critical scope limits. Every sentence earns its place; there is no filler or repetition.
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, annotations cover safety and idempotency, and the schema documents all parameters. The description supplies the remaining conceptual completeness: what evidence is returned, what is not returned, and which grammar issues are excluded.
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 all three parameters are already documented. The description reinforces the optional 'pairings' behavior by describing unnatural verb + noun pairs, but adds little syntax or semantic detail beyond the schema. Baseline 3 is appropriate when the schema does the parameter-level work.
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 gives a clear resource and enumerates the specific proofreading checks performed: unknown words, misspellings, diacritics, repetition, and optional pairings. It also distinguishes the output from correction tools by stating it returns findings with offsets, not corrected text. It stops short of explicitly naming sibling tools or directly contrasting itself with check_orthography.
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 by the phrase 'Proofreading evidence for a text' and by the listed checks, but there is no explicit when-to-use guidance or named alternatives. The negative scope ('Grammar ... is not checked' and 'not a corrected text') helps, but does not fully route the agent among siblings such as check_orthography or suggest_replacements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The orthography rules check_orthography applies and the parts of Slovenski pravopis 2001 that match a query: rule, § number, a paraphrase, and how reliable the check is. Use it to justify a correction to the user. The rulebook is paraphrased, not quoted.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A rule id (s_z), a § number (683) or a word (vejica, comma, velika začetnica) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds genuinely new behavioral context: the rulebook is paraphrased, not quoted, which matters for how the agent presents results. It doesn't describe matching breadth (e.g., multiple matches, empty results), so not 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?
Two tight sentences: what it returns first, then how to use it. The paraphrase disclaimer is well placed at the end. 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?
Output schema exists so return values needn't be explained, and the description still summarizes them and flags the paraphrase caveat. What's missing is behavior on ambiguous or zero-match queries, a minor gap for a simple single-parameter lookup.
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 query parameter's description already lists all the accepted forms (rule id, § number, word) with examples, so the description adds nothing beyond the schema here. 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 (explain) and resource (orthography rules / Slovenski pravopis 2001), and names what is returned: rule, § number, paraphrase, reliability. It also explicitly links to the sibling check_orthography, distinguishing it from the other 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?
"Use it to justify a correction to the user" gives a clear use context, effectively positioning it as the follow-up to check_orthography. It does not state exclusions (e.g., don't use it to perform checks), so a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fixed expressions and idioms with their meaning, register and whether they are figurative: find one for an idea, or explain one. Covers the expressions kontekst has explained (about 870 Slovenian, 3,000 Croatian, 1,500 Serbian).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | Yes | sl Slovenian, hr Croatian, sr Serbian; auto picks the language whose lexicon knows most words | |
| limit | No | ||
| concept | No | A word for the idea, e.g. 'oprez' | |
| expression | No | Or a fixed expression to explain |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and a closed-world hint, so the safety profile is clear. The description adds useful scope information beyond that: what fields are returned (meaning, register, figurative status) and approximate lexicon sizes per language, making the limited coverage of the resource explicit.
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 compact sentences front-load the purpose and modes, with the parenthetical coverage counts giving useful scoping detail without waste. Every clause earns its 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 does not need to explain return values, and annotations cover safety. It communicates the resource scope and the two main use modes, though it could be slightly more explicit about how concept and expression interact and what happens when neither is supplied.
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 75%, and the schema already documents lang, concept, and expression. The description's 'find one for an idea, or explain one' usefully suggests the concept vs. expression modes, but it does not clarify mutual exclusivity, the limit parameter, or the behavior of 'auto' beyond what the schema 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 states a specific resource (fixed expressions and idioms) and two clear modes: finding an expression for an idea, or explaining a given expression. It does not explicitly name or differentiate itself from the sibling lookup_word, so sibling routing is only implicit rather than explicit.
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 phrase 'find one for an idea, or explain one' implies the two usage modes and loosely maps them to the concept vs. expression parameters. However, it gives no explicit exclusions, prerequisites, or guidance about when to use lookup_word instead, leaving alternative selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inflected forms from the lexicon: one form (with features or like) or the whole table.
Each form says whether it occurs in the corpus (attested); prefer attested forms.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | Yes | sl Slovenian, hr Croatian, sr Serbian; auto picks the language whose lexicon knows most words | |
| like | No | Another word's form to copy, e.g. like='utječemo' gives this verb's first person plural | |
| word | Yes | A lemma or any of its forms | |
| features | No | Wanted form, e.g. {"case": "genitive", "number": "plural"}; keys case, number, gender, person, tense, degree, definiteness; values as in the readings (nominative, genitive, dative, accusative, vocative, locative, instrumental; singular, plural, dual; first, second, third; present, infinitive, ...) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/closed-world, so the description's job is additive — and it delivers by disclosing the `attested` flag per form and the recommendation to prefer attested results. It doesn't cover table size, ordering, or pagination behavior for the 'whole table' mode, which keeps it at 4.
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 sentences, front-loaded on what the tool returns, with the preference rule last. Backticked parameter names tie the prose to the schema. Tight and purposeful, though the first sentence is somewhat elliptical.
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 shape needn't be explained, and the description still surfaces the one output field that affects decisions (`attested`). Enum-constrained `lang` and the nested `features` object are covered by the schema, leaving no major gap.
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 goes further by framing `features` and `like` as the two ways to target a specific form, which contextualizes otherwise dense schema entries. It stops short of restating value vocabularies, which the schema already does.
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+resource ('Inflected forms from the lexicon') and lays out the two retrieval modes (single form via `features`/`like`, or the whole table). It does not explicitly differentiate from the sibling `lookup_word`, so a 4 rather than a 5.
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 one useful usage rule ('prefer attested forms'), which is real guidance. However, it never says when to call this versus `lookup_word` or the other lexicon-adjacent siblings, so the when-to-use decision is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What kontekst knows about each word: lemma and grammatical readings, corpus count and
frequency band (1 rarest .. 5 commonest), standard spelling if it is a variant, loanword
flag, and the parts asked for in include.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | Yes | sl Slovenian, hr Croatian, sr Serbian; auto picks the language whose lexicon knows most words | |
| words | Yes | Up to 50 words or phrases, any inflected form | |
| include | No | similar: the site's similar words (own forms and misspellings removed); negations: list words that negate it; family: same-root words across word classes; phrases: phrases containing it; forms: full inflection table |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful detail about what data is returned and how frequency bands are interpreted, but it does not disclose behavior such as handling unknown words or response shape beyond 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?
The description is a single front-loaded sentence that moves directly into the returned fields. It is dense but efficient, with every listed item contributing to the tool's purpose.
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 the complete input schema, existing output schema, and annotations, the description is largely complete for calling the tool correctly. It could have added brief usage routing against siblings, but the core lookup contract is clear.
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 lang, words, and include thoroughly. The description adds only marginal semantic value by summarizing that include controls which extra parts are returned.
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 clearly states that the tool returns lexical information about words, including lemma, readings, corpus frequency, variant spelling, loanword status, and requested include parts. It is specific about the resource and fields, but it does not distinguish this tool from siblings such as get_forms or check_orthography.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor when not to use it. The lexical nature of the tool implies a lookup use case, but the description leaves selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cleaned text plus a list of every change. For text typed without diacritics, from
speech recognition or OCR, or for analytics. Changes a word only when the evidence is
clear (the winning spelling at least 5x commoner); the rest are listed in undecided
with their options. Words the lexicon knows are never respelled except to add
diacritics or fix broken encoding.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | Yes | sl Slovenian, hr Croatian, sr Serbian; auto picks the language whose lexicon knows most words | |
| text | Yes | Up to 20,000 characters | |
| steps | No | diacritics: restore č ć š ž đ where one spelling clearly wins; spelling: fix known misspellings; lemmas: base form and reading per word; entities: names with their Wikidata ID |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnly/idempotent/openWorld annotations, it discloses the decision rule (the winning spelling must be at least 5x commoner), that borderline cases are not silently changed but returned in `undecided` with their options, and that lexicon words are never respelled except for diacritics or broken encoding. These are exactly the non-obvious behaviors that determine whether an agent can trust the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, none wasted, each adding a distinct fact (output shape, use cases, threshold, lexicon exception). The ordering is slightly off for scanning: it leads with the return value rather than with what the tool does and when to reach for it.
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 characterizes the meaningful parts (changes and `undecided`). With annotations covering safety and full schema coverage on parameters, the definition is sufficient to call the tool correctly; only explicit sibling differentiation 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%, including per-value enum documentation for `lang` and `steps`, so the schema already carries parameter meaning. The description adds behavioral context around diacritics decisions and the `undecided` output but never refers to `text`, `lang`, the 20,000-character limit, or the `steps` selection, so it does not go beyond the structured fields.
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 opening line states the result ('cleaned text plus a list of every change') and later sentences make clear it rewrites words only on strong evidence, which together pins down a normalization/fixing operation over Slovenian/Croatian/Serbian text. It is inferable rather than stated as a direct verb+resource, and it never names the sibling checkers it differs from, but the purpose is unambiguous.
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 concrete usage contexts: text typed without diacritics, speech recognition or OCR output, and analytics. That is a clear when-to-use signal with no explicit exclusions and no named alternative among check_orthography, check_text, or suggest_replacements, so an agent must infer that this tool applies fixes rather than only reporting problems.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alternatives for a word, each already inflected to the same case, number, gender and
person as the input (konzistentnoj -> dosljednoj), so it can be dropped into the sentence.
Candidates come from kontekst's similar-word lists: they can be related or opposite words
rather than synonyms, so choose by meaning. When the input form is ambiguous (several
readings), other_readings gives each candidate's form per reading; pick the one the
sentence needs.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | synonym: closest words; simpler: only commoner words; domestic: no loanwords (replaces internationalisms such as konzistentan, implementirati) | synonym |
| lang | Yes | sl Slovenian, hr Croatian, sr Serbian; auto picks the language whose lexicon knows most words | |
| safe | No | Leave out vulgar and derogatory words | |
| word | Yes | The word as it stands in the text, inflected | |
| limit | No | ||
| sentence | No | The sentence it is in; each candidate then gets `context_fit`, how strongly it goes with the neighbouring words (higher is better; 0 = no evidence) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world behavior, so the bar is lower. The description still adds real context: the provenance of candidates (kontekst's similar-word lists), the warning that results may be related or opposite words, and the ambiguity handling via `other_readings`.
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 replacement-ready guarantee are front-loaded, followed by the candidate-source caveat and ambiguity note. Dense with no filler, though the parenthetical example and reading guidance make it a fairly long block for a six-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?
Output schema exists, so return values need not be re-explained, yet the description proactively explains the `other_readings` output field's purpose and how to use it. Combined with the synonymy caveat and inflection guarantee, an agent has everything needed to call and interpret 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 83% (goal, lang, safe, word, sentence all documented), so baseline would be 3. The description adds semantic value beyond the schema by stressing that `word` must be the surface/inflected form as it stands in the text and explaining why infllected output matters for substitution.
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 (returns alternatives for a word) plus the key differentiator: candidates are pre-inflected to match the input's case/number/gender/person so they can be dropped into the sentence. The example (`konzistentnoj` -> `dosljednoj`) and the caveat that candidates may be related or opposite rather than synonyms cleanly separate it from lookup_word, get_forms, and find_expression.
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 in-task guidance: choose by meaning rather than assuming synonymy, and when the input form is ambiguous use `other_readings` to pick the form the sentence needs. It does not explicitly name when to prefer a sibling tool (e.g. lookup_word for definitions), but the replacement-in-context scenario is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_orthographycheck_pairingcheck_textexplain_rulefind_expressionget_formslookup_wordnormalize_textsuggest_replacements
Add one secure layer between your agents and this server.