ETABS MCP Server

by mdvaleed7

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Tools are generally distinct with clear descriptions, but the large number (69) and some similar prefixes (e.g., 'etabs_add_', 'etabs_assign_') may cause minor confusion. Overall, each tool has a well-defined purpose.
Naming Consistency5/5
All tools follow a consistent 'etabs_verb_noun' snake_case pattern, making it predictable and easy for an agent to infer functionality from names.
Tool Count3/5
69 tools is high for an MCP server, but the domain (ETABS structural engineering) is complex. The count is borderline heavy, though each tool addresses a specific aspect of modeling, analysis, or design.
Completeness4/5
The tool set covers the full cycle of structural analysis: geometry, materials, sections, loads, analysis, results, and design codes. Minor gaps (e.g., nonlinear analysis, link objects) but sufficient for typical building design.
Average 4.1/5 across 69 of 69 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and non-destructive. The description adds that it assigns to area/line objects for wall spandrels but does not disclose other behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-structured; it lists args and returns but lacks front-loading of key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters and output schema, the description is minimally adequate but fails to cover parameter semantics or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no detail beyond the schema. The parameter 'item_type' has a default and possible values not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assigns a spandrel label to area or line objects, with context 'for wall spandrels'. However, it does not explicitly differentiate from sibling tools like etabs_assign_pier_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds context that it is for wall piers and that item_type can be 'Object', 'Group', or 'SelectedObjects', but does not disclose additional behavioral traits like error handling or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single-line purpose followed by a bulleted parameter list. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic function and parameters, and an output schema exists. However, it misses context about appropriate use cases compared to similar assign tools, and does not explain the concept of a pier label or the full behavior of item_type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the parameter descriptions in the Args section provide minimal meaning: 'Object name', 'Name of the pier label', and the options for item_type. However, they lack depth, such as valid string formats or the relationship between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool assigns a pier label to an area or line object for wall piers, which is a specific verb-resource combination. It distinguishes from sibling tools like etabs_assign_spandrel_label implicitly by focusing on piers, but could explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as etabs_assign_spandrel_label or etabs_assign_diaphragm. It only describes what it does, not the context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds parameter context (e.g., color defaults, boolean flags) but does not disclose behavioral traits like whether duplicate group names cause errors or if the tool modifies the model globally. It adds some value beyond annotations but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, a structured list for arguments, and a return line. Every element earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and an output schema (returning 'Confirmation'), the description is minimally adequate. It lacks context about the model state (e.g., 'Creates a new group in the current ETABS model') and does not explain the 'Confirmation' return format. Sibling tools like etabs_define_load_case are more descriptive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With input schema having 0% description coverage, the description provides all parameter semantics. Each parameter gets a brief but clear explanation (e.g., 'Color for the group (-1 for auto)'). This is essential for correct invocation, though explanations are terse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Define a new group.' which clearly indicates the verb (define) and resource (group). It distinguishes from sibling tools like define_area_section or define_load_case by the resource type, but does not explicitly differentiate from other 'define' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool versus alternatives (e.g., etabs_add_to_group) or any prerequisites. This leaves the agent without guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns a JSON array of names, but does not elaborate on any behavioral traits beyond what annotations provide. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded. It could be improved by replacing 'properties' with 'names' for accuracy, but overall it is concise and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and an output schema, the description is mostly complete. It explains the return format. However, adding context about typical usage (e.g., 'Use before assigning sections') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema description coverage is 100%. The description correctly implies no inputs are needed, so it adds sufficient meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'get' and resource 'frame section properties' clearly indicates retrieval. However, it mentions 'properties' but returns only names, causing slight ambiguity. It distinguishes from sibling tools like etabs_define_frame_section and etabs_assign_frame_section which modify or assign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not specify that it should be used to list existing sections before defining or assigning, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds little behavioral insight. It does mention the return is 'Confirmation,' which is useful but minimal. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence plus return line). While concise, it could be better structured (e.g., using bullet points or providing context). It is not wasteful but is barely adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is moderately complete for a simple tool with no parameters. However, it does not explain what constitutes 'pending edits' or how they accumulate from previous operations (e.g., set_table_data). For a complete agent understanding, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description does not need to explain parameters; it simply states the action. Baseline 4 is appropriate given no parameter complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Apply all pending database table edits to the model.' It uses a specific verb ('apply') and a precise resource ('pending database table edits'). This distinguishes it from sibling tools like set_table_data (which sets data but does not apply) and get_table_data (which retrieves data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that edits are pending until this tool is called, nor does it refer to prerequisites like using set_table_data first. An agent would lack context for proper sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only (modifies model) and not destructive. The description adds no further behavioral details, such as whether it creates a new section or updates an existing one, or any side effects like dependency on materials already being defined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear one-sentence purpose, followed by a parameter list grouped logically and shape-specific notes. No redundant or unclear sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite missing usage guidelines and behavioral transparency, the description adequately explains the parameters and shape dependencies. It mentions that material must be previously defined and gives example section names. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter, including shape-specific requirements (e.g., depth/diameter for circular, flange dimensions for I/Tee/Channel). It adds meaning beyond the schema titles, making it easy for agents to determine which parameters are needed for a given shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool defines frame section properties (beams/columns) with specific shapes. It is distinct from siblings like etabs_assign_frame_section (which assigns an already defined section) and etabs_get_frame_sections (retrieves existing sections), but does not explicitly differentiate from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For instance, it does not mention that sections must be defined before assignment, nor does it indicate that defining a section with an existing name might overwrite or error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only says 'Define a new load pattern' without disclosing side effects, required permissions, or error conditions. Annotations (readOnlyHint=false, destructiveHint=false) are not contradicted but offer no additional insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded header followed by structured Args section. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple creation tool given output schema existence and param coverage, but lacks usage context and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args section adds meaningful context: explains name, load type examples, and self-weight multiplier typical values. This compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Define a new load pattern' with examples (Dead, Live, Wind, Quake), distinguishing it from sibling tools like etabs_define_area_section or etabs_define_load_case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites or context for when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not destructive, not idempotent, and not open-world. The description adds minimal behavioral context beyond stating it returns a confirmation. It does not disclose potential side effects like creating a new database entry or validating input, which would be helpful given the lack of annotation detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence for purpose followed by clear parameter definitions and return value. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a definition tool with 3 required parameters and an output schema, the description covers basic semantics but lacks context about preconditions (e.g., model must be open), error conditions (e.g., duplicate name), or the exact structure of the confirmation response. The output schema exists but is not provided, so the agent cannot rely on it for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: name with examples ('#4', '#8'), area as 'cross-sectional area in current units', and diameter similarly. This adds meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Define a rebar size' uses a specific verb and resource, clearly indicating the tool's purpose. It effectively distinguishes from sibling tools like define_area_section or define_frame_section, which define different structural elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other define_* tools. There is no mention of prerequisites, context, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true and readOnlyHint: false. The description adds minimal behavioral context beyond 'run the design check.' It doesn't describe side effects, data modifications, or required permissions, but the annotations cover the core destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two lines. While it could include more detail about the return value, it avoids fluff and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description only says 'Returns: Confirmation.' This is insufficient for a tool that performs a design check; it does not explain what the confirmation contains or where design results are stored. The tool's complexity is low (zero params), but the description lacks important context about post-invocation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters; schema coverage is 100%. With no parameters to document, the description cannot add parameter-level meaning. The baseline of 4 applies as the description does not need to compensate for parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action and resource: 'Run the concrete frame design check.' This is a specific verb-resource pair that clearly distinguishes from sibling tools like 'etabs_run_steel_design' and 'etabs_run_analysis'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites (e.g., prior analysis run) or conditions under which this tool should or should not be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds the 'replace' parameter behavior but does not disclose side effects, error conditions, or the full effect of the operation beyond param details. Little new behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with Args and Returns, which is clear and organized. It is concise, though the dir mapping could be more compact; nonetheless, every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the operation's simplicity and the presence of an output schema, the description covers the essential parameter semantics. It lacks prerequisites or post-conditions but is adequate for a straightforward assignment command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains each parameter: name, load_pattern, value (with units), dir (with value mapping), replace (semantics), and item_type (allowed values). This adds significant meaning beyond the schema's titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Assign') and resource ('uniform surface load to an area object'), clearly distinguishing it from sibling tools like etabs_assign_frame_load and etabs_assign_point_load. The details about parameters reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., frame or point load assignment). It does not mention prerequisites like requiring an existing area object or load pattern, nor does it exclude any use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations provide destructiveHint=true, the description adds no extra behavioral context such as side effects, model modifications, or confirmation details beyond 'Returns: Confirmation.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise; two sentences with no unnecessary information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with annotations and output schema, the description covers the core function. Lacks mention of prerequisites like design code, but completeness is adequate given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description does not need to elaborate on inputs. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Run') and resource ('steel frame design check'), distinguishing it from sibling tools like etabs_run_concrete_design and etabs_run_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or required setup (e.g., design code, prior analysis).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, but the description does not clarify behavioral traits such as whether it overwrites existing grids, requires model initialization, or has side effects. The description adds minimal behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, followed by parameter descriptions and a return value note. It is concise and front-loaded, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and return value adequately. Given the tool's moderate complexity and the presence of an output schema, it is mostly complete, though it could mention behavior on existing grid systems.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains each parameter in the docstring, including default behavior for optional grid IDs. Since the schema has 0% coverage for parameter descriptions, this adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Define or modify a Cartesian grid system,' which clearly identifies the action and resource. It distinguishes from siblings like etabs_get_grid_systems, which reads grid systems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., etabs_get_grid_systems). The description lacks context on prerequisites or scenarios where defining/modifying a grid system is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description describes assignment, which is consistent. However, it does not mention that assigning a new section overwrites the previous one or any other side effects, but annotations already cover the basic safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 8 lines, with a clear structure: purpose, parameter list, return type. No redundant information. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 parameters and an output schema. The description covers the purpose and parameter semantics. The return value is minimal ('Confirmation'), but sufficient for a straightforward assignment operation. No missing critical details for its use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes parameter explanations (e.g., 'name' interpreted based on item_type, 'section_name' as the section to assign) which the input schema lacks. All three parameters are clearly explained beyond schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (assign) and resource (area/shell section property to an area object). It distinguishes from sibling tools like etabs_define_area_section (definition vs. assignment) and etabs_assign_frame_section (frame vs. area), though not explicitly. No misleading information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., etabs_assign_frame_section, etabs_define_area_section). The description only states the function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and not destructive. The description adds that it assigns a constraint to area or point objects, which is mild behavior detail. However, it does not disclose error handling, idempotency behavior, or what happens if the diaphragm name is invalid. It adds some context beyond annotations but not richly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences for purpose, a compact args list, and a returns statement. Every sentence serves a purpose with no fluff. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description is adequate but not thorough. It lacks error scenarios, prerequisites (e.g., the diaphragm must already be defined), and broader workflow context. Returns 'Confirmation' is vague but acceptable for a simple assignment with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries full burden. It explains each parameter: name as 'Object name or group name', diaphragm_name as 'Name of the diaphragm to assign', and item_type with explicit allowed values ('Object', 'Group', 'SelectedObjects'). This adds significant meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear, specific verb-resource combination: 'Assign a diaphragm constraint to an area or point object.' It directly states the action and target, distinguishing it from sibling tools like assign_area_load or assign_frame_section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other assignment tools (e.g., assign_area_load). The description does not mention prerequisites, when it should be avoided, or how it fits into a larger workflow. The context of sibling tools is provided externally but not leveraged by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive, but the description adds no behavioral details beyond basic creation, such as error handling or overwrite behavior. With minimal annotation detail, the description misses an opportunity to clarify side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, making it easy to parse. It is concise without being terse, though it could be slightly shorter by omitting the generic 'Returns: Confirmation.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers parameters well, it lacks details on return behavior and potential errors. The presence of an output schema may mitigate this, but it is not provided for assessment. For a tool with four parameters, the description is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides explicit parameter semantics in a docstring format, explaining combo_type values (0=LinearAdd, etc.) and the relationship between load_names and scale_factors. This adds critical meaning beyond the schema, which has 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Define a new load combination,' using a specific verb and resource. It distinguishes itself from sibling tools like etabs_define_load_case and etabs_define_load_pattern, which deal with individual load cases and patterns, not combinations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like etabs_define_load_case. It only states the action without context of prerequisites or when-not-to-use, which is adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (not read-only) and destructiveHint=false, but the description adds minimal behavior beyond 'Define'. It does not disclose what happens if the material already exists (e.g., error or overwrite), nor any side effects. The return is vaguely 'Confirmation'. With annotations conveying basic traits, the description adds little extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: a brief purpose statement followed by a bullet-style parameter list and a one-line returns note. It is front-loaded and contains no unnecessary words. However, the 'Returns' line is minimal and could be slightly more descriptive, but overall it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema (not shown), the description covers parameter meanings and return type. However, it misses important context like 'the material is added to the current model' or what happens if a duplicate name is used. For a structural engineering domain, additional context about prerequisites (e.g., model must exist) would be helpful. Overall, adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the input schema has 0% description coverage, the description fully carries the burden. It lists all 5 parameters with explanations, examples (e.g., '4000Psi', 'Grade 50'), and enumerates allowed values for material_type (Steel, Concrete, etc.). This adds critical meaning beyond the bare schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Define a new material property' with specific verb and resource. It provides examples for name, material_type, standard, and grade, making the tool's purpose unambiguous. This distinguishes it from sibling define tools like etabs_define_area_section or etabs_define_frame_section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 vs alternatives, e.g., that it should be used before assigning material to sections, or if prerequisites like an open model are required. However, the purpose is clear enough from the name and context, so it's adequate but lacking strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds a return value ('Success confirmation') but does not cover error handling (e.g., what happens if object doesn't exist) or side effects, leaving gaps despite annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: 4 lines including Args and Returns. Front-loaded with purpose, no redundant information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with 2 parameters and output schema, the description covers purpose, parameters, and return. However, it lacks discussion of idempotency, error behavior, or prerequisites, leaving some contextual gaps despite annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by specifying valid values for object_type ('point', 'frame', 'area', or 'link'). For 'name', it adds only minimal clarification. Overall, adds moderate value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and resource 'named object', specifying parameters object_type (with explicit valid values: point, frame, area, link) and name. This distinguishes it from sibling tools like etabs_delete_results or etabs_add_area.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusion criteria. While the purpose is clear, there is no contextual guidance beyond the obvious deletion scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, so the description adds that it returns a confirmation. However, it does not disclose any side effects or behavior beyond idempotency, such as whether the change persists to the model or requires saving. With annotations covering the core safety profile, the description adds minimal extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus structured Args/Returns. No fluff, but it could be slightly more structured (e.g., bullet points for clarity). Still, every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 string params, idempotent, returns confirmation) and the presence of an output schema, the description is sufficiently complete. It explains both parameters and the return value. No gaps for the intended usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by specifying that design_type is 'Steel' or 'Concrete' and provides example code names like 'AISC 360-16' and 'ACI 318-19'. This adds essential meaning beyond the schema's plain string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the design code for steel or concrete design' with a specific verb and resource. It distinguishes from sibling tools like 'etabs_run_concrete_design' and 'etabs_run_steel_design' which are for running designs, not setting the code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., model must be open) or when not to use it. It lacks context about the typical workflow, such as that this tool should be called before running design.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool can add or remove controlled by the 'remove' flag, and annotations indicate idempotency. However, it does not explain effects like whether adding a non-existent object creates it, or what happens if the group doesn't exist. Given annotations cover idempotency, the description adds some but not deep behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a bullet-style parameter list. Each line earns its place, no fluff. The structure is front-loaded with the core action, then parameter details, then return type. Ideal length and organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the existence of an output schema (confirmation), the description covers what an agent needs to use it correctly. It explains the main operation, parameters, and returns. No major gaps for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries full burden. It provides clear, meaningful explanations for all four parameters: 'name' (object name), 'group_name' (group name), 'object_type' (allowed values listed), and 'remove' (controls add vs remove). This adds significant value beyond the schema's type/constraint info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add or remove an object from a group.' It specifies the primary action (add/remove) and the resource (object/group), and distinguishes itself from siblings like etabs_define_group (which creates groups) and etabs_add_area (which adds areas, not to a group).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites (e.g., group must exist) or when not to use it (e.g., if the object is already in the group). No guidance on choosing between add and remove contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds that the tool returns a JSON array, which is useful but does not elaborate on behavioral traits like data freshness or error conditions. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no redundant information. Every word contributes to understanding the tool's purpose and output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with an existing output schema, the description is sufficiently complete. It clearly states what is returned. However, it could mention the requirement for an analyzed model, but given the context of sibling tools, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. The description adds valuable context by specifying the output 'per load case', which goes beyond the schema. Baseline for 0 params is 4, and this is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves global base reactions per load case, distinguishing it from sibling tools like etabs_get_joint_reactions and etabs_get_story_forces. The verb 'Get' and resource 'base reactions' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other reaction or results retrieval tools. The description does not mention prerequisites (e.g., model must be analyzed) or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, idempotent, and non-destructive. The description adds no behavioral details beyond the return format. It does not contradict annotations. With annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose, a clean Args list with defaults, and a Returns line. No wasted words. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, arguments, and return type. However, it omits prerequisites (e.g., analysis must be run) and error conditions. For a read-only retrieval tool with output schema, this is mostly complete but could add a note about when results are available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description is the sole source for parameter meaning. The docstring explains all three parameters: design_type ('Steel' or 'Concrete'), name (empty for all), and item_type (enum-like values). This provides sufficient semantics beyond the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a summary of design results') and the resource ('for frames'). The verb 'get' and the resource 'design results summary' are specific and distinguishable from sibling tools that deal with raw forces or displacements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like etabs_get_frame_forces or etabs_get_table_data. It does not mention context prerequisites (e.g., design must have been run) 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description confirms it creates a point and returns a JSON with the name, but doesn't elaborate on side effects or error conditions. It adds some context but not substantial beyond defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a clear intro sentence followed by a bullet-like list of parameters. Each sentence is informative, though a bit more structure (e.g., separating args from returns) could improve readability. Still, it's well-organized for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool adds a simple point object, the description covers inputs and output adequately. It notes return value (JSON with name). Completeness is good for the complexity level, though it could mention units precision or coordinate system details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains coordinates are in current units, name is optional (defaulting if blank), and csys defaults to 'Global'. This provides useful meaning beyond the schema's property titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Add' with a specific resource 'point (joint) object at specified coordinates'. It clearly distinguishes from sibling tools like etabs_add_area and etabs_add_frame, which add different object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the purpose is self-evident for adding a point. There are no exclusions or context provided, so it meets a minimally acceptable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the behavioral profile is clear. The description adds context about the table_key being an internal key from get_available_tables, which is useful but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: 4 sentences plus structured Args/Returns. It front-loads the purpose in the first sentence and avoids unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema, the description does not need to detail return values. It mentions 'JSON object containing table fields and row data,' which is sufficient. The tool is part of a set of data retrieval tools, and the description is complete for its function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: for table_key, it explains it is 'the internal key of the table (from get_available_tables)' and for group_name, it clarifies 'Optional group name to filter results (default '' means all).' Since schema description coverage is 0%, this compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get the contents of a specific database table,' clearly indicating the verb and resource. It mentions the table_key parameter is from get_available_tables, distinguishing it from sibling tools like etabs_get_available_tables. However, it could be more specific about what 'contents' includes; the return description clarifies it returns fields and row data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the table_key comes from get_available_tables, suggesting a prerequisite step. It does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among sibling getter tools like etabs_get_all_frames or etabs_get_base_reactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare `idempotentHint: true` and `destructiveHint: false`, so the description does not need to restate these. However, it adds no further behavioral context (e.g., whether the section must be predefined, or that assignment overwrites previous assignments). With annotations present, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and structured as a docstring with Args and Returns. Every sentence is necessary, and no extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the basics well. It explains parameters and indicates a return confirmation. Minor gaps include missing prerequisites (e.g., section must be defined) or error scenarios, but overall it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for parameters (0% coverage). The description fully explains each parameter: `name` can be object or group name, `section_name` is the section to assign, and `item_type` specifies the scope. This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assign') and the resource ('frame section property to a frame object'). The tool name reinforces this, and it is easily distinguishable from sibling tools like `etabs_define_frame_section` which defines a section rather than assigning it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 (e.g., `etabs_assign_area_section` or `etabs_define_frame_section`). While the name and context make the purpose clear, no guidance is provided on selection conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is mutable but not destructive (destructiveHint=false) and idempotent (idempotentHint=true). The description adds the 'replace' parameter behavior—whether to replace or add loads—which is valuable. However, it does not mention potential side effects, error conditions, or prerequisites, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using an Args/Returns format. Every sentence adds value, and the purpose is front-loaded. There is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, 2 required, no output schema details beyond 'Confirmation', and annotations covering safety, the description is fairly complete. It explains all parameters and the replace behavior. However, it lacks details on error handling, units, and prerequisites (e.g., joint existence). The output is vaguely described as 'Confirmation', which may suffice but could be more specific.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description entirely carries the burden of explaining the 10 parameters. It clearly defines each parameter's purpose: name (point object), load_pattern, f1/f2/f3 (forces in directions), m1/m2/m3 (moments about axes), replace (replace vs add), and item_type (scope). This adds necessary meaning beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Assign point loads/moments to a joint object,' which is a specific verb and resource. This clearly distinguishes it from sibling tools like etabs_assign_frame_load or etabs_assign_area_load, which assign loads to 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.
Usage Guidelines3/5
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 vs alternatives. While the purpose is clear from the name and first sentence, no guidance is provided on when not to use it or what prerequisites are needed (e.g., existing joint or load pattern).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining that deleting results 'unlocks the model,' which is important behavioral context. Annotations already indicate destructive and idempotent hints; the description complements these without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. The first sentence conveys the action and effect, and the second indicates the return value. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, clear annotations, and an output schema (which describes returns), the description is fully complete. It covers the core behavior and outcome without missing necessary details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description implies no parameters are needed, which is consistent with the empty schema. No additional parameter-specific information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete all analysis results') and the effect ('unlocking the model'), making the purpose unambiguous. It distinguishes from sibling tools like etabs_delete_object by specifying 'analysis results' instead of objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. For example, it does not mention that this should be used after analysis is complete or before modifying the model, nor does it compare with etabs_run_analysis or etabs_setup_results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it returns connectivity and section info but doesn't disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Clearly states purpose and return format, front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and a simple retrieval task, the description fully covers the tool's functionality. Output schema exists, so return format description is a bonus.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description cannot add parameter meaning. Schema coverage is 100%, and the description hints at return fields which is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves all frame objects in the model with connectivity and section info. The verb 'Get' and resource 'all frames' are specific and distinct from siblings like etabs_get_all_areas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. alternatives. For a simple retrieval tool, usage is implied but no disclaimers or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds return format (JSON array of names) but does not disclose additional behavioral traits beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states function, second states return format. Fully front-loaded, no unnecessary text. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (no params, safe read operation). Description tells what it does and what it returns. Output schema exists, so return structure is further detailed. Complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined; schema coverage is 100% (empty object). Baseline for 0 parameters is 4. Description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly says 'Get all grid system names defined in the model.' Verb+resource are clear: 'get' and 'grid systems.' Distinguishes from sibling tools like 'etabs_set_grid_system' which modifies, and other get tools are for different objects (areas, frames, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives or when not to use it. However, given its simplicity and specificity, usage is implied. The description lacks context like prerequisites or when it might be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds the return format (JSON array of names and types), which provides some behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words, front-loaded with the core purpose. Returns are specified efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (no parameters, clear annotations, documented return format), the description is fully sufficient for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description does not need to add parameter information; it is complete as is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'list of currently selected objects', which distinguishes it from sibling tools like etabs_get_all_* that retrieve all objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after objects have been selected (e.g., via etabs_select_objects), but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true and idempotentHint=true, but the description only mentions returning success confirmation. It does not add context about potential side effects like closing the current model or overwriting state, which is expected given the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two sentences plus a brief returns line. Every sentence serves a purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, output schema, and annotations, the description covers core functionality but omits important details like side effects on the current model (e.g., whether it closes unsaved work), which is relevant given destructiveHint=true.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by providing a clear explanation and example for the file_path parameter: 'Full path to the .edb model file (e.g. "C:/Models/Building.edb")'. This adds meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Open' and the resource 'existing ETABS model (.edb) file'. Among sibling tools like etabs_new_model and etabs_close_model, it distinguishes itself by specifying the action on an existing file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for opening existing .edb files, contrasting with siblings like 'new_model' for creation. However, it lacks explicit guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, but the description does not clarify whether the tool modifies the model state or only computes values. The name suggests 'set', but the description says 'compute and report', creating ambiguity. The description adds formula context but lacks explicit behavior disclosure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the main purpose and then providing detailed parameter information. It is slightly verbose due to formula repetitions, but each sentence adds necessary value for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (10 parameters, no schema descriptions, output schema exists), the description is comprehensive: it covers the calculation methodology, parameter meanings, defaults, and return format (JSON with specific fields). It also references related tools and code clauses, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% schema description coverage, but the description provides detailed explanations for all 10 parameters, including defaults, accepted values, formulas, and references (e.g., IS 1893 tables). This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes and reports IS 1893:2016 seismic scale factors for RSA cases. It specifies the verb (compute and report) and the resource (seismic scale factors), which sets it apart from sibling tools like etabs_check_is1893_drift or etabs_define_response_spectrum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used before defining a response spectrum with etabs_define_response_spectrum, but it does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. The connection is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, but readOnlyHint=false, confirming the tool modifies state. The description adds no extra behavioral details beyond the fact that it sets units. It does not mention side effects, permissions, or that it only affects display units, which would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, a clear Args section with enumerated values, and a Returns line. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, output schema present), the description is complete enough for an AI agent to use correctly. It covers parameter values and return type. Minor omission: it could clarify that units are display-only, not internal model units.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the 'units' parameter, but the description compensates by listing all 16 possible values with a clear format. This provides meaning well beyond the bare schema, making parameter selection unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set the active display units') and the target ('ETABS model'). Among many sibling tools starting with 'etabs_set_', this one uniquely addresses unit setting, distinguishing it from others like set_design_code or set_stories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need to change display units) but does not provide explicit guidance on when not to use it or suggest alternative tools. Given its simplicity, the usage context is clear but lacks formal guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) are neutral. The description details the operation (adds frame object) and parameters, but omits potential side effects like duplicate names or invalid coordinates. Still, it adequately conveys the mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph plus clear bulleted list for Args and Returns. Efficient and well-structured, though slightly verbose due to full parameter listings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 9 parameters and return value. Missing prerequisite information (e.g., model must be open), but given sibling tools for model management, context is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Every parameter is described in the Args list with meaningful explanations (coordinates, property name default, optional name, coordinate system). This adds significant value beyond the schema, which has 0% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Add a frame object (beam, column, brace) between two points by coordinates.' It specifies the verb, resource, and types, distinguishing it from siblings like etabs_add_area and etabs_add_point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., etabs_assign_frame_section, etabs_define_frame_section). The description assumes domain knowledge and does not provide when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the effect of setting releases, describes the boolean array meaning, and notes that a confirmation is returned. Annotations indicate idempotent and non-destructive behavior; the description aligns with these. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro, bullet-like explanation of release lists, common patterns, and an Args section. It is clear and informative, though the explanation of the 6-element list could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of releases and the presence of an output schema, the description covers parameter meanings, common usage, and return. It lacks prerequisites (e.g., frame must exist) but is otherwise complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains each parameter in the Args section, including the release list format and common patterns. This adds significant meaning beyond the schema, which only has names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set end releases (moment releases / pins) for a frame object.' It uses specific verbs and distinguishes from siblings like etabs_assign_frame_section or etabs_assign_frame_load.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides common patterns and explains the release list format, which implies usage context but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a write operation ('define') and provides basic behavior. Annotations show readOnlyHint=false, so no contradiction. However, it lacks details on idempotency or whether duplicate names overwrite existing definitions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with four sentences covering purpose, arguments, and return value. It uses a clear Args/Returns structure without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (indicated as present), the description is complete: it explains the purpose, all parameters, and the return confirmation. Enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all five parameters clearly, including examples, allowed values, and the mapping for shell_type (1-6). This adds significant meaning beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool defines area/shell section properties for slabs, walls, decks, using a specific verb and resource, and distinguishes from sibling tools like etabs_add_area and etabs_assign_area_section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the material must be previously defined, providing a usage prerequisite. However, it does not explicitly guide when to use this tool versus alternatives, such as when to define a section vs assign it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false, which are consistent with the description. The description adds context about modal analysis and code requirements but does not disclose any additional behavioral traits beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured: a concise purpose line, followed by a code reference, recommendations, and an 'Args' section. While slightly verbose (especially the code reference), it remains focused and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (JSON confirmation) and the tool's definition nature, the description is fairly complete. It covers the purpose, parameter semantics, usage context (IS code), and necessary recommendations. Minor gaps exist (e.g., no mention of default behavior when case_name is omitted), but overall it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears full responsibility for parameter semantics. It explains each parameter (case_name, modal_type, max_modes, min_modes, shift_value) with context (e.g., Ritz is faster for RSA, recommended max_modes based on storeys), adding significant meaning beyond the schema defaults and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Define a modal analysis load case (Eigenvector or Ritz).' It uses a specific verb (define) and resource (modal analysis load case), and distinguishes from sibling tools like etabs_define_load_case and etabs_define_response_spectrum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance by referencing IS 1893:2016 and recommending parameter values (e.g., max_modes = 3 × number of storeys, minimum 12) and modal type (Ritz is faster for RSA). It lacks explicit when-not-to-use instructions but offers clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, which are consistent with the description. The description adds behavioral details about preset values, override logic, and return structure. It does not contradict annotations. Additional context about performance or side effects is not necessary for this idempotent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, bullet points for target selection, a table for presets, and a detailed Args list. It is appropriately verbose for a tool with 9 parameters but could be slightly more concise by avoiding redundancy (e.g., repeating default values in both preset table and Args list).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 0 required, with presets and overrides), the description is thorough. It covers all aspects: target selection, preset definitions, parameter interactions, and return type. The existence of an output schema reduces the need to document return values in detail, but the description still mentions the structure. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the tool's 'Args' section in the description provides comprehensive explanations for all 9 parameters, including default values, override behavior, and preset options. This fully compensates for the lack of schema descriptions, making parameter semantics exceptionally clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies cracked-section stiffness modifiers to frame objects. It specifies the verb 'Apply' and resource 'frame objects'. However, it does not explicitly distinguish itself from the sibling tool 'etabs_apply_aci_stiffness_modifiers', which likely focuses only on presets. The description implies differentiation by offering both presets and overrides, but a direct comparison is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on how to select targets via names, group, or all frames, and explains when to use presets versus individual overrides. It does not, however, explicitly state when to avoid using this tool or mention alternative tools for similar tasks, such as 'etabs_apply_aci_stiffness_modifiers'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. Description adds value by disclosing the key behavioral trait 'without exiting the application' and the save_first option. No contradictions or omissions noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences for description plus brief Args/Returns. No redundant words; every sentence adds value. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, clear return type), the description covers all necessary context: what it does, the optional save behavior, and that it returns success confirmation. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description clearly explains the save_first parameter: 'If True, save the model before closing.' Parameter name and description align, providing sufficient semantic meaning for agent use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Close the current ETABS model without exiting the application', specifying verb, resource, and key constraint. Distinguishes from sibling tools like etabs_save_model (only save), etabs_open_model, etabs_new_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this tool versus alternatives (e.g., save model separately then close). The mention of 'without exiting the application' implies a context but lacks direct comparisons or exclusions. However, the save_first parameter gives some usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, non-destructive, and idempotent. The description expands on this by detailing the return format (JSON array with name, points, section), adding value beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a bullet list. It front-loads the purpose and return structure without any extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 the return structure is described in the description, the description is complete. The presence of an output schema (as per context signals) further supports that the agent can understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema is fully covered. The description adds no further parameter info, but this is acceptable given no parameters exist. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all area objects with connectivity and section details. The verb 'Get' and resource 'area objects' are specific, and the sibling tools like etabs_get_all_frames and etabs_get_all_points are distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. However, the name and description imply it is the default for listing all areas, but no exclusion criteria or comparative advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the exact output structure (JSON array of load cases and status) and example values, providing transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one stating the purpose and one describing the return value. Every sentence earns its place with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, existing output schema), the description is complete. It explains what the tool does and what it returns, which is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description does not need to explain parameters. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the status of all analysis cases, specifying the return format as a JSON array with load cases and their status (e.g., 'Finished', 'Not Run'). This distinguishes it from sibling tools that perform other operations like defining or running analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for checking analysis status but does not explicitly state when to use it versus alternatives like etabs_get_status, nor does it provide exclusions or prerequisites. The context implies it is used after running analysis, but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the description adds valuable context by specifying the return format (JSON array of names). This goes beyond the annotations to clarify output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, no filler, and front-loads the purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, comprehensive annotations, and the existence of an output schema, the description fully covers what the agent needs to know: the tool lists area section properties and returns their names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description doesn't need to add parameter semantics. With schema coverage at 100% (trivially), the description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of all defined area/shell section properties and specifies the return format as a JSON array of names. It distinguishes from sibling tools like etabs_define_area_section (which defines) and etabs_get_frame_sections (which retrieves frame sections).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, but the context of sibling tools implies its use for querying area sections. No when-not-to-use or trade-off information is given, making it adequate but not exceptional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds the output format ('JSON array of load pattern names'), which is useful behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundant words. Every sentence adds value: the first states purpose, the second states output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema present. The description sufficiently explains the purpose and return value. Annotations cover safety and idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description does not need to add parameter info; schema coverage is 100% by default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('load patterns'), clearly indicating retrieval of data. It is distinct from sibling tools that involve adding, defining, or assigning, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when load pattern names are needed, but lacks explicit guidance on when to use this tool versus other get tools (e.g., etabs_get_materials). For a simple retrieval, it is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds return format details (JSON array with specific fields), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second lists return fields. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with no parameters; description covers purpose and return format. Output schema exists but not needed. Complete for a get-all tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no parameters; description compensates by listing return fields. Baseline 4 for zero parameters, and description adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves all story definitions, using specific verb and resource. It distinguishes from siblings like etabs_get_story_drifts and etabs_get_story_forces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates usage (to get story definitions) but lacks explicit guidance on when not to use or alternatives. Sibling tools exist but no exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds behavioral context by detailing the code-check logic and the return format, which goes beyond the annotations. No contradictions or missing critical behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, followed by code references, then parameter documentation, and finally return description. While slightly verbose due to code quote blocks, every part is relevant and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 3 optional parameters and an output schema exists. The description covers the return format as a JSON array of storeys with drift ratios and code-check results. Combined with annotations that cover safety, the description is complete for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 carries the full burden. It explains each parameter in detail: case_or_combo defaults to all selected cases, direction accepts X/Y/Both, and check_is1893 triggers code limit flagging. It also provides the code references for the limits, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves inter-storey drift ratios and checks against IS 1893:2016 and ASCE 7-22 limits. The verb 'get' and specific resource 'inter-storey drift ratios' combined with the code-checking capability distinguishes it from sibling tools like etabs_check_is1893_drift.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 explicitly tell when to use it versus alternatives. For example, it doesn't mention that this tool retrieves data and performs checks, while etabs_check_is1893_drift may only perform the check. No prerequisites or contextual cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, indicating potential to overwrite. The description adds the template option but does not disclose that creating a new model may close an existing unsaved model, nor does it mention required permissions. Additional context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and presents parameters in a clear, structured list. Every sentence is necessary and efficiently conveys information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and zero schema descriptions, the description covers all parameter semantics. It mentions return value. However, it could mention that creating a new model closes the current one, which is implied by destructiveHint. Overall, it is sufficiently complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 fully explains all 9 parameters, including units with enumerated values, template types, story heights, and bay dimensions. This adds significant meaning beyond the schema's property names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new ETABS model, optionally from a template.' The verb 'Create' and resource 'new ETABS model' are specific and distinct from sibling tools like etabs_open_model and etabs_save_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates creation of new models, but does not explicitly exclude alternatives or state when to use versus etabs_open_model. The mention of 'optionally from a template' provides some context, but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations by detailing clear_previous behavior and returning confirmation. Annotations indicate idempotent and non-destructive. The description aligns with annotations and provides useful behavioral context (affects UI selection, clears prior selection optionally).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for purpose, then clear Args list. No redundant words. Effectively communicates everything needed in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a selection tool: explains what it does, parameters, return value. Doesn't mention error handling for non-existent objects, but that's acceptable. Annotations and output schema fill minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description's 'Args' section fully explains each parameter: name, object_type with allowed values, clear_previous with effect. This compensates fully, adding meaning beyond the schema which only provides names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Select objects by name in the ETABS UI', specifying the verb 'select', the resource 'objects', and the context (ETABS UI). Distinguishes from siblings like etabs_get_selected (retrieves selection) and etabs_delete_object (deletes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description is straightforward but lacks 'when-to-use' or 'when-not-to-use' advice. The clear purpose somewhat compensates, but no exclusion criteria or references to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true). It adds context about the parameters but does not disclose additional behavioral traits beyond what annotations imply. The idempotency is not explicitly mentioned, but the description implies it by stating the action is setting degrees of freedom.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sentences and a bullet-like list. It is front-loaded with the core purpose and efficiently adds parameter details without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters (none required), the description covers all parameters and provides usage examples. The return value is noted as 'Confirmation'. While error handling or side effects are not mentioned, the tool's simplicity and the presence of an output schema make this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains each parameter thoroughly: u1, u2, u3 as translations and r1, r2, r3 as rotations, with axis references. It also provides default values and usage examples, adding significant meaning beyond the schema's type/title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('active degrees of freedom for the analysis'), with examples like '3D, 2D X-Z'. This effectively differentiates it from sibling tools like 'etabs_set_design_code' or 'etabs_set_units'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific usage examples (3D space, 2D X-Z plane) and explains the parameter values for each scenario. However, it does not explicitly describe when not to use this tool or contrast it with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint: true, and the description confirms it is a write operation ('Define'). It adds constraints like same length for story_heights but does not explicitly warn about overwriting existing stories or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with clear Args and Returns sections. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameter details, and return value. It lacks explicit mention of units or potential errors, but given the tool's simplicity and the presence of an output schema, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully defines each parameter: story_names as list from bottom to top, story_heights as same length, bottom_elevation with default. This adds crucial value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Define the building stories' and explains the ordering from bottom to top. This distinguishes it from sibling tools like etabs_get_stories which retrieves stories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates that stories are defined from bottom to top, implying when to use this tool. However, it does not explicitly state when not to use it or mention alternatives, though the context of siblings provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds that the tool modifies stiffness modifiers and returns a JSON with applied values, which aligns with annotations. No contradictions; transparency is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-structured: intro, target selection, presets, parameter definitions, and return value. It is front-loaded with the main action, and every sentence adds value, though minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no schema descriptions), the description covers target selection, presets, parameter semantics, and return format. It lacks mention of error handling or prerequisites (e.g., model must be open), but is largely complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides detailed explanations for all 11 parameters, including the meaning of membrane, bending, and shear modifiers, and a full list of presets. This adds critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply') and resource ('area objects (walls, slabs, decks)'), clearly distinguishing it from sibling tools like etabs_assign_frame_stiffness_modifiers. It also states the exact purpose: applying cracked-section stiffness modifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states how to select targets (names, group, or all areas), which provides clear context. However, it does not mention when NOT to use this tool versus the sibling etabs_apply_aci_stiffness_modifiers, which might cause confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are neutral (not read-only, not destructive, not idempotent). The description adds that it defines a new load case, but does not disclose behavior if the name already exists (overwrite/error), prerequisites, or side effects on the model. Adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a structured Args/Returns format. It front-loads the purpose and uses bullet-like lists. Every sentence adds value, though the docstring style is slightly longer than necessary. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (3 params, 1 required, output schema returns confirmation), the description covers the main points: purpose, parameters, and return value. It could mention that the load case is added to the model and what happens on conflict, but overall it is complete enough for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully carries the burden. It explains name (just name), case_type with a detailed list of options including descriptions, and modal_case with its condition and default. This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Define a new load case' and lists the case_type options, distinguishing it from sibling tools like etabs_define_modal_case and etabs_define_response_spectrum by explicitly recommending them for full control. It specifies the verb 'Define' and resource 'load case'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives: for Modal cases it directs to etabs_define_modal_case, and for ResponseSpectrum cases to etabs_define_response_spectrum. It also clarifies that modal_case is only for ResponseSpectrum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description need not repeat safety. It adds value by stating the return format (JSON array) and the prerequisite for analysis completion, which is beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no extraneous text. It front-loads the core action, then lists arguments and return value in a structured format. Every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an explicit output schema (not shown but present), the description sufficiently covers usage. It notes prerequisites and parameter options. Minor missing context (e.g., units) is likely addressed in the schema, so overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 clarifies 'name' as a frame or group, and specifies that 'item_type' can be 'Object', 'Group', or 'SelectedObjects' with a default, adding meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves frame internal forces and lists the specific components (P, V2, V3, T, M2, M3). This distinguishes it from sibling tools like etabs_get_joint_displacements or etabs_get_base_reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a critical prerequisite: 'Ensure analysis has been run and results are set up.' While it does not explicitly contrast with alternatives, the prerequisite guidance is valuable. No misleading or missing usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the prerequisite about analysis but doesn't disclose additional behavioral traits beyond what annotations provide. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear first sentence stating purpose, followed by a prerequisite note and an organized Args block. Every sentence adds value, and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers all input parameters, prerequisites, and is complete for the tool's usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. It explains 'name: Name of the point or group' and 'item_type: "Object", "Group", or "SelectedObjects".' This adds meaning beyond the schema's type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get joint reactions (support forces) for a specified point or group.' This is a specific verb and resource, clearly distinguishing it from sibling tools like 'get_joint_displacements' or 'get_frame_forces'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Ensure analysis has been run and results are set up.' This guides when to use the tool. However, it does not explicitly compare to alternatives or mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readonly, non-destructive, etc. The description adds that editing is interactive and requires a follow-up, which provides behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a one-sentence overview, a crucial note, and a clear Args section. No unnecessary words; front-loads the key message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters, no nested objects, and a simple return (confirmation), the description covers the purpose, parameters, and follow-up action sufficiently. Slightly more detail on return value could be added, but it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description's Args section explains each parameter: 'internal key', 'column names', 'list of rows...', adding meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set data in a specific database table') and specifies it's for interactive editing, distinguishing it from related tools like etabs_get_table_data and etabs_apply_table_edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes the prerequisite call to etabs_apply_table_edits for changes to take effect, helping the agent understand the workflow. While it hints at interactive use, it does not explicitly state when to use vs. alternatives, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false, and the description aligns by explaining load assignment and replacement behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary followed by parameter details. It is slightly lengthy but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 10 parameters and absence of nested objects, the description explains all parameters and mentions the return type ('Confirmation'). The output schema exists, so completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds essential meaning for all 10 parameters, including direction codes, distance semantics, and boolean flags, fully compensating 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assigns a uniform or trapezoidal distributed load to a frame object. It distinguishes from sibling tools like etabs_assign_area_load and etabs_assign_point_load by specifying 'frame object'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to set uniform vs trapezoidal loads (w1=w2 for uniform) but does not explicitly state when to use this tool over alternatives. However, the tool name and specificity make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it explains the raw return tuple, the need to provide COM ref/out parameters as dummy values, and that methods are accessed via SapModel paths. Annotations indicate readOnlyHint=false, destructiveHint=false, but the tool can call destructive methods, creating a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with purpose, then examples, then parameter details. Every sentence adds value, and it is appropriately concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return format (JSON of raw tuple) and usage patterns. It could mention potential error handling or that some methods may fail, but given the tool's generic nature, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining each parameter: interface_path (dot-separated, empty for SapModel), method_name, and arguments (list required even for ref/out). This provides essential meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an escape hatch for calling any ETABS API method not covered by other tools, effectively distinguishing it from sibling tools. The examples reinforce its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use when a method isn't covered by other tools, and provides examples and parameter explanations. However, it does not explicitly state when not to use it, though the implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds transparency about the return format (JSON array with name and coordinates), which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise—one sentence stating the purpose plus a clear description of the return format. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema (implied by 'Has output schema: true'), the description fully explains the tool's behavior and return value. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description correctly avoids adding parameter info, and a score of 4 is baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a list of all point/joint objects in the model', identifying the specific resource (points/joints) and action (get list). This distinguishes it from siblings like etabs_get_all_areas and etabs_get_all_frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when all points are needed, with no filtering. While it doesn't explicitly state when not to use it or mention alternatives, the tool's purpose is straightforward given its zero parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by specifying the return format (JSON array of material names and types). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the purpose, the second describes the return value. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no complex behavior), the description fully covers what the tool does and returns, complementing the annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, there is nothing to document. The description correctly does not add param info, and the schema coverage is 100% (vacuously). Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get) and resource (list of all defined materials in the model). It is distinct from sibling tools like etabs_define_material which add materials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving material definitions but does not provide explicit guidance on when to use vs. alternatives. However, the name and sibling context make it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds specifics about returned fields (periods, frequencies, mass participation ratios) and code requirements, providing additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, a code reference, and explicit Args/Returns sections. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter input and presence of output schema, the description fully covers purpose, usage context, and return format. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 parameter with default but no description. The tool description explains the 'modal_case' parameter, its purpose, and default value, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get modal analysis results: periods, frequencies, and mass participation ratios.' It uses a specific verb and resource, distinguishing it from sibling tools like etabs_get_base_reactions or etabs_get_joint_displacements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It cites IS 1893:2016 Cl. 7.7.5a and advises to verify cumulative UX and UY against a 90% criterion, providing explicit guidance on when to use the tool. It does not mention alternatives but context and distinctive purpose suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds the return format and usage ordering, but behavioral traits are well-covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences: purpose, return details, and usage advice. Every sentence is valuable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and annotations covering safety, the description fully explains the tool's purpose, return structure, and recommended usage, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description does not need to add parameter information, meeting the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves ETABS connection status, model filename, and lock state, using specific verbs and resources. It distinguishes itself by recommending use before other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'Use this tool first to verify ETABS is running before calling other tools,' providing clear context for when to employ it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. Description adds the important behavioral requirement that the model must be saved, which is critical for safe invocation. Also notes the return is a confirmation, implying the tool does not return results directly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two impactful sentences plus a return note. Front-loaded with the core action, followed by a critical condition, and ends with a clear outcome. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with output schema and annotations, the description is fully complete. It states the action, prerequisites, and outcome. No gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is trivially 100%. The description does not need to add parameter info, and it correctly indicates no arguments are required via the note and context. This is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Run the structural analysis for all active load cases.' Verb is 'run' on 'structural analysis', distinguishing it from siblings like etabs_run_concrete_design and etabs_run_steel_design. Specifics scope to 'all active load cases'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes prerequisite: 'The model must be saved (have a file path) before running analysis.' Provides clear context for when to use. Does not mention alternatives or when not to use, but the single condition is sufficient for a straightforward tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it returns a JSON with the assigned area name and requires ordered points. Annotations are minimal, so the description carries the burden well, though it doesn't mention potential side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a one-line summary, followed by bullet-point usage guidelines, then a labeled Args section. No redundancy or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (6 parameters, 3 required) and the presence of an output schema, the description covers purpose, parameter semantics, usage constraints, and return value. It is sufficient for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all 6 parameters in an Args block, including defaults for optional ones (prop_name='Default', name='', csys='Global'). Since the input schema has no parameter descriptions (0% coverage), the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add an area object (slab, wall, deck) defined by corner coordinates.' It specifies the verb (add), resource (area object), and scope (types: slab, wall, deck), distinguishing it from sibling tools like etabs_add_frame and etabs_add_point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage instructions: coordinates must be ordered clockwise/counter-clockwise, at least 3 points, and property name default. However, it lacks explicit comparison to alternative tools for adding frames or points, leaving the agent to infer when to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, destructive, idempotent, and openWorld hints. Description adds context about the compliance calculation and the format of the output (tabulated PASS/FAIL report). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: five sentences front-loaded with the main purpose, followed by brief parameter explanations and return description. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully handles the tool's scope: specifies code clause, required inputs, optional parameter, and output format. Given the output schema exists, no further details needed. Complete for a read-only analysis check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description thoroughly explains all three parameters, including the optional story_heights_m dict and its purpose (absolute drift in mm vs ratio only), adding valuable meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs IS 1893:2016 Cl. 7.11.1 inter-storey drift compliance check, listing the specific code clause and PASS/FAIL classification. Distinct from siblings like etabs_get_story_drifts which likely only retrieve drifts without compliance assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly defines the purpose: compliance check per a specific code clause. Does not explicitly state when not to use or mention alternative tools, but the purpose is singular and clear, making misuse unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. The description adds behavioral context by specifying a prerequisite and that it returns a JSON array of displacements per load case/combo. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three main sentences plus args/returns) and front-loaded with the core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with annotations and an output schema, the description covers purpose, prerequisite, parameter semantics, and return format. It is complete given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters with examples: 'name: Name of the point or group' and 'item_type: "Object", "Group", or "SelectedObjects".' This adds enum-like values not present in the schema (which lacks descriptions), fully compensating for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves joint displacements for a specified point or group. It distinguishes from sibling tools like etabs_get_joint_reactions (different resource) and etabs_get_story_drifts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite: 'Ensure analysis has been run and results are set up.' This gives clear when-to-use guidance but doesn't 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by detailing the return structure (JSON array with specific fields like P, VX, VY, MX, MY, MZ) and the parameter behavior ('Empty = use currently selected'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose in first sentence, usage context, parameter explanation, and return format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema not shown but return fields enumerated, the description fully covers the tool's behavior for its simple parameter set. Adds standard reference for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description fully explains the single parameter: 'case_or_combo: Load case or combo name. Empty = use currently selected.' This provides essential context beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get storey forces' and lists specific quantities (shear, overturning moment, axial). It distinguishes from sibling tools like etabs_get_base_reactions and etabs_get_story_drifts by focusing on story-level forces for seismic verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly ties usage to IS 1893:2016 Cl. 7.6.3 verification, providing a clear context. While it doesn't list alternatives, the specific standard reference gives strong guidance for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive nature. Description adds the file path behavior and return value, providing additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence description plus Args/Returns. Every sentence is necessary and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one optional parameter) and presence of output schema, the description fully explains the tool's operation, parameter, and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the file_path parameter with an example and the behavior when left empty, adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Save' and the resource 'the current ETAMS model', distinguishing it from siblings like open, new, close, run analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for saving a model, including an optional file path and default behavior of saving to current file. Does not explicitly mention alternatives but is sufficient for a straightforward operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and no destructive side effects. Description adds that it's a setup prerequisite and returns confirmation, consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences plus arg list, front-loaded with purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input parameters, return value, and prerequisite. Lacks detail on multi-call behavior but adequate for a simple setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description adds clear semantics: 'List of load cases to select' and 'List of load combos to select'. Could include format details but sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it configures load cases/combos for result extraction. Differentiates from sibling tools that actually extract results (e.g., get_joint_displacements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'MUST be called before getting displacements, forces, or reactions if you want to filter the results', providing clear usage context and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) are fully consistent with description. Description adds that it returns a JSON array of table names, providing extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the purpose, second describes return format and usage. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, annotations cover safety, and an output schema exists (from context signals), the description fully covers what the agent needs: purpose, output, and suggested follow-up tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description does not need to add parameter details, earning a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Get a list'), the resource ('all available database tables'), and the context ('in the ETABS model'). It distinguishes from sibling tool 'get_table_data' by noting that the returned names are used in that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Use these names in get_table_data,' which guides the agent on the next step. However, it does not explicitly state when not to use or provide alternative tools, but given the tool's simplicity, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No contradictions with annotations; adds context about being a one-shot convenience and requiring either names or groups. Idempotent hint is supported by 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, examples, and clear parameter breakdown; informative yet concise with no unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: parameter modes (names vs. groups), defaults, outputs (JSON summary), and references to other tools for presets. Output schema exists but description sufficiently describes return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description thoroughly explains all parameters, their roles, defaults, and provides examples, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies ACI 318 stiffness modifiers to beams, columns, walls, and slabs in a single call, distinguishing it from lower-level sibling tools like etabs_assign_frame_stiffness_modifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit examples for using names vs. groups, explains that categories with neither are skipped, and directs users to other tools for full preset lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true (safe to call multiple times) and non-destructive. The description adds substantial behavioral context: scale factor formulas (Z·I·g/2R), code references (IS 1893 Cl. 7.7.5, ASCE 7 Sec. 12.9.1), default values (ecc_ratio=0.05, modal_combo='CQC'), and explanation of directional combination. This goes beyond annotations to fully describe 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear one-sentence purpose, followed by code references, formula explanation, and a bulleted Args list. Every sentence serves a purpose, and the format is easy to scan. Despite length due to parameter count, there is no redundancy or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, 0% schema coverage, no output schema provided), the description covers all necessary information: standards, formulas, default values, parameter meanings, and even references a sibling tool for scale factor calculation. The return type is mentioned ('JSON confirmation'), which is sufficient for a define action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears full burden. It explains all 14 parameters: case_name, modal_case, direction flags, scale factors with formulas, modal and directional combination rules, eccentricity ratio, and function names. This provides essential meaning that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Define a multi-directional Response Spectrum Analysis (RSA) load case,' which clearly states the tool's action (define) and resource (RSA load case). It distinguishes from sibling tool etabs_set_is1893_seismic_params by noting that tool computes scale factors automatically, while this one requires precomputed values. This specificity avoids confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool: for defining RSA load cases per IS 1893 and ASCE 7 standards. It provides guidance on scale factor calculation and references the alternative etabs_set_is1893_seismic_params for automatic computation. It recommends CQC and SRSS combinations, giving clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ETABS-mcp MCP server](https://glama.ai/mcp/servers/mdvaleed7/ETABS-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mdvaleed7/ETABS-mcp)

Score Badge

Copy to your README.md:

[![ETABS-mcp MCP server](https://glama.ai/mcp/servers/mdvaleed7/ETABS-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mdvaleed7/ETABS-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mdvaleed7/ETABS-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server