Remote MCP for a concern-matching marketplace. Agents can browse listings, create posts, chat, and read matches.
Scored across 15 tools
Each tool targets a distinct resource+action (posts, matches, chats, messages, profile, categories, feedback), and descriptions explicitly clarify the boundaries. Minor overlap remains between benachrichtigungen and chats_ansehen, which both surface unread counts and point to the same poll-then-read workflow, and between chats_ansehen and nachrichten_lesen.
A clear German noun_verb convention dominates: markt_ansehen, profil_aendern, post_erstellen, nachricht_senden, chat_verwalten, etc. Deviations are limited to bare-noun names (benachrichtigungen, meine_posts, meine_treffer) and singular/plural drift within the same domain (chat_verwalten vs chats_ansehen, nachricht_senden vs nachrichten_lesen).
15 tools sits at the top of the well-scoped range and each one maps to a concrete marketplace operation. Nothing looks padded or redundant.
Strong lifecycle coverage: post create/browse/manage/report, match listing, full chat loop (list, read, send, mark read/archive), notifications, profile read/edit, categories and platform feedback. The notable gap is that post_verwalten can only close, reactivate, or delete a post — there is no way to edit a post's text without deleting and recreating it.
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?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds real behavior beyond them: unread-first ordering, the fact that ungelesen_gesamt aggregates notification rows AND unread chats without double counting, and that there is no push channel. It does not describe the response shape (e.g. what 'art=nachricht' entries look like end-to-end), which keeps it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core identity, then behavior, then the workflow as an arrow chain — efficient with no filler. Docked slightly because several fragments are telegraphic and the mojibake characters ('—') make the middle sentence harder to parse than it needs to be.
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?
No output schema exists, and the description compensates by explaining key response fields (art=nachricht, chat_id, ungelesen_gesamt) and how to act on them. For a 2-parameter read tool with full annotation coverage this is close to sufficient; only the entry structure for hit-type results is left implicit.
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 both parameters (anzahl, nur_ungelesen) are already documented. The description hints at unread-first default ordering, which lightly reinforces nur_ungelesen, but it adds no format, bounds, or interaction detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first clause names the resource precisely ('Posteingang fuer Agents: Treffer, Chat-Nachrichten und Plattform-Hinweise'), which tells an agent this is a unified inbox rather than a single-type list. It is meaningfully distinct from siblings like meine_treffer and chats_ansehen, though it never says explicitly that it is the aggregate view of them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit polling instruction ('Kein Push - pollen') and a concrete follow-up flow: 'wenn ungelesen_gesamt > 0 -> nachrichten_lesen -> antworten', naming the sibling tools to chain into. Missing only the reverse case (when NOT to call this, e.g. use meine_treffer for a single-type listing).
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 the safety profile (readOnly, idempotent, closed-world), and the description adds real value on top: it discloses that the tool never pushes updates and must be polled, what fields come back, and the unread-count escalation path. It does not mention pagination limits or ordering guarantees beyond 'letzte Nachricht', but the missing return schema is largely compensated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the payload contents, then the polling caveat, then the escalation workflow – no filler. Minor deduction for the mojibake em-dash ('—') that slightly hurts readability.
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 carries the return-value burden itself and does so by enumerating the per-chat fields, plus it adds the crucial non-obvious fact that there is no push and the tool must be polled. Nothing an agent needs to select and invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'anzahl' is fully documented in the schema (1-100, default 30, newest first). The description adds nothing about it, so the baseline 3 applies – no deficiency, but no extra value either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb and resource ('Listet die laufenden Unterhaltungen') and enumerates exactly what each row contains (counterpart, post, mein_post flag, empty status, last message, unread count). This clearly distinguishes it from nachrichten_lesen/nachricht_senden, which it names as follow-up tools, though it never contrasts itself with chat_verwalten or benachrichtigungen.
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 explicit operational guidance: there is no push mechanism, so poll it when the user asks whether anyone wrote or on a periodic basis. It also states the concrete branch 'Bei ungelesen_gesamt > 0: nachrichten_lesen, dann nachricht_senden mit chat_id', which tells the agent exactly which sibling to call next and in what order.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, so the bar is lower, yet the description adds real value: archiving is explicitly not deletion and the conversation reappears when someone writes again, and 'gelesen' explains its effect on the unread counter. It does not cover permissions or return behavior, keeping it at 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences: purpose first, then each action, then the parameter source. Every sentence carries information. Minor deduction for the mojibake character ('—') in the middle of the text, which slightly harms readability.
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 two required parameters, annotations present and no output schema, the description covers everything an agent needs to call it correctly: both actions, their effects, and chat_id provenance. Only permission/error behavior and the exact response shape are unstated, which is acceptable given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline would be 3, but the description meaningfully expands the enum parameter: the schema only says 'Was passieren soll' while the text spells out the exact semantics and side effect of each of the two values. It also reinforces chat_id provenance.
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 resource (eine Unterhaltung) and defines both concrete operations ('gelesen' sets read state so the counter is correct; 'archivieren' hides it from the list) rather than leaving the vague verb 'aufraeumen' alone. It is clearly distinguishable from siblings like chats_ansehen or nachrichten_lesen, though the headline verb itself is generic.
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?
Each enum action is explained well enough to imply when to use it, and the description tells the agent where chat_id comes from ('aus chats_ansehen'). However, there is no explicit when-not guidance and no statement of when to prefer chats_ansehen or nachrichten_lesen instead.
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?
Annotations only say this is a non-destructive, non-idempotent write with no open-world access. The description adds genuinely useful behavioral context: "Landet bei den Betreibern", telling the agent the text is routed to the platform operators (a human-facing destination) rather than stored locally. It does not describe any confirmation or response, but that is a minor gap.
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, front-loaded with what the tool does, then destination, then the usage condition. Every sentence carries information and none repeats the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter submission tool with full schema coverage, no output schema and clear annotations, the description covers purpose, trigger and destination adequately. It could note that the user's wording should be preserved verbatim, but nothing essential 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?
Only one parameter and schema coverage is 100%, with the schema itself already saying the text should be the user's own words. The description's "was nicht funktioniert, was fehlt, was stoert" loosely describes content but adds no formatting or length guidance beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Gibt Rueckmeldung zur Plattform selbst weiter") and scopes it away from sibling territory by insisting the feedback concerns the platform, not posts or users. It does not name the nearest alternative (post_melden) explicitly, so the differentiation is implied rather than spelled out.
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 a clear trigger: use it when the user complains about the platform or expresses a wish, "statt es nur zu bestaetigen". That contrast tells the agent when not to just acknowledge. It stops short of naming sibling tools for other kinds of complaints.
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 cover read-only, idempotent, non-destructive and open-world behavior, so the bar is lower. The description still adds value by disclosing what the response contains (active-entry counts broken down by Gesuche vs. Angebote) and its role as an entry point, though it says nothing about result size or ordering.
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 packed sentences with the primary usage ('Nutze das zuerst') front-loaded and no filler. Minor blemish: an encoding artifact ('—') in the dash, but meaning is unaffected.
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 parameterless overview tool with rich annotations and no output schema, the description gives enough to call it correctly and interpret the result at a high level. A brief note on what each category entry looks like would close the last 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?
Zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond confirming the tool takes no input, which it implicitly does by describing a global listing.
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 ('Listet alle Fachgebiete') plus the exact payload — count of active entries split into Gesuche and Angebote. An agent can distinguish this overview tool from markt_ansehen without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sequencing: 'Nutze das zuerst' to discover which areas exist and where activity is, then 'danach gezielt mit markt_ansehen hineingehen'. It names the alternative sibling and the condition that selects it.
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 readOnly, idempotent, non-destructive, openWorld, so safety is covered. The description adds real behavioral context beyond them: the response exposes 'gesamt' and 'weitere', pagination terminates when 'weitere' is false, and an incremental-sync pattern via 'seit' is supported. It does not describe rate limits or what fields an individual entry carries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and the no-arguments default, then pagination and sync guidance in a logical order. It is somewhat long with all-caps emphasis and visible encoding artifacts ('—'), but nearly every sentence carries usable 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?
With no output schema, the description compensates by naming the return keys 'gesamt' and 'weitere' and the loop condition for paging, which is what an agent needs to drive pagination. It still leaves the shape of individual entries undescribed, a minor gap for a 7-parameter listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining how 'seite' and 'weitere' interact for paging and how 'seit' enables delta sync, which is workflow meaning beyond the per-field schema text. The other filters (art, suche, anzahl, sortierung) are left entirely to the already-complete 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: reads entries from Open Platform, a location-based marketplace for offers (Angebote) and requests (Gesuche). An agent can tell it is a read/list tool over market posts, but the description never distinguishes it from close siblings like meine_treffer or meine_posts, so sibling differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says all filters are optional and that calling without arguments returns everything, and it prescribes two concrete workflows: page through while 'weitere' is true, or do an initial full pull then incremental pulls with 'seit'. It also points to kategorien_ansehen for valid 'fachgebiet' values. It stops short of stating when to prefer this over meine_treffer/meine_posts.
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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the result shape: header fields, "von_mir markiert eigene Nachrichten", and the default window "letzte 50, aelteste zuerst". That ordering and self-message flagging is behavior an agent cannot infer from 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 carrying a distinct fact (what it returns, where chat_id comes from, default ordering, response flagging) with the primary purpose and the usage imperative front-loaded. 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?
With no output schema, the description correctly takes on the burden of describing return contents and the von_mir flag, which makes the tool callable and interpretable. The one gap is pagination: anzahl caps at 200 and nothing says how to reach older messages beyond the default window.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented; the description adds provenance for chat_id ("kommt aus chats_ansehen oder benachrichtigungen") which tells the agent where to obtain a valid value. The "Standard: letzte 50" largely restates the schema's default, so it earns a 4 rather than a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Liest den Verlauf einer Unterhaltung") and enumerates what the response contains (post_id, Eintrag-Snippet, mit wem, mein_post), so an agent knows exactly what it gets. The closing line "Vor dem Antworten lesen" implicitly contrasts it with nachricht_senden, making the read-versus-write split obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ("Vor dem Antworten lesen — sonst schreibst du an etwas vorbei") and names where the required chat_id must come from (chats_ansehen or benachrichtigungen), which is real routing guidance. No explicit when-not-to-use case or named alternative tool, 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.
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 annotations, it discloses rate limiting ('Hoechstens 20 pro Stunde'), absence of push notifications with polling guidance, acting under the account holder's name, and the marketplace-versus-private-inbox distinction. These are exactly the behavioral details an agent needs before sending.
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 purpose and identity constraint are front-loaded, followed by clear reply/first-contact branches, rate limit, polling behavior, and user-confirmation guidance. It is dense but every sentence provides operational value.
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 non-idempotent, open-world send tool with no output schema, the description covers identity, rate limit, no-push polling, parameter branching, and user confirmation. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds the critical mutual-exclusivity rule and workflow meaning for chat_id versus post_id. It does repeat some schema text, but the 'bevorzugt' note and chat-creation consequence add real value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Schreibt im Marktplatz-Chat') and scope ('Marktplatz-Kontakt, kein privater Posteingang'). It distinguishes reply versus first-contact behavior and names relevant sibling tools, so an agent can identify it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use chat_id for replies from chats_ansehen or benachrichtigungen, and post_id for first contact from markt_ansehen or meine_treffer. It also states 'Genau eines von beidem', describes polling after send, and instructs showing text to the user before sending.
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?
The annotations show this is a write operation with an external effect: readOnlyHint is false and openWorldHint is true. The description adds several useful practical details: the entry is public, there is a rate limit of 5 per hour, and the platform assigns a category and matches people in the background. It does not explain what happens on failure or what the response looks like.
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 purpose comes first, followed by writing style, platform behavior, the rate limit, and the confirmation requirement. Each sentence earns its place, and there is no filler, though the confirmation step could have been placed earlier.
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?
There is no output schema, and the description still covers the essentials: it states the public visibility, the rate limit, the confirmation requirement, and the background matching. The response format is mentioned only indirectly — through the 'ort' field — so the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents 'art', 'ort', and 'text' in detail, including the fallback behavior for 'ort'. The description adds style guidance for 'text' — one to two sentences, concrete, and without marketing language — but otherwise it does not add information beyond what the schema provides.
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 specific verb and resource: it posts a 'Gesuch oder Angebot' on behalf of the user, matching the 'art' enum. This is clear enough to separate it from 'post_verwalten' or 'meine_posts', even though no sibling is named.
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 a prerequisite before calling: ask the user whether they really want to post, since the entry is publicly visible. It also gives a rate limit of 5 per hour. What is missing is a direct comparison with alternative tools such as editing, managing, or reporting an existing post.
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?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds that a human moderator reviews the report afterward and that the agent should confirm with the user first, which is valuable behavioral context beyond the annotations. It stops short of describing response behavior or follow-up status.
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 short and front-loaded: it states the action and report categories first, then the post_id source, then the human-review and confirmation guidance. Every sentence adds operational value without 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?
For a non-destructive but consequential moderation action with no output schema, the description covers the key workflow: where post_id comes from, what the tool does, and that a human reviews it after confirmation. It could say more about what the agent should report back after submission, but it is otherwise complete enough to call 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?
Schema coverage is 100%, so the schema already documents grund, post_id, and anmerkung. The description still adds useful semantics by explaining that post_id is obtained from markt_ansehen and by listing report reasons that map to the grund enum, giving the agent more than the raw 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 uses a specific verb ('Meldet') and resource ('einen fremden Eintrag') and enumerates the report categories (Spam, Betrug, Beleidigungen, unangemessene Inhalte), which distinguishes it from post_verwalten and other posting tools. An agent can immediately tell this is a moderation-report action, not a content-edit action.
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 clear workflow guidance: post_id comes from markt_ansehen, the call mirrors the website report button, and the user should be asked for confirmation first. It does not explicitly name when not to use it or contrast it with another reporting alternative, but the context is still strong enough to route the agent correctly.
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?
Beyond the annotations, the description discloses that 'schliessen' is reversible and keeps the post, that 'wieder_aktivieren' re-runs matching, and that 'loeschen' permanently removes the post along with matches and cannot be undone. It also adds ownership constraints and a confirmation requirement for destructive deletion.
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 operation, then moves through post_id provenance, the three action modes, and the destructive-action warning. Each sentence carries useful information, and the longer length is justified by the three distinct behaviors and the safety requirement.
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 mutation tool with no output schema, the description covers purpose, ownership scope, parameter meaning, action semantics, reversibility, side effects, and a safety protocol. Combined with the annotations, an agent has enough information to select and invoke 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 schema coverage is already 100%, the description adds substantial meaning by explaining each enum value's behavior and consequence. It also clarifies that post_id refers to one's own entry from meine_posts, which is more than the schema itself 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 action on a specific resource: managing one's own post by taking it back, reactivating it, or deleting it. It also scopes the tool to 'eigene Eintraege' and names where post_id comes from, making it distinguishable from post creation, reporting, and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains when to use each of the three actions: 'schliessen' as the normal path when something is done, 'wieder_aktivieren' for closed posts, and 'loeschen' for permanent removal. It also gives a clear guardrail to ask the user before deletion and to suggest 'schliessen' when in doubt.
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?
Annotations already mark the tool as destructive and idempotent. The description adds important context beyond that: unspecified fields are preserved, and setting 'kontaktierbar' to false has the concrete effect of preventing anyone from messaging the user via the marketplace. It also instructs the agent to tell the user what will change beforehand.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action and then adds only the details an agent needs: partial update semantics, a key parameter effect, and a confirmation 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 mutation tool with optional parameters, no output schema, and annotations covering safety, this is nearly complete. The description could say more about validation or return behavior, but the schema already documents field-level constraints such as the 300-character limit.
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 meaning beyond the schema by clarifying partial-update behavior and explaining the specific consequence of 'kontaktierbar=false'.
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: changing the user's own profile. It is clearly distinct from the sibling profil_ansehen without naming it, and an agent can immediately tell what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: pass only changed fields and notify the user before applying changes. It implies when to use this versus viewing the profile, but does not explicitly name alternatives or exclusion cases.
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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description is free to add the parts that matter: the exact content returned (Name, Beschreibung, Stichworte, contactability setting) and the important nuance that another person's profile is only the public view. It stays consistent with readOnlyHint and adds real value 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?
Three short sentences, front-loaded with the core action, then the no-argument case, then the nutzer_id case. Every sentence carries information and none repeats annotations or schema text.
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 correctly compensates by listing the fields returned, and with only one fully documented parameter the remaining burden is small. It lacks only an edge case such as what happens for an unknown nutzer_id, which is minor for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: omitting nutzer_id yields the caller's own profile while supplying it yields the other person's *public* profile. That privacy distinction is genuinely useful for deciding which value to pass.
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 ('Liest ein Profil') and immediately splits the behaviour into two named modes: own profile without arguments, and another person's public profile with nutzer_id. It is clearly distinguishable from the write sibling profil_aendern, though it never names that alternative 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?
Gives concrete usage context: without arguments for the user's own profile, with nutzer_id when you want to see someone else's public profile 'etwa bevor du sie anschreibst'. That is a clear trigger condition, but there are no explicit exclusions or pointers to sibling tools.
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.
post_erstellen1 field changedInput schema / properties / ort / descriptionPrevious value: -"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."New value: +"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."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.