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

With no annotations provided, the description should disclose safety, side effects, or operational characteristics. It only mentions that execution happens outside the MCP event loop, which is a technical detail but does not inform the agent about permissions, reversibility, blocking behavior, or return values. The description misses the opportunity to compensate for the lack of 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 a single sentence, which is concise, but it is under-specified. It does not front-load the essential purpose; instead, it gives an implementation detail. A short description is acceptable, but this one is vague and could have been more informative without being longer.

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

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

Given this is a 3-parameter tool with no annotations and no schema descriptions, the description is far from sufficient. Even though an output schema exists, the description does not provide enough context about when to use the tool, what it does, or how parameters relate to behavior. It is inadequate for an agent to select and invoke 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 description coverage is 0%, and the description provides no information about the three parameters (query, portal_name, allow_external). It does not explain what values these parameters take, what they represent, or how they influence the tool's behavior. The description entirely fails to compensate for the lack of schema 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 states it 'executes the older real browser path outside the MCP event loop,' but does not clearly explain what the tool does with the portal or query. The verb is generic ('executes') and the resource is an implementation detail ('browser path'), making the purpose vague and indistinguishable from sibling tools like portal_suche or portal_recherche.

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?

There is no guidance on when to use this tool versus alternatives. The phrase 'outside the MCP event loop' hints at a specific use case, but no explicit when-to-use or exclusions are provided. Sibling tools are not mentioned, and no context is given for selecting 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?

With no annotations, the description carries the full burden. It states the action 'deletes' but does not disclose irreversibility, permission requirements, or whether it affects active sessions. The description is terse and lacks additional context that would inform an agent about side effects.

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, concise sentence that directly conveys the tool's action and target. It is appropriately sized with no redundant words 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 simple delete operation with one parameter, the description gives the essential action. However, it lacks context on side effects or usage, and because there are no annotations, the overall guidance is minimal. The presence of an output schema reduces the need to describe return values.

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 0%, so the description must compensate. It does not explain what 'portal_id' refers to or how to obtain it. The schema title 'Portal Id' is minimally descriptive, but the description adds no value beyond that.

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 'Loescht' (deletes) and a clear resource 'hinterlegte Anmeldedaten eines Portals' (stored login data of a portal). It clearly distinguishes from sibling tools like 'anmeldedaten_hinterlegen' (store credentials) and 'portal_sitzung_loeschen' (delete session).

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?

No guidance is provided about when to use this tool instead of alternatives. It does not mention prerequisites, such as needing an existing portal_id, or contrast with sibling operations like storing or updating credentials. Usage context must be inferred.

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 annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable security context: credentials are encrypted using Fernet and plaintext is never logged. However, it does not disclose whether the tool is idempotent, what happens on duplicate portal IDs, or any required permissions. This is a partial but meaningful transparency effort.

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 exceptionally concise—two short clauses in German. Every word contributes meaning: 'hinterlegt' (stores), 'verschluesselt' (encrypted), 'Fernet' (algorithm), and the no-logging guarantee. There is no fluff, and the structure is front-loaded with the action.

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?

This is a mutation tool with no annotations and a very brief description. While an output schema exists (so return format is not needed), the description omits critical context such as whether the operation overwrites existing credentials, how to handle errors, or what side effects occur. For a 3-parameter tool, the description is too sparse to be fully actionable.

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 0%, and the description adds no parameter-level information. The parameter names (passwort, portal_id, benutzername) are somewhat self-explanatory, but the description does not explain formats, constraints, or relationships between parameters. It fails to compensate for the lack of schema 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 identifies the action ('Hinterlegt Anmeldedaten' = stores login data) and the resource, which distinguishes it from the sibling 'anmeldedaten_entfernen' (remove). However, it does not specify whether this creates or updates existing credentials, and the verb 'hinterlegen' is slightly generic, so it is not a 5.

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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., portal ID must exist) or scenarios where this is preferred over portal_login or other siblings. No exclusions or alternative tool references are given.

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 reveals that the tool compares offers to a profile and sorts results, but it does not disclose side effects, required permissions, or error behavior. With no annotations provided, this limited behavioral disclosure is insufficient for an agent to anticipate consequences.

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, front-loaded sentence with no filler words. It efficiently communicates the core action and result.

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 two parameters and no annotations, this description is too sparse to fully prepare an agent. It omits details about input formats, the sorting criterion, and how results are structured, making it inadequate for confident invocation.

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 description loosely maps to the parameters by mentioning 'Angebote' and 'Profil', but does not explain their types, formats, or relationships beyond the schema. With 0% schema description coverage, the description should offer more detail, such as what angebote entries look like or what profil_pfad points to.

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 evaluates offers against the profile and returns sorted matches, using a specific verb and resource. It differentiates from sibling search/analysis tools by its focus on matching and sorting.

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?

No guidance is provided about when to use this tool versus alternatives, such as portal_suche or analysiere_echtes_portal. The description lacks any context like prerequisites 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Zeigt' implies a non-mutating read operation, but the description does not explicitly address side effects, the effect of portal_id, or behavior when drivers are unavailable, limiting transparency.

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, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose while remaining compact.

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 core functionality but omits parameter semantics and usage context. Since an output schema exists, return values are not needed, but the missing portal_id explanation is a significant gap for a simple status tool.

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

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

The schema has 0% description coverage and the description does not mention portal_id at all. The optional parameter's meaning is entirely undocumented, forcing the agent to guess whether it filters by portal or has other effects.

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 'Zeigt verfügbare Browser-Treiber und den Sitzungsstatus der Portale' uses a specific verb ('Zeigt') and resource ('Browser-Treiber', 'Sitzungsstatus'), clearly distinguishing it from sibling tools like portal_login or liste_portale. It states exactly what the tool reports, making the purpose unambiguous.

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 provides no guidance on when to use this tool versus alternatives such as portal_login or portal_sitzung_loeschen. It only states what it shows, without any context on suitable situations or exclusions, leaving the agent to infer usage.

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 annotations, the description carries full burden. It states the tool writes a report and returns a path, implying a filesystem side effect, but it does not disclose overwrite behavior, error conditions, or required prior steps. This is insufficient for a mutation 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, concise sentence that front-loads the primary action and return value without any waste.

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 four parameters, none required, and no parameter descriptions, the brief description is insufficient for reliable invocation. It lacks details on parameter relationships, defaults, and its role in the overall evaluation workflow.

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 0%, so the description must compensate. It mentions 'Angebote' and 'Markdown-Bericht' relating to 'angebote' and 'bericht_pfad', but it does not explain 'quellen' or 'profil_pfad', nor the expected structure of the inputs.

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 evaluates offers, writes a Markdown report, and returns the path. This distinguishes it from sibling 'bewerte_angebote' by adding the report-writing and path-delivery responsibilities.

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?

No guidance is given on when to use this tool versus alternatives like 'bewerte_angebote'. There is no mention of prerequisites, workflow position, 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 annotations, the description must disclose behavioral traits, but it only says 'reads and validates'. It does not mention what happens on invalid profiles, whether any side effects occur, or if errors are raised, leaving safety and failure modes undocumented.

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, tightly worded sentence that states the action and object without unnecessary words. It is front-loaded with the verb and resource, making it highly efficient.

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 tool is simple with one optional parameter and an output schema, so the description covers the basic function. However, it omits error handling behavior and usage context relative to sibling tools, leaving gaps for an agent unfamiliar with the workflow.

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 single parameter 'profil_pfad' is self-explanatory by name, and the description adds context that the profile is a job search profile in JSON format. However, schema description coverage is 0%, so the description only partially compensates by implying the path parameter without explicitly detailing it.

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

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

The description clearly states the tool reads and validates a specified job search profile (JSON + JSON schema). It uses a specific verb+resource structure and is distinct from sibling tools like portal_suche or portal_login.

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?

No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description only states what it does, leaving the agent to infer its place in the workflow.

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?

There are no annotations, so the description must fully convey behavioral traits. 'Transparenter Zugangsstatus' hints at providing status information but does not explicitly state that the tool is read-only or that it has no side effects. No permissions, rate limits, or return behavior are mentioned.

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, concise sentence that front-loads the verb and resource. It contains no filler and every word contributes meaning.

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 tool is simple (no parameters) and an output schema exists, so the description needs less detail. However, terms like 'aktive Adapter' and 'weitere Portale' are vague without additional context, and it does not explain what 'transparenter Zugangsstatus' entails. The description is serviceable but leaves room for clarification.

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, so the baseline is 4. The description does not add parameter-specific meaning, but since there are no parameters to document, this is adequate.

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 a specific verb 'Listet' (lists) and a resource ('aktive Adapter und weitere Portale'), which distinguishes it from search or login tools. However, it does not explicitly name sibling tools or contrast its scope beyond the phrase 'weitere Portale', leaving some ambiguity about what counts as an 'Adapter'.

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?

No guidance is provided on when to use this tool versus alternatives. The description gives no context, prerequisites, or exclusions, and there are no hints about typical scenarios (e.g., 'use this to check availability before logging in').

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 annotations, the description must disclose behavior, but it only mentions that the search happens in a worker thread. It does not state whether the operation is read-only, whether it launches browser sessions, modifies profiles, or has side effects. This is a significant gap for a tool that likely interacts with browser state.

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 concise sentence, front-loaded with the verb and resource. However, it is under-specifying: while it is brief, it omits critical information such as parameter semantics and usage context. Being short is helpful, but not at the expense of necessary detail.

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?

Despite having an output schema, the description lacks essential context about what 'aktive Browser- und Feed-Quellen' means, how the worker thread affects the caller, or whether there are prerequisites. Given the tool's complexity (4 optional parameters, multiple portal-related siblings), this description is incomplete.

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 0% and the description mentions none of the four parameters (ort, query, portal_ids, profil_pfad). The agent receives zero explanation of what these fields mean or how they relate to the search. The description entirely fails to compensate for the schema's lack of 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 states a clear verb ('Durchsucht') and resource ('aktive Browser- und Feed-Quellen'), plus a technical context ('Worker-Thread'). It communicates the tool's function effectively, though it does not explicitly distinguish it from sibling tools like 'portal_suche' or 'analysiere_echtes_portal'.

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?

There is no guidance on when to use this tool vs. alternatives. No use cases, prerequisites, or exclusions are provided. The only implicit hint is the tool name, which is insufficient for an agent to choose correctly among the many sibling tools.

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 annotations, the description bears full responsibility for disclosing behavior. It reveals that the tool opens a visible browser and saves login, but does not clarify whether login is persistent, whether it overwrites existing credentials, or if any setup is required. The mutating nature of 'speichert den Login' is noted, but side effects and reversibility are absent.

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, concise sentence that front-loads the primary action. Every word contributes meaning, with no redundant phrases or irrelevant details.

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 parameters, no annotations, and minimal description, the context is incomplete. It omits when to use the tool, what 'auto' controls, and expected outcomes beyond opening and saving login. The output schema exists but does not offset the lack of operational guidance.

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?

Input schema has no parameter descriptions (0% coverage), and the tool description does not explain the purpose of 'auto', 'sichtbar', or 'portal_id'. It only loosely maps 'sichtbar' to 'sichtbar fuer den Nutzer' but leaves the other parameters undefined, failing to compensate for the schema's lack of detail.

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 function with a specific verb and resource: 'Oeffnet den Portalbrowser sichtbar fuer den Nutzer' (opens the portal browser visibly) and 'speichert den Login' (saves the login). This distinguishes it from sibling tools like browser_status (status only) and anmeldedaten_hinterlegen (storing credentials separately).

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or explicitly say to prefer this over sibling tools like anmeldedaten_hinterlegen. Usage context is only implied by the action described.

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 annotations provided, the description carries the full burden of behavioral disclosure. It only says 'outside the MCP loop', which is cryptic, and does not explain side effects (e.g., writing a report file), permissions, or what 'loop' means. This is a significant gap for a tool that likely creates or modifies files.

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 sentence, which is concise in length, but it is severely under-specified. It provides no useful detail about inputs, outputs, or behavior, so the brevity does not contribute to usability.

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?

Despite having an output schema, the description is far from complete for a tool with five parameters and no annotations. It fails to explain the purpose of parameters, the meaning of 'outside the MCP loop', or how the research/evaluation/report flow works, making it inadequate for an agent to use 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 description coverage is 0%, and the description does not mention any parameter. None of the five parameters (portal_id, ort, profil_pfad, bericht_pfad, max_begriffe) are explained, leaving the agent to guess their meaning and expected 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 states the tool 'researches, evaluates and writes a report', giving a clear sequence of actions and a resource (report). However, it does not specify which portal or input is used, and it does not distinguish itself from sibling tools like bewerte_angebote and erstelle_bericht, which appear to cover similar ground.

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?

There is no guidance on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, leaving the agent without any decision support.

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 annotations, the description carries the full behavioral burden. It discloses the client-side scope, which is a useful behavioral detail, but does not mention whether authentication is required, what happens if no session exists, or any side effects beyond clearing the local session. The client-side qualifier provides some transparency but leaves gaps.

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 concise sentence that front-loads the core action and scope, with no filler. It is appropriately sized for a simple tool and every word contributes meaning.

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?

Though an output schema exists, the description omits essential context such as parameter semantics and usage guidelines, and does not clarify behavior when the session is absent. The simple tool could be used with just the name, but the description alone leaves the agent under-informed for correct invocation.

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 has zero description coverage for portal_id, and the tool description does not explicitly explain the parameter. However, the phrase 'eines Portals' implies that portal_id identifies which portal's session to delete, providing a minimal semantic link. The description does not add detail about format or how to obtain the ID.

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 deletes the saved session of a portal, using the specific verb 'Loescht' and the resource 'gespeicherte Sitzung eines Portals'. It also clarifies the client-side logout scope, which distinguishes it from sibling tools like portal_login and anmeldedaten_entfernen.

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 provides no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions such as not affecting stored credentials. The clause 'Logout auf Client-Seite' implies a client-side operation but does not specify when to invoke it (e.g., after portal_login).

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 annotations, the description carries the transparency burden. It discloses two behavioral traits: headless operation and conditional login use. This is useful, but it omits other behavioral context like result handling, external effects, or authentication prerequisites beyond the login condition.

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 sentence, front-loaded with the core purpose and free of redundancy. It loses one point because essential parameter and usage details are omitted, which is not purely a matter of brevity.

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 five parameters, no annotations, and an output schema, the description is incomplete. It does not explain the required portal_id, optional filters, engine/profil_pfad defaults, or how login integration works, leaving the agent without enough context for reliable invocation.

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 0%, and the description does not explain any of the five parameters (ort, query, engine, portal_id, profil_pfad). The description must compensate for missing schema documentation, but it provides no parameter semantics whatsoever.

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: 'Sucht headless nach Stellen' (searches headlessly for jobs), which identifies the function and resource. However, it does not distinguish this tool from sibling tools like portal_recherche or mehrportal_suche.

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?

No guidance is given about when to use this tool compared to alternatives. The only usage-related comment, 'Login wird nur bei Portalpflicht verwendet', explains login behavior but does not help an agent choose between portal_suche and sibling search tools.

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