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

With no annotations, the description carries the behavioral burden. It discloses that only completed notes are removed, open notes remain untouched, and that the action is a destructive cleanup beyond the checkbox action. It does not mention irreversibility or confirmation, but the destructive scope is clearly stated.

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 compact and front-loaded, starting with the primary purpose, then providing a short rationale and an Args section. The explanatory sentences are relevant, though the date reference adds a minor extra 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?

For a simple two-parameter tool without annotations or output schema, the description covers the trigger, the deletion scope, and the preservation of open notes. However, it does not fully specify the interaction between nr and nur_erledigte or what the tool returns after success, leaving some ambiguity for an agent.

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 add parameter meaning. It explains 'nr' as a single note number with the special value 0 meaning no single deletion, and 'nur_erledigte' as a way to discard all completed notes while preserving open ones. There is slight ambiguity about the effect of nur_erledigte=false and how it interacts with nr.

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 concrete verb-resource pair ('Räumt Prüfhinweise weg') and identifies the scope: only processed check notes are removed. It does not explicitly contrast with siblings like report_check_note, but the cleanup semantics are 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 gives clear context on when to use the tool: checking a note alone is not enough, completed notes remain in the list and hide new ones, so the user should call this tool after implementing a note. It does not enumerate exclusions or alternatives, but the triggering condition is evident.

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 full responsibility for behavioral disclosure. It explicitly states that the tool empties the session storage completely and returns the number of deleted entries, conveying both the destructive nature and the observable result. This is sufficient for a no-argument reset operation.

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 short sentences with no filler. The action is front-loaded, followed by usage guidance and the return-value note, making it easy for an agent to parse quickly.

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 tool, the description covers everything needed: what it clears, when to use it, and what it returns. Since there is no output schema, explicitly stating that it returns the deletion count is valuable and makes the tool self-contained.

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 already reflects that with an empty properties object. With no parameters to document, the description appropriately focuses on behavior and return value instead; the baseline of 4 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 opens with a specific verb and resource: 'Leert den Session-Speicher der Bridge komplett.' It clearly states the action, the scope (the bridge session storage), and the outcome (returns how many entries were deleted). This sufficiently distinguishes it from siblings like clear_check_notes, which targets a different resource.

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 context: useful at the start of a new task or after bridge timeouts. It does not mention alternatives or explicit when-not-to-use scenarios, but the provided context is clear enough for an agent to decide when this tool is appropriate.

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 and does well: it states that the tool creates a new file, never overwrites, requires the init file to exist and be non-empty, requires the target file not to exist, and requires both paths to be absolute .3d paths. It also implies the tool does not open the file itself by instructing the caller to use open_document afterwards.

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 compact, well-structured, and front-loaded with the main purpose before detailing constraints. Every sentence earns its place: path requirements, existence rules, no-overwrite behavior, and the follow-up step.

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 creation tool with no annotations and no output schema, the description covers the essential invocation facts: source validity, target constraints, path format, and next step. It leaves out explicit error/return behavior, but that is not critical for selecting and 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?

Schema coverage is 0%, but the description compensates by explaining the role and constraints of both parameters: init_datei must be an existing non-empty .3d template, and ziel_datei must be an absolute .3d path whose file does not exist but whose folder does. This adds real meaning beyond the bare schema names.

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: it creates a new Cadwork file as a copy of an existing init/template file, and explicitly positions it as step 1 of the file bootstrap. This clearly distinguishes it from siblings like open_document, which is referenced as the follow-up step.

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: this is step 1 of the file bootstrap, and after calling it the agent should call open_document(ziel_datei). It does not explicitly name alternatives or when-not-to-use conditions, but the sequential guidance and preconditions are enough for correct use.

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 and exceeds it. It discloses timeout behavior, bridge freezes (cut_shoulder), response desyncs with marker workaround, side effects like solder_elements returning a list, and restrictions on embedded functions or generators. It even explains that timeouts do not mean the command was not executedhare. The return format and error object are fully specified.

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 extremely long, dominated by a massive 'BEKANNTE PROBLEME + WORKAROUNDS' list. It is well-structured with bullets and sections, and nearly every point is actionable.g., p1=START checklist, cut_shoulder dangers, vertical element stretch behavior. However, it is far from concise and could overwhelm an agent with edge cases that apply only in specific situations.

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 highly complex, side-effect-prone tool with no output schema, the description is remarkably complete. It covers module availability, security restrictions, result conventions, return structure, known pitfalls, and recovery strategies. An agent has all needed information to invoke the tool correctly and to handle failures gracefully.

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 property descriptions, so the description must compensate entirely. It does: 'code: cwapi3d-Python-Code. Endergebnis bitte in `result` schreiben.' and 'description: Kurzer Klartext... Bitte immer setzen.' It also includes a concrete example (result = ec.get_all_identifiable_element_ids()) and explains where description is displayed, fully covering both parameters.

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 precise verb-resource statement: 'Führt cwapi3d-Python-Code in Cadwork aus und liefert das Ergebnis.' It explicitly defines the agent's role ('Du generierst den Python-Code als String') and differentiates from siblings by referencing alternatives like get_working_examples, get_detail, and bash_tool for other tasks. The tool's identity as a code-execution bridge is unmistakable.

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 explicit when-to-use and when-not-to-use guidance: 'Reine Berechnungen NICHT ueber die Bridge... mit bash_tool ausfuehren.' It routes users to get_working_examples() for verified patterns fiirst, to get_detail() for construction details, and to get_connection_status() after timeouts. It also dictates sequencing (e.g., material assignment must be a separate call), making selection and invocation 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses that the tool reads Type-Stubs (.pyi) locally, requires no bridge call, and works even when Cadwork is not running. It also describes the varying output depending on provided arguments. It does not mention error behavior for invalid module/function names, but the read-only local nature is clearly conveyed.

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 compact but information-dense. It front-loads the core purpose, adds the environment constraint, then uses a clear, scannable code-block style for invocation patterns and separates the Args section. Every sentence or example contributes useful information without 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?

Given there is no output schema, the description explains the return content for each invocation mode: module list, function signatures with short descriptions, or full docstrings. It also covers the key environment behavior and both parameters. Missing only minor edge-case details such as what happens for unknown module names or whether 'function' can be used without 'module'.

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 0%, so the description is the only parameter documentation. It explains 'module' as an optional module name with a concrete example ('element_controller') and 'function' as an optional function name within the module. The call patterns clarify how the parameters combine, though the dependency that 'function' likely requires 'module' is only implied, not stated explicitly.

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 line states a clear verb and resource: 'Listet verfügbare cwapi3d-Module bzw. -Funktionen.' The description also distinguishes the tool from bridge-dependent siblings by emphasizing that it reads local .pyi stubs and requires no running Cadwork instance, so an agent can identify its role precisely.

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 invocation patterns for all three useful call shapes (no args, module-only, module+function), which is strong usage guidance. It also states when this tool is appropriate: when you need API information even without Cadwork/bridge access. It does not explicitly name alternative tools or exclusions, but among the siblings this tool has a distinct self-help introspection role.

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 and does so thoroughly. It discloses that the call responds even during long drawing operations, does not use the job queue, and can distinguish a still-running job from a paused connection or a hung main thread. This is meaningful operational context beyond the tool name.

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, then the key use case, then the returned fields. Each sentence adds information, and the structured list of state values is compact and useful rather than padded.

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 no-parameter, no-output-schema, no-annotation tool, this description is complete: it explains when to invoke it, what it does, what it reports, and how to interpret the outcome. The field list and state enum give the agent everything needed to call and consume the result appropriately.

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 input schema is empty, so the baseline is 4. The description cannot add parameter meaning, but instead uses the space to document the output fields and state enum, which is appropriate 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 the tool reports the state of the Open-MCP-CAD connection to Cadwork, and goes beyond a tautology by enumerating the returned data (instance, port, PID, document, state, queue, write license, last error). It also distinguishes itself from execute_cadwork_command by explicitly positioning this as the diagnostic call for timeouts.

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?

Usage guidance is explicit: 'Genau dafür gedacht, wenn execute_cadwork_command in ein Timeout gelaufen ist' tells the agent exactly when to call it. It also states the action to take based on the result ('dann warten, NICHT wiederholen') and clarifies that this query bypasses the plugin job queue, so it is usable while Cadwork is busy.

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, and it delivers: it discloses the data source (knowledge/detail_catalog.json), the three distinct return modes (overview, short list, complete detail with code/rules/parameters/status), the on-demand-only performance expectation, and the critical semantics of validated=false (not visually checked in Cadwork; code may be a placeholder). This is rich behavioral disclosure well beyond what the bare schema offers.

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 purpose and well structured using headings and code-block call patterns. It is long, but nearly every sentence earns its place given the catalog domain and three retrieval modes. The main inefficiency is that the 'Aufrufmuster' section and the 'Args' section partially restate the same parameter information, so a small redundancy keeps it from a perfect score.

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 3-parameter tool with an output schema and zero annotations, the description is nearly complete: it documents all parameters, return-mode differences, the validation flag, the source file, and usage timing. The one genuine gap is that all parameters are optional with empty-string defaults, yet the behavior of a bare get_detail() call (no args) is never specified — an agent could legitimately invoke it that way and get undefined behavior.

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 there are no required parameters, so the description must fully compensate — and it does. Every parameter gets documented meaning: type with example values ('aw_decke', 'aw_ecke', 'aw_iw'), variant with examples ('platform', 'stumpf'), and list_types with its exact behavior ('True = nur Typen/Varianten-Übersicht zurückgeben'). The call-pattern section reinforces how combinations of parameters change the result.

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 opening sentence states a specific verb and resource: 'Liefert Konstruktionsdetails für den Holzrahmenbau (Detail-Katalog)' — a lookup tool for a timber-frame construction detail catalog. It further clarifies the domain with concrete examples of types and variants ('AW-Decken-Anschluss' with platform/setzschwelle/durchlaufend), and explicitly differentiates itself from the sibling execute_cadwork_command by stating it is NOT embedded there. An agent can tell exactly what this tool retrieves and how it differs from nearby 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?

Provides explicit when-to-use guidance: 'Nur on-demand abrufen, wenn ein konkretes Detail gebaut werden soll' (only fetch on-demand when a concrete detail is to be built). It also gives a when-not/alternative signal by naming execute_cadwork_command and clarifying the tool is not part of its description. Three concrete call patterns (list_types=True, type only, type+variant) tell the agent exactly which invocation matches which need.

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 of behavioral disclosure. It reveals the delegation mechanism (TCP bridge to McpBridge plugin) and labels the call as a harmless status check, implicitly suggesting read-only behavior. However, it does not disclose potential failure modes (e.g., no document open, bridge not connected), authentication needs, or side effects beyond reading. The description is informative but incomplete for an unannotated 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 exactly two concise sentences. The first sentence states the primary function front-loaded, and the second adds a usage hint and implementation detail without redundancy. Every word earns its place; there is no fluff or over-explanation.

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

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

Given the tool's simplicity (0 params, no output schema, no annotations), the description covers the essential purpose and expected outputs. However, it omits critical context such as the need for an open document, the dependency on a connected bridge (especially given the sibling wait_for_bridge tool), and any error states. An agent could call this too early and get a failure, which a more complete description would warn against.

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% (vacuously complete). There are no parameters to document, so the baseline of 4 applies. The description does not need to explain parameter semantics, and it properly focuses on the tool's outputs instead.

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 ('Liefert' = provides) and a specific resource (information about the currently open document in Cadwork). It names concrete outputs — document name and number of identifiable elements — which distinguishes it from generic 'get' tools like get_connection_status or get_detail. It does not explicitly name sibling tools, but the purpose is 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 phrase 'Schneller Status-Check' (quick status check) implies a lightweight, informational use case, but there is no explicit guidance on when to use this tool versus alternatives such as get_connection_status or get_detail. No prerequisites (e.g., must have an open document, bridge must be connected) or exclusions are mentioned, leaving the agent to infer when it is appropriate.

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 of behavioral disclosure. It reveals a critical side effect: 'Abgeholte Nachrichten werden als gelesen markiert, damit dieselbe Anweisung nicht zweimal umgesetzt wird.' It also discloses that the `alle` parameter avoids altering state, and it describes the message payload (element IDs, names, groups, dimensions, facets). It does not mention potential rate limits or failure behavior, but for a simple polling tool the disclosed traits are substantial.

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 somewhat long but well-structured: purpose, usage context, message content, side effect, then parameter explanation. Each paragraph earns its place by providing context necessary for correct invocation. The only minor redundancy is the conversational explanation of the mailbox model, but it reinforces the polling behavior. Slightly trimmed would be tighter, but it remains 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 one-parameter tool with no output schema, the description is complete. It explains what the messages contain, when to call the tool, that calls consume messages, and how the `alle` flag changes behavior. An agent has everything needed to decide when and how to use this tool, and the description effectively stands in for missing schema and annotation details.

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 provides only a bare boolean `alle` with a default of false, and schema description coverage is 0%. The description compensates fully by explaining the exact semantics: 'True liefert auch schon Gelesenes und ändert nichts am Zustand (zum Nachschlagen, was vorhin gewünscht war).' This adds meaningful meaning beyond the schema, clarifying both the retrieval behavior and the side effect difference.

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: 'Holt Nachrichten ab, die der Nutzer in Cadwork in den Briefkasten gelegt hat.' It clearly identifies the tool as a message-retrieval endpoint and distinguishes it from a chat by explaining the mailbox model. This makes its purpose unambiguous and easily differentiated from siblings like report_check_note or get_detail.

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 guidance on when to call the tool: 'Während einer Zeichensitzung regelmässig aufrufen — etwa zwischen zwei Batches.' It also explains why regular polling is necessary ('Sonst wartet eine Korrektur unbemerkt') and clarifies that there is no external push mechanism. Since no sibling provides equivalent functionality, explicit alternatives are unnecessary; the guidance fully covers usage context.

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 behavioral disclosure burden. It discloses the data source (knowledge/working_examples.json), the verified Cadwork version (2025/437), and the fact that it returns snippets, implying a safe read-only operation. It could mention side-effect absence or error behavior, but the core behavioral traits are covered.

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 compact and front-loaded: it states the main purpose first, then adds verification details, source, and parameter semantics. Every sentence contributes meaningful information with 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 tool with one optional parameter and an output schema present, the description covers everything an agent needs: purpose, source, verification level, and category filtering behavior. Nothing critical 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 0%, but the description fully compensates by explaining the category parameter, providing concrete category examples, and defining empty-string behavior as 'all examples'. This adds meaning far beyond the bare schema field.

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 ('returns') and resource ('verified code examples for Cadwork operations' backed by knowledge/working_examples.json). It clearly differentiates this from sibling tools by emphasizing verified, working snippets rather than API reference or connection management.

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 clear usage context: use this when Claude needs proven Cadwork code snippets for timber construction operations and shouldn't guess. It does not explicitly name alternatives or when-not-to-use conditions, so it falls 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?

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the tool only shows stored names, that storage is cleared on plugin restart, and provides an example output showing the response shape. This is adequate for a no-side-effect listing operation, though it does not explicitly state that no data is modified.

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 concise and front-loaded: the main purpose appears first, followed by usage context and a concrete example. Every sentence adds value, and the example output is compact and informative.

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, no-output-schema tool, the description is complete. It explains what the tool does, why it is useful, a relevant behavioral caveat (cleared on restart), and the exact shape of the response. An agent can invoke this tool and interpret its result without additional 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 tool has zero parameters, so the description need not explain input semantics. The baseline of 4 applies because there is nothing to document, and the example output usefully documents the returned key names and count, which is the closest thing to parameter/output semantics.

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: 'Zeigt alle gespeicherten Namen im Session-Speicher der Bridge.' It clearly identifies what the tool does and its scope (session storage keys). It also differentiates itself from siblings like clear_store by focusing on listing rather than mutating.

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: it is 'Nützlich zum Debuggen' and explains what information it reveals (which element-ID lists are present). It does not explicitly mention when not to use it or name alternative tools, but the debugging-oriented framing is sufficient for a simple read-only listing 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 provided, the description carries the full behavioral burden. It discloses that the tool does NOT wait for Cadwork, that a manual plugin click is required, and that it rejects duplicate filenames to preserve bridge uniqueness. This is meaningful non-obvious behavior beyond the schema.

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 compact and front-loaded: the main action appears in the first sentence, followed by essential behavioral steps and a rejection condition. Every sentence contributes useful information with 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?

The description explains what the tool does, what it does not do, the required follow-up step (wait_for_bridge), and a key failure condition. Given the single parameter and lack of output schema, this is largely complete, though it could optionally clarify error handling when the file is not found or Cadwork cannot start.

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 for the undocumented parameter. It adds that ziel_datei must be an existing .3d file and notes a same-name constraint, which clarifies the parameter's meaning. However, it does not specify path format, required extension details, or example values, so compensation is partial.

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: "Oeffnet eine vorhandene .3d-Datei" via Windows file association, and identifies itself as "Schritt 2 des Datei-Bootstraps." It clearly distinguishes the tool from siblings like wait_for_bridge by describing its role in the bootstrap sequence.

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 sequencing: after opening, the plugin "Open MCP CAD" must be clicked, then wait_for_bridge(ziel_datei) is called. It also states a rejection condition when a connected instance already has a file of the same name open. It does not explicitly enumerate alternatives, but the bootstrap context makes the usage 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?

With no annotations present, the description carries the full behavioral burden and does so well. It discloses that the note appears immediately in the Hinweise tab, that element_ids make it clickable, that clicking can zoom to the affected parts, and that notes can be checked off. It also exposes the deliberate design separation between severity and urgency.

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 action, then moves through purpose, usage guidance, exclusions, and parameter details in a scannable structure. Every sentence earns its place, including the rationale for separating dringlichkeit and schweregrad, which an agent needs to respect when setting values.

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?

All five parameters are semantically described, defaults and value spaces are explicit, and the behavioral effect is stated clearly. The lack of an output schema is not a gap here because the tool's effect is visible in the Cadwork UI and the description says exactly where and how it appears.

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%, but the Args block fully compensates for every parameter: titel is described as a one-line headline, text carries assumptions and reasons, element_ids make the note clickable, schweregrad enumerates its allowed values with its default, and dringlichkeit explains the 1–5 scale, the 0 auto-derivation mapping, and why it is intentionally separate from severity.

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: 'Meldet einen Prüfhinweis ins Fenster „Open MCP CAD“ in Cadwork.' It is unmistakably about creating a visible check note for a human, and the explicit contrast with collision search and chat-only communication removes any ambiguity about its scope.

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 direct when-to-use guidance: use this instead of mentioning uncertainties only in chat, because chat messages get lost while notes sit next to the model and can be ticked off. It also gives an explicit when-not-to-use: no collision search, because Cadwork has its own.

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 and does well: it discloses that screen refresh is disabled during a drawing job and re-enabled afterward, even if the job fails. It also notes the switch exists in the Cadwork UI. It does not cover every edge case, but the key side effects are clearly explained.

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 four sentences long and each sentence adds value: the toggle behavior, side-effect details, performance rationale, and UI location. It is well-structured and front-loaded with the primary purpose, with only minor redundancy in the final UI-location note.

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 toggle with no output schema, the description provides sufficient behavioral and usage context to invoke the tool correctly. It explains what happens during and after a drawing job and why the toggle is useful. The main gap is the lack of explicit guidance on alternative tools, which is more a usage-guidelines concern.

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 only provides a boolean named 'an' with no description, and schema coverage is 0%. The description compensates by clarifying that 'an' means the fast-draw feature is enabled ('Ist es an...'), effectively mapping true to on and false to off. This is helpful, though the exact true/false mapping could be more explicit.

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 and resource: 'Schaltet das Schnellzeichnen ein oder aus' (switches fast drawing on or off). It is unambiguous about what the tool does, though it does not explicitly differentiate itself from sibling tools such as execute_cadwork_command.

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 implies when to use the tool: 'Bei langen Zeichenläufen mit vielen Elementen spart das spürbar Zeit' explains the beneficial context. However, it does not mention alternatives or state when not to use it, leaving usage guidance mostly implicit.

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 reveals the binding side effect, the lock on execute_cadwork_command, the checks involving get_document_info, and the exact conditions under which nothing is bound: timeout, multiple matches, foreign port/folder, or OPEN_MCP_CAD_EXPECT_DOC mismatch.

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 moves from parameter meaning to binding conditions. It is dense but each sentence adds necessary operational detail; a slightly more structured layout would improve scanability.

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 stateful tool with no annotations and no output schema, the description is quite complete: it explains when it is mandatory, what input forms are accepted, what is checked, what side effects occur, and when binding does not happen. It does not explicitly state the behavior when `timeout_s` elapses or what the success/failure response looks like, which leaves a small but real 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?

The schema has 0% description coverage, so the description must compensate. It substantially explains `dokument`: full path vs. filename and the folder-check implication. However, it does not explain `timeout_s` beyond its self-evident name and schema default, leaving one parameter semantically under-described.

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: wait until exactly ONE Cadwork instance has `dokument` open, verify it, and bind the session to it. It clearly distinguishes itself from siblings like get_connection_status and open_document by describing its unique wait-and-bind role.

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 positions itself as 'Schritt 3 des Datei-Bootstraps' and as mandatory before every model job after open_document, giving clear when-to-use context. It does not explicitly name alternative tools for cases where waiting/binding is not needed, so it stops short of full exclusion guidance.

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