RSAP MCP

by nhantruong96

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: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: define/create/assign/query are cleanly separated, and singular vs. bulk variants (e.g., add_node vs. add_nodes) are clearly named. Even similar results tools (bar_forces vs. bar_force_envelope) differ in purpose and are unambiguous.
Naming Consistency3/5
All tools share the 'rsap_' prefix and snake_case, but the verb-noun pattern is not universal: results tools (bar_forces, node_displacement, node_reaction, results_summary) omit the verb, while most others use verb_first (add_, list_, define_). This mixed convention is readable but not fully predictable.
Tool Count3/5
35 tools is above the typical well-scoped range, but the domain (full structural analysis lifecycle) justifies the breadth. The count feels heavy yet each tool covers a distinct need; a smaller set would require awkward multi-purpose tools.
Completeness4/5
The set covers the core workflow: project management, geometry (nodes/bars), properties, supports, loads, analysis, and results. Notable gaps exist for shell/plate modeling (despite project types including shell) and there are no update/edit tools for existing objects, but the main frame/bar analysis pathway is complete.
Average 3.9/5 across 35 of 35 tools scored. Lowest: 3.1/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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It vaguely states 'extreme internal forces' without explaining what 'extreme' means (e.g., min/max over samples or load cases), what forces are included, or the return format. This ambiguity is a significant gap for a tool that computes envelope values.
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 clear one-sentence purpose followed by a compact parameter list. Every sentence provides essential information without redundancy or filler.
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?
For a tool with no output schema, no annotations, and only three parameters, the description should explain what 'extreme' means and what output should be expected. It does not describe the return format (e.g., list of forces per sample point, min/max pairs, which force types) or any related context such as load case combinations. This makes it incomplete for an agent to confidently invoke and interpret results.
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 compensates for the 0% schema description coverage by explaining each parameter: 'bar' as bar number, 'case' as load case/combination number, and 'samples' as the number of equally spaced sample points (>= 2). This adds meaningful semantics beyond the raw schema types, though it does not mention the default value of 11.
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 a specific action ('sample a bar along its length') and outcome ('return the extreme internal forces'), clearly identifying the tool's purpose. It distinguishes itself from the sibling rsap_bar_forces by mentioning 'extreme' but does not explicitly contrast 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 is provided on when to use this tool versus alternatives like rsap_bar_forces. It implies usage by describing the sampling behavior, but there are no exclusions, prerequisites, or criteria for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral transparency. It merely states the action without disclosing prerequisites (e.g., nodes must exist), auto-numbering behavior, error handling, or side effects on the project. No behavioral traits are disclosed.
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, consisting of one sentence plus a brief Args block. Information is front-loaded with the core purpose, and there is no wasted content. Every word earns its place.
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?
Given the tool is a mutation with a nested array parameter, no annotations, and no output schema, the description is insufficient. It omits critical contextual details like the requirement that start_node and end_node must already exist, how auto-numbering works, and what happens if invalid specs are provided. The description needs more depth to be 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?
The description lists 'bars: List of {start_node, end_node, number?, section?, material?} specs.' which is a compact summary of the schema's BarSpec fields. However, the schema already provides detailed descriptions for each property (e.g., 'auto if omitted', 'existing section label'), so the description adds little meaning beyond a shorthand. It does not compensate for the 0% coverage of the top-level 'bars' parameter itself.
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 many bars at once' with a specific verb (create) and resource (bars) and scope (many at once). This distinguishes it from the sibling tool 'rsap_add_bar' which likely handles single bars. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'many bars at once' implies this tool is for batch creation, providing clear context for when to use it. However, it does not explicitly name the singular alternative (rsap_add_bar) or state any exclusions, so usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether it requires prior calculation, what happens if the node or case is invalid, or any error/edge-case behavior. The only behavioral hint is 'global axes,' which is more of a semantic qualifier than a disclosure of 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 extremely concise: a one-line purpose statement followed by a two-item argument list. Every word earns its place, and the structure is immediately scannable. It avoids repetition of the tool name and includes only essential information.
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 is a simple query with two integer parameters and an output schema exists, the description covers the basic purpose and parameters adequately. However, it omits important contextual details such as the need to run a calculation first, whether the result is from the current project, and what form the output takes. These gaps are notable for a results-query tool in a larger API.
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's Args section is the primary source for parameter meaning. It provides clear, concise definitions for both 'node' (Node number) and 'case' (Load case or combination number), adding context that the schema lacks. It could specify indexing or units, but the given information is sufficient for basic use.
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 identifies the resource ('Nodal displacement') and adds a scoping detail ('global axes'), distinguishing it from other result queries like reactions or bar forces. However, it lacks a direct verb (e.g., 'Get' or 'Return'), making it a noun phrase rather than a full command. It is not a tautology because it adds coordinate-system context beyond the tool name.
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 rsap_bar_forces or rsap_node_reaction. There is no mention of prerequisites (e.g., running a calculation first) or scenarios where this tool is preferred. This is a clear gap for a result-query tool among many siblings.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions that an explicit case number is auto-assigned if omitted, but it does not disclose that this tool mutates project state, whether a project must be open, or what the return value is.
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 line followed by an Args block. It is not overly long and each line provides useful detail, though the examples could be condensed without losing value.
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 creation tool with four explained parameters, the description is mostly adequate. However, it omits return value information and prerequisites, and the lack of annotations means those gaps are not filled elsewhere.
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 fully compensates for the 0% schema description coverage. It explains every parameter with examples and enumerates allowed values for 'nature' and 'analysis', and it clarifies the 'number' auto-assignment behavior.
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 starts with 'Create a simple load case', which is a specific verb and resource. While it doesn't explicitly distinguish from sibling tools like rsap_add_combination, the word 'simple' hints at a distinction from combinations, and the overall meaning is clear.
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?
There is no explicit guidance on when to use this tool versus alternatives. The description does not mention that this tool should be used before applying loads, nor does it contrast with load application tools like rsap_add_nodal_force or rsap_add_bar_uniform_load.
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?
With no annotations provided, the description carries the full burden of behavioral transparency. It discloses only that nodes are created and coordinates are in meters, but omits any side effects, behavior on duplicate node numbers, validation rules, or what happens to existing nodes. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and immediately followed by parameter details. It avoids fluff, but could be slightly more informative without being verbose.
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?
Given the lack of annotations and output schema, the description is too thin for a batch creation tool. It does not cover potential issues like node numbering rules, maximum batch size, or error handling, leaving significant gaps for an agent to correctly invoke the tool.
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% for the 'nodes' parameter itself, so the description's line 'List of {x, y, z, number?} node specifications (coordinates in m)' adds essential meaning beyond the schema by explaining the structure and units. However, it does not elaborate on optional fields or edge cases, so it only partially compensates for the missing schema description.
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 'Create many nodes at once,' clearly identifying the verb (create), resource (nodes), and distinguishing it from the sibling rsap_add_node by emphasizing batch creation. This is a specific and unambiguous purpose.
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 phrase 'many nodes at once' implies when to use this tool (for batch node creation) but does not explicitly state when not to use it or mention alternatives like rsap_add_node for single-node creation. The usage context is implied but not detailed.
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?
There are no annotations, so the description must fully disclose behavior. It only restates the action implied by the name without specifying whether it is read-only, what the return format is, or whether a project must be open. No extra behavioral context is added.
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 a single concise sentence, front-loaded with the action and resource. No redundant words or unnecessary details.
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 listing tool, this is minimally viable but incomplete. It lacks context about return format, empty-list behavior, and prerequisites like an active project, which are not covered by annotations or an 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?
The tool has zero parameters, so schema coverage is trivially 100%. With no parameters to describe, the baseline for 0 params is 4, and the description does not need to compensate for missing parameter information.
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 specific verb 'list' and names the resource 'load cases and combinations', clearly distinguishing it from other listing tools (e.g., rsap_list_sections, rsap_list_nodes).
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 or how it relates to alternatives. There is no mention of prerequisites like an active project or connection, which is important for a model-specific operation.
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?
No annotations are provided, so the description carries the full burden. It adds that results are in 'global axes', but lacks disclosure about output structure, error conditions (e.g., unsupported node), or that the tool is read-only. It does not mention whether results require a completed calculation.
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 stating purpose, followed by clear argument explanations. No filler or redundant information, appropriate for a simple two-parameter tool.
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 there is an output schema, return values need not be described. However, the description omits important context such as the need to run a calculation first or the fact that this tool is only valid after a successful analysis. It also does not mention units, which could be inferred from output schema. Overall, adequate but with a noticeable gap in prerequisites.
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 no parameter descriptions (0% coverage), so the description must compensate. It does: 'node: Node number (must be a supported node)' and 'case: Load case or combination number' clarify the meaning of both parameters. This goes beyond the bare schema, though it could include examples or units.
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 function: 'Support reaction at a node (global axes).' This is specific with a verb+resource pattern and distinguishes it from sibling result tools like node_displacement and bar_forces.
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 on when to use this tool versus alternatives. It does not mention prerequisites (e.g., model must be calculated) or indicate when other result tools are more appropriate. The purpose statement implies usage but does not provide contextual direction.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the listing action and return fields, but does not disclose default behavior (e.g., limit=500 applies by default), pagination, ordering, or any side effects. Without annotations, this is a significant gap for a read operation.
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 one clear sentence followed by a brief parameter explanation. It is front-loaded with the core purpose and contains no unnecessary words or repetition.
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 low complexity (one optional parameter) and no output schema, the description provides the essential information: what the tool lists and what the parameter does. It could be more complete by noting the default limit or ordering behavior, but for a simple list operation it is 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?
The description includes an explicit Args section explaining that 'limit' is the 'Maximum number of bars to return'. This adds clear meaning beyond the schema's type and default, fully compensating for the 0% schema 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?
The description clearly states the verb 'List' and the resource 'bars', and specifies the return content as 'start/end node numbers'. This distinguishes it from siblings like rsap_list_nodes and rsap_list_sections, 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 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., list_nodes, list_sections). It does not mention any exclusions or contexts where a different list tool would be preferred. The only implicit hint is the tool name itself, which is insufficient.
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?
With no annotations, the description carries the burden of disclosing behavioral traits. It only states the basic list operation, without explicitly noting that it is read-only, whether it requires an active connection/project, or any potential side effects. This is a minimal disclosure for a read operation, similar to the 'update_drive' example.
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 just two sentences (or a sentence plus an Args list) to convey purpose and parameter meaning. Every word earns its place with no repetition or fluff.
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 tool with one parameter and no output schema, the description covers the core purpose and parameter semantics. However, it does not describe the return structure beyond mentioning coordinates, nor any prerequisites like needing an open project or connection. Given the simplicity, this is minimally adequate but not fully complete.
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 provides only the type and default for 'limit', with 0% description coverage. The description's Args section adds the meaning 'Maximum number of nodes to return', compensating for the schema gap. This provides useful semantic information beyond the structured 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 'List nodes with their coordinates', providing a specific verb and resource. It distinguishes from sibling tools like rsap_list_sections and rsap_list_bars by explicitly targeting nodes with coordinate details.
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?
There is no explicit guidance on when to use this tool versus alternatives, but the name and description imply it is for listing nodes. No exclusions or alternative tool references are provided, so the usage context is implied but not fully articulated.
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?
The description does not disclose any side effects or dependencies, such as whether creating a new project discards unsaved changes, requires an active connection, or affects the current project state. With no annotations available, this lack of transparency is a significant gap for a mutation-like tool.
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 a one-sentence summary and a brief parameter list. It is front-loaded and contains no unnecessary information, though the Args section duplicates schema information but is acceptable.
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 simplicity, the description covers the core action and parameter values, but it lacks important contextual information such as when to use it relative to other project tools and the meaning of each project type. These gaps prevent it from being fully complete.
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 adds the list of allowed values for project_type ('shell, frame_3d, frame_2d, truss_3d, truss_2d, plate, grillage'), which is not present in the schema (schema coverage is 0%). However, it does not explain what each project type means, so it only partially compensates for the schema's lack of detail.
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 function: 'Create a new, empty Robot project.' This is a specific verb (Create) and resource (Robot project), and it distinguishes itself from sibling project tools like open, save, and close.
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 no explicit guidance on when to use this tool versus alternatives like rsap_open_project or rsap_save_project. The context of siblings implies it is for starting a new project, but this is not stated, so the usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states what it reports, but does not disclose whether it is read-only, requires an active connection, or whether it triggers any side effects. The word 'Report' hints at a safe read operation, but this is not explicit.
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 a single, short sentence (13 words) that front-loads the verb 'Report' and clearly lists the two outputs. Every word 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?
The tool is simple (no parameters, no output schema), so the description covers the basic scope. However, it does not clarify what the 'summary' includes or whether connection is required, which could be important for an agent deciding between this and similar reporting tools.
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, so the baseline for parameter semantics is 4. The description correctly implies no arguments are needed, and there is nothing else to explain beyond the schema's empty object.
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 a specific verb ('Report') and resource ('connection status and a summary of the current Robot model'). This distinguishes it from sibling tools like rsap_connect (establishing connection) and rsap_calculation_status (calculation progress).
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 usage is implied: one would call this to check connection status and get an overview of the model. However, there are no explicit alternatives, exclusions, or prerequisites mentioned, so it stays at the 'implied usage' 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?
With no annotations, the description carries the full burden. It discloses that the tool only reports status and performs no mutation, but it does not clarify what 'currently available' means, how availability is determined, or what the return payload looks like. This is acceptable but 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?
A single sentence with no filler. It front-loads the action and subject immediately, making it efficient and easy to scan.
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 no parameters, no output schema, and low complexity, the description is largely complete. A minor gap is that 'currently available' is not defined precisely (e.g., whether it refers to a completed calculation, loaded results, or something else), but the overall context is sufficient for a status check.
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, so the baseline is 4. There are no parameter semantics to clarify, and the description does not need to compensate for missing schema information.
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 ('report') and resource ('whether analysis results are currently available'), clearly distinguishing it from sibling tools like rsap_status, which likely concerns connection or program state. It also differentiates from result query tools such as rsap_bar_forces by focusing on availability rather than values.
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. The description implies it might be used to check result availability before querying results, but it does not state this or mention any conditions or exclusions.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not state whether defining a label overwrites an existing name, whether the model is mutated, whether special permissions are needed, or how errors are reported; it only explains parameter semantics.
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 compact, front-loaded with the core definition, and every sentence earns its place: the True=restrained rule, presets, and an itemized Args list. There is no filler or repetition.
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?
All parameters are covered and presets help, but the description omits workflow context: it doesn't mention that the defined label must later be applied with rsap_assign_support, nor does it describe any return value or failure behavior. For a 7-parameter tool with no annotations/output schema, this leaves meaningful 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?
Schema description coverage is 0%, but the Args section explicitly documents every parameter (name and six DOF booleans) and adds the key semantic 'True = restrained' plus preset combinations. This fully compensates for the absence 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 opens with 'Define a support (boundary condition) label,' clearly stating the action and resource. It distinguishes from the sibling rsap_assign_support by focusing on label creation rather than assignment, and it clarifies the core boolean semantics with 'True = restrained.'
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?
Common presets (pinned, fixed, roller) imply when this tool is useful, but the description never explicitly contrasts it with rsap_assign_support or indicates that labels must be defined before they can be assigned. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses prerequisites (nodes must exist, section/material must be defined) and one behavior (number auto-assigned). It does not mention what happens on failure, error handling, or any side effects beyond creation, which leaves gaps for a mutation tool.
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 front-loaded with the core action and then lists parameters with concise explanations. It avoids redundancy, though the arg list mirrors the schema's properties; however, the added semantic detail justifies each element. Tight and well-organized.
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?
With no annotations and no output schema, the description covers the main inputs and prerequisites but omits differentiation from the plural tool rsap_add_bars, potential error cases, and any return/output behavior. It is adequate for basic invocation but not fully complete for an agent deciding between similar tools.
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 fully compensates by providing meaningful semantics for every parameter: start/end node roles, number auto-assignment, and references to define tools for section/material. This goes well beyond the schema's bare type/title information.
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 function: 'Create a bar (beam/column) between two existing nodes' with specific verb and resource. It distinguishes from siblings like rsap_add_bars by emphasizing a single bar, and clarifies that section/material assignment is optional.
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 context: 'between two existing nodes' and references rsap_define_section/rsap_define_material for required definitions. However, it does not explicitly state when to use this tool instead of the plural sibling rsap_add_bars, nor does it give exclusions or alternative conditions.
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?
With no annotations, the description carries the burden, and it does explain key behaviors: 'relative' and 'local' flags, and position interpretation. However, it omits other behavioral traits like whether the load is additive over multiple calls, whether the load case must already exist, or what happens on error.
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 front-loaded with a one-sentence purpose, then a compact labeled argument list. No wasted words; the arg list is scannable and directly maps to the schema properties.
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 complex 11-parameter tool with no output schema and no annotations, the description covers all parameters, units, and mode flags. It could add more about prerequisites (e.g., existing load case) and selection syntax, but it is sufficiently complete for an experienced structural analysis user.
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 substantial meaning beyond the bare schema: it gives units (N for forces, N·m for moments), explains the 'presence' of position as relative fraction or metres, and clarifies the effect of 'relative' and 'local' flags. The schema itself has no property descriptions (coverage 0%), so this is a strong contribution.
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 opens with a specific verb+resource statement: 'Add a concentrated (point) force/moment on bars.' This clearly distinguishes it from siblings like rsap_add_bar_uniform_load and rsap_add_nodal_force by identifying the load type and target element.
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 on when to choose this tool over alternatives. The description only explains parameters, not the context in which a point load vs. uniform load or nodal force is appropriate. Given the sibling tools, an explicit distinction would be helpful.
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?
With no annotations, the description carries full burden for disclosing side effects, but it only states the action without mentioning potential state changes (e.g., closing the current project), prerequisites (like requiring an active connection), or failure behaviors (e.g., invalid path handling).
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 a clear verb-first opening and a structured Args block. Every word earns its place, and the format is standard for documentation.
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 tool has only one parameter and no output schema, so the description is relatively complete for a simple open action. However, it lacks context about prerequisites (e.g., needing to connect first via rsap_connect) and expected return values, which are not covered by annotations or 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 must compensate. It adds meaning by specifying the path must be 'absolute' and points to a '.rtd file on the machine running Robot', which is valuable context beyond the bare schema title 'Path'. However, it could be more detailed about constraints like file existence or extension.
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 'Open an existing Robot model from an absolute .rtd path', which is a specific verb+resource combination. It distinguishes itself from sibling tools like rsap_new_project and rsap_close_project by explicitly targeting existing models.
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 phrase 'an existing Robot model' implies this tool is for opening previously saved projects, as opposed to creating new ones. However, it does not explicitly mention alternatives or exclusions, though the context is clear enough for an agent to infer when 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose a key prerequisite (database active, profile exists) and a behavioral default (db_section defaults to name). However, it does not explain side effects such as whether an existing label is overwritten, nor does it describe error behavior if the profile is missing or the database is inactive, which limits 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 appropriately structured: a clear first sentence stating the purpose, a second sentence for the prerequisite, and a concise Args list. It is slightly longer than strictly necessary but contains no fluff and is easy to scan. Every sentence adds value, though the Args section could potentially be left to the schema if the schema had descriptions.
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 no annotations and no output schema, the description covers the essential aspects: purpose, prerequisite, and all parameter meanings. It does not mention return values or error behavior, but for a definition tool with a simple API, the provided information is largely complete. The only gap is the lack of detail on failure modes or side effects, which prevents a perfect score.
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 no descriptions for parameters (0% schema coverage), but the description's Args section fully explains each parameter: name, db_section (with default behavior), and material (optional). This adds significant meaning beyond the schema titles, clearly defining the role and default of each parameter, and even offers a usage clue ('often the profile name itself').
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 function: defining a bar section label by loading a profile from Robot's section database. It uses specific verbs (define, loading) and a specific resource (bar section label), and provides concrete examples of profile types. This distinguishes it from sibling tools like rsap_list_sections or rsap_assign_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 implies usage by stating the prerequisite that the section database must be active and contain the profile. However, it does not explicitly mention when to use this tool versus alternatives, nor does it provide any exclusions or alternative tool suggestions. This is an implied usage scenario rather than explicit 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?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the local vs. global coordinate interpretation and the projected flag, but it does not disclose whether loads are additive, whether a load case must pre-exist, or any side effects/errors. This is partial transparency, not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured: a single purpose statement followed by a compact Args list. Every line adds informational value, with no repetition, fluff, or wasted words. It is front-loaded and easy to scan.
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 7-parameter tool with no annotations and no output schema, the description covers all parameters and gives key contextual details (units, axes, projection). It lacks explicit prerequisites (e.g., that the load case must exist) and return behavior, but for a load-adding operation the core usage is well-covered. Slightly more could be said about cumulative behavior or validation.
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, and it does thoroughly. It defines every parameter (case_number, bars, px/py/pz, local, projected), provides units, a bars format example ('1to10'), and clarifies local/global defaults. This adds substantial 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 opens with a specific verb+resource: 'Add a uniformly distributed load along bars.' This clearly distinguishes it from sibling tools like rsap_add_bar_point_load and rsap_add_nodal_force, stating exactly what load type and target are involved.
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 clearly implies its use case (applying distributed loads to bars), but it does not provide explicit when-to-use versus alternative guidance. No mention is made of point loads (rsap_add_bar_point_load) or other load types, leaving the agent to infer the distinction from the tool name and first sentence.
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?
With no annotations provided, the description carries the full burden. It adds useful behavioral context by specifying global axes and units for each force/moment component. However, it does not disclose whether repeated calls accumulate, whether the tool requires an existing load case, or any side effects beyond 'add'.
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 one-sentence summary followed by a bullet-like Args block. Every sentence serves a purpose, and the format makes parameters easy to scan.
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 moderate complexity (8 parameters) and absence of an output schema or annotations, the description covers all parameters with units and examples. It does not mention return values or preconditions like required connection, but for a simple mutation tool this is acceptable.
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 compensates fully by explaining every parameter: case_number, nodes with an example format, and the six force/moment components with units. This provides clear meaning beyond the raw schema property names.
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 ('Add') and resource ('nodal force/moment to a case'), and clarifies the coordinate system ('global axes'). This clearly distinguishes it from sibling tools like bar loads or self-weight loads.
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 gives clear context (adding a nodal load to a load case) but does not explicitly state when to choose this over alternatives or mention exclusions. Sibling names imply the distinction, but there's no direct 'use this for nodal loads, not bar loads' 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?
With no annotations provided, the description carries the burden of explaining behavior. It discloses that node numbers are auto-assigned if omitted and clearly lists coordinates in metres, but does not mention side effects, error conditions, or mutating nature beyond 'Create'. Some transparency present, but gaps remain.
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 front-loaded with the core action, followed by a clean argument list. Each sentence serves a purpose, with no filler or 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?
For a simple additive operation, the description covers the essentials: coordinates, units, and optional numbering. It does not mention return values or the need for an open project, but given the low complexity and no output schema, the omission is minor and the tool description is sufficiently complete for its 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 schema provides only titles and types, leaving the description to explain each parameter's meaning and units. The Args section fully documents x/y/z as coordinates in metres and specifies that 'number' is optional with auto-assignment behavior, adding 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 uses a specific verb ('Create') and resource ('a single node') with clear coordinate specification in metres, distinguishing it from the sibling tool rsap_add_nodes which likely handles multiple nodes. The purpose is unmistakable.
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 for creating one node at a time, especially given the sibling rsap_add_nodes for bulk creation, but does not explicitly state when to prefer this tool or mention prerequisites like an open project. Guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits on its own. It states the action but does not explain whether existing material assignments are overwritten, what happens if the material name is invalid, or any side effects. The prerequisite hint about defining the material is the only additional behavior-related information, which 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 concise and well-structured: one sentence for the purpose followed by a clear Args section. Every sentence contributes value—there is no fluff or repetition of schema details. The format is easily scannable.
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 assignment tool with two required parameters and no output schema, the description covers the key aspects: what it does, how to provide each argument, and a necessary prerequisite. It does not address error behavior or overwrite semantics, but these are not critical for basic usage of this 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?
The input schema provides only types and titles for the two parameters, with no descriptions. The description fully compensates by explaining material_name as the name of a material label defined with rsap_define_material, and bars as selection text with concrete examples ('1to20' or '1 2 3'). 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 begins with 'Assign an existing material label to a set of bars,' which uses a specific verb (assign) and clearly identifies both the resource (material label) and the target (bars). It distinguishes itself from sibling tools like rsap_assign_section and rsap_assign_support through the explicit mention of material labels.
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 context by specifying that the material must be 'defined with rsap_define_material,' which communicates a prerequisite. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for a user to know when to apply this tool.
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?
No annotations are provided, so the description carries the full burden. It explains the local axes and position range but does not state whether the operation is read-only, error behavior, or prerequisites like prior calculation. It adds some useful behavioral context but lacks explicit safety or side-effect disclosure.
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 two main parts: a clean one-line purpose statement followed by a compact Args list. Every sentence is necessary, and the structure front-loads the key information for quick comprehension.
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 query tool with an output schema, the description covers the core functionality and all parameter semantics. It lacks explicit usage guidance and preconditions, but the tool's purpose is well-scoped enough for an agent to select and invoke it reasonably given the sibling set.
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 fully compensates by explaining each parameter: bar number, load case/combination number, and relative position with range 0.0-1.0. This goes well beyond the plain parameter titles in 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 tool computes 'Internal forces at a point along a bar (local axes)', specifying the resource (bar) and the exact output (forces at a position). This distinguishes it from sibling rsap_bar_force_envelope, which likely covers force envelopes.
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 for querying internal forces at a specific position along a bar but doesn't explicitly compare with alternatives like rsap_bar_force_envelope or mention preconditions such as a completed analysis. No exclusions or alternative guidance provided, but the context is clear enough.
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?
With no annotations, the description carries the full burden and does provide a key behavioral trait beyond the tool name: 'Robot itself stays open'. This clarifies that the operation does not terminate the application. However, it does not mention the potential loss of unsaved changes, which is a notable omission for a close operation.
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 a single, front-loaded sentence. Every word adds value—the main action and the clarifying parenthetical—with no redundant or extraneous information.
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 zero-parameter tool with no output schema, the description covers the core behavior but omits an important consequence: unsaved changes may be lost when closing the project. This is a significant gap for an AI agent deciding whether to call this tool, especially given the presence of a save_project sibling. The clarification about Robot staying open is helpful but does not fully address the risk.
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, so the baseline is 4. The description does not need to explain parameter semantics, and the input schema is empty. Nothing is missing here.
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 ('Close') and the target ('current project'), and the parenthetical 'Robot itself stays open' clarifies the scope, distinguishing it from closing the application entirely. This is a specific verb+resource that differentiates the tool from sibling project operations like open, save, or new.
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 a context—closing the active project while keeping the application running—but does not explicitly state when to use this tool versus alternatives such as save_project or open_project. There is no guidance on prerequisites (e.g., saving before closing) or exclusions (e.g., not for exiting Robot).
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is 'delete' (implying destructive behavior) but does not mention potential impacts such as deleting connected bars, permissions required, or error handling. This leaves significant behavioral ambiguity.
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 main purpose, and then lists parameters with examples. Every sentence earns its place with no fluff or repetition.
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 delete tool with two parameters and no output schema, the description covers the key aspects: what it does, the parameters, and examples. It omits return value/error behavior, but this is a minor gap given the tool's simplicity.
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 explicitly explains both parameters: object_type ('node' or 'bar') and selection (Robot selection text with examples like '1to10 15'). This adds essential meaning beyond the bare schema fields.
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 'Deletes nodes or bars matching a selection string', which is a specific verb+resource combination. It distinguishes itself from sibling add/list tools by specifying the deletion operation and the selection mechanism.
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 context for when to use the tool (to delete nodes/bars) and gives the selection text format. It does not explicitly mention alternatives or when not to use, but the purpose is so distinct that usage is nearly self-evident.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The verb 'List' implies a non-destructive read-only operation, but the description does not explicitly state that the model is unmodified, nor does it mention any other behavioral details such as ordering or uniqueness of returned names. It is minimally adequate but adds no context beyond the obvious.
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 a single sentence, front-loaded with the action, and contains no filler or redundant phrasing. Every word 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?
For a simple list tool with no parameters and no output schema, this description is complete. It states exactly what information is provided (names of section labels) and sufficient for an agent to understand the tool's function. No additional 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 tool has zero parameters, and the schema has no properties, so there is nothing to document. The description correctly omits any parameter details. With 0 parameters, the baseline is 4, and no compensation is needed.
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 ('List') and the resource ('the names of section labels defined in the model'). It is specific and distinguishes this tool from sibling list tools such as rsap_list_nodes, rsap_list_bars, and rsap_list_load_cases, which target different entities.
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 gives no explicit guidance on when to use this tool versus alternatives. However, the purpose is self-evident for a list operation, and the sibling context implies that this is the go-to tool for viewing section labels. It lacks explicit exclusions or alternative recommendations, so it stops at implied usage.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals that max_nodes and max_bars act as caps, scanning only the nodes/bars with the largest |Uz| and |My| respectively, which is useful behavioral detail. However, it does not disclose the return format, whether results are sorted, or how peak values are aggregated, leaving some 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: a one-sentence summary followed by a clean Args list. Every sentence earns its place, with no filler or repetition of schema defaults. The format makes it easy to parse.
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 summary tool with three parameters, the description covers the main purpose and parameter semantics well. It lacks explicit context about prerequisites (e.g., calculation must be run) and does not describe the output structure, but given the absence of an output schema and the tool's straightforward nature, it is mostly complete. It could benefit from a quick usage hint or mention of alternatives, but these are 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?
Schema description coverage is 0%, but the description's 'Args' section explicitly explains each parameter: 'case' as load case or combination number, 'max_nodes' as a cap on nodes scanned (largest |Uz|), and 'max_bars' as a cap on bars scanned (largest |My|). This adds meaningful semantics beyond the raw schema, 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 states the exact purpose: 'Summarise results for a case: peak nodal displacement and peak bar moment.' This is a specific verb ('Summarise') with a clear resource (results for a case) and distinguishes from sibling tools that return detailed results like rsap_node_displacement or rsap_bar_forces. It clearly serves as a high-level summary tool.
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 a calculation is complete, as it summarizes results, but it does not explicitly compare to alternatives or state when not to use it. Sibling tools like rsap_node_displacement and rsap_bar_forces offer more detailed views, but no guidance on choosing between them is provided. Usage is implied rather than explicitly directed.
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?
No annotations are provided, so the description must carry the burden. It discloses the blocking characteristic and the recommended follow-up steps, but does not mention potential failure modes, side effects on existing results, or prerequisites such as a completed model.
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 two sentences, front-loaded with the core purpose, and contains no superfluous 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?
For a simple tool with no parameters and no output schema, the description covers the essential lifecycle (calculate then retrieve results). It omits error behavior and the relationship to rsap_calculation_status, but remains 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 tool has zero parameters and the input schema is empty, making schema coverage trivially 100%. The baseline for 0 params is 4, and the description adds no parameter details because none exist.
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 'Run the structural analysis (solve the model)' clearly states the action and resource, and it distinguishes the tool from result-retrieval siblings by specifying it initiates calculation and blocks until completion.
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 gives clear context: 'This blocks until Robot finishes calculating. After it returns, use the results tools.' This implies when to use the tool, though it does not explicitly exclude alternatives like rsap_calculation_status.
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?
With no annotations, the description carries the full transparency burden. It discloses auto-assignment of the combination number and the meaning of combo_type, but does not mention prerequisites (e.g., existing load cases) or potential side effects such as overwriting existing combinations or error behavior. This is a moderate level of disclosure for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose followed by a compact Args list with examples. Every line adds value, and the formatting enhances scannability without wordiness.
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 all five parameters and key behaviors, with examples that illustrate real use. However, it omits any mention of return values or error conditions, and does not explicitly note that existing load cases must be present, which would be useful given the absence of an output schema and annotations.
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 schema has 0% coverage for top-level parameters, but the description fully compensates by explaining each parameter, providing concrete examples for name and factors, specifying allowed values for combo_type, and clarifying default behavior for nature and number. This is exemplary parameter documentation.
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 opens with a specific verb and resource—'Create a load combination from weighted load cases'—which clearly states the tool's function. This distinguishes it from sibling tools like rsap_add_load_case, which creates individual load cases, whereas this tool combines them.
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 through parameter examples (e.g., 'ULS 1.35G + 1.5Q') and explains combo_type values ('uls' or 'sls'), giving clear context for when to use this tool. However, it does not explicitly name alternative tools or state when not to use it, leaving a small gap in usage 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?
With no annotations, the description must carry the full burden. It explains the core operation (adding a dead load) and the effect of parameters, but does not disclose side effects such as whether the load is appended to existing loads, whether it overwrites prior self-weight definitions, or whether a target load case must already exist. This leaves some behavioral ambiguity.
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 one-sentence purpose followed by a clean argument list. Every sentence/line adds value, and there is no fluff or repetition of schema defaults.
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 all four parameters and the core behavior, which is good given the tool's moderate complexity. However, it does not mention prerequisites (e.g., the load case must exist) or what happens after calling (e.g., return value or model update). These omissions are noticeable without an output schema or annotations.
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 compensates. It explains every parameter: 'case_number' as target case, 'direction' with explicit options, 'factor' as multiplier, and 'selection' with syntax examples. This is exactly the kind of semantic enrichment 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 clearly states the action ('Add') and the object ('self-weight (dead) load to a case'), which is specific and distinct from sibling load tools like rsap_add_nodal_force or rsap_add_bar_uniform_load. The first sentence is informative and unambiguous.
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 gives clear context that this tool is for applying self-weight loads, and the parameter descriptions clarify scope via 'selection' and direction. It does not explicitly mention alternatives or when not to use it, but the tool name and sibling context make the intended use reasonably obvious.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It tells the agent that the section must already exist and how to specify bars, but it does not disclose whether the assignment overwrites existing section assignments, nor does it describe any errors or side effects. This is a moderate gap for a mutation tool.
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 front-loaded with the main purpose. The Args section cleanly lists parameters with clear explanations. Every sentence earns its place with no redundancy or 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?
For a simple two-parameter assignment tool, the description covers the core behavior and both parameters. It does not mention return values or behavior when the section does not exist, but given the straightforward nature of the tool and lack of output schema, it is reasonably complete. A note on overwrite semantics would push it to a 5.
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 schema provides no descriptions for either parameter (0% coverage). The description compensates fully by explaining both: section_name is 'a section label defined with rsap_define_section' and bars is 'Robot selection text, e.g. 1to20 or 1 2 3.' Both parameters are clearly documented, exceeding what the structured schema offers.
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 an existing section label to a set of bars.' It specifies the resource (section label) and target (bars), distinguishing it from sibling tools like rsap_assign_material (which assigns material, not section). The reference to rsap_define_section also reinforces the domain.
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 the usage context: it assigns a section that must already exist (defined via rsap_define_section), and provides the bar selection syntax. While it doesn't explicitly name alternatives or exclusions, the context is clear enough to guide correct use among the sibling 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?
No annotations are provided, so the description bears the full burden. It clarifies that the support must be pre-existing and shows how to specify nodes, but it does not disclose whether existing supports on those nodes are replaced, how invalid names or node selections are handled, or any side effects. This is a moderate gap for a basic assignment tool.
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: one main sentence and a compact argument list. It front-loads the purpose and every sentence provides necessary operational detail, with no wasted 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 that this is a simple two-parameter tool with no output schema, the description covers the core operation and parameter semantics well. It could mention behavior on existing assignments or result feedback, but for the tool's complexity 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?
The schema has 0% description coverage, but the description fully compensates. It explains support_name as a name of a support defined by rsap_define_support, and nodes as Robot selection text with concrete examples ('1 4' or '1to4'). This adds critical 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 clearly states the tool's action: 'Assign an existing support label to a set of nodes.' It uses a specific verb plus resource and target, and the mention of 'existing' and 'defined with rsap_define_support' distinguishes it from defining supports and other assignment tools like rsap_assign_material or rsap_assign_section.
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 context by indicating the prerequisite that the support label must already exist via rsap_define_support, and it gives the node selection format. It does not explicitly mention when not to use this tool or compare it to alternatives, but the context is sufficient for an agent to infer proper usage.
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?
With no annotations, the description carries the disclosure burden. It provides substantial behavioral detail: precedence of 'from_database' over explicit properties, unit clarifications (Pa, N/m^3, RO as weight density), and naming of Robot's internal 'Kirchoff' property. It doesn't disclose what happens if the name already exists or if incomplete parameters are provided, but the disclosed quirks are highly valuable.
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 concise opening sentence followed by an Args block. Every line conveys necessary information, with no redundant text. The front-loaded purpose makes it easy to scan.
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 7 parameters and no output schema or annotations, the description covers all parameters and critical behaviors. It lacks explicit guidance on required vs optional parameters (e.g., whether e/nu/ro/kirchoff are needed when from_database is omitted) and potential overwrite semantics, but the overall information provided is substantial and well-rounded.
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 fully compensates by explaining every parameter's meaning, units, and role. It even clarifies the 'from_database' precedence and contrasts RO (weight density) with mass density. This exceeds the schema's bare property names.
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 material label' and distinguishes two modes (from database or explicit elastic properties). It distinguishes from sibling tools like 'assign_material' by focusing on creation/definition rather than assignment.
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 the tool (when you need a material label) but does not explicitly state alternatives or exclusions. It doesn't mention that you should use 'assign_material' to apply the label, leaving usage context implicit rather than explicit.
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?
No annotations are provided, so the description carries the full behavioral disclosure burden. It mentions overwriting the current file in the omit case, but does not clarify whether a supplied path will overwrite an existing file, what happens if no project is open, or whether a success/failure response is returned.
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 compact and front-loaded: two introductory sentences immediately convey the save modes, followed by a concise Args definition. Every sentence provides useful information without filler.
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 single parameter and no output schema, the description covers the core usage well. The main gaps are minor: no explicit mention of preconditions (e.g., an open project) or edge-case behavior for Save As overwriting an existing file. Still, it is nearly complete for this simple 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?
The schema has 0% description coverage, but the Args block fully compensates by explaining that path must be an absolute .rtd path (Save As) or None to overwrite the current file. This adds important meaning beyond the schema's raw anyOf string/null 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 'Save the current model' and distinguishes two modes: Save As (with path) and Save in place (without path). This is a specific verb+resource that is distinct from sibling project tools like new/open/close.
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 explicit conditional usage: pass an absolute .rtd path for Save As, or omit it to overwrite the currently open file. There is no alternative save tool among the siblings, so the guidance is clear and actionable even without explicit alternatives.
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?
With no annotations provided, the description carries the transparency burden. It discloses key behavioral traits: it only applies to shell models, is a no-op for bar/frame models, and meshing happens automatically on rsap_calculate(). This goes beyond the name and gives important operational context, though it doesn't mention potential errors or 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 two sentences with no wasted words. It front-loads the primary action, then provides a concise, valuable note about applicability. 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?
Given the tool's simplicity (0 parameters, no output schema), the description is complete. It explains what the tool does, when it applies, and when it's a no-op, including the automatic mesh generation behavior. No critical information is missing for an agent to decide whether and how to invoke it.
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, so the baseline is 4. The description doesn't add parameter-level details, but none are needed. The contextual note about model types compensates for the lack of parameters by clarifying when the tool is meaningful.
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 function with a specific verb and resource: 'Generate the finite-element mesh.' It also distinguishes from siblings by clarifying scope—only surface/panel (shell) models, and explicitly notes it is a no-op for bar/frame models, which differentiates it from other rsap_ tools.
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 context on when the tool matters (shell models) and when it's unnecessary (bar/frame models), even noting that Robot generates mesh automatically via rsap_calculate(). It stops short of explicitly stating 'use this instead of rsap_calculate' or naming alternatives, but the applicability guidance is strong.
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?
No annotations are present, so the description carries the burden. It reveals key behavioral traits: attaching to an existing Robot instance or launching a new one, and the effects of the visible and interactive parameters. It does not mention failure modes or prerequisites, but for a connect tool this is strong coverage.
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 compact, front-loaded with the purpose, then usage, then parameter details. Each sentence earns its place, with no repetition or fluff. The structured Args section improves readability.
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 its simplicity (2 optional boolean params, no output schema, no annotations), the description covers purpose, usage, behavior, and parameters sufficiently. It omits return-value details, but these are not critical for a connection tool. The auto-connect note provides necessary context about alternative setups.
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 no descriptions (0% coverage), but the description's 'Args' section explains each parameter clearly: visible shows the window, interactive refreshes the GUI. This adds meaning beyond the schema and fully compensates 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 the action 'Connect to (or launch) Autodesk Robot Structural Analysis Professional' with a specific verb and resource. It distinguishes itself from sibling tools by noting it should be called before other tools, establishing its role as the initial connection step.
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?
Explicit guidance is given: 'Call this once before other tools, unless auto-connect is enabled.' This tells the agent when to use the tool and acknowledges an alternative condition (auto-connect). It also clarifies the attach-or-launch behavior, providing context for expected behavior.
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:

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

Score Badge

Copy to your README.md:

[![rsap-mcp MCP server](https://glama.ai/mcp/servers/nhantruong96/rsap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nhantruong96/rsap-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/nhantruong96/rsap-mcp'

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