wiktionary-de-mcp

Get conjugation/declension table

get_inflection_table

Read-onlyIdempotent

Retrieve the complete inflection table for a German word, including verb conjugations, adjective declensions, or noun case forms.

Instructions

Return the complete inflection table for a German word.

For verbs this is the full conjugation (all tenses, moods, persons, participles,
imperative); for adjectives the full strong/weak/mixed declension of the positive,
comparative and superlative. Both come from the page "Flexion:<word>". Nouns
usually have no such page; for them this returns the case and number forms
listed on the entry itself.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`word`	Yes	The lemma (dictionary form), e.g. 'laufen', 'gehen', 'Haus'.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Oct 18, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and open-world behavior, so the bar is lower. The description adds useful behavioral context: data comes from the 'Flexion:<word>' page, and nouns usually lack that page so the tool falls back to forms listed on the entry itself. It does not explain what happens if a verb or adjective page is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and compact: purpose first, then the per-part-of-speech behavior, then the noun fallback. Every sentence carries specific information with no filler.

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

Completeness5/5

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

With annotations covering safety behavior and an output schema covering return structure, the description supplies the remaining necessary context: language, scope by part of speech, source page, and noun fallback. An agent has enough to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100% for the single 'word' parameter, which the schema already documents as the lemma/dictionary form with examples. The description adds no further parameter meaning beyond that baseline.

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

Purpose5/5

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

The description states a specific verb and resource: 'Return the complete inflection table for a German word.' It then precisely scopes what that means for verbs, adjectives, and nouns. This makes it readily distinguishable from lookup_word and get_raw_wikitext without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by explaining what content is returned and for which parts of speech, but it never explicitly says when to use this tool instead of lookup_word or get_raw_wikitext. There are no exclusions or alternative-tool routing instructions.

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

Deploy Server