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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds the substantive behavioral content of what is inspected, but says nothing about result shape, whether findings are truncated, or that maxPerCheck caps output. With annotations doing the safety work, a 3 reflects real but incomplete added context.

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

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

A single front-loaded sentence that opens with the tool's purpose and lists checks efficiently, with zero padding. It is dense rather than verbose, though the comma-list format reads more like a spec than a prompt-facing cue.

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-required-parameter, read-only tool with no output schema, the definition covers the 'what is checked' dimension adequately but omits return format and the meaning of maxPerCheck/selectedOnly scoping. An agent knows what it validates but not what it gets back or how results are bounded.

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 80% and the checks enum is exhaustively documented in the schema itself, including what each check means. The description adds no parameter-level guidance of its own, so the baseline of 3 for high coverage 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 names a specific resource (model quality checks) and enumerates exactly what is inspected: missing/duplicate IDs, unclassified elements, duplicate geometry, hidden/locked layers, zero-area zones, unnamed/empty stories. An agent can tell this is a read-only validation tool and distinguish it from the many creation/mutation siblings (CreateWalls, MoveElements, classify_elements). It is a noun-phrase enumeration rather than an explicit verb, which keeps it just short of 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?

There is no statement of when to reach for this tool versus alternatives such as archicad_model_summary, archicad_quantities, or the individual GetElements/FilterElements tools. The only usage signal is the implied 'use it to audit model hygiene', inferred from the check names. No exclusions or prerequisites 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results include the item path, which is useful output context, but says nothing about result size, pagination, or behavior when the system search string matches nothing or multiple systems.

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?

One sentence, front-loaded with the operation and terminated with the routing hint. Nothing is redundant and nothing is buried.

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-optional-parameter read-only lookup with a fully documented schema and no output schema requirement, the definition is nearly sufficient; only the upstream/downstream relationship to the other classification tools is thin.

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

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

Schema description coverage is 100%, so both parameters (search, system) are already documented in the schema, including the 'first one by default' behavior. The description adds no format, matching, or scoping detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Lists the items of a classification system') and names what the output contains ('with their path'), which is enough to distinguish it from the write-oriented sibling archicad_classify_elements. It does not, however, explicitly differentiate itself from the similarly-named GetClassificationsOfElements.

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 clause 'to use in archicad_classify_elements' implies a workflow context and points at the consuming tool, but there is no explicit when-to-use / when-not guidance and no mention of the alternative classification-reading siblings. Usage is inferred rather than stated.

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 annotations declaring a non-readonly, non-destructive write, the description adds real value: it discloses the default scope constraint (unclassified elements only) and the recovery path (archicad_undo). It stops short of stating permission requirements or what a partial/ambiguous match does.

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

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

Two sentences with zero waste; the core operation and matching rule come first, with defaults and the revert path packed efficiently into the tail.

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 7-parameter mutation tool with full schema coverage and no output schema, this covers the essentials: scope default, matching semantics, and undo path. What it omits — result reporting and interaction with dryRun/overwrite — is minor since those parameters are self-documenting.

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

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

Schema description coverage is 100%, so every parameter including rules, dryRun, overwrite, and selectedOnly is already documented in structured data; baseline is 3. The description's example of a rule (Slab on layer '02 PLAZA - Pasto' → 'Terrain') restates the schema's own example rather than adding new meaning.

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

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

States a specific verb (Classifies) with a broad scope (many elements at once) and the matching mechanism (rules by element type and/or layer), plus a concrete example. It does not explicitly contrast with the sibling SetClassificationsOfElements, which does the same job on explicit elements, so it falls short of the top score.

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 implies the default usage context ('by default only those still unclassified') and points at archicad_undo for reversal, which is useful steering. However, it never says when to prefer this tool over SetClassificationsOfElements or when to pass the explicit 'elements' parameter instead of rules.

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=false, destructiveHint=false, openWorldHint=false, so safety is largely covered. The description adds value by disclosing that output is solid bodies, that a named layer can be created on demand, and that the operation is reversible via archicad_undo. It does not describe the return value or whether dryRun changes reporting, but that is minor given annotation coverage.

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

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

A single front-loaded sentence carries the purpose, scope, and use cases, followed by a short recovery hint. No filler or redundancy.

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

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

For a 6-parameter creation tool with no output schema, the description covers purpose, terrain semantics, layer behavior, and undo recovery. It omits the dryRun verification path and skirtLevel depth semantics, but those are documented in the schema, leaving only a small 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?

Schema coverage is 67%, and the description reinforces the most important semantics (z relative to level, per-point heights, layer naming). However, it adds no meaning for skirtLevel, floorIndex, or dryRun beyond what the schema already states, so the baseline 3 is appropriate.

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

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

States a specific verb (Creates) and resource (terrain Meshes) plus the key characteristic that differentiates it: heights per point, solid bodies, optional named layer. The concrete use cases (surveyed ground, paths, curbs) let an agent distinguish this from siblings like archicad_set_mesh and archicad_create_surface_morph.

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 usage context (terrain modeling) and points to archicad_undo for reverting, which is useful. But it never states when to prefer this over archicad_set_mesh or archicad_create_surface_morph, and there are no explicit exclusions or prerequisites.

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=false and destructiveHint=false, and the description is consistent with that. It adds genuinely useful context beyond the annotations by naming the undo tool as the reversal path and scoping the operation to a single story, though it says nothing about permissions, failure modes, or what happens on an invalid polygon.

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

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

Two tightly written sentences, front-loaded with what is created and followed by the reversal instruction. No filler or restated field names.

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 an 11-parameter mutation tool with no output schema and only 64% schema coverage, the description is thin: it never mentions the dryRun preview, zone naming/numbering, or thickness/structure options, and there is no indication of what the call returns. The undo hint and story scoping are helpful but do not fill the gaps.

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 64%, so a baseline of 3 applies. The description maps loosely onto the polygon, walls, slab, and story parameters ('outline', 'on one story') but adds no syntax, units, or defaults beyond the schema — notably it never mentions dryRun, zoneName, or the slab/wall thickness options.

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

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

States a specific verb and resource ('Creates a room from an outline') and enumerates exactly what gets built — walls along its edges, a floor slab, and a zone, on one story. This composite scope distinguishes it from siblings like CreateWalls, CreateSlabs, and CreateZones, which each build a single element type.

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 offers a recovery path ('Revert with archicad_undo'), which is useful, but gives no guidance on when to prefer this composite tool over chaining CreateWalls/CreateSlabs/CreateZones, nor any prerequisites such as needing a valid story from GetStories. Usage is only implied.

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 a non-read-only, non-destructive, non-open-world operation, and the description adds the crucial recovery hint ('Revert with archicad_undo') plus the batch/global-geometry semantics that annotations cannot convey. It still omits permissions, rate limits, and what happens to the created layer on failure.

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

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

Two tightly packed sentences, zero filler, with the core capability front-loaded and the recovery instruction appended last.

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 6-parameter batch mutation with no output schema, the description covers purpose, geometry model, layer behavior, and reversibility. Minor gaps: floorIndex is unexplained and no hint of the dryRun return shape is given, though the schema handles dryRun.

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 67% schema coverage, the description meaningfully clarifies that 'top level and thickness' are exact values applied uniformly across the batch ('homogeneous'), which disambiguates the global topLevel/thickness parameters. It does not address floorIndex or the dryRun toggle, which the schema partially covers.

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

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

States a specific verb ('Creates'), resource ('slabs'), and scope ('many homogeneous ... at once'), with concrete use cases (site blocks, platforms, masses). It is clearly distinguishable from the single-slab sibling CreateSlabs and from archicad_create_meshes.

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 parenthetical use cases imply when this tool fits (bulk massing/site geometry), and 'Revert with archicad_undo' gives a recovery path. However, it never explicitly contrasts with CreateSlabs or Archicad's other creation tools, so selection guidance is only implied.

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 cover the safety profile (readOnly=false, destructive=false), so the description needn't repeat that; instead it adds the undo-based rollback path and clarifies that the surface will visually read differently from the underlying mesh. It stops short of noting the dryRun preview capability or any model-side 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?

Two short sentences, zero filler; the purpose and the visual differentiator are front-loaded, with the rollback tip as a compact trailing 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 7-parameter creation tool with no output schema and annotations that only cover safety, the description conveys purpose, differentiator, and recovery, which is largely sufficient. It leaves the dryRun preview and the triangles/faces interplay to the schema, a minor gap rather than a blocker.

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 86%, so the schema already carries most parameter meaning. The description only echoes two of them implicitly ('from triangles', 'building material') and adds nothing about the triangles-vs-faces distinction, solid mode, or dryRun. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description gives a precise verb+resource ('Creates a Morph surface from triangles'), names the key differentiating payload ('its own building material'), and contrasts it with the mesh sibling ('so it reads differently from the mesh below'). An agent can distinguish it from archicad_create_meshes/archicad_set_mesh without opening the schema.

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

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

It supplies a recovery path ('Revert with archicad_undo') and an implicit use case ('a path draped on terrain'), but never explicitly states when to choose this over archicad_create_meshes or archicad_set_mesh, nor any prerequisites such as selection or layer requirements. Usage is implied rather than stated.

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 openWorldHint=false, so safety is covered. The description adds the default-to-selection fallback and what imagery is returned, but omits cap behavior (limit max 20), large-model cost, or whether images come inline or as references.

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?

One sentence, front-loaded with the resource and immediately listing output variants. 'So you can see them' is mildly redundant but the rest 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 6-param, no-output-schema tool, describing the returned imagery is valuable since nothing else specifies returns. Still, it leaves the limit/cap semantics and scope precedence (elements vs elementType vs selectedOnly) unstated.

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 67% schema description coverage, the schema handles size, limit, elements, and selectedOnly. The description only glosses imageType values and hints that Zone elementType yields a floor plan clip, adding slight meaning beyond the enum but not explaining size/limit trade-offs.

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

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

States a specific verb+resource (returns images of elements) and enumerates the output flavors: 3D/2D/section previews plus floor-plan zone clips. No sibling tool produces images, so it is effectively distinguishable, though it never says so explicitly.

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

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

Provides one useful scope rule — 'defaults to the selection when no scope is given' — but gives no guidance on when to prefer explicit element lists vs elementType vs selectedOnly, and names no alternatives.

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 openWorldHint=false, so safety is covered. The description adds ordering (newest first) and scope (open project), which is real but modest context; it says nothing about list size, truncation, or entry format.

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?

One sentence, front-loaded with the verb and resource, with the ordering constraint packed into a trailing clause. Zero 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 no output schema, the description carries the return-value burden, and it only partly does so: it identifies what the list contains and its ordering but not the entry shape, count limits, or whether the history is bounded.

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 takes zero parameters, so the baseline is 4 and there are no parameter semantics for the description to clarify or obscure.

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

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

States a specific verb (Lists) and resource (the actions archicad_undo can revert), and ties itself directly to the sibling tool it relates to. An agent can distinguish it from archicad_undo and from generic list tools without opening any schema.

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

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

Naming archicad_undo implies this is the inspection step before an undo, but the description never explicitly says when to use this rather than calling undo directly, nor any exclusions. Usage is inferable but 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 openWorldHint=false, so the safety profile is covered externally. The description still adds useful behavior context by disclosing the compact field set returned and the relative cost versus GetDetailsOfElements. It omits any mention of the default limit/truncation behavior, which is a minor gap.

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

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

Two short sentences with the resource and return shape front-loaded and the sibling comparison immediately after. Nothing is redundant and every clause adds information.

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

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

For a read-only list tool with full schema coverage, no output schema, and annotations covering safety, the description is nearly complete: it says what comes back and when to use it. The remaining gap is the lack of differentiation from the several other element-listing siblings, which an agent would have to resolve elsewhere.

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

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

Schema description coverage is 100%, including limit, elements, elementType, and selectedOnly, so the schema carries parameter meaning. The description adds no per-parameter syntax or format detail beyond what the schema already states, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb (list) and resource (elements) and enumerates the returned fields (guid, type, ID, story name, layer name). It also names a sibling, GetDetailsOfElements, and contrasts itself with it, so an agent can distinguish the two without opening either schema.

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

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

"use it to find elements before acting on them" gives clear when-to-use context, and "Much smaller than GetDetailsOfElements" routes the agent away from the heavier sibling. It does not, however, address the other list-like siblings in the family (GetAllElements, FilterElements, GetElementsByType), so the routing guidance is incomplete.

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 openWorldHint=false, so the safety profile is covered. The description adds the useful behavioral trait that this consolidates many reads into a single call ('One-call overview'), but says nothing about response size, cost, or whether the data is live versus cached.

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

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

Two sentences, zero waste. The content enumeration is front-loaded and the usage cue ('Start here to understand a model') closes it out. Every clause earns its place.

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

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

With no output schema and no parameters, the description carries the burden of describing the return contents, and it does so by listing the six categories returned. It is nearly complete, missing only any note on structure or size of the aggregated payload.

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 takes zero parameters, so the schema fully covers the (empty) surface; per calibration this is baseline 4. The description correctly implies no filtering is required and that the scope is the whole open project.

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

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

States a specific verb+resource ('One-call overview of the open project') and enumerates exactly what the overview contains: project info, stories, element counts by type/story/layer, zone areas, current selection. That is far more specific than the adjacent archicad_status or GetProjectInfo, though it never explicitly names which sibling it supersedes.

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?

'Start here to understand a model' gives a clear orienting/entry-point context for when to reach for this tool. It does not say when NOT to use it or point to a narrower alternative (e.g., use GetStories if you only need stories), so it stops short of full routing 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 declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, which establishes the mutation-but-not-destructive profile. The description adds real value beyond that by naming the recovery path ('Revert with archicad_undo'), telling the agent the move is an undoable operation rather than an irreversible one.

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

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

Two short sentences with the operation and its addressing scope front-loaded, followed immediately by the recovery instruction. No filler; every clause carries information.

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

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

For a 5-parameter mutation tool with no output schema, the description covers what moves, how it is addressed, the unit, and the undo path. It stops short of describing return content or whether dryRun counts as touching the model, though the schema's dryRun description partially covers that.

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 80%, so the baseline is 3, and the description earns the bump by supplying the unit ('by a vector in meters') that the schema omits for x/y/z, plus confirming that the three addressing modes map onto the elements/selectedOnly/elementType 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?

States a specific verb (moves) plus resource (elements) and explicitly enumerates the three addressing modes: explicit list, selection, or a type. This distinguishes it from rotate/delete siblings, though it does not name the near-identical MoveElements sibling it sits next to.

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 usage by listing the three element-selection modes and points to archicad_undo as the revert path, which is genuinely helpful. It never states when to prefer one selection mode over another, nor any prerequisite (e.g. model must be open, selection must be active), so guidance is implied rather than explicit.

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 openWorldHint=false, so the safety profile is covered. The description adds useful context that quantities derive from built-in properties and can be emitted as JSON or CSV, but says nothing about performance, limits, or the cost of scanning the full model.

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

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

A single dense sentence, front-loaded on the core measure, with units and output dimension appended efficiently. No filler, though it packs several clauses that could be split for readability.

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

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

With no output schema the description carries some return burden, but it names the four quantity measures and the JSON/CSV formats, which is adequate for a read-only aggregation tool. It stops short of describing the response shape or how grouping affects output.

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 high (83%), so the schema already documents format, groupBy, elements, elementType, selectedOnly, and extraProperties. The description echoes the grouping and output-format dimensions but adds no syntax or naming detail beyond what the schema's own descriptions provide, so baseline 3 is appropriate.

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

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

The description states a specific verb+resource ('quantity take-off from Archicad's built-in properties') and enumerates the measures produced (lengths, areas, volumes, counts). This clearly distinguishes it from sibling read tools like GetAllProperties or Get3DBoundingBoxes, though it never names an alternative explicitly.

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

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

Usage is implied rather than stated: the mention of 'totalled by element type and optionally by story or layer' signals the aggregation scenario but does not say when to prefer this tool over GetAllProperties or GetPropertyValuesOfElements. No when-not guidance or prerequisites 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?

Annotations already declare it is a non-destructive, non-open-world mutation, so the description's added value is the reversibility path ('Revert with archicad_undo') plus the 2D plan-plane constraint. It does not explain what happens to geometry beyond the rotation or whether undo is guaranteed, so it stops short of a 5.

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

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

Two sentences, zero filler, with the core action front-loaded and the recovery guidance appended. Every clause earns its place.

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

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

For a mutation tool with six parameters, no output schema, and the destructive flag already handled by annotations, the description covers the essential behavior and the undo path. It omits the default element-selection behavior (elements vs elementType vs selectedOnly interplay), which would matter to an agent calling it blind.

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 83%, so the schema already documents dryRun, degrees direction, elementType examples, and selectedOnly; the description only echoes the origin/degrees semantics. Baseline 3 is appropriate since the description adds little beyond the structured fields.

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

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

The description gives a specific verb (rotates), resource (elements), and operating scope ('in plan around a point by an angle in degrees'), which is far more precise than the bare tool name. It does not explicitly contrast itself with the sibling archicad_move_elements, so sibling differentiation is left to inference.

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 only usage guidance is 'Revert with archicad_undo,' which tells the agent how to undo but not when to choose rotate over archicad_move_elements or what the default element scope is. Usage context is implied rather than stated.

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 destructiveHint=true and openWorldHint=false, so the safety profile is carried there. The description adds essentially no behavioral context beyond that - it does not warn that some commands mutate the model, does not state what happens on failure, and does not describe the response, which matters for a generic pass-through runner.

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

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

Two short sentences, front-loaded with the core action and immediately followed by concrete examples. Efficient with no filler, though the external-reference pointer is the only content of the second half.

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 an open-ended command runner with a nested free-form parameter object and no output schema, the description is thin: it omits how to discover valid commands, how the arbitrary 'parameters' payload is shaped, and what the call returns. An agent is left to guess or leave the tool context entirely.

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 50%: 'command' is described in the schema, but the nested 'parameters' object has no description anywhere. The description compensates only weakly by redirecting to Graphisoft's reference, adding no syntax or structure for the parameter payload, so it lands at the baseline for partial coverage.

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

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

States a specific verb and resource ('Runs an official Archicad JSON API command') with concrete examples ('API.GetElementsByType'). It is clear what the tool does, but it does not differentiate itself from the near-identical siblings tapir_run_command / tapir_describe_command, so an agent cannot easily tell which runner to pick.

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 when-to-use, when-not-to-use, or alternative guidance. 'See Graphisoft's JSON API reference for parameters' is a pointer to external documentation, not usage direction, and it never mentions the sibling discovery tools (tapir_list_commands, tapir_describe_command) an agent would need to find valid commands.

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=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is partly covered. The description adds real value by disclosing that the change is revertible via archicad_undo, but it does not note the tension between 'changes IDs' and destructiveHint=false, nor whether operations are atomic across the id list.

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?

One sentence, front-loaded with the action, with the three modes compactly parenthesized and the recovery note at the end. No filler.

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

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

For a 7-parameter mutation tool with no output schema, the essentials are present (modes, revert path, dryRun in schema), but the concept of 'in scope' — which determines what numbering and fixDuplicates actually touch across elements/selectedOnly/elementType — is never defined in the description, leaving a meaningful 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?

Schema description coverage is 100%, including the non-obvious fixDuplicates numbering rule and the numbering format example, so the schema carries the parameter burden and baseline 3 applies. The description restates the modes but adds no syntax or scoping detail beyond the schema.

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

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

States a specific verb and resource ('Changes element IDs') and then enumerates the three operating modes (explicit values, fixDuplicates suffixes, numbering sequence), which lets an agent distinguish it from any sibling — no other tool in the list sets IDs.

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 names one recovery path ('Revert with archicad_undo'), which is genuinely useful guidance, and the mode enumeration implies which parameter to reach for. But it never states when to prefer this over adjacent tools like SetPropertyValuesOfElements, nor any precondition (e.g., element selection or type scoping needed before calling).

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=false and destructiveHint=false, so the safety profile is partly covered. The description adds genuinely useful non-schema behavior: it operates even on locked layers, performs a 3D result check, and is reversible via archicad_undo — consistent with destructiveHint=false. It still does not say how conflicting/unspecified fields are handled.

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

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

Two tight sentences with zero waste; the core effect is front-loaded and the recovery instruction follows immediately.

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

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

For a mutation tool with full schema coverage and no output schema, the definition covers what it does, its lock-layer behavior, and the revert path. It stops short of describing interaction between the geometry parameters (polygon vs holes vs sublines) or partial-update semantics, but nothing critical for invocation is missing.

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

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

Schema description coverage is 100%, so every parameter (guid, holes, level, dryRun, polygon, sublines, skirtLevel) is already documented. The description mentions level, skirt depth and holes but adds no syntax, units, or coordinate-frame detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Changes) and resource (a Mesh (terrain)) and enumerates the exact aspects modified: level, skirt depth and holes. This clearly distinguishes it from siblings like archicad_create_meshes, archicad_set_slab_levels, and archicad_move_elements.

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 is only implied: the description names the target object and a revert path (archicad_undo), but never says when to choose this over archicad_create_meshes or how it relates to other element-editing tools. No exclusions or preconditions are stated.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false), and the description adds genuinely useful behavior beyond that: it verifies the result in 3D and states the operation is reversible via archicad_undo. It does not mention the dryRun affordance or permissions, keeping it short of a 5.

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

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

Two sentences, fully front-loaded with the action first and the recovery note second. No filler or redundancy.

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

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

For an eight-parameter mutation tool with no output schema, the description covers the core action and reversibility. It could mention the dryRun safety option explicitly, but the essential information an agent needs to invoke it correctly is present.

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

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

Schema description coverage is 100%, so all eight parameters (topLevel, thickness, keepBottom, dryRun, elements, layer, elementType, selectedOnly) are already documented in the schema. The description adds no extra parameter detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('changes the top level and/or thickness of slabs') and clarifies the intent with a concrete example ('the height of site masses'). This is unambiguous and clearly distinct from sibling tools like archicad_create_slabs or archicad_move_elements.

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?

Offers recovery guidance by naming archicad_undo as the revert path, which is useful context for a mutation. However, it gives no explicit when-to-use conditions or alternatives (e.g. when to prefer this over archicad_set_mesh).

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 openWorldHint=false, so safety is covered. The description adds real behavioral context by disclosing what is inspected: live instance ports, versions, and whether the Tapir add-on responds — effectively a reachability probe. It stops short of noting failure modes or latency 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?

A single sentence with the core action front-loaded and the returned fields parenthesized inline. Every clause earns its place; no filler or restated title.

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

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

With no output schema, the description must convey return values, and it does: instance list with port and version plus add-on responsiveness. That is sufficient for a zero-parameter status tool, though a note on empty/failure responses would make it 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?

The tool takes no parameters (schema coverage 100%, empty properties), so there is nothing for the description to disambiguate. Baseline 4 applies since parameter semantics are trivially satisfied.

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

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

States a specific verb (Lists) and a unique resource (running Archicad instances) plus the exact fields returned (port, version) and the add-on health check. No sibling tool covers instance discovery, so an agent can route to it unambiguously.

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 never states when to call this versus another tool, e.g. as a pre-flight connectivity check before tapir_run_command or archicad_run_api_command. However, the usage of a status/discovery tool is strongly implied by its name and resource, so it is not entirely guidance-free.

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 flag destructiveHint=true and readOnlyHint=false, and the description adds real semantic content beyond that: what destruction means (deletes created objects, restores changed ones) and that it is scoped to the open project. It omits irreversibility, whether the revert can itself be undone, and behavior when nothing is available to revert.

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

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

A single sentence that front-loads the core action, though the middle is a long roster of tool names. The payoff clause lands at the end; still, every element is load-bearing and nothing is wasted.

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

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

No output schema exists, but return values are implied by the described effect, and annotations carry the safety profile. The description is nearly sufficient for a destructive single-param tool, missing only edge-case behavior (empty history, failure modes).

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

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

Schema coverage is 100% with a single self-documented 'steps' parameter, so the baseline is 3. The description never references the parameter or clarifies the granularity of an undo 'step' relative to the enumerated 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?

States a specific verb ('reverts') and enumerates precisely which sibling-created actions it undoes, plus the concrete effect ('deletes what they created and restores what they changed'). An agent can distinguish this from archicad_history or individual creation tools without opening a schema.

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

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

The description establishes a clear usage context: it applies to the actions of a named set of mutation tools within the open project. It does not name an alternative (e.g. archicad_history) or state when not to use it, so it falls short of 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 already declare readOnlyHint=false and destructiveHint=true, so the mutation and non-reversible nature is known from structured data. The description adds almost nothing beyond restating add/remove: it does not say what happens with an empty selection, whether the selection is replaced or merged, or whether both parameters are applied in one order.

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?

One tight sentence, front-loaded with the action. The trailing parenthetical is dead weight that the description would be better without.

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?

A mutation tool with zero required parameters, 0% schema coverage, and no output schema leaves the caller guessing on the most basic points: mutual exclusivity of the two lists, ordering, and behavior with empty input. Annotations carry the safety signal, but the description should carry the rest and does not.

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 both parameters are unannotated in the description. The tool name and prose imply an add/remove dichotomy, but nothing states that 'addElementsToSelection' and 'removeElementsFromSelection' are the two parameters, that they accept lists of element-id objects, or what happens when both are supplied – or neither, since both are optional.

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

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

States a specific verb (adds/removes) and resource (elements to/from selection), and is distinguishable from the read-only sibling GetSelectedElements. The parenthetical '(Tapir, Element Commands)' is unexplained noise rather than clarification.

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 when-to-use or when-not-to-use guidance, and no mention of alternatives such as atomically replacing the selection versus incrementally modifying it. The sibling GetSelectedElements is closer to this tool than most of the listed names yet is never referenced.

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=false and destructiveHint=true, so the mutation profile is covered, but the description adds nothing beyond that - no note on permissions, batching semantics of the array, partial-failure behavior, or what the operation returns. It also fails to explain the 'Tapir' command context it references.

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

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

Two short clauses, front-loaded with the verb and resource. The phrase 'based on the given parameters' is filler, but the overall definition is tight and not 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 destructive batch-create tool with a deep nested payload schema and no output schema, the description omits essential context: array batching behavior, duplicate/coordinate conflicts, required authoring mode, or what an agent gets back. The rich schema covers field-level detail, but the tool-level behavior is unexplained.

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 effectively 100%, with each sub-field of columnsData (depth, width, profileId, circleBased, etc.) thoroughly documented in the schema itself. The description adds no extra semantics over the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Creates Column elements'), which is enough to separate it from sibling creators like CreateObjects, CreateZones, or CreateSlabs. However, it offers no explicit differentiation from those siblings beyond the noun, and the trailing '(Tapir, Element Commands)' is internal taxonomy rather than user-facing meaning.

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 when-to-use or when-not-to-use guidance and names no alternatives, despite a crowded sibling set of element-creation tools. An agent is left to infer that this is the column-specific path.

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=false, destructiveHint=true, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: no mention of required permissions, whether the issue is persisted locally vs. synced, or what destructiveHint=true actually implies for this create 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?

Extremely short and front-loaded, which is fine, but the parenthetical '(Tapir, Issue Management Commands)' is vague noise that doesn't help an agent. Brevity here reflects under-specification rather than disciplined conciseness.

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 mutating create tool with a destructive annotation, three parameters, no output schema, and an ambiguous domain term ('issue'), the description omits what an agent needs: required fields, whether parentIssueId nests an existing issue, and how this relates to tapir_run_command. Inadequate for the tool's 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 coverage is only 67%, and the description supplies zero parameter semantics — it does not even mention name, tagText, or parentIssueId. With a moderate coverage gap, the description was expected to compensate and does not.

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

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

States a specific verb and resource ('Creates a new issue'), which is clear enough to act on. However it offers no differentiation from the sibling GetIssues or from the generic tapir_run_command/tapir_describe_command pair, and 'issue' is never defined (Archicad issue vs. tracker issue).

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 when-to-use guidance, no prerequisites, and no mention of alternatives despite many overlapping siblings (GetIssues, tapir_run_command, archicad_run_api_command). The parenthetical '(Tapir, Issue Management Commands)' reads as a namespace label rather than usage direction.

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=false and destructiveHint=true, so the mutating safety profile is covered by structured data. The description adds no behavioral context beyond that - nothing about what gets created/modified in the model, auth needs, or side effects - so it earns little credit under the already-lowered bar.

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 definition is short, but the second half ('based on the given parameters') is redundant filler and the parenthetical '(Tapir, Element Commands)' is namespace noise rather than informative content. It is concise without being well front-loaded with useful 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 single-parameter creation tool whose schema documents its fields thoroughly and whose annotations carry the destructive/write profile, the description is minimally adequate. It omits contextual details such as what an 'Object' represents in the Archicad model and how it relates to sibling creation tools, leaving those gaps to be inferred.

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

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

Schema description coverage is 100%, and the single 'objectsData' parameter plus its nested fields (libraryPartName, coordinates, favoriteName, etc.) are richly documented in the schema. The description's 'based on the given parameters' adds no semantics beyond that, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Creates Object elements'), and 'Object' implicitly distinguishes it from creation siblings such as CreateWalls, CreateColumns, and CreateSlabs. However, the trailing phrase 'based on the given parameters' is tautological filler and the description never explicitly names or contrasts the sibling alternatives.

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 statement of when to use this tool versus its many creation siblings, no prerequisites (e.g. active project/teamwork requirements), and no exclusions. The parenthetical '(Tapir, Element Commands)' is a category label, not usage 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 already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds only the parenthetical '(Tapir, Element Commands)', which is a taxonomy tag rather than behavioral context; it says nothing about project state requirements, whether creation is undoable, or what happens on partial failure.

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?

One short, front-loaded sentence with the verb first. The trailing '(Tapir, Element Commands)' parenthetical is the only mild filler, but the whole definition is compact and not 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?

This is a destructive write tool with a deeply nested schema and no output schema. The description omits what the call returns (e.g., created element IDs), whether the slabs bind to existing stories, and how the legacy 'polygonCoordinates' alias behaves, leaving real gaps for a mutation 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 100%, so the schema already documents the single 'slabsData' array and every nested field (level, thickness, holes, referencePlaneLocation, etc.). The description's phrase 'based on the given parameters' adds nothing beyond that, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Creates Slab elements'), which is enough to distinguish it broadly from siblings like CreateWalls or CreateZones. However, it does not differentiate itself from the near-identical sibling 'archicad_create_slabs', leaving the agent unable to tell the two apart without inspecting schemas.

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 'archicad_create_slabs', 'archicad_create_meshes', or 'CreateWalls'. No prerequisites (active project, story/level availability) or exclusions are stated.

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=false, destructiveHint=true, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that - it does not disclose that wallsData is a batch array, what happens on partial failure, or what the caller receives back after creation.

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

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

Two very short sentences that are front-loaded with the action. The '(Tapir, Element Commands)' tag is mildly noisy but does hint at the command namespace, so it is not pure 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?

This is a complex batch-mutation tool with many optional geometry, story, and material fields and no output schema. The description says nothing about return values (e.g. whether created element IDs come back), error behavior, or required context, which is far too thin for the tool's 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?

The single top-level parameter (wallsData) has zero schema-level description and the tool description offers no explanation of it either. While several nested fields carry their own schema descriptions, the description should compensate for the top-level coverage gap by explaining the batch shape and required sub-fields, and it does not.

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

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

States a specific verb and resource ('Creates Wall elements'), so the agent immediately knows the operation type. However, 'based on the given parameters' is filler and the description does nothing to distinguish this from sibling creators such as CreateSlabs, CreateColumns, or CreateZones.

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 rather than the other creation tools, no prerequisites (e.g. valid story index, attribute IDs), and no mention of whether walls can be batched or must be created one at a time. The agent is left to infer everything from the schema.

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 destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that: it never says zones are persisted to the model, whether the operation is undoable (archicad_undo exists as a sibling), or how batch failure is handled.

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

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

Two short sentences with the action front-loaded and no wasted explanation. The parenthetical category tag is mild noise but the core statement is tight.

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 batch creation tool with a deep nested schema the definition is thin: it never mentions the manual-vs-automatic geometry choice or what the call returns (no output schema exists, and created zone identifiers are what an agent typically needs next). The rich schema and annotations carry most of the load, leaving this merely 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?

Schema description coverage is 100% and every nested field (geometry modes, stampPosition, favoriteName override semantics) is already documented inline, so the baseline of 3 applies. The description adds no syntax or format meaning beyond what the schema provides.

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

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

States a specific verb and resource ("Creates Zone elements"), which cleanly separates it from CreateWalls, CreateSlabs, CreateColumns and archicad_create_room. The trailing clause "based on the given parameters" is filler and the parenthetical "(Tapir, Element Commands)" adds no distinguishing information.

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 when-to-use guidance, no prerequisites (e.g. active project/story), and no pointer to alternatives such as CreateWalls or archicad_create_room. Nothing tells the agent when this tool is the right choice over a sibling creation command.

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 destructiveHint=true, so the safety profile is known, but the description adds genuinely non-derivable behavior: per-element execution results, and that locked layers produce a failed result rather than a silent skip. It stops short of saying whether deletion is undoable or what permissions are required.

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

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

Two tightly written sentences — the core action is front-loaded and the failure-semantics detail earns its place. The trailing '(Tapir, Element Commands)' provenance tag is minor overhead.

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 destructive, no-output-schema tool, the description covers the outcome shape and partial-failure behavior, which is the most important gap. It omits reversibility/undo availability and any indication of authorization constraints, leaving real gaps for an irreversible operation.

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 one parameter and the schema itself only describing the list as 'A list of elements,' the description's phrase 'for each input element' usefully confirms batch semantics and cardinality. It adds no identifier format or list-size detail beyond that, so it lands at the baseline.

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

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

States a specific verb+resource ('Deletes elements') that clearly distinguishes it from the many create/move/get siblings in the list. It does not, however, explicitly name a sibling or scoping condition the way a top-tier definition would.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as archicad_undo or the selective filtering implied by the batch input. The only usage signal is the tool name itself.

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 and openWorldHint=false, so the agent knows it's a safe, non-open-world read. However, the description adds no behavioral context: it doesn't explain what 'testing' means, what the output represents, or whether it returns boolean results per element. For a filter tool with 13 possible filter enum values, this is a significant gap.

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

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

Very brief, but the single sentence contains grammatical errors ('an elements', 'criterias') and lacks front-loading of key information. While concise, it's under-specified rather than efficiently 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 tool with 2 parameters (one required, one with 13 enum options), no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what 'testing' entails, what results are returned, or how filters are applied. An agent would struggle to use this tool correctly based on the available 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?

Schema description coverage is 0%, meaning neither the schema nor the description documents parameters meaningfully. The description mentions 'criterias' but doesn't explain the 'filters' array or 'elements' array beyond the schema's structural definitions. The 13 enum values for filters are listed in the schema but not elaborated in the description, leaving agents without guidance on filter 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 attempts to state a verb and resource: 'Tests an elements by the given criterias.' This suggests filtering elements, but the phrasing is grammatically broken and unclear. It doesn't clearly distinguish the tool from siblings like GetAllElements or GetElementsByType beyond a vague testing/filtering notion.

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 on when to use this tool versus alternatives. The description provides no context about appropriate scenarios or exclusions, leaving the agent to infer usage from siblings like GetElementsByType or GetAllElements.

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 openWorldHint=false, so safety is covered. The description adds valuable behavior: bounding boxes are calculated from the global origin in the 3D view, and the output array corresponds to the input array order. It lacks error, empty-input, or unit details.

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 front-loaded sentences with no redundant restatement of the tool name. The parenthetical provenance adds little, but overall it is compact and easy to parse.

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

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

For a simple read-only tool with no output schema, the description should specify the bounding-box return format. It only says an array of bounding boxes is returned and mentions the global origin, omitting coordinate representation, units, and handling of missing elements.

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?

There is one parameter with 0% schema description coverage, so the description should compensate. It clarifies that the input is an array of elements and that the output aligns with that input, but it does not explain the element identifier structure or validation behavior, leaving some semantic gaps.

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: getting 3D bounding boxes of elements. It also clarifies the calculation reference and output mapping. However, it does not differentiate this tool from sibling getters such as GetDetailsOfElements or GetZoneBoundaries.

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, nor any mention of prerequisites or exclusions. The description only explains what the tool does, leaving usage context entirely 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully discloses that only identifiers are returned (not full element data), which is behavioral context beyond annotations, but it says nothing about scoping, volume, or performance on large plans.

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

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

Two short sentences with the core purpose front-loaded and no filler prose. The trailing parenthetical '(Tapir, Element Commands)' is organizational metadata that adds little for an agent.

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 0% schema description coverage, no output schema, no required params, and an enum-typed filter array plus an undocumented databases param, the description leaves key invocation details unexplained. It does not do enough for an enum-driven filter API.

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 carry parameter meaning, but it only alludes vaguely to a 'filter parameter' (the schema's actual param is a plural 'filters' enum array) and never mentions the 'databases' parameter at all. It fails to compensate for the coverage 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?

States a specific verb and resource ('Returns the identifier of all elements on the plan'), so an agent knows it enumerates element IDs globally. However it never distinguishes itself from close siblings like archicad_list_elements, GetElementsByType, or FilterElements, leaving overlap ambiguous.

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 only guidance is 'Use the optional filter parameter for filtering,' which restates the parameter name rather than saying when to choose this tool over GetSelectedElements, FilterElements, or archicad_list_elements. No when-not conditions or alternatives 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description adds only the scope ('all user defined and built-in'), with no note on return shape or ordering, which is minimal but not misleading.

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?

One sentence plus a namespace parenthetical, front-loaded with the core action. The '(Tapir, Property Commands)' note is minor overhead but aids grouping.

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, read-only enumeration tool with no output schema, the description is adequate. Return format is unspecified, but there is no output schema demanding 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 tool takes zero parameters, so schema coverage is vacuously complete and the baseline for no-param tools is 4. There is nothing for the description to clarify.

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

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

States a clear verb ('Returns') and resource ('properties'), scoped to 'all user defined and built-in' ones. However, it does not distinguish itself from the close sibling GetPropertyValuesOfElements, so an agent could confuse property definitions with property values.

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 when-to-use, when-not-to-use, or alternative routing is provided. The description gives no signal for choosing this over GetPropertyValuesOfElements or other property-related siblings.

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 openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond that, such as whether it returns all attributes unfiltered, any performance considerations, or what the returned 'details' include. It essentially restates the purpose without enriching behavioral understanding.

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

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

The description is a single, well-structured sentence with no filler. The key action and scope are front-loaded immediately, making it easy to scan.

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

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

For a simple read-only, single-parameter tool with annotations, the description covers the basic purpose. However, without an output schema, it does not explain what 'details' are returned, leaving ambiguity about the response shape. This is a clear gap, though the tool remains minimally usable.

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 reported as 0%, and the description only says 'of the given type', which is tautological with the parameter name. It does not explain what the attribute type values represent, the effect of choosing each enum value, or any constraints. The description fails to compensate for the lack of schema-level parameter documentation.

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 ('details of every attribute of the given type'), which clearly conveys what the tool does. It does not explicitly differentiate itself from siblings like GetLayers or GetAllProperties, but the core 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?

There is no guidance on when to use this tool versus alternatives. The description only states what it does, with no context, prerequisites, or exclusions. An agent must infer usage from the tool name and schema alone.

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 and openWorldHint=false, so the agent knows this is a safe read operation on a closed dataset. The description adds the behavioral note that it works for subelements of hierarchical elements, which is useful context beyond the annotations. However, it does not describe return format, pagination, or error 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 two concise sentences with the main purpose front-loaded. The parenthetical '(Tapir, Classification Commands)' is arguably noise, but overall it is efficient and not bloated.

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 required nested-object parameters and no output schema, the description is incomplete. It lacks parameter explanations, return value details, and usage context, forcing the agent to rely entirely on the schema and annotations for invocation 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?

Schema description coverage is 0% and the description does not explain the two required parameters (elements, classificationSystemIds) or their formats. The bare mention of 'elements' and 'classification systems' is vague and does not compensate for the undocumented schema, leaving the agent to infer structure from the JSON schema alone.

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

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

The description states a specific verb and resource: 'Returns the classification of the given elements in the given classification systems.' It is clear what the tool does, though the parenthetical '(Tapir, Classification Commands)' is cryptic filler and doesn't help differentiate from siblings like SetClassificationsOfElements.

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 explicit when-to-use guidance or alternatives mentioned. The phrase 'It works for subelements of hierarchal elements also' hints at scope but does not tell the agent when to choose this tool over sibling tools like GetPropertyValuesOfElements or archicad_classification_items.

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 and openWorldHint=false, so safety is covered; the description adds non-obvious behavioral context that unlisted fields are not computed at all and that floorPlanPolygons extraction dominates batch execution time. That is genuine performance information beyond the structured fields.

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

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

Two front-loaded sentences: purpose first, then the performance-relevant tip. Only the trailing '(Tapir, Element Commands)' tag is wasted space.

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

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

No output schema exists, but the field enum plus the description's explanation of returned fields and the omission default make the return shape inferable. For a read-only lookup tool the coverage is adequate, though it doesn't describe the shape of 'details' itself.

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 only 50%, so the description carries weight, and it does: it explains the semantics of 'fields' as a filter that also suppresses computation, and what happens when omitted (every field returned). The 'elements' parameter is left implicit, which is acceptable given its self-evident name.

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

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

States a specific verb and resource ('Gets the details of the given elements') and adds scope with 'geometry parameters etc', which separates it from property/classification siblings like GetPropertyValuesOfElements. It doesn't explicitly name any sibling, so it stops short of 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?

Gives useful in-tool guidance on how to call it (use the optional fields parameter to skip unneeded computation), but offers no when-to-use-this-vs-alternatives routing against the many sibling read tools such as GetAllElements or GetPropertyValuesOfElements. Usage is implied rather than framed.

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 openWorldHint=false, so the safety profile is covered by structured data. The description adds only that it works for any type and hints at filtering; it says nothing about result volume, pagination, or behavior when a type has no instances.

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

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

Three short sentences, front-loaded with the return value. The trailing '(Tapir, Element Commands)' tag is filler, and the filter sentence restates the obvious, but there is no bloat.

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

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

No output schema exists, so the description usefully states the return shape ('identifier of every element'), which is the key missing piece. However it omits any mention of the databases scoping parameter and gives no semantics for the filter enum, leaving a three-parameter tool under-explained.

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 carry the parameter burden. It mentions the type and a 'filter parameter' (singular, while the schema defines a 'filters' array) but never explains the 13 ElementFilter options, and the 'databases' parameter is not mentioned at all.

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

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

States a specific verb ('Returns') and resource ('identifier of every element of the given type') with scope ('on the plan'). It is clear what comes back (identifiers), which distinguishes it from richer siblings like GetAllElements or GetDetailsOfElements, though it never names those siblings explicitly.

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

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

Only guidance is 'Use the optional filter parameter for filtering,' which is tautological rather than directive. There is no when-to-use, no when-not-to-use, and no routing against the very close siblings FilterElements or GetAllElements.

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 openWorldHint=false, so the agent knows this is a safe, non-open-world read. The description adds that each parameter is returned as name/type/value, which clarifies the return shape. However, it says nothing about whether the call is per-element or batched, whether results are ordered like the input, or any size limits, which are open questions for a multi-element fetch.

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

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

A single front-loaded sentence that delivers the verb, resource, scope, and returned fields with no waste. The appended '(Tapir, Element Commands)' is a minor inventory tag rather than description content, so it is not a 5.

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

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

For a one-parameter read-only tool with no output schema, the description covers what comes back (name/type/value per GDL parameter) and annotations cover safety, so it is minimally complete. It still leaves the agent to infer the relationship with SetGDLParametersOfElements and whether the call is batched per element, which a more complete definition would state.

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 is one required parameter, 'elements', documented only structurally (an array of {elementId: {guid}}). The description says the parameters are fetched 'of the given elements', implying the input is the set to inspect, but it does not explain the nesting, the required guid, or what happens with an unknown/empty list. Baseline 3 is appropriate: the schema shape is unambiguous even if undescribed.

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

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

States a specific verb ('Gets') and resource ('GDL parameters') with the exact fields returned (name, type, value) and the scope ('of the given elements'). The sibling SetGDLParametersOfElements is clearly the write counterpart, so an agent can distinguish them without opening either schema.

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

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

No when-to-use guidance, no exclusions, and no mention of the closest alternative SetGDLParametersOfElements. The parenthetical '(Tapir, Element Commands)' is a namespace tag, not usage guidance. An agent must infer context from the name alone.

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 openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that - no return format, no pagination, no scope of the returned issue set - so it contributes minimal behavioral context.

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?

One tight sentence with a parenthetical command-suite tag; front-loaded with the verb and resource and free of padding. The parenthetical adds little value but costs nothing.

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-param read-only tool this is close to sufficient, but with no output schema and no description of what 'information' is returned, the agent cannot anticipate the response shape or the scope of issues included.

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

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

Zero parameters, so the baseline is 4. There is nothing for the description to clarify, and it correctly implies a parameterless retrieval.

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

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

States a specific verb ('Retrieves') and resource ('existing issues'), so the agent knows this lists/reads issues rather than creating one. It distinguishes itself reasonably from the CreateIssue sibling by the word 'existing', but never names or contrasts that sibling explicitly.

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

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

The description gives no guidance on when to use this versus CreateIssue or the other query-style siblings (GetSelectedElements, GetProjectInfo). It only restates the operation; nothing tells the agent when this is the right call or what its prerequisites are.

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 openWorldHint=false, so the safety profile is covered. Beyond that the description adds almost nothing: it does not describe the return shape, the meaning of 'details', or any scope/limit behavior, leaving behavior opaque for a query 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?

A single short sentence with the parenthetical source tag; it is front-loaded and wastes no words. The only minor cost is that its brevity comes at the expense of substance.

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

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

With no output schema and thin annotations, the description should carry more of the load for a query tool with two parameters including a required nested-array identifier. It does not explain what a Layer's 'details' contain or how the attributeIds array maps to a single layer, leaving it 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 only 50%; the 'fields' parameter is well documented in the schema, but 'attributeIds' relies solely on a $ref type description. The description text adds no parameter meaning, so it fails to compensate for the coverage 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 pairs a specific verb ('Returns') with a resource ('Layer attributes'), which is better than a tautology. However, the phrasing 'the details of the given Layer attributes' is ambiguous about whether it returns layers or attributes of layers, and it makes no attempt to distinguish itself from siblings like GetAttributesByType or GetAllProperties.

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 guidance on when to use this tool versus the many other 'Get...' query tools in the sibling list. There is no mention of prerequisites, exclusions, or alternative 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the WHOLE tree is returned (not a partial/paginated view), which is modest behavioral value, but it says nothing about depth, size, or cost of the traversal.

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?

One front-loaded sentence that states the action and scope immediately, plus a short provenance tag. No padding, though the '(Tapir, Navigator Commands)' tag adds little for an agent.

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

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

No output schema exists, so the description carries some burden for return-shape disclosure; 'navigator item tree' implies a nested structure but its shape, depth, and size are left unstated. With annotations and full schema coverage handling the rest, this is minimally 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?

Schema description coverage is 100% and both parameters are documented in the schema, including the conditional use of publisherSetName with the PublisherSets enum. The description adds nothing beyond 'the specified map', so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Returns the full navigator item tree for the specified map.' No sibling tool covers navigator trees, so it is effectively distinguishable, though it does not explicitly name an alternative.

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 when-to-use guidance, no prerequisites, no mention of alternatives. The reader must infer from the tool name and parameter enum that this is the navigator-inspection entry point.

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 openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — it does not say what data is returned, whether it requires a loaded project, or what happens if no project is loaded.

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

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

A single front-loaded sentence that states the action and resource with no waste. The trailing '(Tapir, Project Commands)' tag is minor noise but does not harm readability.

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

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

For a zero-parameter read tool with annotations covering safety, the description is minimally sufficient but vague about what 'information' actually contains (project name, metadata, settings?). No output schema exists, so some indication of the return content would have added value.

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 takes zero parameters and the schema is trivially complete, so the baseline of 4 applies. There is nothing parameter-related the description could or should add.

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

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

States a specific verb (Retrieves) and resource (information about the currently loaded project), which is clear on its own. However, it does not distinguish itself from near-siblings like archicad_status or archicad_model_summary that also read project-level state, so it scores below 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 gives no indication of when to use this tool versus alternatives such as archicad_status, archicad_model_summary, or GetStories. There are no prerequisites, exclusions, or alternative names mentioned.

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 openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that the lookup descends into subelements of hierarchical elements — but says nothing about missing properties, error behavior, or result ordering.

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

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

Two compact sentences with the core action front-loaded and no filler. The parenthetical '(Tapir, Property Commands)' is a low-value trailing label, which is the only real 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 no output schema, the description should say more about what is returned (matching structure, multiple properties per element, missing values). It gets the basic shape across but leaves the response format for the agent to guess.

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% at the parameter level (elements and properties are bare $refs, only nested $defs carry text). The description mentions 'the elements' and 'the given property' but does not clarify that properties is a list, nor that each entry is a propertyId wrapper, so it fails to compensate for the coverage 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?

States a specific verb and resource: it returns property values for given elements. The verb 'Returns' contrasts cleanly with the sibling SetPropertyValuesOfElements, though the description does not explicitly name or differentiate itself from GetAllProperties.

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 when-to-use guidance, no prerequisites, and no alternatives named. The sentence about subelements of hierarchical elements describes coverage scope rather than selection guidance, so the agent must infer usage from the tool name alone.

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 openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it doesn't say whether an empty selection returns an empty list or an error, nor what element representation is returned. With annotations carrying the burden, a 2 is warranted for a description that contributes no extra behavioral context.

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?

One front-loaded sentence that states the resource and scope. The trailing parenthetical '(Tapir, Element Commands)' is grouping metadata rather than useful agent-facing content, which keeps it from a 5.

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

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

For a zero-parameter read-only tool with no output schema, the description conveys the essential contract: it returns the list of selected elements. It could say more about the returned element shape or the empty-selection case, but the core is 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for 0 params is 4. Schema coverage is 100% with an empty parameter object, leaving no gaps.

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

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

States a specific verb+resource ('Gets the list of the currently selected elements'), and the qualifier 'currently selected' distinguishes it from GetAllElements, GetElementsByType, and FilterElements. It does not explicitly name those siblings, so it stops short of 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?

Usage is implied by the name and description: call it when you need the user's current selection. There is no explicit when-to-use guidance, no note that the selection may be empty, and no routing to related tools like ChangeSelectionOfElements or HighlightElements.

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 openWorldHint=false, so the safety profile is covered. The description contributes only the scoping detail that it reads from the currently loaded project, and says nothing about the shape or granularity of the story data returned.

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 core sentence is short and front-loaded, but the trailing '(Tapir, Project Commands)' tag is unexplained metadata noise and 'sructure' is a typo that slightly undermines clarity.

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

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

With no parameters, no output schema, and read-only annotations, the definition is nearly sufficient for invocation. However, because there is no output schema, the description should say what story information is returned (names, elevations, levels) rather than just 'information about the story structure'.

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 takes zero parameters, so the baseline is 4. The description correctly implies the tool is parameterless by scoping everything to the currently loaded project.

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 pairs a clear verb ('Retrieves') with a specific resource ('the story structure of the currently loaded project'), so an agent knows this returns floor/story data. It does not, however, differentiate itself from siblings such as GetProjectInfo or GetAllElements, which also describe project-level retrieval.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The phrase 'currently loaded project' hints at the required context, but nothing tells the agent when this tool is preferable to GetProjectInfo or the element-listing siblings.

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 openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: the cost model of the boundary recalculation and the batching benefit, which is exactly the kind of information annotations cannot express.

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

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

Three sentences, zero padding, and the core purpose is front-loaded before the performance advice. The trailing '(Tapir, Element Commands)' tag is the only non-earning text and is trivial.

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 2-param read tool with full schema coverage and annotations covering safety, the description supplies everything needed to select and invoke it correctly. It does not hint at the shape of the returned boundary data, which is the only remaining gap given there is no output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the mutual-exclusivity constraint and, more importantly, the performance rationale for choosing the list form, which tells an agent how to pick between the two parameters rather than just what they are.

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?

Specific verb+resource ('Gets the boundaries of the given Zones') and it even disambiguates what 'boundaries' means (connected elements, neighbour zones). It contrasts with the sibling CreateZones implicitly, though it never names a competing read tool such as GetAllElements or Get3DBoundingBoxes.

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

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

Gives clear operational guidance: prefer the zones list because the expensive recalculation runs once per call, and notes only one of zoneElementId/zones may be supplied. It stops short of stating when this tool is the wrong choice versus a 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?

With destructiveHint=true already set, the description adds real value by disclosing the non-obvious clearing semantics: an empty elements array removes all previously set highlights. It does not, however, say anything about undo, persistence, or permission requirements.

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

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

Two tightly written sentences with the primary action front-loaded and the edge case immediately after. The trailing '(Tapir, Element Commands)' tag is minor noise but the body wastes no words.

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

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

For a mutation tool with four parameters, no output schema, and destructive behavior, the description covers the core action and the clearing case but omits defaults (e.g., what color is used if highlightedColors is empty) and any return/confirmation detail. Adequate but with evident gaps.

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 75% and the schema itself documents highlightedColors, nonHighlightedColor, and wireframe3D in detail. The description clarifies the empty-array case for 'elements' but adds nothing about the color arrays or the wireframe flag beyond what the schema already provides. Baseline 3 applies.

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

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

The description states a specific verb ('highlights') and resource ('elements given in the elements array'), and no sibling tool performs highlighting, so it is distinguishable. It stops short of explicitly contrasting itself with related selection tools like ChangeSelectionOfElements.

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 explicit when-to-use or when-not-to-use guidance and no named alternative among the many element tools in the sibling list. The empty-array note implies a clear/remove use case but is framed as behavior, not routing advice.

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 destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the mutation risk is covered structurally. The description adds no behavioral context beyond the annotations - no note on irreversibility, undo availability (archicad_undo exists), or that coordinates are model-space - and does not contradict them.

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?

One short sentence front-loads the action and the input, with no wasted prose. The parenthetical tag is the only filler, so it is close to optimally sized for what it attempts.

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 schema is fully documented and annotations carry the safety profile, so an agent can invoke it. However, for a destructive mutation tool the description omits any usage context (coordinate semantics, whether moves are in a shared reference frame, batching behavior), leaving it minimally viable.

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

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

Schema description coverage is 100% with a single array parameter whose elementId, moveVector, and copy fields are all documented inline. The description's 'given vector' phrasing adds no syntax or format detail beyond that, so the baseline 3 is appropriate.

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

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

States a specific verb (moves) and resource (elements) plus the mechanism (a given vector), which is enough to distinguish it from siblings like archicad_rotate_elements. It stops short of naming alternatives or scope, so it is clear but not differentiating.

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 when-to-use guidance, no prerequisites, and no mention of how it differs from archicad_rotate_elements or the copy-vs-move choice. The '(Tapir, Element Commands)' tag is provenance metadata, 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 declare destructiveHint=true and readOnlyHint=false, flagging this as a mutating operation. The description adds real behavioral context beyond that: omitting classificationItemId clears an existing classification, and subelements are affected too. It doesn't state whether existing classifications are overwritten, whether the write is idempotent, or what errors occur for invalid ids.

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

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

Three short sentences, front-loaded with the core action and the unclassify rule. The trailing '(Tapir, Classification Commands)' is metadata that adds little for an agent, but the overall length is appropriate.

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 destructive, no-output-schema mutation the description covers the essential unclassify trick and hierarchical scope, but omits return/error behavior and whether the whole input array is applied atomically. Adequate but with clear gaps given the destructive annotation.

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% at the parameter level, so the description must compensate; it does explain the omit-classificationItemId semantics, though that fact is also already documented on ClassificationId.classificationItemId in the nested schema. It says nothing about the elementId/classificationSystemId structure or that elementClassifications is an array of {elementId, classificationId} pairs, so the batch shape is left to the schema.

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

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

The first sentence states a specific verb and resource ('Sets the classifications of elements'), and the remaining sentences add scope (subelements of hierarchical elements). It does not, however, distinguish itself from the sibling archicad_classify_elements or GetClassificationsOfElements, leaving the agent to infer which classification tool to call.

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 one genuinely useful conditional ('to set to unclassified, omit the classificationItemId field') and notes it works for subelements, but provides no guidance on when to prefer this tool over archicad_classify_elements or GetClassificationsOfElements, and no prerequisites or batch-size limits.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say whether existing parameter values are overwritten, whether array resizing is destructive, or what happens on partial failure, despite setting GDL values being an overwrite 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?

It is a single front-loaded sentence with no padding, which is good. It is arguably too terse for a destructive nested-schema tool, but there is no filler or redundancy.

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

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

For a destructive, nested-schema mutation tool with no output schema, the description is inadequate: it omits any behavioral context about overwriting, resizing, or failure modes. The annotations carry the safety signal but the description fails to add the context an agent needs to call this confidently.

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

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

Schema description coverage is 100%, so the nested parameter details (name/index/value/index1/index2) are fully documented in the schema itself. The description adds no parameter-level meaning on top of that, which is the expected baseline when the schema does the heavy lifting.

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

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

The description states a concrete verb and resource ('Sets the given GDL parameters of the given elements'), so an agent knows it mutates parameter values. However, it does not differentiate itself from the obvious sibling GetGDLParametersOfElements, which would help confirm this is the write counterpart.

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 the read-only GetGDLParametersOfElements or other setter tools, and no prerequisites or conditions are mentioned. The only extra text, '(Tapir, Element Commands)', is a provenance tag, not usage 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 already declare readOnlyHint=false and destructiveHint=true, so the agent knows this mutates data; the description's added value is the note that it also applies to subelements of hierarchal elements, which expands the blast radius understanding. However, it says nothing about whether existing values are overwritten, whether the operation is undoable, or what happens on partial failure — meaningful gaps for a destructive bulk write.

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

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

Two short sentences, front-loaded with the core action, with the hierarchical-element caveat second. The '(Tapir, Property Commands)' provenance tag adds little but costs almost nothing.

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, destructive batch mutation with no output schema, the description omits failure behavior, overwrite semantics, undo support, and permission/auth needs. The one parameter is also undocumented in prose. This is under-specified for the operation's risk profile.

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 reported at 0% for the single top-level parameter, and the description contributes nothing about the elementPropertyValues structure, the element/property/value triple, or that multiple values can be set in one call. The nested $defs do carry their own descriptions, so the schema is not opaque, but the description itself does no compensating work.

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

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

The description gives a specific verb+resource ('Sets the property values of elements'), which cleanly pairs against the sibling GetPropertyValuesOfElements, and it adds a scope note about subelements of hierarchical elements. It does not explicitly name a sibling alternative, but the purpose is unambiguous from the name plus first sentence.

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 when-to-use guidance, no prerequisites, and no routing against the many adjacent mutation tools such as SetClassificationsOfElements, SetGDLParametersOfElements, or ChangeSelectionOfElements. The only contextual hint is the parenthetical '(Tapir, Property Commands)', which signals provenance but not selection criteria.

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 openWorldHint=false, so the safety profile is covered. The description adds workflow context beyond that: this is a schema-introspection prerequisite to tapir_run_command. It does not describe the shape of the returned schemas, but the read-only behavior is unambiguous.

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

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

Two short sentences, zero waste. The return-value statement is front-loaded and the prerequisite instruction follows immediately; every sentence earns its place.

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

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

For a one-parameter read-only introspection tool with no output schema, the description covers what the tool returns (input and output JSON schemas) and why it exists (prerequisite to execution). Nothing essential for correct invocation is missing.

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

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

The single 'command' parameter has 100% schema description coverage including an example ('CreateWalls'), so the schema carries the semantics. The description adds no further parameter detail, making the baseline 3 appropriate.

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

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

States a specific verb and resource: 'Returns the input and output JSON schemas of a Tapir command.' This is clearly distinct from tapir_run_command and tapir_list_commands, though the differentiation from the latter is only implicit.

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

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

Explicitly names the workflow position ('Read this before tapir_run_command'), which tells the agent exactly when to reach for this tool and which sibling it precedes. It stops short of stating the inverse (e.g., don't call it standalone), but the routing signal is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds that results come with a one-line description, which is useful context, but says nothing about return count, ordering, or what happens when both filters are supplied. With annotations carrying the safety burden, this is a solid but unremarkable 3.

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

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

A single efficient sentence that front-loads the primary action and tucks the optional filtering detail after it. No filler or redundancy, though it is terse enough to leave some gaps unaddressed.

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

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

For a simple read-only list tool with 0 required parameters, fully documented schema, and annotations covering the safety profile, the description tells an agent what it needs to invoke it correctly. Minor gaps (filter interaction, result volume) are not critical for this complexity level.

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

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

Schema description coverage is 100%, so both the group and search parameters are already fully documented in the schema. The description restates that filtering is by group name or text but adds no syntax, format, or matching-semantics detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb (Lists) and resource (Tapir commands) and even characterizes the output (a one-line description). It does not explicitly name how it differs from siblings tapir_describe_command and tapir_run_command, but the 'one-line description' phrasing implicitly separates it from the fuller describe variant.

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 states the optional filters ('optionally filtered by group name or text'), which implies when this tool is useful, but gives no explicit when-to-use vs tapir_describe_command/tapir_run_command guidance or prerequisite conditions.

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 destructiveHint=true and openWorldHint=false, so the safety bar is partly covered. The description adds useful nuance beyond the annotation by clarifying the destructiveness is conditional ('depending on the command') and that parameters are validated against the command's input schema, which tells the agent how failures arise.

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

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

Three short, front-loaded sentences with no filler. Each sentence contributes: capability, validation mechanism, and mutation risk.

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 generic command dispatcher there is no output schema, and the description does not cover return shape, error behavior, or how to discover valid command names (beyond a soft pointer). It covers the essentials for invocation but leaves meaningful gaps for a tool whose behavior depends entirely on an opaque string parameter.

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

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

Schema coverage is 100% and both parameters are documented in the schema itself. The description adds only the pointer that 'parameters' must conform to the target command's input schema (via tapir_describe_command), which is genuinely helpful but does not elaborate individual parameter formats.

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

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

States a specific verb (Runs) and resource (any Tapir command), which is distinguishable from siblings like tapir_list_commands and tapir_describe_command. However, it does not differentiate itself from the similarly-named archicad_run_api_command, leaving some ambiguity about which dispatcher to pick.

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 implicitly routes the agent to tapir_describe_command for parameter lookup and warns that data may be modified or deleted, but gives no explicit when-to-use guidance versus archicad_run_api_command or the dedicated typed tools. Usage context is implied rather than stated.

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