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

Annotations include readOnlyHint: false, indicating this is a write operation. The description lists create operations but does not disclose additional behavioral traits such as coordinate system expectations, layer requirements, or impact on existing drawing state. Beyond the raw operation names, little is added to what the annotation already signals.

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 well-structured: a one-line overview followed by a bulleted list of operations with their data schemas. No unnecessary prose or repetition. It front-loads the main purpose and uses a scannable format, though it could benefit from brief explanations of each operation.

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 complexity (6 distinct operations) and the sparse schema, the description provides a functional reference but lacks deeper context. It does not explain concepts like 'leader', units for coordinates, or how screenshots factor in. An output schema exists, so return values are not needed, but overall completeness is only adequate.

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 is minimal (data, operation, include_screenshot) with 0% description coverage. The description compensates by enumerating the valid operation values and providing a data structure for each operation. This adds critical meaning that the schema lacks, though some fields (e.g., dim_x, offset) remain underspecified.

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 tool as handling annotations: text, dimensions, and leaders. It lists six specific create operations, making the purpose distinct from sibling tools like 'layer' or 'entity'. However, it does not explicitly state that this is for creating annotation objects in a drawing, but the operation names make it 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?

No explicit guidance is given on when to use this tool versus alternatives. The operation names imply usage (e.g., 'create_text' for text annotations), but there is no context about prerequisites, selection criteria, or exclusions. An agent would have to infer when to choose 'annotation' over 'entity' or 'drawing'.

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 indicate readOnlyHint=false, and the description confirms mutating actions (insert, update_attribute, define) alongside the read-only list. It does not disclose side effects, coordinate system, units, or error behavior, but the per-operation breakdown is useful. The tool's mutating nature is implicit and consistent 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?

The description is a well-structured, front-loaded summary with a compact line-by-line operation list. Every line has a purpose, and there is no redundant text. It is easy to scan and references each operation's data shape succinctly.

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 a multi-operation convenience wrapper with a minimal schema. The description covers all operations and their data requirements, but misses include_screenshot and has some ambiguity in 'define' (entities: [{type, ...}]). Given the complexity, it is mostly complete for invocation, but a few details would improve it.

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 does so by specifying the data payload for each operation (e.g., insert expects name, x, y, scale?, rotation?, block_id?). However, the include_screenshot parameter is not explained, and some value types/units (rotation degrees vs radians) are omitted. Overall, it adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool's scope: 'Block definition, insertion, and attribute management' and enumerates six specific operations. Each operation has a distinct verb and purpose, making it easy to identify what the tool does and distinguish it from siblings like layering or entity 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 operation list implicitly provides usage guidance: list for definitions, insert for placement, update_attribute for editing attributes, etc. There is no explicit 'when to use vs alternatives', but the context is clear enough for selecting the appropriate operation within this tool. 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 discloses behavioral details for each operation (e.g., save uses QSAVE if no path, plot_pdf exports to PDF, undo/redo available). This goes beyond the sparse annotation (readOnlyHint=false), which only indicates mutability. However, it doesn't specify side effects like purge permanence or undo depth.

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 compact list with each operation on one line, efficiently packaging all operations. No wasted words; every line adds value.

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

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

The tool has 10 operations and a minimal schema, but the description covers all operations with sufficient detail for basic use. Output schema exists, so return values are not needed. Minor gaps include side effects for purge/undo and the role of include_screenshot.

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?

With 0% schema description coverage, the description carries the full burden for parameter meaning. It specifies the required data shape for each operation (e.g., data: {name?} for create, data: {path} for open), which is essential. It omits include_screenshot entirely, though the schema provides a default.

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 tool as 'Drawing file management' and enumerates ten specific operations with one-line explanations, making it unambiguous what the tool does. It distinguishes from siblings by focusing on file-level operations (create, open, save) rather than object-type operations like layer or entity.

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 no explicit guidance on when to choose this tool over siblings; usage must be inferred from the operation names. It lacks statements like 'use for file-level operations only' or 'use the layer tool for layer-specific 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?

The description discloses that the tool performs create, query, and modify operations, and lists specific operations including destructive ones like 'erase'. However, it lacks deeper behavioral context such as coordinate system, units, side effects on existing entities, or return format. The annotation readOnlyHint=false is consistent with the modification operations, so there is no contradiction, but the description adds only moderate transparency 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?

The description is well-organized into Create, Read, and Modify sections with a compact bullet-list format. Every operation line is informative and directly maps to usage. It is long but appropriately so given the tool's breadth, and it avoids redundant explanations. The opening line fronts the core purpose, and the structure enables quick scanning.

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 complexity (many operations, 10 parameters), the description covers all operations and their parameter needs comprehensively. An output schema exists, so return values are not required here. However, it omits mention of the 'include_screenshot' parameter and lacks details on operation semantics (e.g., what 'fillet' or 'offset' does beyond its name). Minor gaps, but overall sufficient for a multi-operation dispatcher.

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 so by mapping each operation to its required parameters, e.g., 'create_line — x1, y1, x2, y2, layer?' and 'create_circle — data: {cx, cy, radius}, layer?'. This gives meaning to generic schema fields like 'data' and 'points'. However, it does not explain the full semantics of each parameter (e.g., what 'data' means for fillet vs. scale), leaving some room for interpretation.

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 'Entity creation, querying, and modification' and then breaks down into create, read, and modify operations. This distinguishes it from sibling tools like layer, drawing, and block, which focus on other domain aspects. The title annotation 'AutoCAD Entity Operations' reinforces the scope, though the tool is a broad dispatcher rather than a single focused action.

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

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

The description provides no guidance on when to use this tool versus alternatives. It lists operations but does not mention conditions, prerequisites, or exclusions. For example, it does not clarify when to use 'entity' versus 'drawing' or 'block' for related tasks. There is no explicit when/when-not guidance.

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 only provide readOnlyHint: false, so the description carries the burden of disclosing behaviors. It lists all mutating operations (create, set_current, set_properties, freeze, thaw, lock, unlock) and their data fields, going beyond the annotation. However, it does not describe side effects, error conditions, or permission requirements, leaving some behavioral 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 compact, well-organized operation list. Each line corresponds to a valid operation and includes only necessary data fields. No wasted words; 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 multi-operation tool, the description covers all operations and their data requirements. The include_screenshot parameter is unexplained, and general behavior such as return values and error handling is not addressed. However, an output schema exists, which likely covers return formats. Minor gaps prevent a perfect score.

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 descriptions for operation, data, or include_screenshot. The description compensates by detailing per-operation data structures, e.g., 'set_properties — data: {name, color?, linetype?, lineweight?}', which is essential for correctly constructing the 'data' object. This adds significant meaning beyond the raw schema.

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

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

The description clearly states 'Layer creation and management' and enumerates all operations (list, create, set_current, etc.), making the tool's scope explicit. This distinguishes it from sibling tools like drawing, entity, block, and annotation by focusing on layer-specific actions.

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 operation list implies when to use each sub-operation (e.g., create for adding layers, freeze for toggling visibility), but there is no explicit guidance on when to choose this tool over alternatives or when not to use it. No exclusions or alternative recommendations are provided.

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 readOnlyHint=false annotation, the description does not disclose behavioral traits such as side effects, permissions, or return values. The operations imply actions (insert, draw, add) but do not detail what changes occur to the drawing or what the output looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized as a list of operations with inline data schemas. It is somewhat long due to the number of operations, but each line is necessary and the format is scannable. The opening sentence is concise and front-loaded with the tool's purpose.

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 many operations, the description does well to enumerate them all, but it lacks semantic details about each operation's behavior and parameters. It also omits the 'include_screenshot' parameter entirely. The output schema likely covers return values, but the description itself is incomplete for a tool of this complexity.

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 description fully compensates by listing every operation and its corresponding data fields. For instance, 'insert_symbol — data: {category, symbol, x, y, scale?, rotation?}' provides concrete structure for the 'data' parameter, which the schema leaves as an opaque object. This is highly informative.

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 'P&ID drawing with CTO symbol library', clearly identifying the tool's domain and purpose. The extensive list of operations (insert_symbol, draw_process_line, etc.) specifies exactly what the tool can do, distinguishing it from generic sibling tools like 'drawing' or 'entity'.

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 lists operations but does not state prerequisites, context, or exclusions. For example, it does not clarify when to use this P&ID tool over the generic 'drawing' 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?

Annotations declare readOnlyHint=true, yet the description reveals operations like 'init — Re-initialize the backend' and 'execute_lisp — Execute arbitrary AutoLISP code', which are clearly mutating and potentially destructive. This directly contradicts the read-only annotation, making the description unreliable for safety expectations.

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 well-organized with a clear front-loaded summary and a bulleted operation list. It avoids unnecessary prose, though the repeated use of 'Backend' in multiple operations slightly reduces tightness.

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 output schema exists, so return values are covered, but the description lacks critical context for a multi-operation tool: no guidance on which operation to use in what situation, no explanation of the 'File IPC only' restriction beyond execute_lisp, and no mention of potential side effects for init. The annotation contradiction further undermines completeness.

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?

With 0% schema description coverage, the description must compensate, but it only partially does. It lists valid values for the operation parameter and shows that execute_lisp expects data: {code}, but other operations' data requirements and the include_screenshot parameter remain unexplained, leaving significant ambiguity.

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 'Server status and management' and enumerates six specific operations, making the tool's purpose explicit. It also distinguishes itself from sibling tools like layer, entity, and drawing by focusing on system-level operations rather than drawing content.

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 operation list implies various use cases (health check, backend info, executing LISP), but there is no explicit guidance on when to choose this tool over alternatives or when to prefer one operation over another. The context is clear enough for basic decisions, but exclusions and alternatives are not spelled out.

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 the description adds valuable behavioral context: the tool is deterministic ('항상 동일한 input → 동일한 output 보장'), it prunes branches ('valid/pruned 분류'), and it can return all_pruned failures with suggestions. It does not contradict the read-only annotation and goes beyond it by describing the output structure's behavior.

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 well-structured with a clear overview, an operations list with data formats, and concrete return examples for pipeline (PASS/FAIL). Each sentence contributes information without redundancy, and the format is scannable and front-loaded with the core workflow.

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 is quite complete for a complex tool with an output schema: it covers the high-level pipeline, lists all operations, provides data shapes, and gives return examples for the pipeline both on success and failure. However, it omits details about the 'rule_set' parameter and does not show return formats for the individual branch/check/select operations, which keeps it from being fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It defines the data structures for each operation (e.g., branch data: {intent: {shape_type, params, features?}}), which helps clarify the 'data' parameter. However, the 'rule_set' parameter is not explained at all, and the 'operation' parameter's allowed values are only implied by the operations list, leaving a significant gap.

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 explains the tool's core workflow: it takes LLM ambiguity, generates branch candidates, prunes them via a constraint tree, and returns a deterministic execution order. The operations list (branch, check, select, pipeline) specifies exact actions, and the final line distinguishes it from sibling tools by directing execution of returned commands to entity/layer/etc.

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: 'selected_branch.commands 를 순서대로 entity/layer/... 툴에 실행하면' indicates this is a precursor to executing on other tools. However, it does not explicitly state when not to use it or compare it to alternatives besides the implicit contrast with the sibling creation/modification 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?

The readOnlyHint annotation is consistent with the operations described (zooming and capturing screenshots are non-mutating). The description adds useful details about each operation's effect, but it does not disclose potential nuances such as coordinate systems or error handling. The annotation lowers the burden, so the added context earns a 4.

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 succinct and well-structured, front-loading the main purpose and then using a clear list to detail operations. Every sentence contributes value without repetition or fluff.

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

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

Given the presence of an output schema and the read-only annotation, the description covers the operations adequately. It could be more explicit about which operation requires which parameters, but the overall context is sufficient for a viewport control 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 description names the parameters for zoom_window (x1, y1, x2, y2) and lists operation options, but it does not explain the meaning of coordinates (units, system) or how parameters apply to other operations. With 0% schema coverage, the description partially compensates but leaves ambiguity for parameter requirements across operations.

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 as 'Viewport control and screenshot capture' and enumerates specific operations (zoom_extents, zoom_window, get_screenshot). This specific verb+resource framing clearly distinguishes it from sibling tools focused on layers, entities, etc.

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 operation list implicitly guides when to use this tool (any zooming or screenshot need), and the context is clear. However, it does not explicitly mention when not to use it or contrast with alternatives, though the sibling list makes the separation obvious.

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