Remote MCP for a concern-matching marketplace. Agents can browse listings, create posts, chat, and read matches.
Scored across 15 tools
The tools are mostly distinct, each targeting a specific resource and action (e.g., markt_ansehen for market entries, post_erstellen for creating posts). However, there is potential confusion between benachrichtigungen (notifications), chats_ansehen (view chats), and nachrichten_lesen (read messages) since notifications include chat messages and the boundaries require careful reading of descriptions. Overall, clear enough for an agent with descriptive hints.
Most tools follow a consistent noun_verb pattern (e.g., chats_ansehen, post_erstellen, profil_aendern), but a few are pure nouns (benachrichtigungen, meine_posts, meine_treffer) which imply read operations without explicit verbs. The German naming is consistent and readable, with only minor deviations from the dominant pattern.
With 15 tools, the server is well-scoped for a marketplace platform covering posting, messaging, profiles, notifications, and feedback. Each tool serves a distinct purpose and none feel redundant, making the count appropriate for the domain.
The tool surface covers the core lifecycle: create, view, manage (close/reactivate/delete), report posts, view categories, handle chats and messages, and manage profiles. Minor gaps exist, such as lacking the ability to edit an existing post's content or block users, but these are not critical for typical agent workflows.
Posteingang fuer Agents: Treffer, Chat-Nachrichten und Plattform-Hinweise. Ungelesene zuerst. art=nachricht hat chat_id (Antworten mit nachricht_senden + chat_id). ungelesen_gesamt zaehlt Notification-Zeilen UND ungelesene Chats ohne Doppelzaehlung. Kein Push — pollen. Ablauf: wenn ungelesen_gesamt > 0 → nachrichten_lesen → antworten.
| Name | Required | Description | Default |
|---|---|---|---|
| anzahl | No | Wie viele (1-100, Standard 30) | |
| nur_ungelesen | No | Nur die ungelesenen (Standard: alle) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Über die Annotationen hinaus werden Sortierreihenfolge ('Ungelesene zuerst'), Polling-Pflicht, die Zähl-Semantik von ungelesen_gesamt ohne Doppelzählung sowie die chat_id-Konvention bei art=nachricht offengelegt. Kein Widerspruch zu readOnlyHint oder idempotentHint.
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?
Jeder Satz trägt eine eigene Information: Zweck, Sortierung, Feldkonvention, Zählweise, Polling und Folgeablauf. Der Einstieg ist prägnant und die Struktur ist kompakt.
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?
Ohne Output-Schema erklärt die Beschreibung zentrale Felder wie art, chat_id und ungelesen_gesamt sowie den Anschluss-Workflow, was für einen Polling-Inbox ausreicht. Eine vollständige Auflistung aller Rückgabefelder fehlt jedoch.
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?
Das Schema beschreibt beide Parameter (anzahl, nur_ungelesen) vollständig. Die Beschreibung fügt keine neuen Syntax- oder Formatdetails hinzu, daher genügt die 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?
Die Beschreibung nennt konkret den Ressourcentyp ('Posteingang fuer Agents') und die enthaltenen Inhalte (Treffer, Chat-Nachrichten, Plattform-Hinweise). Eine explizite Abgrenzung zu nachrichten_lesen fehlt zwar, aber der genannte Ablauf deutet die Rolle an.
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?
Die Beschreibung enthält einen klaren Ablauf ('wenn ungelesen_gesamt > 0 → nachrichten_lesen → antworten') und weist auf das Polling-Verhalten hin ('Kein Push — pollen'). Sie sagt aber nicht explizit, wann man stattdessen nachrichten_lesen verwenden sollte.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet die laufenden Unterhaltungen: mit wem, zu welchem Eintrag, ob der Eintrag dem Nutzer gehoert (mein_post), ob der Chat noch leer ist, letzte Nachricht und Ungelesene. Kein Push — pollen, wenn der Nutzer fragt ob jemand geschrieben hat, oder periodisch. Bei ungelesen_gesamt > 0: nachrichten_lesen, dann nachricht_senden mit chat_id.
| Name | Required | Description | Default |
|---|---|---|---|
| anzahl | No | Wie viele Unterhaltungen (1-100, Standard 30), neueste zuerst |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive properties, so the description doesn't need to repeat them. However, it adds valuable behavioral context by stating this tool is for polling (not push) and by describing conditional follow-up actions based on the unread count. This goes beyond the structured annotations and helps the agent understand the operational pattern.
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 three sentences, front-loaded with the core purpose, then adds usage guidance and follow-up actions. It is efficient with no fluff, though it could be slightly tightened. The structure is logical and easy to parse.
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 no output schema, the description compensates by explicitly listing the return fields (with whom, entry, ownership, empty status, last message, unread). It also includes usage context and follow-up steps, making the tool self-contained for an agent. Minor omissions like error handling or pagination details are not critical for a simple list 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?
The schema covers the parameter fully (name 'anzahl', type number, range 1-100, default 30, sort order 'neueste zuerst'). The description does not add meaning beyond that, so the baseline of 3 applies. It is adequate but not enhanced.
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 the tool lists ongoing conversations ('Listet die laufenden Unterhaltungen') and enumerates specific fields returned (participant, associated entry, ownership flag, empty status, last message, unread counts). This is specific and distinguishes it from siblings like 'nachrichten_lesen' or 'nachricht_senden', which are follow-up actions rather than list 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?
The description explicitly states when to use this tool: 'Kein Push — pollen, wenn der Nutzer fragt ob jemand geschrieben hat, oder periodisch.' It also provides a concrete post-call flow: 'Bei ungelesen_gesamt > 0: nachrichten_lesen, dann nachricht_senden mit chat_id.' This gives clear context and routing to related tools, leaving no ambiguity about when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Raeumt eine Unterhaltung auf. 'gelesen' setzt sie auf gelesen, damit der Zaehler stimmt. 'archivieren' blendet sie aus der Liste aus — sie ist nicht geloescht, und sobald jemand wieder hineinschreibt, kommt sie zurueck. Die chat_id kommt aus chats_ansehen.
| Name | Required | Description | Default |
|---|---|---|---|
| aktion | Yes | Was passieren soll | |
| chat_id | Yes | Die Unterhaltung, aus chats_ansehen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals meaningful behavioral details: archiving does not delete the conversation, and it will reappear when someone writes anew. It also clarifies the side effect of 'gelesen' on the counter. This adds substantial context that the annotations alone do not 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?
The description is three compact sentences, each earning its place. The main action is front-loaded, followed by the two action definitions and a helpful parameter source hint. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description covers the operation, both action effects, and the source of the required chat_id. There are no obvious gaps an agent would need to fill before invoking the tool 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?
Although the schema already covers both parameters, the description adds real semantic value by explaining exactly what each enum value does and by indicating the source of chat_id via chats_ansehen. This goes well beyond the schema's minimal 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 clearly states the tool's purpose ('Raeumt eine Unterhaltung auf') and then precisely defines both allowed actions, 'gelesen' and 'archivieren', with their effects. This distinguishes it from any sibling tool by naming the unique operations it performs on a conversation.
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 practical context for when to use each action: 'gelesen' is for fixing the unread counter, 'archivieren' is for hiding a conversation without deleting it. It also tells the agent where to obtain the required input ('Die chat_id kommt aus chats_ansehen'), which provides clear workflow guidance, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gibt Rueckmeldung zur Plattform selbst weiter — was nicht funktioniert, was fehlt, was stoert. Landet bei den Betreibern. Nutze das, wenn dein Nutzer sich ueber die Plattform beschwert oder sich etwas wuenscht, statt es nur zu bestaetigen.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Die Rueckmeldung, in den Worten des Nutzers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no informative annotations (readOnlyHint=false, destructiveHint=false, etc.), the description carries the behavioral burden. It discloses that feedback 'Landet bei den Betreibern' (goes to operators), which is a useful behavioral trait. However, it doesn't mention side effects, confirmation, or anything about reversibility — acceptable for a simple feedback tool but not rich disclosure.
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 with no fluff. The first sentence front-loads the action and scope; the second provides usage guidance. Every phrase earns its place, and the message is immediately parseable.
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 one-parameter tool with no output schema and nested objects, the description covers purpose, scope, destination, and usage conditions. It doesn't specify return values, but that's unnecessary here. The only small gap is not explicitly describing the tool as a write-action with potential side effects, but annotations already signal non-read-only.
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?
The schema covers the single parameter text 100%, including 'in den Worten des Nutzers'. The description adds some context by listing example feedback content (what doesn't work, what's missing, what bothers), but it largely restates the schema's intent. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Gibt Rueckmeldung ... weiter') and a clear resource ('zur Plattform selbst'), distinguishing it from sibling tools like post_melden. It defines the scope with concrete examples (was nicht funktioniert, was fehlt, was stoert), so an agent immediately understands what this tool is for.
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 explicit usage condition: 'Nutze das, wenn dein Nutzer sich ueber die Plattform beschwert oder sich etwas wuenscht' — this clearly tells the agent when to select this tool. It does not explicitly name alternatives or when not to use it, but the platform-scope wording implicitly separates it from post reporting and other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet alle Fachgebiete mit der Anzahl aktiver Eintraege, aufgeteilt nach Gesuchen und Angeboten. Nutze das zuerst, um zu sehen, welche Bereiche es ueberhaupt gibt und wo etwas los ist — danach gezielt mit markt_ansehen hineingehen.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description does not need to restate safety. It adds useful output behavior by specifying that only active entries are counted and that results are split by Gesuchen and Angeboten, going 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?
Two tightly written sentences: the first states exactly what is returned, and the second gives actionable positioning relative to markt_ansehen. There is no filler or redundancy.
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 zero-parameter read-only listing tool, the description is complete: it explains the returned content, the active-entry filtering, the Gesuche/Angebote split, and how to proceed with markt_ansehen. No output schema is present, but the description supplies enough detail for correct use.
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?
The tool has zero parameters and the schema coverage is 100%, so there is nothing parameter-related for the description to explain. The baseline of 4 applies because no parameter semantics are needed.
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 the specific verb 'Listet' and a precise resource: all Fachgebiete with counts of active Eintraege split by Gesuchen and Angeboten. It distinguishes itself from sibling markt_ansehen by framing this as the overview step before drilling into market details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to use this tool first to discover which Bereiche exist and where activity is, then to go into markt_ansehen for targeted exploration. This provides clear when-to-use guidance and names the alternative tool directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liest Eintraege von Open Platform (Marktplatz fuer Angebote und Gesuche, ortsbezogen). OHNE ARGUMENTE BEKOMMST DU ALLES — alle Filter sind freiwillig. Die Antwort nennt 'gesamt' (wie viele es insgesamt gibt) und 'weitere'; zum vollstaendigen Abholen 'seite' hochzaehlen, solange 'weitere' true ist. Willst du eine eigene Kopie pflegen: einmal alles holen, danach nur noch mit 'seit' (Zeitstempel des letzten Abrufs) die neuen Eintraege nachladen. So kannst du selbst entscheiden, was zu deinem Nutzer passt, statt dich auf die Vorauswahl der Plattform zu verlassen.
| Name | Required | Description | Default |
|---|---|---|---|
| art | No | 'request' = Gesuche, 'offer' = Angebote | |
| seit | No | Nur Eintraege, die nach diesem Zeitpunkt entstanden sind (ISO-8601). Fuer den Abgleich einer eigenen Kopie. | |
| seite | No | Seite ab 0. Zum Blaettern hochzaehlen, solange 'weitere' true ist. | |
| suche | No | Volltextsuche im Text der Eintraege | |
| anzahl | No | Eintraege pro Abruf (1-200, Standard 50) | |
| fachgebiet | No | Nur ein Fachgebiet, z.B. 'handwerk'. Verfuegbare Werte liefert kategorien_ansehen. | |
| sortierung | No | Standard: relevanz |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and open-world; the description adds useful context about response fields ('gesamt', 'weitere'), pagination behavior, and the incremental-fetch strategy using 'seit'. This goes beyond what the annotations alone 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?
The description is front-loaded with the core purpose and then provides operational details in a logical order. It is somewhat dense and the final sentence about deciding what fits the user is slightly rhetorical, but overall every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 7 optional parameters and no output schema, the description covers default behavior, pagination, and incremental syncing sufficiently for an agent to invoke it correctly. It does not describe individual entry fields, but that is a minor gap given the schema coverage and the page/response metadata it does explain.
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?
The schema already covers all 7 parameters with descriptions, so the baseline is 3. The description adds value by explaining how 'seite' relates to the 'weitere' response field and how 'seit' enables maintaining an up-to-date local copy, which the raw schema does not 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?
The description states a specific verb and resource: 'Liest Eintraege von Open Platform' and clearly identifies the domain as a location-based marketplace for offers and requests. This distinguishes it from sibling tools like chats, messages, or profile management even without naming them explicitly.
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 clear operational guidance: all filters are optional, fetching everything is the default, and pagination via 'seite' while 'weitere' is true is explained. It also explains the incremental sync use case with 'seit'. However, it does not explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet die eigenen Eintraege des Nutzers mit Fachgebiet, Status, Datum und der Anzahl gefundener Treffer. Nutze das, um zu wissen, wonach dein Nutzer sucht oder was er anbietet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful scoping ('eigene Eintraege des Nutzers') and output field context, but it does not disclose additional behavioral details such as authentication requirements, pagination, sorting, or what is not included.
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 only two sentences with no filler. The first sentence states the resource and returned fields; the second provides the practical purpose. It is front-loaded and every sentence 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?
For a tool with no parameters and strong annotations, the description is largely complete. It names the key output fields and explains how to interpret the data. It could be more explicit about the response shape or ordering, but nothing critical is missing for an agent to select and invoke the 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?
The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to explain. The description correctly focuses on what the tool returns rather than inputs, which satisfies the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action and resource: 'Listet die eigenen Eintraege des Nutzers' with specific fields (Fachgebiet, Status, Datum, Trefferanzahl). It is clear, but it does not explicitly distinguish itself from sibling tools like 'meine_treffer' or 'post_verwalten', so it stops short of full 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?
The description gives a direct usage context: 'Nutze das, um zu wissen, wonach dein Nutzer sucht oder was er anbietet.' This tells the agent when the tool is relevant, but it does not mention when to avoid it or name alternative tools, so exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Zeigt die Treffer zu den eigenen Eintraegen: welcher fremde Eintrag passt, wie weit entfernt und mit welcher Begruendung entschieden wurde.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already communicate read-only, idempotent, non-destructive behavior. The description adds content-level transparency by specifying exactly what the operation shows: the matching foreign entry, distance, and decision reasoning, which an agent could not infer from the annotations alone.
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?
A single compact sentence front-loads the main action and then uses a colon and concise list to elaborate. There is no filler, no repetition of the title/name, and 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?
For a parameter-free read-only display tool, the description covers the essential return semantics and scope. It omits minor niceties like empty-state behavior or ordering, but nothing an agent needs in order to correctly invoke this tool 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?
The input schema has zero parameters, so the 0-parameter baseline applies and there is no parameter documentation burden on the description. The mention of 'eigenen Eintraegen' clarifies whose data the tool operates on, adding implicit context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Zeigt') and a concrete resource ('Treffer zu den eigenen Eintraegen'), then goes beyond the name by detailing the result contents: which foreign entry matches, the distance, and the decision rationale. This makes the tool's purpose clear and distinct from siblings such as meine_posts.
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 'zu den eigenen Eintraegen' establishes a clear trigger and scope: use this tool to view matches generated for the current user's own entries. It does not explicitly name alternatives or exclusions, so it misses the top score, but the intended usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liest den Verlauf einer Unterhaltung inkl. Kopf (post_id, Eintrag-Snippet, mit wem, mein_post). Die chat_id kommt aus chats_ansehen oder benachrichtigungen. Standard: letzte 50, aelteste zuerst. von_mir markiert eigene Nachrichten. Vor dem Antworten lesen — sonst schreibst du an etwas vorbei.
| Name | Required | Description | Default |
|---|---|---|---|
| anzahl | No | Wie viele Nachrichten (1-200, Standard 50) | |
| chat_id | Yes | Die Unterhaltung, aus chats_ansehen / benachrichtigungen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations: default limit (50), ordering (oldest first), and the inclusion of header fields. This is useful but not exhaustive; it doesn't describe potential edge cases or full response structure.
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 three sentences, front-loading the main purpose and then providing usage details and a warning. It is efficient and contains no filler, though it could be slightly tighter if the warning were integrated more directly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description adequately covers what is returned (header fields), the default limit and ordering, and the source of the chat_id. It also gives a usage directive. It doesn't mention error handling or pagination, but these are not critical for this simple read operation.
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 fully documented. The description adds minimal extra meaning—it mentions the default count and ordering (not in schema), but it largely repeats the chat_id explanation from the schema. The added ordering info is helpful, but the overall parameter semantics are already well-handled by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a conversation history, listing specific header fields (post_id, entry snippet, with whom, my_post). It implies differentiation from siblings by noting chat_id comes from chats_ansehen/benachrichtigungen, which are list-type tools, though it doesn't explicitly name alternatives.
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 explicit context: 'Vor dem Antworten lesen — sonst schreibst du an etwas vorbei' tells the agent when to use this tool (before replying). It also explains the chat_id source and default behavior, providing clear usage guidance without naming alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schreibt im Marktplatz-Chat von Open Platform. Du handelst im Auftrag des Kontoinhabers unter seinem Namen — Marktplatz-Kontakt, kein privater Posteingang. Zum ANTWORTEN in einem laufenden Chat: chat_id aus chats_ansehen oder benachrichtigungen (bevorzugt — verhindert vermischte Threads). Zum ERSTEN Kontakt: post_id aus markt_ansehen oder meine_treffer; dann entsteht der Chat. Genau eines von beidem. Schreib konkret. Hoechstens 20 pro Stunde. Es gibt kein Push — nach dem Senden spaeter benachrichtigungen oder chats_ansehen pollen. Zeig dem Nutzer den Text, bevor du ihn abschickst.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Die Nachricht | |
| chat_id | No | Bestehende Unterhaltung (Antworten). Aus chats_ansehen / benachrichtigungen. | |
| post_id | No | Fremder Eintrag fuer den ersten Kontakt. Aus markt_ansehen / meine_treffer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses acting on behalf of the account owner, the 20-per-hour limit, the absence of push notifications, the need to poll later, and the requirement to show the user the text before sending. This is substantial behavioral context that annotations alone do not 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?
The description is dense but every sentence carries operational value: action, identity, parameter selection, rate limit, polling behavior, and user confirmation. The ANTWORTEN/ERSTEN contrast provides clear scannable structure without fluff.
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 three-parameter tool with no output schema, the description covers the full workflow: how to choose and source parameters, what happens on first contact (chat is created), the rate limit, and what to do after sending. Nothing needed 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?
Although schema coverage is 100%, the description adds crucial semantics: chat_id is for an existing conversation, post_id is for first contact, and exactly one must be provided. It also tells the agent where each ID comes from, which the schema does not 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?
The description opens with a specific verb and resource: 'Schreibt im Marktplatz-Chat von Open Platform.' It clearly differentiates this marketplace-chat write operation from sibling read tools like nachrichten_lesen and chats_ansehen, and clarifies it is not a private inbox.
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 explicit when-to-use guidance: use chat_id when replying in an existing chat and post_id for first contact, with exact source tools for each. 'Genau eines von beidem' enforces exclusivity, and the preference for benachrichtigungen over chats_ansehen is a practical selector.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stellt im Namen des Nutzers ein Gesuch oder Angebot ein. Schreib es so, wie der Nutzer es sagen wuerde: ein bis zwei Saetze, konkret, ohne Werbesprache. Die Plattform ordnet es selbst einem Fachgebiet zu und sucht danach im Hintergrund nach passenden Leuten. Hoechstens 5 pro Stunde. Frag den Nutzer vorher, ob er das wirklich einstellen will — es ist oeffentlich sichtbar.
| Name | Required | Description | Default |
|---|---|---|---|
| art | Yes | 'request' = ich suche, 'offer' = ich biete | |
| ort | No | Ortsname wie 'Muenster', 'Muenster Kreuzviertel' oder 'Wien Leopoldstadt' -- weltweit. Gib ihn IMMER mit, wenn der Nutzer sagt, wo er ist oder dass er woanders ist. Laesst du ihn weg, wird der Ort des letzten Posts uebernommen; gibt es keinen, wird zurueckgefragt. Rate nicht — frag den Nutzer. Die Antwort nennt den Ort, der daraus geworden ist, samt Land — SAG IHN DEM NUTZER, damit er widersprechen kann. | |
| text | Yes | Was gesucht oder angeboten wird, in eigenen Worten |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing that posts are publicly visible, the platform auto-assigns a subject area, background matching occurs, and there is a rate limit of 5 per hour. Also instructs to ask the user for confirmation before posting, adding behavioral context not present 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?
The description is five sentences, each serving a distinct purpose: core action, content style, platform behavior, rate limit, and user confirmation. It is front-loaded with the primary function and contains 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?
The description covers the essential details for invoking the tool, including parameter nuances (e.g., location resolution behavior is in the schema) and pre-flight user confirmation. It does not describe the return value or post-creation response, and there is no output schema, which leaves a small gap; however, this is not critical for a create action.
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?
The input schema already describes all three parameters thoroughly (100% coverage). The description adds useful extra guidance for the 'text' parameter, e.g., one to two sentences, concrete, without advertising language, which helps the agent generate an appropriate value. It does not add much for 'art' or 'ort' because the schema already covers them.
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 clearly that it publishes a request or offer on behalf of the user ('Stellt im Namen des Nutzers ein Gesuch oder Angebot ein'). This distinguishes it from sibling tools like post_verwalten or post_melden, which handle management and reporting rather than creation.
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?
Provides clear context for when to use it: whenever the user wants to post a request or offer. It also gives important interaction rules (ask for confirmation, max 5/hour), though it does not explicitly contrast with alternative tools such as post_verwalten for editing existing posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Meldet einen fremden Eintrag der Moderation — Spam, Betrug, Beleidigungen, unangemessene Inhalte. Die post_id kommt aus markt_ansehen. Das ist derselbe Weg wie der Melden-Knopf auf der Webseite; ein Mensch sieht sich das danach an. Frag den Nutzer vorher, ob er das wirklich melden will.
| Name | Required | Description | Default |
|---|---|---|---|
| grund | Yes | Warum gemeldet wird | |
| post_id | Yes | Der Eintrag, um den es geht | |
| anmerkung | No | Was genau das Problem ist, in eigenen Worten |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: this is the same path as the website's report button, a human will review the report afterward, and the user should be asked beforehand. This clarifies consequences without contradicting the readOnlyHint=false or destructiveHint=false 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?
Four short sentences, each earning its place: purpose first, then parameter source, then behavior and user confirmation. No fluff, no repetition of schema fields.
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 low-complexity tool with no output schema, the description covers everything an agent needs: what the tool does, which entries it applies to, where the key parameter comes from, what happens after the report, and the required user confirmation.
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 adds value by explaining that post_id comes from markt_ansehen, which is helpful for correctly selecting that parameter. The mentioned reasons also map naturally to the grund enum values.
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 uses a specific verb and resource: 'Meldet einen fremden Eintrag der Moderation' — reporting a foreign entry for moderation. It lists concrete reasons (Spam, Betrug, Beleidigungen, unangemessene Inhalte) and clearly distinguishes this from related actions like managing one's own posts.
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 clearly states when to use the tool: to report a foreign entry, and even tells the agent where to obtain the post_id ('Die post_id kommt aus markt_ansehen'). It also instructs to ask the user for confirmation before reporting. It does not explicitly name alternatives or say when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nimmt einen eigenen Eintrag zurueck oder stellt ihn wieder ein. Die post_id kommt aus meine_posts. Drei Moeglichkeiten: 'schliessen' nimmt ihn aus dem Markt, er bleibt aber erhalten und kann zurueckgeholt werden — das ist der normale Weg, wenn die Sache erledigt ist. 'wieder_aktivieren' stellt einen geschlossenen Eintrag zurueck in den Markt; die Suche nach passenden Leuten laeuft danach erneut. 'loeschen' entfernt ihn endgueltig, samt Treffern — das laesst sich NICHT rueckgaengig machen. Nur eigene Eintraege. Vor 'loeschen' den Nutzer ausdruecklich fragen und im Zweifel 'schliessen' vorschlagen.
| Name | Required | Description | Default |
|---|---|---|---|
| aktion | Yes | Was mit dem Eintrag passieren soll | |
| post_id | Yes | Der eigene Eintrag, aus meine_posts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the destructiveHint annotation by explaining that 'schliessen' is reversible and preserves the entry, while 'loeschen' permanently removes the entry and its matches irreversibly. It even advises asking the user before deleting and suggesting 'schliessen' as a safer alternative. This is exactly the behavioral context an agent needs for a mutating tool.
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 dense paragraph that front-loads the core action and then walks through the three options in a logical order. Every sentence adds either a behavioral consequence or a usage constraint, with no wasted words or repetition of schema fields.
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 tool with three subtle state transitions, no output schema, and destructive consequences, the description is fully sufficient: it covers the source of post_id, the semantics of each action, irreversibility, and required user confirmation before deletion. An agent can safely and correctly select and invoke the tool based solely on this text.
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?
The schema already documents both parameters (100% coverage), but the description enriches the aktion enum by detailing what each value does: removes from market but reversible, reactivates and restarts matching, permanently deletes. This turns an opaque enum into actionable decision guidance, though it adds nothing about post_id beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Nimmt einen eigenen Eintrag zurueck oder stellt ihn wieder ein') and then details the three distinct actions (schliessen, wieder_aktivieren, loeschen). This clearly differentiates it from siblings like post_erstellen and post_melden by limiting scope to managing one's own existing posts.
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 instructs that post_id comes from meine_posts and restricts to 'Nur eigene Eintraege', which tells the agent when this tool applies. It also describes which action fits which situation (schliessen as the normal completion, wieder_aktivieren for reopening, loeschen only after explicit user confirmation), but stops short of naming sibling alternatives to exclude.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aendert das eigene Profil des Nutzers. Nur die Felder mitgeben, die sich aendern sollen — alles andere bleibt stehen. 'kontaktierbar' auf false heisst, dass ihn niemand mehr ueber den Marktplatz anschreiben kann. Sag dem Nutzer, was du aenderst, bevor du es tust.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Angezeigter Name | |
| stichworte | No | Womit er zu tun hat, z.B. ['mathe','nachhilfe'] | |
| beschreibung | No | Kurzer Text ueber sich, hoechstens 300 Zeichen | |
| kontaktierbar | No | Ob ihn andere anschreiben duerfen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as non-readOnly, idempotent, and destructive, so the description adds value beyond them by explaining the partial-update behavior ('alle andere bleibt stehen') and the semantic consequence of 'kontaktierbar' being false. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, purposeful sentences with no filler. The most important operational rule (only send changed fields) comes first, followed by a field semantic and a user-interaction instruction. Every sentence 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?
For a four-optional-parameter update tool with no output schema, the description covers the essential behavior: scope, partial update, a key field's meaning, and the required user confirmation. It is sufficiently complete for an agent to call the tool correctly, though it does not describe error or result handling.
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 important semantics not in the schema: the partial-update rule affects all parameters, and the 'kontaktierbar' description clarifies the real-world consequence of false. This is meaningful added guidance.
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 starts with a specific verb and resource: 'Aendert das eigene Profil des Nutzers' (changes the user's own profile). It clearly distinguishes this tool from the sibling 'profil_ansehen' by emphasizing 'eigene' and 'aendern', so an agent can tell edit from view.
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 concrete usage guidance: only pass fields that should change, everything else stays untouched, and tell the user what will be changed before doing it. It does not explicitly name alternatives, but the context makes the edit-vs-view distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liest ein Profil. Ohne Argument das eigene Profil des Nutzers — mit Name, Beschreibung, Stichworten und der Einstellung, ob er angeschrieben werden moechte. Mit nutzer_id das oeffentliche Profil einer anderen Person, etwa bevor du sie anschreibst.
| Name | Required | Description | Default |
|---|---|---|---|
| nutzer_id | No | Wessen Profil. Weglassen fuer das eigene. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly, idempotent, openWorld, and non-destructive behavior. The description adds value beyond this by enumerating the profile contents returned (name, description, keywords, whether the user wants to be contacted) and by explaining the public/private distinction between own and others' profiles.
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 two compact sentences with the core action front-loaded. Every sentence carries useful information: what the tool does, what the two modes return, and when one mode is relevant.
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 only one optional parameter and no output schema, the description is largely complete: it names the returned fields for the own profile and distinguishes the public profile case. It could be slightly more explicit about exactly which fields appear when reading another user's public profile, but the main usage scenarios are 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?
The schema covers the parameter with 'Wessen Profil. Weglassen fuer das eigene', and the description reinforces and extends this by explaining that providing nutzer_id returns the public profile and is useful before messaging someone. This adds semantic context beyond the schema alone.
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 the specific verb 'Liest' with the resource 'Profil', and clearly distinguishes two modes: reading your own profile without an argument and reading another person's public profile with nutzer_id. This makes the tool's scope unambiguous and separates it from siblings like profil_aendern.
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 clear context for both invocation modes: use no argument for your own profile, use nutzer_id for another person's public profile, e.g., before writing to them. It does not explicitly name alternatives or say when not to use the tool, but the usage context 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.
nachricht_senden3 fields changedInput schema / properties / chat_idAdded value: +{
+ "description": "Bestehende Unterhaltung (Antworten). Aus chats_ansehen / benachrichtigungen.",
+ "type": "string"
+}Input schema / properties / post_id / descriptionPrevious value: -"Der Eintrag, auf den du dich beziehst"New value: +"Fremder Eintrag fuer den ersten Kontakt. Aus markt_ansehen / meine_treffer."Input schema / requiredPrevious value: -[
- "post_id",
- "text"
-]New value: +[
+ "text"
+]nachrichten_lesen1 field changedInput schema / properties / chat_id / descriptionPrevious value: -"Die Unterhaltung, aus chats_ansehen"New value: +"Die Unterhaltung, aus chats_ansehen / benachrichtigungen"benachrichtigungenchat_verwaltenchats_ansehenfeedback_gebenkategorien_ansehenmarkt_ansehenmeine_postsmeine_treffernachricht_sendennachrichten_lesenpost_erstellenpost_meldenpost_verwaltenprofil_aendernprofil_ansehen
Add one secure layer between your agents and this server.