GermanExam.pro

Evaluate text

evaluate_text

Use this when the user wants a German text they wrote themselves (about 50 to 900 words) evaluated the way an examiner would, for the writing section of TestDaF, DSH, Goethe-Zertifikat C1, telc Deutsch C1 Hochschule or telc Deutsch C1 (general). Without an account the result shows the passages an examiner would mark and the biggest risk (a user without an account can use one part). With a free GermanExam.pro account the result also includes the verdict (is it enough, level, how close it is); a request that the account does not include is answered with a short note and a link to an information page. For signed-in users the text and the result are saved in their GermanExam.pro account. Starts the evaluation and returns a job_id immediately; the result is collected with get_evaluation_result. Send only the user's own text. Not for: translations, grammar questions, exam tasks, phrase lists, texts the user did not write, or other languages.

Input Schema

Name	Required	Description
`exam`	Yes	The exam the text is for: testdaf, dsh, goethe_c1, telc_c1 (Hochschule) or telc_c1_allgemein (general). Ask the user if unclear — plain "telc C1" can mean either telc exam.
`part`	No	Only for goethe_c1: 1 = discussion post for an internet forum, 2 = (semi-)formal e-mail.
`task`	No	Optional: the exam task the text answers, verbatim, if the user has it.
`text`	Yes	The German text exactly as the user wrote it (their own writing, at least about 50 words). Only the text itself — no chat history, no instructions.
`feedback_language`	No	Language of the feedback: the language the user is writing to you in (de, en, ar, tr, ru, zh, fa). Default de.

Output Schema

Name	Required	Description	Default
`jobId`	No
`labels`	No
`status`	Yes
`infoUrl`	No
`message`	Yes
`preview`	No
`verdict`	No
`infoLabel`	No
`retryAfterSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedOutput schema / properties / status / enum

Previous value: -[
-  "running",
-  "done",
-  "not_in_plan",
-  "not_a_submission",
-  "no_verdict",
-  "invalid_input",
-  "limit",
-  "busy",
-  "unavailable",
-  "not_found",
-  "sign_in_required"
-]New value: +[
+  "running",
+  "done",
+  "not_in_plan",
+  "not_a_submission",
+  "no_verdict",
+  "invalid_input",
+  "limit",
+  "busy",
+  "unavailable",
+  "not_found",
+  "sign_in_required",
+  "account_needed"
+]

Changed18 schema fields changedOct 28, 2026
- removedOutput schema / properties / preview / properties / biggestRisk / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / preview / properties / biggestRisk / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / verdict / properties / criteria / items / properties / mark / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / verdict / properties / criteria / items / properties / mark / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / verdict / properties / criteria / items / properties / reason / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / verdict / properties / criteria / items / properties / reason / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / verdict / properties / headline / properties / cefrEstimate / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / verdict / properties / headline / properties / cefrEstimate / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / verdict / properties / headline / properties / levelLabel / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / verdict / properties / headline / properties / levelLabel / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / verdict / properties / headline / properties / scoreLabel / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / verdict / properties / headline / properties / scoreLabel / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / verdict / properties / headline / properties / verdictText / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / verdict / properties / headline / properties / verdictText / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / verdict / properties / improvements / items / properties / why / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / verdict / properties / improvements / items / properties / why / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / verdict / properties / passRule / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / verdict / properties / passRule / type
```
Added value: +[
+  "string",
+  "null"
+]
```
AddedOct 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that the call is asynchronous (returns a job_id immediately rather than the result), that output varies by account tier (guest sees marked passages and top risk; free account adds verdict; out-of-scope requests get a short note and link), and that signed-in users' text and results are persisted — consistent with readOnlyHint=false and idempotentHint=false.

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

Conciseness4/5

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

Front-loaded with the trigger condition and dense with load-bearing detail, but the sentence about guest-tier results is muddy — the parenthetical '(a user without an account can use one part)' is ambiguous and reads as leftover drafting. Slightly long, though nearly every sentence earns its place.

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?

For a 5-parameter, tiered, asynchronous tool with an output schema, this covers everything an agent needs: trigger, scope, async completion path, account-dependent behavior, persistence, and negative cases. Return-value details are correctly omitted because an output schema exists.

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%, so the schema already explains exam, part, task, text and feedback_language; the baseline is 3. The description adds only the external length guidance ('about 50 to 900 words') and the 'send only the user's own text' constraint, which is useful but does not meaningfully extend parameter meaning.

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?

States a specific verb and resource ('evaluated the way an examiner would' a 'German text they wrote themselves') plus the exact scope: the writing section of TestDaF, DSH, Goethe C1, telc C1 Hochschule, telc C1 allgemein. It is clearly separable from siblings like get_evaluation_result and lookup_exam_rubric because it names the async hand-off explicitly.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('Use this when the user wants a German text they wrote themselves'), an explicit exclusion list ('Not for: translations, grammar questions, exam tasks, phrase lists, texts the user did not write, or other languages'), and points to the follow-up tool get_evaluation_result for retrieval. Nothing about selection is left to inference.

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

All GermanExam.pro tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?