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

No annotations are provided, so the description carries the full burden. It describes the tool as a 'powerful query tool' for finding elements, implying a read operation, but does not explicitly state it is non-destructive. It also lacks details on performance implications, permissions, or limitations on spatial bounds. The default max_elements is mentioned in the schema but not in the description.

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

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

The description is well-structured with a one-line summary, a brief paragraph, and a bullet-like Args list. While the Args list is verbose, each line is informative and earns its place. The opening sentence is front-loaded with the tool's purpose. Minor overuse of whitespace could be trimmed slightly.

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

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

Given that the tool has 6 parameters (including nested objects) and no output schema, the description should explain what the tool returns. It fails to describe the output format (e.g., list of element IDs or properties), which is a significant gap. The input parameters are well-covered, but the overall completeness is lacking for an effective agent interaction.

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?

Despite the schema having 0% description coverage, the description includes a detailed Args section for each parameter, explaining the expected format (e.g., BuiltInCategory name, partial match, units in mm), which adds significant meaning beyond the schema's basic type and title information. This fully compensates for the schema's lack of descriptions.

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

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

The description starts with 'Filter and find Revit elements by category, type, visibility, and spatial bounds,' which clearly states the verb (filter/find) and resource (Revit elements). Among the sibling tools, which include simpler retrieval tools like get_current_view_elements and get_selected_elements, this tool’s multi-criteria filtering capability distinguishes it effectively.

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

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

The description provides an example ('find all exterior walls on Level 1 visible in the current view') and advises to combine filters for precise results. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention conditions to avoid using it. Nonetheless, the context implies it is for advanced filtering.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It implies the tool is read-only but does not explicitly state that, nor does it describe potential side effects, performance implications, or output format. The mention of a 'ctx' argument not present in the schema adds confusion.

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 brief with two sentences and an unnecessary 'Args' line. The core purpose is clear and front-loaded, but the redundant argument mention wastes 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?

Given the lack of an output schema, the description should specify the structure of the return value (e.g., dictionary of categories to counts). It only says 'element counts grouped by category,' which is vague. Compared to siblings like get_revit_model_info, it lacks details on what exactly is returned.

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

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

The input schema has no parameters, so schema coverage is 100%. However, the description includes an 'Args' line referencing a 'ctx' parameter that does not exist in the schema, which could mislead an agent. For a zero-parameter tool, the description should not introduce phantom parameters.

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

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

The description clearly states the tool analyzes the Revit model and returns element counts grouped by category, with examples like walls, doors, windows. However, it does not differentiate itself from sibling tools such as get_material_quantities or get_revit_model_info, which also provide model analysis.

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 mentions it is useful for progress tracking and model health checks, providing context for when to use it. However, it lacks explicit guidance on when not to use it or how it compares to 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?

Discloses that it removes all color overrides and returns elements to default appearance. Returns count of processed elements. Without annotations, this provides adequate transparency for the tool's effect, though it omits details like undo capability 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?

Starts with a focused one-line purpose, followed by a brief elaboration and well-structured Args/Returns sections. Every sentence adds value without 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?

Covers the main action, parameter, and return value adequately for a simple tool. Lacks mention of error handling (e.g., invalid category) or prerequisites, but overall is sufficient given the tool's simplicity.

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

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

The description's Args section provides a clear explanation of category_name with examples ('Walls', 'Doors'), adding significant meaning beyond the schema which only has a title and type. With 0% schema coverage, this fully compensates.

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 clearly states the action: 'Clear color overrides for elements in a category.' It specifies the resource (color overrides for category elements) and the verb (clear). This sufficiently distinguishes it from siblings like color_splash or modify_element.

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 (e.g., individually clearing overrides on elements). No context on prerequisites or conditions like needing a valid category that has overrides.

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

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

The description explains that elements with the same parameter value get the same color, and mentions optional gradient and custom colors. It also describes return value with statistics, but lacks details on persistence or reversibility. Since no annotations exist, the description covers behavior adequately.

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 structured with a brief summary followed by parameter descriptions. It is concise and front-loaded, though the parameter list could be more compact. Overall, it is clear and without redundancy.

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

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

The description covers the tool's core functionality and all parameters, and mentions return values. Given no output schema, the description is fairly complete, though it could mention error handling or edge cases.

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

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

The description provides detailed parameter explanations beyond the schema, including example values and formats (e.g., hex for custom_colors). With 0% schema coverage, the description compensates well by clarifying each parameter's role.

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

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

The description clearly states the tool's purpose: coloring Revit elements based on parameter values, with examples of parameters. It distinguishes from siblings like 'clear_colors' or 'set_parameter'.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only describes the function without contextual usage 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?

Without annotations, the description explains that detail lines are view-specific and 2D, and requires a valid view type. However, it does not disclose potential side effects, error conditions (e.g., invalid view name), or authorization requirements, leaving gaps in transparency for a creation tool.

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

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

The description starts with a clear one-line purpose, followed by contextual prose, then a structured Args list. It is informative and well-organized, but could be slightly more concise by merging some redundant statements. Still effective and front-loaded.

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

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

Given 4 parameters (2 required) and no output schema, the description covers parameter meaning, view restrictions, and the distinction from model lines. It does not document return values or error behavior, but for a straightforward creation tool, it provides sufficient context for an AI agent to use it correctly.

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

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

The schema has 0% coverage, so the description fully carries the burden. It explains each parameter's role, format (including coordinate component keys and units in mm), and defaults (view_name defaults to active view, line_style uses default style if omitted), adding substantial value 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?

The description specifically identifies the tool as creating a detail line for annotation in Revit, clarifying it is view-specific and 2D, distinguishing it from model lines. It also specifies valid view types (plan, section, detail), leaving no ambiguity about the tool's purpose.

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 states that lines appear only in the view where created and must be in a plan, section, or detail view, providing clear context. While it contrasts with model lines, it does not explicitly name alternative tools like create_line_based_element or provide when-not-to-use guidance, slightly reducing completeness.

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?

Without annotations, the description discloses that the dimension line is automatically placed at an offset for readability. However, it lacks details on potential side effects (e.g., overwriting existing dimensions), error handling, or permissions 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?

The description is concise with four sentences, front-loading the primary action and view constraints. The Args list is clear but could be more integrated.

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

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

The description covers purpose, view support, and parameter meaning but omits details like default offset distance, behavior in 3D views, and error scenarios. For a simple tool, it is adequate but not fully complete.

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

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

Although the schema description coverage is 0%, the description's Args section defines the parameters: element_ids as 'List of element IDs to dimension' and dimension_type with possible values ('linear', 'aligned', 'angular'), adding meaning 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?

The description clearly states the verb 'Create', the resource 'dimension annotations', and the scope 'for elements in the current view'. It also specifies the view types (plan, section, elevation), which distinguishes it from sibling tools like create_detail_line.

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 indicates that the tool works in plan, section, and elevation views, providing context for when to use it. However, it does not explicitly mention when not to use it or provide alternatives, which could be improved for better 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?

No annotations provided. The description indicates a write operation but does not disclose side effects, permissions needed, or potential issues. It mentions auto-detection behavior for some parameters, offering moderate transparency.

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

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

The description is well-structured with a summary paragraph and an Args list. It is somewhat lengthy but front-loads the main action. Could be slightly more concise, but effective.

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

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

Given 8 parameters, no output schema, and no annotations, the description covers shape modes, defaults, and units adequately. Lacks return value info but is fairly complete for a creation tool.

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

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

Schema coverage is 0%, yet the description provides detailed explanations for each parameter, including units, default behaviors, and selection logic. This adds significant value beyond the bare schema.

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

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

The description clearly states 'Create a duct in the Revit model between two points,' which is a specific verb and resource. It distinguishes from sibling tools like create_pipe and create_structural_framing by specifying duct creation.

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

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

The description mentions requirements ('MEP template') and usage patterns ('diameter for round, width+height for rectangular'). It does not explicitly state when not to use or provide alternatives, but context makes it 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?

No annotations are provided, so the description carries full burden. It discloses batch creation, auto-naming behavior, and units (mm). However, it does not mention side effects, error conditions, permissions, or what happens on duplicate names. It is adequate but not thorough.

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 informative and well-structured with a clear introductory sentence followed by detailed parameter documentation. It is slightly verbose (e.g., 'Grids define the column grid system' is somewhat redundant) but generally earns its place without excessive fluff.

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

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

Given the tool's moderate complexity (batch creation of grid lines with auto-naming), the description covers the essential aspects: parameter format, auto-naming, and batch support. It lacks mention of the return value (e.g., created grid IDs) and coordinate system reference, but these are minor omissions.

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

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

The input schema is minimal (array of objects with additionalProperties: true). The description adds rich semantic detail: each grid item requires start_point and end_point (with x,y,z floats in mm) and an optional name. This fully compensates for the 0% schema description 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?

The description clearly states the verb 'Create' and the resource 'grid lines for the structural layout of a building.' It differentiates this tool from all siblings, as no other tool deals with grid lines. The purpose is specific and unambiguous.

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

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

The description implies the tool is for creating structural grid lines but provides no explicit guidance on when to use it versus alternatives, prerequisites, or ordering relative to other tools (e.g., before columns). It lacks 'when not to use' or context about the design phase.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the creation action and parameter details, missing key information such as side effects (e.g., whether existing levels are affected), required permissions, failure modes, or implications for model state.

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

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

The description is concise, front-loading the main purpose, followed by a brief explanation of levels' role, then a structured Args section. Every sentence adds value without unnecessary 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?

Given the absence of an output schema, the description does not explain what the tool returns (e.g., a list of created level IDs), leaving the agent without expected response structure. Also lacks behavioral notes. For a creation tool, this is incomplete.

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

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

The input schema is sparse with a single array parameter 'levels' having extra properties allowed (0% coverage). The description adds needed meaning by specifying each element requires 'elevation' (float in mm) and optionally 'name', which is essential for correct invocation.

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

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

The description uses a specific verb 'Create' and clearly identifies the resource 'building levels (floor elevations)' in Revit. It explains what levels do and distinguishes this tool from siblings like list_levels, which only list levels.

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 states that levels 'must be created before placing walls, floors, or other level-dependent elements,' providing clear context for when to use this tool. It does not explicitly exclude alternative approaches or mention when not to use it, but the guidance is strong.

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

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

No annotations are provided, so the description carries the full burden. It discloses batch creation capability and parameter structure but lacks details on side effects, permissions, or failure behavior. For a mutation tool, this is moderately transparent.

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

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

The description is well-structured with paragraphs and an Args section, but slightly lengthy. It front-loads the purpose and remains informative without 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?

Input parameters are thoroughly described, but there is no output schema or explanation of return values (e.g., created element IDs). Error handling and model state implications are missing, leaving gaps for a creation tool.

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

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

The input schema has 0% description coverage with minimal structure. The description compensates by detailing each element definition (type, points, optional fields), adding significant meaning 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?

The description clearly states it creates 'walls, beams, and other line-based building elements' with a specific verb and resource. It distinguishes from sibling tools like create_detail_line, create_duct, and create_pipe, which target different element types.

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 for line-based elements but does not explicitly state when to use this tool vs alternatives like create_duct or create_pipe. It mentions batch creation but lacks guidance on 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It covers the basic operation (creation, optional add) but lacks details on side effects, permission requirements, naming constraints, or error conditions. It is a minimal description without contradictions.

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

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

The description is concise at approximately 50 words and well-organized with a one-line summary followed by a bullet-style Args section. Every sentence is informative, and the structure is front-loaded.

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

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

Given no output schema, the description should explain the return value (e.g., system ID). It omits this, leaving a gap for the agent. It covers the core function but is incomplete for post-invocation understanding.

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

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

The input schema has 0% description coverage, so the description's Args section adds crucial meaning: system_type as 'mechanical' or 'piping', system_name as display name, and element_ids as optional list. This compensates for the schema gap, though it could provide more detail on name constraints.

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

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

The description clearly states 'Create a mechanical or piping system' and 'Groups ducts or pipes into a named system for organization and analysis.' The verb 'Create' and resource 'MEP system' are specific, and the mention of system_type distinguishes it from sibling tools like create_duct and create_pipe.

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 after individual duct/pipe elements are created, and it notes optional element addition. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, leaving the agent to infer context.

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

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

No annotations provided, so description must disclose behavioral traits. It only mentions 'Create' implying mutation, but lacks details on side effects, reversibility, permissions, or state changes.

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

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

The description is well-structured with a summary, prerequisites, and a parameter list. It is concise but front-loaded appropriately.

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

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

Given no output schema or annotations, the description should explain return values or success criteria. It only covers inputs, leaving behavior post-execution unclear.

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 has 0% description coverage, but the description adds semantic meaning for all 6 parameters (e.g., coordinates in mm, auto-detect, default behavior), significantly enhancing understanding.

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

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

The description clearly states 'Create a pipe in the Revit model between two points,' specifying the action (create) and the resource (pipe). It distinguishes from sibling tools like create_duct and create_mep_system.

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 notes prerequisites (MEP template with plumbing families) and units (millimeters), but does not explicitly state when to use this tool versus alternatives or when not to use it.

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

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

No annotations are provided, so the description carries full burden. It discloses that rooms require enclosed areas and that auto-placement occurs if no location is given, but it fails to explain error handling, permission needs, side effects, or the return value. For a mutation tool, this is insufficient.

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 relatively compact and front-loaded with the core purpose. The Args list is slightly redundant with the schema but adds context. It could be more concise, but overall it is well-structured.

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

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

The tool has no output schema, but the description does not explain what is returned after creation (e.g., room ID). It also omits error conditions like invalid level or location outside enclosure. Given the complexity (4 params, nested object), this is incomplete.

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

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

Schema description coverage is 0%, but the description adds significant meaning: it specifies level_name as the target level with an example, location as an optional point with x,y in mm, and names/numbers with examples. It also explains auto-placement when location is omitted, which is not evident from 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 description clearly states the tool creates a room in the Revit model at a specified level. It specifies the verb 'create', the resource 'room', and the context 'Revit model', which distinguishes it from sibling tools like create_detail_line or create_dimensions.

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 mentions that rooms must be placed inside enclosed areas bounded by walls or room separation lines, implying a prerequisite. However, it does not explicitly guide when to use this tool versus alternatives like create_room_separation, nor does it state when not to use it.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the lines 'act as invisible walls for room calculation' but does not mention whether this operation is destructive, if special permissions are needed, or what side effects (e.g., modification of room boundaries) occur. The description lacks critical details about the tool's impact on the 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?

The description is well-structured with an Args section, but includes unnecessary details like 'ctx: MCP context for logging' which is not relevant for an agent selecting the tool. The purpose is front-loaded, and the overall length is appropriate, but a few words could be trimmed.

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

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

Given no output schema and 3 parameters, the description explains the input well but does not mention what the tool returns (e.g., element IDs, success status). For a creation tool, return value is often needed for subsequent operations. The description is incomplete for full context.

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

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

The input schema has 0% description coverage, so the description must compensate. The Args section explains lines as list of segments with start_point and end_point dicts (x,y,z in mm), and level_name/view_name default to active view. This adds significant meaning, but could be more structured for the 'lines' parameter (e.g., exact format of dict).

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

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

The description clearly states 'Create room separation lines to define room boundaries,' specifying the verb (create) and resource (room separation lines). It distinguishes from sibling tools like create_room and create_grid by focusing on invisible walls for room calculation, making its purpose unambiguous.

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

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

The description provides explicit use cases: 'Use these when physical walls don't fully enclose a space (e.g., open-plan areas, corridors).' However, it does not mention when not to use or suggest alternatives, which would be helpful for an AI agent deciding between this and other creation 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?

No annotations exist, so the description carries the full burden. It states that the schedule appears as a new view, but does not disclose side effects, prerequisites (e.g., category existence), or permissions. The description is adequate but could be more thorough.

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 fairly concise with front-loaded purpose, a short explanation, and an args list. No unnecessary sentences.

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

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

For a tool with no output schema, the description explains the outcome (new view appears). However, it omits error conditions, default behaviors, and any return value. It is adequate but not complete.

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

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

Schema coverage is 0%, so the description must compensate. It explains category as a BuiltInCategory name with examples, fields as column parameter names, and schedule_name as a view name. This adds meaning but lacks details like accepted values or constraints.

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

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

The description clearly states the tool creates a schedule (quantity takeoff view) for a specific element category, with an example of walls. However, it does not explicitly distinguish it from sibling tools like create_view, which might also create views.

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 does not provide guidance on when to use this tool versus alternatives (e.g., create_view or list_families). No when-not or exclusion criteria are 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?

No annotations provided, so description must cover behavioral traits. It mentions optional parameters and defaults, but does not disclose potential conflicts (e.g., duplicate sheet numbers), error conditions, permissions required, or side effects. Lacks transparency for a creation 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?

Well-structured with a clear opening sentence and an args section. Some redundancy ('Views can be placed on sheets after creation' could be integrated), but overall efficient 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?

Does not describe return values (e.g., sheet ID) or confirmation of creation. No mention of error handling or prerequisites. For a creation tool without output schema, this leaves a significant gap in completeness.

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

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

Adds meaning beyond the schema by providing examples and explanations for each parameter (e.g., sheet_number as 'e.g. A101', sheet_name default). However, does not clarify valid values for title_block_name or constraints, leaving some ambiguity.

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

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

Clearly specifies the verb 'create' and resource 'drawing sheet in Revit for construction documentation'. Provides context on what sheets are and that views can be placed later, distinguishing it from sibling tools like create_view or create_detail_line.

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?

Implies usage for construction documentation and mentions that views can be placed afterward, but does not explicitly state when to use this tool vs alternatives like create_view. No 'when not to use' guidance, leaving the agent to infer from context.

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

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

No annotations are provided, so the description carries full burden. It discloses that it creates elements, uses millimeters, and supports batch creation, but it does not mention side effects (e.g., overwriting existing elements), permissions, limits, or error handling. This provides moderate transparency but lacks depth.

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

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

The description is concise, with a brief overview followed by a parameter list. Each sentence adds value, but the parameter list could be more compact. It is well-structured 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?

The description explains the basic usage and input structure, but it lacks information about return values (output), error conditions, validation rules, or limitations. Given the complexity (nested objects, no output schema), more details on behavior and outcomes would improve completeness.

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

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

The input schema is sparse with only an array of objects and no parameter descriptions. The description compensates by detailing each sub-parameter (start_point, end_point, type_name, etc.) with types and optionality, adding significant meaning. However, it could be more precise about the dict structure or coordinate units (mm already noted).

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

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

The description clearly states it creates structural beams and framing elements in Revit, specifying they are placed along a line between two points. This distinguishes it from sibling creation tools like create_detail_line or create_grid, which serve different purposes.

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 for creating beams and framing elements, and mentions batch creation, but it does not explicitly state when to use this tool over alternatives like create_line_based_element or other structural tools. No exclusions or context for when not to use it.

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

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

No annotations, but description details the creation process and required parameters. Lacks mention of permissions, reversibility, or error handling.

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?

Front-loaded with purpose, includes Args section. Moderately concise but could be trimmed slightly.

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?

Provides good detail on inputs but misses return value, error handling, and prerequisites. 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 has 0% coverage, but description thoroughly explains the structure of 'elements' including required fields, types, and boundary format.

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?

Description clearly states it creates surface-based elements like floors, roofs, ceilings, with batch creation and polygon requirement. Distinguishes from sibling create_line_based_element.

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 general context but lacks explicit guidance on when to use this tool vs. alternatives or exclusions.

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

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

With no annotations provided, the description must disclose behavioral traits. It explains parameter requirements for different view types but does not describe side effects (e.g., document modification, active view changes, write permissions, or error states). The focus is on parameter structure rather than the operation's impact, leaving the agent underinformed about the tool's behavior.

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

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

The description is well-structured with a clear opening sentence followed by parameter details in bullet-like format. It front-loads the purpose and uses concise language. The section_box breakdown uses indentation for clarity. Slightly lengthy due to the nested parameter details, but each sentence adds value.

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

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

Given no output schema and no annotations, the description covers creation abilities and parameter rules but lacks completeness. It does not describe return values (e.g., view ID), success/failure behavior, or prerequisites (e.g., open Revit document). The sibling tools provide some context, but the description should stand alone.

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

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

Schema coverage is 0%, so the description carries the full burden. It adds significant meaning: enumerates view_type values, clarifies the level_name condition, and provides a detailed nested structure for section_box (origin, direction, up, width, height, depth). This compensates well for the bare schema. However, the description mentions a 'ctx' parameter not present in the schema, which could confuse agents.

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

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

The description clearly states the tool creates a new view in the Revit model and lists supported view types (floor plans, ceiling plans, sections, elevations, 3D). It distinguishes itself from sibling tools like create_room or create_sheet by focusing on views, but does not explicitly contrast with other view-related tools (e.g., set_active_view). The purpose is specific but lacks explicit sibling differentiation.

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

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

The description provides usage conditions: floor plans and ceiling plans require a level name, sections require a section box definition with specific fields. This guides the agent on when certain parameters are needed. However, it does not state when not to use the tool or suggest alternatives (e.g., if a view already exists). The context is clear but lacks non-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?

With no annotations, the description carries full burden. It discloses cascade deletion of hosted elements and that all deletions occur in a single transaction (all or none). This is good transparency, though it could mention return values 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 concise, well-structured with a brief paragraph and a clearly formatted Args section. Every sentence adds value without 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?

Given the single parameter, no output schema, and no annotations, the description covers the essential behavior and parameter meaning. It could be slightly improved by mentioning error handling or return value, but it is largely 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 schema has one parameter with no description (0% coverage). The description adds meaning by identifying the parameter as 'Revit element IDs' and explaining the cascade and transaction context. This provides necessary semantics beyond the raw schema.

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

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

The description clearly states the tool deletes elements from the Revit model by IDs, and mentions cascade deletion and transactional behavior. It is specific and distinguishes itself from sibling tools, which involve other operations like creating, modifying, or querying 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?

The description does not explicitly state when to use this tool versus alternatives, such as modifying elements instead. However, it provides clear behavior (cascade deletion, atomic transaction) that helps the agent understand its effects. No explicit when-not-to-use guidance is 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?

Despite no annotations, the description fully discloses behavior: it executes IronPython 2.7.12, wraps code in a transaction, provides access to doc/DB/revit/print, and includes error-handling tips. This is comprehensive.

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 long but well-structured with sections, example, and tips. It could be trimmed slightly, but the content justifies the length for a complex code-execution tool.

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

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

Given no annotations or output schema, the description covers purpose, usage, behavioral details, parameter guidance, and even troubleshooting. It feels complete 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 0%, but the description compensates with a detailed example and tips for writing code, adding significant meaning to both parameters 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?

The description clearly states it executes IronPython code in Revit context. It explicitly says to use this when existing MCP tools cannot accomplish what you need, distinguishing it from siblings.

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

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

The description provides explicit usage guidance: use when other tools fail. It also lists available objects and gives tips, making it clear when and how to apply the tool.

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

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

Without annotations, description bears full behavioral burden. It explains it exports to file on disk and lists supported formats, but does not disclose error handling, file overwrite behavior, or performance implications. Adequate but not comprehensive.

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?

Description is concise, front-loaded with purpose, and includes a well-structured Args section. Every sentence adds value without 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?

Given 3 parameters and no output schema, description covers core behavior and parameter details. However, it omits return value (file path) and potential error cases (e.g., invalid view name), leaving minor 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 0%, so description adds crucial meaning. It explains each parameter with defaults, usage, and context (e.g., resolution ignored for PDF/DWG), fully compensating for the lack of schema descriptions.

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

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

Clearly states it exports a Revit view or sheet to PDF or image format. Specific verb 'Export' and resource 'Revit view or sheet' with supported formats listed. Distinguishes from sibling export tools like export_ifc and export_room_data by focusing on view/sheet to PDF/image.

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?

Describes when to specify a view name and that it falls back to the active view. However, lacks explicit guidance on when to use this tool versus other export tools like export_ifc or export_room_data, and does not mention prerequisites or limitations.

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

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

No annotations exist, so the description carries the full burden. It states that the tool creates an IFC file, effectively a write/mutation operation, and mentions logging context. It lacks details on potential side effects or permissions required, but for a file export tool, the behavior is well explained.

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

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

The description is concise: three short paragraphs with a clear first line front-loading the purpose. No fluff; every sentence adds useful information.

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

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

Given the tool's moderate complexity (4 params, no output schema, no nested objects), the description covers all necessary aspects: purpose, parameters, options, and context argument. It is complete enough for an AI agent to invoke correctly.

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

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

Schema coverage is 0%, so the description must explain parameters. It does so by listing each argument with its meaning, default values, and constraints (e.g., file_path must end in .ifc). This adds value 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?

The description starts with a clear verb and resource: 'Export the Revit model to IFC format.' It specifies the output format and offers filtering options, distinguishing it from sibling tools like 'export_document' or 'export_room_data'.

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 explains when to use the optional view filter and IFC version selection, but it does not explicitly mention when NOT to use this tool or alternatives. The context is clear enough for an AI agent to make an informed choice.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool exports all rooms and returns a structured format, implying a read-only operation. However, it lacks details on potential side effects, permission requirements, or failure modes.

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

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

The description is concise with two sentences and an args note, front-loading the purpose. Every sentence earns its place without unnecessary fluff.

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

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

Given no parameters, no output schema, and no annotations, the description provides adequate context: it names the exported data fields and indicates the output is structured. It could mention output format or limits, but overall it is sufficient for a simple data export tool.

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

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

The tool has no parameters, and the schema coverage is 100%. The description does not add parameter information, but the baseline for zero parameters is 4, as there is nothing 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?

The description clearly states the tool exports data for all rooms in the Revit model, listing specific return fields (names, numbers, levels, etc.), which distinguishes it from sibling tools like export_document or export_ifc.

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 use for room data reporting but does not explicitly state when to use this tool versus alternatives, nor does it mention 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?

No annotations are provided, so the description carries full burden. It describes the return data (IDs, names, types, categories, etc.) but does not disclose potential side effects, performance impacts, or edge cases like empty views. Basic transparency is achieved.

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

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

The description is concise at 7 lines, front-loading the core purpose. Each sentence adds value: purpose, return fields, and a note on usefulness. No redundant or extraneous 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 simple read operation with no parameters and no output schema, the description sufficiently explains what the tool returns and when it is useful. It lacks information on error handling or performance, but overall completeness is 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?

There are no parameters, so the input schema fully covers the interface. The description adds no parameter details, which is appropriate. Baseline for zero parameters is 4.

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

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

The description clearly states the tool gets all elements visible in the currently active view, specifying the resource (elements in active view) and the verb (get). It mentions detailed return fields, distinguishing it from siblings like get_selected_elements and get_current_view_info.

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 for understanding visible elements and analyzing view content, but does not explicitly state when to use it over alternatives or provide exclusions. The guidance is implied but not direct.

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

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

No annotations provided, so the description carries the full burden. It describes the return info but does not disclose behaviors like read-only status, error conditions (e.g., no active view), or performance impact. The description is accurate but lacks depth.

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

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

The description is concise with two clear sentences and a bulleted list of return fields. There is no unnecessary text, and the structure is 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?

Given no output schema, the description thoroughly explains the return values, covering all relevant aspects of a view. The tool has low complexity (no parameters), and the description is complete for an agent to understand what the tool provides.

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

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

The tool has zero parameters, and the description adds significant value by listing the specific information returned (view name, type, ID, scale, detail level, crop box, family type, discipline, template status). This goes beyond the schema, which has no parameter descriptions.

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

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

The description clearly states it gets detailed information about the currently active view, listing specific fields like name, type, ID, scale, etc. This distinguishes it from siblings like get_current_view_elements, get_revit_view, list_revit_views, and set_active_view.

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

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

The description implies usage when needing details about the active view but does not explicitly state when to use it over alternatives or provide exclusions. No guidance on prerequisites or context.

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

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

With no annotations, the description adequately discloses that the tool reads element properties and returns detailed parameter information (values, storage types, read-only status). It does not mention side effects or error cases, but for a read operation this is sufficient.

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

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

The description is concise and well-structured: a one-line purpose, a bullet-like return description, and an args section. Every sentence adds value, though the args section could be slightly more compact.

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

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

Given no output schema, the description explains the return values well. It covers both parameters. However, it lacks details on error handling (e.g., invalid element_id) and does not mention performance considerations, which are minor 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?

Despite 0% schema description coverage, the description includes an 'Args' section that explains both parameters: element_id is 'Revit element ID to inspect' and include_type_params describes its effect and default. This adds meaning beyond the raw schema.

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

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

The description clearly states the action ('Get all properties and parameters') and the resource ('a Revit element'), and lists the specific data returned (category, family, type, parameters). It distinguishes itself from siblings like get_selected_elements and list_category_parameters.

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 explains what the tool does but does not provide explicit guidance on when to use it over alternatives like list_category_parameters or get_revit_model_info. The agent must infer usage from the tool's purpose.

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

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

No annotations are provided, and the description does not disclose behavioral traits beyond the basic operation. It does not specify that the tool is read-only, mention side effects, or address performance or permissions. Additionally, the description includes a 'ctx' parameter not present in the schema, causing minor inconsistency.

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 relatively short and front-loads the core purpose. The inclusion of an 'Args' section provides structure, though the 'ctx' line could be considered unnecessary if it is not part of the actual input schema.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description explains inputs and output type (aggregated material data with areas and volumes). However, it lacks detail on the exact return format (e.g., list of objects) and units, which would be needed for full completeness.

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

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

The single parameter 'categories' has no schema description, but the tool description adds meaning by providing an example and stating it defaults to all categories. This compensates for the missing schema documentation, though the description references an extra 'ctx' parameter not in 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 description clearly states the tool retrieves material quantities (areas and volumes) from a Revit model, with optional category filtering. It is specific about the verb and resource but does not differentiate from sibling tools like 'analyze_model_statistics'.

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 mentions it is 'useful for quantity takeoffs and cost estimation', implying a use case but providing no explicit guidance on when to use this tool vs alternatives or when not to use it.

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

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

No annotations provided, and the description does not disclose behavioral traits such as whether the tool is read-only, the scope of information returned, performance implications, or any side effects. The agent has no insight into what the tool does beyond a generic phrase.

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

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

The description is concise (one sentence) but lacks necessary detail. Conciseness is not valuable when the content is insufficient to guide the agent. It earns a middle score because it is not overly verbose but fails to be 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?

Given the lack of output schema, the description should explain what information is returned. It does not, making it incomplete for the agent to understand the tool's output. The tool is simple but the description omits essential context.

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

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

The tool has zero parameters, and the schema coverage is 100%. Since no parameters exist, the description does not need to add parameter detail. The baseline of 4 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 'Get comprehensive information about the current Revit model' is vague. It does not specify what 'comprehensive information' includes, nor does it differentiate from sibling tools like 'analyze_model_statistics' or 'get_element_properties'.

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 lacks any context for appropriate use or exclusions, leaving the agent without decision support.

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

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

No annotations are provided, so the description carries the full burden. It describes a read-only health check operation with no side effects, which is transparent. However, it does not specify the response format or what 'active' exactly means.

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, clear sentence with no unnecessary words. It is appropriately concise and front-loaded.

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

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

Given the tool's simplicity and no output schema, the description is adequate but could be more complete by specifying the response (e.g., returns a boolean or status object). It lacks details on what 'active' entails.

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

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

The tool has no parameters, so the baseline is 4. The description does not add parameter information, but none is needed as the schema already covers 100% of the (empty) parameters.

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

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

The description clearly states the tool checks if the Revit MCP API is active and responding, which is a specific verb-resource combination. It distinguishes itself from sibling tools that perform creation, modification, or analysis tasks.

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 does not explicitly guide when to use this tool versus alternatives. However, its status-checking nature implies it should be used before other operations to verify connectivity, but this is not 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?

Without annotations, the description must disclose behavior but only says 'export an image', omitting details on permissions, file format, resolution, or whether the view must be active.

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, short sentence without wasted words, but lacks key details that could be added without verbosity.

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 one-parameter tool, the description provides minimal viable purpose but lacks details on output format, error handling, and prerequisites, leaving 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?

The sole parameter 'view_name' has no description in schema or description; with 0% schema coverage, the description adds no meaning beyond the parameter name itself.

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

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

The description clearly states the verb 'Export' and the resource 'a specific Revit view as an image', making it distinct from sibling tools like get_current_view_info or list_revit_views.

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

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

No guidance is provided on when to use this tool versus alternatives like export_document or get_current_view_info, nor any prerequisites or context for invocation.

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?

Without annotations, the description covers key behaviors: returns empty list on no selection (not an error), and indicates read-only nature. Could mention that an active Revit document is required, but still provides solid transparency.

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

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

Four short, front-loaded sentences with no filler. Each sentence adds value: purpose, return details, edge case behavior, and argument placeholder.

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

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

Given no output schema or annotations, the description adequately explains return values and empty behavior. Missing context: prerequisite of active selection or document, but still complete enough for a simple get tool.

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

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

No parameters exist, schema coverage is 100%. Per calibration, zero parameters achieve baseline 4. No additional parameter documentation needed.

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

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

The description clearly states it gets details of elements selected in the Revit UI, specifies exactly what is returned (IDs, categories, types, key parameters), and distinguishes from sibling tools like get_current_view_elements by focusing on current selection.

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 context (when user has selected elements), but does not explicitly state when to use this vs. alternatives like get_element_properties or get_current_view_elements. No when-not or exclusion criteria provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses that linked files maintain a live connection and imported files are embedded, which is key behavioral info. However, it omits details about error handling, permissions, or what happens if the file path is invalid.

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 paragraph with a clear list of arguments, making it scannable. It could be slightly more concise, but the information density is good and front-loaded with the primary action.

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

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

Given no output schema, the description does not explain return values or success/error indications. It covers file linking basics but lacks context on prerequisites, side effects, or error scenarios, which is a gap for a file I/O tool.

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

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

With 0% schema description coverage, the description effectively documents all three parameters: file_path (path to supported types), mode (link/import with defaults), and position (optional offset with units). This adds significant meaning beyond the bare schema.

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

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

The description clearly states it links or imports external files into Revit, lists supported formats (DWG, DXF, DGN, RVT), and distinguishes between link and import modes. This is specific and differentiates from sibling tools like export or creation.

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

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

The description explains the two modes (link vs import) and their implications (live connection vs embedded). However, it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria, leaving some ambiguity for an agent.

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

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

No annotations are provided, so the description carries full burden. It clearly indicates a read-only operation (listing parameters) with no side effects, but does not explicitly state read-only, auth needs, or rate limits. The description is sufficient for a benign 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?

The description is clear and well-structured with a purpose line, a contextual note about coloring, and an Args/Returns section. It is concise but could be slightly tighter by removing redundancy between the first sentence and the later 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 simple one-parameter tool with no output schema and no annotations, the description provides adequate context: it explains what the tool returns (list of available parameters with types and sample values) and gives an example input. It is sufficiently complete for an agent to understand and invoke the tool.

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

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

Schema description coverage is 0%, but the description adds meaning with 'Name of the category to check parameters for (e.g., 'Walls', 'Doors')', which provides context and examples not present in 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 description clearly states the tool 'Get available parameters for elements in a category' and specifies it helps discover parameters for coloring. The verb 'list' and resource 'parameters' are specific, distinguishing it from siblings that list families or categories.

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 when needing parameters for coloring but does not explicitly state when to use or not use this tool versus alternatives like ai_element_filter or set_parameter. No exclusions or alternative tools are 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?

With no annotations, the description carries full burden. It discloses that the output is a flat list, but does not mention performance, side effects, or data format. For a read-only query, this is adequate but could be more explicit about return structure.

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

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

The description is a single sentence with essential information only: verb, resource, and scope. No superfluous 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?

The description lacks detail about what is returned (e.g., names, IDs) and does not mention the filtering or limiting capabilities. Without output schema, more information is needed for the agent to understand the tool's full behavior.

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

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

Schema description coverage is 0%, so the description must compensate. However, it provides no information about the two parameters ('contains' and 'limit') or how they affect results. The description adds no value 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?

The description clearly states the action ('Get'), the resource ('family types'), and the scope ('in the current Revit model', 'flat list'). It distinguishes from siblings like 'list_family_categories' which lists categories, not types.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., 'list_family_categories' or 'analyze_model_statistics'). There is no mention of prerequisites or exclusions.

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

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

No annotations are provided, so the description carries full burden. 'Get' implies a read-only operation with no destructive side effects. The description does not elaborate on performance, return size limits, or whether the list is static or dynamic, but for a simple retrieval, this is acceptable.

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

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

The description is a single, concise sentence that directly states the tool's function with no extraneous words. It is front-loaded and efficient.

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

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

Given the tool has no parameters and no output schema, the description is largely sufficient. It could optionally mention that the return is a list of category names or IDs, but the current lack of detail does not hinder understanding for a simple read action.

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

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

The input schema has no parameters and schema coverage is 100%. The description does not add extra semantics beyond what the schema already conveys (i.e., nothing to configure). 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 uses a specific verb ('Get') and clearly identifies the resource ('all family categories in the current Revit model'). It distinguishes from siblings like list_families (which returns families, not categories) and list_category_parameters (which returns parameters of a category).

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 does not explicitly state when to use this tool versus alternatives, nor does it provide usage examples or prerequisites. However, the tool's simple nature and clear purpose imply its usage context without needing extra 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?

No annotations provided, so the description bears the burden. It states a read-only list operation but lacks details on return format, performance, or ordering. 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?

A single sentence with no waste, perfectly concise and well-structured for front-loading the key 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 simple tool with no parameters and no output schema, the description adequately conveys the purpose. Minor improvement could mention return details (e.g., level names/elevations), but current is sufficient.

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 are 0 parameters with 100% schema coverage; the description correctly adds no parameter info, meeting the baseline for zero parameters.

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

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

The description clearly specifies the action ('Get a list'), the resource ('levels'), and the scope ('in the current Revit model'), distinguishing it from sibling tools like create_level or list_families.

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

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

No explicit guidance on when to use or when to avoid this tool, nor alternatives are mentioned. However, the simple context makes the intended use obvious.

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?

Without annotations, the description does not reveal behavioral details such as what 'exportable' means (e.g., views that are not templates or locked), performance implications, or side effects. However, for a simple listing operation with no parameters, the disclosure is minimally adequate.

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

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

The description is a single sentence that directly conveys the tool's purpose with no redundant or extraneous words. It is optimally concise for the tool's simplicity.

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?

While adequate for a no-parameter tool, the description does not specify the format of the returned list (e.g., array of view names or IDs) or any constraints on the model state. Given the absence of an output schema, more detail would improve completeness.

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

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

With zero parameters (100% schema coverage), the baseline is 4. The description adds value by specifying that the list is of 'exportable views', which clarifies what is being returned beyond the empty schema.

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

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

The description clearly states the verb 'Get' and the resource 'list of all exportable views' within the scope 'in the current Revit model'. It distinguishes from siblings like 'get_current_view_elements' and 'create_view', making the purpose unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that this tool lists views suitable for export before using export tools, nor does it specify conditions like needing an active model or that views must be exportable.

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

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

The description discloses that it modifies instance parameters and returns old and new values for confirmation. However, it does not mention error handling (e.g., non-existent parameters), permissions, or side effects. No annotations are provided, so the description carries full burden but is incomplete.

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 relatively concise and front-loaded with the purpose. The docstring-style Args section adds structure but could be more streamlined.

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

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

Given the tool has a nested parameters object and no output schema, the description partially explains the return value. It lacks details on formatting of old/new values and does not cover edge cases like modifying read-only parameters. Siblings include many similar tools, but the description does not fully differentiate context.

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

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

With 0% schema coverage, the description adds meaning by explaining element_id and parameters as a dictionary with example. However, it does not specify valid parameter types, case sensitivity, or constraints, leaving some ambiguity.

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

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

The description clearly states 'Modify parameter values on a Revit element' and 'Changes one or more instance parameters', using a specific verb and resource. It distinguishes from siblings like 'set_parameter' and 'delete_elements' by focusing on modifying multiple instance parameters.

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 for modifying instance parameters but does not explicitly state when to use this tool versus alternatives like 'set_parameter' or 'transform_elements'. No when-not-to-use or prerequisites are 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?

With no annotations, the description must disclose behavioral traits. It states a create action but omits side effects (e.g., whether coordinates are relative, if active view matters, or if duplicate instances are allowed). This is insufficient for an agent to predict 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 a single 12‑word sentence, which is concise but too sparse for 8 parameters. While front‑loading is good, it omits necessary details, making it marginally adequate.

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

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

Given 8 parameters, no output schema, and no annotations, the description is incomplete. It does not explain required vs optional behavior, coordinate semantics, or the 'properties' object. The agent would need to guess many 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%, so the description must compensate. It does not explain any parameter (e.g., family_name meaning, coordinate system, or properties object). The parameter names are self‑descriptive but the description adds no extra meaning, leaving 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 uses a specific verb ('place') and resource ('family instance') and mentions the action occurs at a 'specified location in the Revit model'. It clearly distinguishes from sibling tools like 'list_families' (which lists) and system family creation tools like 'create_duct' or 'create_pipe'.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as prerequisites (e.g., family must be loaded) or excluding situations (e.g., if family not found). No explicit context or when-not advice is 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?

With no annotations, description alone must disclose behavior. It states it changes the UI display but does not mention that no model modification occurs or any potential side effects. Adequate but not thorough.

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?

Description is very concise, using only two sentences plus a docstring. Front-loaded with the primary action and includes prerequisite guidance without unnecessary 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?

Given the tool's simplicity (one parameter, no output schema), the description covers the core action and prerequisite adequately. Could mention failure cases (invalid view name) but overall sufficient.

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

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

Schema coverage is 0%, so description must compensate. It only repeats the parameter name and says 'name of the view to activate,' lacking specifics like case sensitivity or match requirements. Minimal added value.

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?

Description clearly states it switches the active view in Revit to a specified view, differentiating it from sibling tools like list_revit_views (listing) and create_view (creation).

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

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

Explicitly advises to use list_revit_views first to obtain valid view names, providing clear context for when to use this tool. Does not mention alternatives or when not to use, but the guidance is sufficient.

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

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

No annotations are provided, so the description carries full burden. It discloses automatic type conversion and return of old/new values, but lacks details on side effects, prerequisites, or failure modes. For a mutation tool, more behavioral context is needed.

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

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

The description is concise with a front-loaded purpose sentence followed by a feature summary and argument list. Every sentence adds value, and there is no verbosity. Slight improvement possible by integrating the Args section more naturally.

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

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

The description mentions return values but lacks output format details. It does not address error handling, invalid parameters, or active document requirements. For a data-modifying tool in a complex environment, more completeness is warranted.

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

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

With 0% schema coverage, the description's 'Args' section adds essential meaning to each parameter, including an example for parameter_name and the auto-conversion for value. This is a significant improvement over the bare schema, though element_id could benefit from more context.

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

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

The description clearly states the verb 'Set' and the resource 'parameter value on a Revit element', making the tool's purpose unambiguous. It also mentions automatic type detection and conversion, which distinguishes it from generic 'modify_element' sibling.

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 use for setting a single parameter but does not provide explicit when-to-use or when-not-to-use guidance. Given siblings like 'modify_element' that might also modify parameters, some exclusion or alternative mention would improve this score.

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?

Despite no annotations, the description discloses key behaviors: tags are placed on elements, auto-detects tag type if omitted, uses default active view, and explains parameters like offset in mm. It does not mention potential side effects or prerequisites (e.g., elements must exist in the view), but overall provides sufficient transparency for a non-destructive annotation tool.

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

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

The description is concise and well-structured: a one-line purpose, a brief behavioral summary, then a clear list of parameters. Every sentence adds value, and the key information is front-loaded. The inclusion of 'ctx' is minor but acceptable.

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

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

The description covers most aspects for a tool of this complexity: it explains all 6 parameters, works with common categories, and auto-detects tag types. However, it does not mention potential errors (e.g., invalid element_ids) or what the tool returns (no output schema). Slight gaps remain, but overall adequate.

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

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

The input schema has 0% description coverage, but the tool's description fully compensates by detailing each parameter in the 'Args' section, including types, defaults, and units (e.g., offset as '{"x": float, "y": float} in mm'). This adds substantial meaning beyond the schema's titles.

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

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

The description clearly states the tool's purpose: 'Tag elements with annotation symbols in a view.' It specifies that it places tags displaying element properties like type name, mark, or room name/number, and works with specific categories (walls, doors, windows, rooms). This distinguishes it from the sibling 'tag_walls' tool, which presumably targets only walls.

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

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

The description provides usage context by listing compatible element categories ('walls, doors, windows, rooms, and other taggable categories'), but it does not explicitly state when not to use this tool or mention alternatives like 'tag_walls'. Without such guidance, the agent may not know to choose the more specific tool when appropriate.

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

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

Describes behavioral details like centering tags, default tag type selection, and optionally showing leader lines. No annotations provided, but description provides sufficient transparency.

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

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

Well-structured with core action first, followed by details and Args section. Slightly verbose with 'MCP context for logging' but overall efficient.

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

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

Covers purpose, parameters, and behavior. Lacks explicit description of return value or output, but this is likely non-essential for a tagging tool. No output schema, so description need not explain returns.

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?

Adds meaning beyond schema: use_leader controls leader lines, tag_type_name specifies a specific tag family type. Schema coverage is 0%, but description fully explains both parameters.

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

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

The description uses specific verb 'tag' and resource 'untagged walls in current Revit view', clearly distinguishing from siblings like tag_elements which tag selected 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?

Clearly states when to use (tag all untagged walls in current view), but does not explicitly mention alternatives or when not to use.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose side effects (e.g., whether copy creates new elements or move modifies existing), authentication needs, or error states. The description only states the operation type without behavioral caveats.

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

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

The description is well-structured with a title line, summary, and Args list. It is not overly verbose, though the Args section largely duplicates schema info while adding necessary context. The purpose is front-loaded, but the overall length is reasonable for the complexity.

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

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

Given the complexity (6 params, nested objects, no output schema, no annotations), the description covers parameter usage well but lacks behavioral context (e.g., return value, side effects, error handling). The absence of output schema description leaves a gap in completeness.

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

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

Schema coverage is 0%, so the description compensates by providing units (mm, degrees), conditional requirements (e.g., vector is required for move/copy), and structure for objects (e.g., mirror_plane has origin and normal). This adds significant meaning beyond the bare schema, though some parameters like 'mirror_plane' could be slightly clearer.

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

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

The description clearly states the tool's action: 'Move, copy, rotate, or mirror elements in the Revit model.' It uses specific verbs and identifies the resource (elements). This distinguishes it from sibling tools like delete_elements or modify_element.

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 for geometric transformations but does not explicitly state when to use this tool versus alternatives like copy/move via modify_element. No when-not-to-use guidance is provided.

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