Open Platform

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

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that by specifying the ordering ('Ungelesene zuerst') and the scope ('des Nutzers'), which helps the agent understand what results to expect.

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, well-structured sentence that front-loads the core function, adds useful specifics, and ends with a concrete use-case. Every part earns its place and there is no 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 simple read-only list tool with full parameter documentation and safety annotations, the description is complete enough. It covers what the tool shows, the ordering, and the intended scenario. No output schema is present, but the return value is adequately implied by 'zeigt die Benachrichtigungen'.

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%, and the parameter names plus descriptions already explain anzahl and nur_ungelesen. The description adds only a marginal connection via 'Ungelesene zuerst', so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool shows the user's notifications, enumerating specific types (new hits, new messages, platform notices). It is clear and specific, but it does not explicitly contrast with sibling tools like nachrichten_lesen or meine_treffer, so it slightly misses the top bar for 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 phrase 'Der schnellste Weg zu der Frage „gibt es was Neues?“' gives a clear use case for when to call this tool: when the user wants a quick overview of anything new. It does not explicitly state when not to use it or name alternatives, but the intended context is reasonably clear.

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

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

The annotations already declare the tool read-only and idempotent; the description adds value by stating the user-specific scope and the exact result content, including unread counts. It does not contradict 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 front-loaded sentences explain the purpose, the trigger, and the follow-up tool with no filler. 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 one-parameter read-only list tool, the description, parameter schema, and annotations together provide everything needed: what it returns, when to call it, and how to proceed. The lack of an output schema is mitigated by the explicit list of returned information.

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 describes the single optional parameter with range, default, and ordering ('1-100, Standard 30, neueste zuerst'). The description adds no extra parameter detail, so the high schema-coverage baseline 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 description uses a specific verb and resource, 'Listet die laufenden Unterhaltungen des Nutzers', and enumerates the returned data: with whom, for which entry, last message, and unread count. It also clearly distinguishes from sibling nachrichten_lesen by pointing to it as a follow-up.

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 an explicit trigger condition: 'Nutze das, wenn dein Nutzer fragt, ob sich jemand gemeldet hat oder was es Neues gibt.' It also tells the agent what to do next, read messages via nachrichten_lesen with chat_id, which is a clear routing to the right sibling.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds concrete behavior beyond that: the default limit of 50 messages, oldest-first ordering, and a von_mir flag per message. This enriches the read-only profile with the details an agent needs to interpret results. 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 short sentences each carry distinct information: purpose, source/provenance of chat_id, default behavior and interaction guidance. There is no filler, and the most important fact is front-loaded.

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 simple read-only tool with no output schema, the description gives enough usage context and even reveals a key output field (von_mir). It lacks a fuller description of the returned message fields and any pagination beyond the optional anzahl, which is why it is not a perfect 5.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the default of 50 and the chat_id source, but this adds little beyond the schema, which already documents anzahl as 1-200 with default 50 and chat_id as coming from chats_ansehen.

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: 'Liest den Verlauf einer Unterhaltung' (reads the history of a conversation). It further distinguishes itself from chats_ansehen by stating that the chat_id comes from that tool, making clear that this tool consumes a selected conversation rather than listing conversations.

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 timing guidance: 'Nutze das, bevor du antwortest — sonst schreibst du an etwas vorbei, das schon geklaert ist.' This tells the agent to fetch history before replying and why. It does not explicitly contrast with alternatives or state 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.

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

Goes well beyond annotations: acts on behalf of and under the account holder's name, no private inbox/no foreign identity, first message creates a chat while later ones continue it, max 20/hour, and mandatory user confirmation before sending. 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?

Every sentence adds operational value: action, intended use, identity framing, parameter sourcing, chat lifecycle, content guidance, rate limit, and confirmation requirement. It is front-loaded with the core action and stays focused.

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 send action with no output schema, the description covers prerequisites, behavioral effects, limits, and user-confirmation needs. There are no significant gaps that would prevent an agent from invoking it 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 already documents both parameters at 100% coverage. The description adds value by telling the agent the post_id must come from markt_ansehen or meine_treffer and instructs content quality ('Schreib konkret und sag dazu, worum es geht'), which is 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 action: 'Schreibt der Person hinter einem Eintrag ueber den Marktplatz-Chat von Open Platform.' This clearly identifies the verb, resource, and channel, and the sentence 'Das ist die dafuer vorgesehene Kontaktaufnahme' plus the distinction from private inbox/foreign identity differentiates it from read or management siblings.

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

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

Provides clear when-to-use context: contacting someone who publicly posted a listing and expects to be contacted. It also tells the agent where to obtain post_id from markt_ansehen or meine_treffer and to show the text before sending, but it does not explicitly name alternative tools or state when not to use it.

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

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.

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.

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.

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.

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.