PLAXIS-MCP

by yixuanzhong

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.3.5
Disambiguation5/5
Each tool targets a distinct object/action: connections, project lifecycle, geometry creation, material assignment, phase control, calculation, and inspection. Overlapping names like list_members vs list_objects are differentiated by scope (attributes vs object instances). No two tools appear to do the same thing.
Naming Consistency4/5
Most tools follow a verb_noun pattern (connect, list_*, create_*, set_property, calculate), while status/info tools use noun phrases (project_info, model_state, connection_status). This is a consistent convention within each category, though not uniform across all tools.
Tool Count2/5
34 tools is a large surface, exceeding the 25+ threshold. While the engineering domain is complex, the count feels heavy and could overwhelm agents; some tools could be consolidated (e.g., create_point/line/polygon could be one geometry tool).
Completeness4/5
The tool set covers the full typical workflow: project management, geometry, materials, phases, meshing, calculation, and results. Obvious gaps include no delete tools for objects/phases/materials and no explicit import/export, but these are workable around via close_project/recover_project and generic set_property.
Average 3.8/5 across 34 of 34 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 36 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds no behavioral context beyond a terse statement. It does not disclose side effects, whether activation overwrites existing states, or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, but it is overly terse and omits important detail. It is front-loaded but not appropriately sized for the tool's complexity.
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 presence of an output schema and minimal annotations, the description still fails to contextualize the tool's behavior. It does not explain the significance of activation, how it interacts with phases, or why it is destructive, especially with sibling tools like 'deactivate' nearby.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, leaving parameters undocumented. The description loosely implies that 'paths' refers to objects and 'phases' to phases, but it provides no format, examples, or clarification of what these strings expect, making parameter semantics insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Activate' and the resource 'objects in phases', which distinguishes it from sibling tools like 'deactivate'. However, it does not elaborate on what activation entails, leaving some ambiguity about the operation's effect.
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 guidance on when to use this tool versus alternatives. It does not mention deactivate, connect, or any other sibling tool, nor does it describe prerequisites or expected usage scenarios.
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 adds no behavioral context beyond the annotations. It restates the basic action without explaining consequences, reversibility, or side effects of deactivation. The destructiveHint and idempotentHint annotations are present, but the description fails to elaborate on what 'deactivate' actually entails in practice.
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, economical sentence with no redundancy. It is front-loaded and immediately communicates the core action. Every word contributes to the meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the description is incomplete for a destructive tool. It does not explain side effects, prerequisites, or operational impact on phases and objects. Even with schema coverage, an agent would lack essential context to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only loosely maps 'objects' to 'paths' and mentions 'phases' without clarifying array formats or relationships. It does not explain what constitutes a valid path or phase, nor how the two arrays interact. This leaves significant ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deactivate) and the resource (objects in phases), which is specific and easily understood. It implicitly differentiates from the sibling 'activate' tool, though it doesn't explicitly mention alternatives. Still, the verb-resource pair is sufficiently precise.
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 'activate' or 'set_mode'. There is no mention of prerequisites, exclusions, or context where deactivation is appropriate. The description only tells what it does, not when to apply it.
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 annotations already provide destructiveHint=true and readOnlyHint=false. The description adds no additional behavioral context, such as whether existing material assignments are overwritten or what side effects occur. There is no contradiction with annotations, but also no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action and object, and is appropriately sized for a simple two-parameter tool.
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?
While an output schema exists, the description is minimal and lacks context about prerequisites, side effects, or the exact meaning of features. This makes it insufficient for an agent to confidently invoke the tool without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does provide some mapping by mentioning 'material' and 'one or more features', which correspond to the 'material' and 'paths' parameters. However, it does not explain what paths refer to or any constraints beyond the schema, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('assign') and the object ('material to one or more features'), making it distinct from sibling tools like create_material. However, 'features' is somewhat vague and could be defined more precisely, so it doesn't fully earn a 5.
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 given on when to use this tool versus alternatives such as set_property or create_material. Prerequisites like the material already existing or the meaning of paths are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint true, and the description adds no further behavioral context. It does not clarify what happens to existing soil layers (e.g., append, replace) or any side effects, leaving the destructive nature unexplained.
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 a single concise sentence that immediately establishes the action. While it is economical, it omits potentially valuable guidance; however, for a simple one-parameter tool, the brevity 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?
The description adequately covers the core action but misses essential context given the destructiveHint annotation. It does not explain what the 'destructive' aspect involves, nor does it mention any ordering or replacement behavior, leaving the tool partially under-specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description simply repeats the parameter name ('height') without adding units, constraints, or meaning. The schema only provides the type and title, so the description fails to compensate for the lack of 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 uses a specific verb ('Add') and resource ('soil layer') plus the key parameter ('height'), clearly distinguishing it from sibling tools like create_material or create_structural_element. It states exactly what the tool does without ambiguity.
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, prerequisites, or regarding the destructive nature of the operation. The description only states the action and gives no context about suitable scenarios 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?
Annotations already indicate destructiveHint=true, so the agent knows it's destructive. However, the description adds little beyond 'current', failing to disclose what happens (e.g., whether it overwrites the current state with a saved version or is reversible).
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, direct and front-loaded. It contains no wasteful words and is appropriately sized for a parameterless tool.
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?
With a destructive action and no usage context, the description leaves significant ambiguity about what recovery actually does. The presence of an output schema helps but does not clarify behavioral semantics like whether the project is overwritten or restored from a backup.
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 confirms this. With no parameters to document, the description need not add parameter semantics, so the baseline of 4 applies.
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 uses a specific verb 'recover' and names the resource 'current PLAXIS project', which distinguishes it from sibling tools like open_project and save_project. However, 'recover' is somewhat ambiguous without elaboration on what recovery entails.
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 given on when to use this tool or how it relates to alternatives like open_project or save_project. The description simply states the action without context for appropriate use.
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 annotations already mark destructiveHint as true, but the description adds no additional context about side effects, such as whether it resets the current project or requires a specific state. The description merely restates the creation action without disclosing any behavioral nuances beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information without any filler. For a tool with no parameters, this length is perfectly appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with no parameters and an output schema, the description omits important contextual details such as whether it can be called when a project is already open, or if it automatically closes/clears current state. Given the destructive annotation, additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is nothing for the description to clarify. Per the baseline for 0-param tools, the description need not elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the object ('a new PLAXIS project'), making the purpose unambiguous. It distinguishes from siblings like open_project or recover_project by emphasizing 'new', though it doesn't explicitly name alternatives.
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 such as open_project or recover_project. It also fails to mention prerequisites like whether an active connection is required, leaving the agent without clear usage context.
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 adds no behavioral traits beyond what annotations already provide. It does not mention the destructive nature (destructiveHint=true) or any side effects, and it fails to disclose whether the operation overwrites existing data or requires specific permissions. Annotations cover safety, but the description contributes nothing additional.
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 with no redundant content. It directly states the action and the relevant parameter, making it efficient and easy to parse.
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 one-parameter create tool with an output schema, the description covers the essential action but omits prerequisites and side effects. It does not mention that a project must be open or that the operation may be destructive, leaving the agent with partial context despite annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clarifies that 'x' is a coordinate, but provides no details on units, coordinate system, or constraints. This is minimal added meaning beyond the parameter name, so it just meets the baseline.
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 resource ('a borehole'), along with the key parameter ('at the given x-coordinate'). This distinguishes it from sibling tools like create_point or create_line by specifying a unique object type and spatial constraint.
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, nor does it mention any prerequisites (e.g., an active project). The lack of usage context forces the agent to rely on the tool name and sibling list, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description does not disclose what gets destroyed or overwritten when generating a mesh. It adds one input dependency (enhanced_refinement requires relative_element_size) but no behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core action front-loaded in the first sentence and the parameter dependency in the second. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks usage context, side-effect disclosure, and meaningful parameter semantics. It leaves the agent without enough information to know when to invoke the tool or what consequences to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the two parameters. It only names relative_element_size as a factor and states a constraint for enhanced_refinement, without defining what enhanced_refinement does or how the element size factor behaves.
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 'Generate the mesh' with a specific resource, and it distinguishes the tool from sibling tools, none of which target mesh generation. The optional relative element size factor is also mentioned, further clarifying scope.
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 the tool is used when the user wants to generate a mesh, but it provides no explicit guidance on when to prefer this tool over alternatives or when not to use it. The only additional usage-related note is the parameter constraint, which is not about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: each object carries a path, identification, and a short geometry/material summary, and that it avoids probing members individually. It does not disclose pagination behavior (limit/offset) beyond what the schema shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loads the core purpose in the first sentence. The second sentence adds necessary detail about the returned object contents. It is slightly dense but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with an output schema, the description is fairly complete: it explains the purpose, the primary output field (path), and the selection aid (summary). It does not explain pagination usage, but that is apparent from the schema. The tool is simple enough that this suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. It mentions 'one kind' without elaborating on the enum values, and it completely omits explanation of limit and offset. The schema's enum for 'kind' provides some meaning, but the description adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists model objects of one kind and provides each object's path for passing back as a reference. It specifies the resource (model objects) and the action (list), but does not explicitly distinguish from sibling tools like list_materials or list_phases beyond the generic 'model objects' phrasing.
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 saying the path is 'the exact string every reference parameter accepts' and that it gives enough info 'to pick the object you mean without probing members one at a time.' It provides a clear context (use for selecting objects) but does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal context beyond the purpose, but it does specify the PLAXIS domain, which is useful. No additional behavioral details (e.g., output behavior, error handling) are disclosed, but the bar is lower given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose without redundancy. It wastes no words and is appropriately concise for a simple 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?
For a tool with one optional parameter and an output schema, the description is partially complete. It provides the core purpose but omits details about path semantics and what 'inspect' returns (though the output schema covers return values). Given the simplicity and strong annotations, the description is adequate but has clear gaps in parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'path' with 0% description coverage. The description does not explain the format or expected values of 'path', only that the tool inspects a PLAXIS object or property, which implicitly suggests the path targets one. This is minimal compensation, relying heavily on the parameter name and leaving semantics incomplete.
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 inspects a PLAXIS object or property, using a specific verb and resource. It is distinct from sibling tools like list_objects (which lists all objects) and set_property (which modifies), as it targets a single object or property for examination.
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, such as list_objects or model_state. The description only states what the tool does, leaving the agent to infer usage context, which falls short of explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate safety aspects. The description adds the qualifier 'compact' and 'summary', hinting that the output is a condensed representation rather than full material details. However, it does not disclose other behavioral traits such as ordering, filtering, or handling of empty sets.
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 of six words: 'Return a compact material summary.' It is front-loaded with the purpose and contains no filler or redundant information, making it an excellent example of brevity.
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 the tool has no parameters, is marked read-only and idempotent, and has an output schema available, the description adequately covers the core purpose without needing to explain return values. The term 'summary' is slightly vague, but the output schema would clarify the exact shape, so the description is sufficiently complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100% and there is nothing to document. According to the rubric, a baseline of 4 applies when there are no parameters, and the description correctly requires no parameter details.
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 'Return a compact material summary' clearly identifies the verb (Return) and resource (material summary), and the tool name 'list_materials' reinforces this purpose. It is distinct from sibling list tools (list_members, list_phases, list_objects) by focusing specifically on materials, but it does not explicitly differentiate its behavior or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_objects or create_material, nor does it mention prerequisites or context. It is a minimal statement with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive traits, so the bar is lower. The description adds 'compact' and 'model-phase' but does not disclose additional behavioral details such as whether it returns all phases or only the current one, or whether a model must be open. It adds some context but not rich behavioral 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 a single, short sentence ('Return a compact model-phase summary.') with no redundant words or repetition. It is front-loaded and immediately gives the action and object. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters, a strong annotation set (readOnly, idempotent, non-destructive), and an output schema exists, the description is largely complete for a simple read-only list tool. The phrase 'compact model-phase summary' is slightly ambiguous (e.g., does it list all phases or just a summary of the current one?), but the output schema likely clarifies the return shape, so the description is 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 schema coverage is 100% (vacuously). The description does not need to explain parameters. Baseline for zero-parameter tools is 4, and the description adds no confusion around parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Return') and resource ('compact model-phase summary'), which distinguishes it from mutation tools like create_phase and set_current_phase. However, it does not explicitly differentiate from other list tools (e.g., list_members, list_objects) beyond the resource name, so it's a bit below a perfect score.
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. There is no mention of when to select list_phases over list_members, list_objects, or model_state, nor any exclusions or prerequisites. The name implies the use case, but the description itself offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only behavior is clear. The description adds the specific output scope ('common project metadata and units') but does not disclose any other behavioral traits such as whether it returns live or cached data. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly worded sentence with no filler or redundancy. It fully states the purpose in a compact way, which is ideal for an agent to parse quickly.
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 read-only tool with no parameters and an output schema available, the description is adequate. It indicates the broad content ('project metadata and units') without excessive detail. While 'common' is somewhat vague, the output schema would fill in specifics, so this level is sufficient.
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, which sets a baseline of 4. There is nothing for the description to explain about inputs. The empty schema fully covers the parameter space, so the description is not required to add parameter-related information.
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 the tool 'Return common project metadata and units' with a clear verb and resource. It is specific enough to convey the basic purpose but does not distinguish it from similar sibling tools like inspect or model_state. It provides the core function without ambiguity.
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 guidance on when to use this tool versus alternatives. The description gives no context on prevalence, prerequisites, or exclusions. For a tool named project_info among many related tools, this lack of usage direction makes it harder to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the description adds no extra behavioral context. It does not mention whether unsaved changes are lost, whether confirmation is required, or what happens to the project state after closing. Given the destructive nature, more context would be valuable, but the description stays at a surface level.
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, well-formed sentence that delivers the core message without any filler. It is appropriately sized for a tool with no parameters and a simple action, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description is minimal and omits important context for a destructive operation. It does not indicate whether closing implies saving or discarding changes, nor does it describe any potential side effects or errors. The output schema exists but the description adds nothing about return values or preconditions, leaving the agent with limited understanding of the tool's full impact.
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 empty schema is fully covered, and there is no need for the description to explain parameters because none exist. The description correctly focuses on the action rather than parameter details.
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 action ('Close') on a specific resource ('the active PLAXIS project'), which distinguishes it from sibling tools like open_project, new_project, save_project, and recover_project. The use of 'active' also narrows the scope, leaving no ambiguity about what the tool operates on.
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: it should be used when the user wants to close the currently active project. However, it provides no explicit guidance on when not to use it or alternatives (e.g., save before closing, or recover a mistakenly closed project). The context is clear but lacks exclusions or comparison with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the annotations (read-only, idempotent, non-destructive) and adds minimal context by specifying the 'pinned PLAXIS role' as the scope. However, it doesn't explain what 'pinned' means or any side effects, though the annotations already cover safety.
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, focused sentence that directly states the tool's function with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, comprehensive annotations, and an output schema present, the description sufficiently conveys the tool's purpose. The phrase 'pinned PLAXIS role' is domain-specific but likely understood within context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description doesn't need to explain any. The baseline for zero parameters is 4, and the description doesn't introduce any parameter-related ambiguities.
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 uses a specific verb ('Get') and a specific resource ('state for the pinned PLAXIS role'), clearly indicating it retrieves connection state. However, it doesn't differentiate from siblings like 'inspect' or 'model_state', though the tool name itself is distinctive.
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 such as 'connect', 'disconnect', or 'inspect'. The description does not mention prerequisites, typical use cases, 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?
The description adds little beyond the annotations. Annotations already indicate a mutating operation (readOnlyHint=false) with a destructive hint, but the description does not clarify whether creating points overwrites existing data or is purely additive. It also omits side effects or return behavior, though output schema exists.
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 of eight words that front-loads the core action. It contains no redundant information or 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 tool's simplicity, one parameter, and the presence of an output schema and annotations, the description covers the core purpose adequately. The missing behavioral details are partially offset by annotations, and the brief nature is acceptable for this low-complexity operation.
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 only parameter, 'coordinates', has no schema description. The description compensates by explaining that the input is 'one or more points at [x, y] coordinates', conveying the structure of the array of number pairs, which is essential semantic content beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create', identifies the resource 'points', and defines the coordinate format [x, y]. This clearly differentiates it from sibling creation tools like create_line and create_polygon.
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 guidance on when to use this tool versus alternatives, no prerequisites, and no context about the active model or coordinate system. The description only states the action with no exclusions or 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, non-destructive operation. The description adds context about the input being a PLAXIS object path but doesn't disclose additional behavior such as whether methods are included or how results are structured. It adds modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, directly conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, an output schema, and strong annotations, the description is mostly complete. It clearly states what the tool lists and the scope (PLAXIS object path), though it doesn't explain what 'attributes' include. Overall adequate.
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 schema has 0% description coverage for the 'path' parameter, but the description specifies that the path refers to a PLAXIS object path, which gives the parameter meaning. However, it lacks examples, format details, or behavior when path is empty, 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.
Purpose4/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 identifies the resource as 'available attributes on a PLAXIS object path', clearly distinguishing it from sibling tools like list_objects which list objects. It could be more explicit that 'members' are attributes, but the phrase is sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'inspect' or other list_* tools. The implied use case is discovering available attributes for a given object path, but no exclusions or recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotent and non-destructive hints. The description adds no further behavioral context such as session invalidation or reconnection requirements, so transparency is adequate but not enhanced.
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 a clear verb and object, front-loaded and free of any wasted words. Perfectly concise for a simple no-argument tool.
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 zero-parameter tool with an output schema, the description sufficiently explains the core function. However, it lacks any detail on return value or post-condition, which would make it more 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 tool has zero parameters, so the description does not need to explain parameter semantics. The schema covers everything, and the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (disconnect) and the target resource (current PLAXIS worker session). It distinguishes itself from sibling tools like connect and connection_status by naming the exact opposite operation.
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, nor are any prerequisites or consequences mentioned. The description does not explain when disconnecting is appropriate or what happens after.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is mutating (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive (destructiveHint=false). The description adds minimal behavioral context beyond that: it confirms it operates on an existing phase and is intended for subsequent edits. It does not disclose side effects like what happens to the previously current phase or whether a valid phase name/ID is required.
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, well-structured sentence that front-loads the action and resource. Every word earns its place, with no redundancy or filler.
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 low complexity (one required parameter) and the presence of an output schema, the description is minimally adequate. However, the lack of parameter semantics and the absence of guidance on how to reference an existing phase make it incomplete for an agent to use confidently without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain how to specify the 'phase' parameter (e.g., by name, ID, or path). The schema only provides type string and minLength=1, which is insufficient for an agent to know what value to pass. The description's 'existing phase' is a hint but does not clarify the format or identifier expected.
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 'Make an existing phase the current phase for further edits' uses a specific verb ('make') and resource ('phase'), clearly distinguishing this from creating a new phase (create_phase) or setting a property (set_phase_property). The phrase 'existing phase' differentiates it from creation tools, and 'for further edits' clarifies its role.
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: this is used before making edits to set which phase is active. However, it does not explicitly mention alternatives or exclusions, such as 'use activate to enable a phase' or 'do not use this for creating phases.' The implied usage is reasonably clear but lacks 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?
Annotations already indicate destructiveHint=true, so the safety profile is known. The description adds behavioral nuance about the marked-for-calculation state and override logic, which is valuable. It does not elaborate on side effects like overwriting results, but given annotation coverage this is adequate.
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 two-sentence structure. The key action phrase is front-loaded, and the behavior is explained without unnecessary detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description covers the essential selection behavior. It lacks explicit prerequisites (e.g., open project, defined phases), but those are domain-implied. Overall, it is sufficiently complete for 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?
The description fully explains the only parameter 'phases' despite 0% schema coverage. It specifies both omit behavior (all marked-for-calculation phases) and provide behavior (exact list regardless of marked state). This exceeds the schema's minimal 'Phases' label.
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 uses a specific verb ('Calculate') and resource ('phases'), clearly stating the tool's core function. It distinguishes from siblings by focusing on phase calculation, though it does not explicitly reference alternative tools. The additional omit/provide detail clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to control which phases are calculated (omit vs provide), which is practical usage guidance. However, it does not mention when to prefer this tool over sibling tools or any prerequisites. The guidance is useful but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only, is open-world, is idempotent, and is non-destructive. The description adds the context of 'pinned local', which is a specific behavioral constraint, but does not disclose additional traits such as failure behavior when no endpoint is pinned. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately delivers the key information. There is zero wasted text, making it highly efficient and front-loaded.
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 zero-parameter tool with an output schema present, the description is largely complete. It conveys the essential target and action, but it could briefly mention that connecting is a prerequisite for many other operations or that a pinned endpoint must already exist, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema is fully covered and the baseline is 4. The description adds semantic context by clarifying that the tool targets a pre-configured 'pinned local' endpoint, which is helpful beyond the empty 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 'connect' and a clear resource 'pinned local PLAXIS endpoint', making the tool's purpose unambiguous. It distinguishes well from siblings like disconnect and connection_status, which serve adjacent but different functions.
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?
Usage is implied: to initiate a connection to the pinned local endpoint, but the description does not explicitly state when to use it versus alternatives or mention prerequisites like ensuring an endpoint is pinned. It lacks clear guidance on whether connection is required before other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true, readOnly=false, and idempotent=false. The description adds context about the tool's limitation (only add-to-existing-line form) and a prerequisite (create the line first), but does not elaborate on specific side effects or what is destroyed. This goes slightly beyond annotations but not comprehensively.
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. The first sentence states the primary purpose, and the second provides a critical limitation and instruction. Every sentence 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 description gives the core purpose and usage constraint, with annotations covering safety profile and an output schema present. However, the absence of parameter explanations (especially 'kind') leaves gaps in understanding a 2-parameter tool. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. It mentions 'existing lines' which hints that 'paths' refers to line paths, but it does not explain the 'kind' enum values or clarify the format of 'paths'. The description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Add a structural element feature to one or more existing lines.' It distinguishes itself from sibling create_* tools by targeting structural elements on existing lines, and explicitly notes that creating new lines inline is not supported, differentiating from create_line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: only the add-to-existing-line form is implemented, and 'Create the line first with create_line.' This tells the agent when to use this tool (after lines exist) and when not to (for inline line creation), and points to the correct alternative 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?
Annotations already indicate readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds that the operation is phase-scoped, which is useful context, but doesn't disclose additional behavioral details like whether the phase must exist or what happens on failure. Thus a moderate score.
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 the main action front-loaded and the contrast as a second sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the core operation and a key distinction from set_property, and an output schema exists to cover return values. However, with 4 required parameters and no schema descriptions, the description leaves parameter semantics under-specified for a complete invocation. Moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the four parameters. It only mentions 'property' and 'phase' implicitly via 'Set a property... for one specific phase only', but does not explain 'path' (object reference) or 'value' (new value type/format). Therefore it adds minimal parameter semantics.
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 'Set' with a clear resource 'property of an object' and scoping 'one specific phase only'. It explicitly names the sibling 'set_property' and contrasts the phase-scoped behavior, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly distinguishes this from set_property, saying 'distinct from set_property, which changes a property without phase scoping.' This tells the agent when to use this tool (when phase scoping is needed) and when not to (when not phase-scoped).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds value by explaining the InitialPhase convention and relative positioning. It doesn't expand on what destructive means, but the annotation covers that baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action, and every sentence adds value. 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?
Given the simple tool (2 params, output schema exists), the description is sufficiently complete. It explains the crucial InitialPhase usage pattern. Minor gap: does not explain position effects, but schema enum covers options.
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%, and the description only references reference_phase via an example. The position parameter is not explained, though the schema's enum and default provide some self-documentation. Description partially compensates for low 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 'Create a new phase relative to an existing one' with a specific verb and resource. It also distinguishes from sibling creation tools by focusing on phases and references 'InitialPhase'.
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 context for the typical first-phase scenario using reference_phase='InitialPhase', but does not mention exclusion criteria or alternative tools. This gives clear context without explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond annotations by explaining that arguments must be scalar literals and that string arguments are sent as quoted text literals, not references. This clarifies a common pitfall. The annotations already indicate destructive=true and readOnly=false, so the safety profile is covered, but the literal-reference distinction is a valuable addition.
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 and information-dense. The first sentence states the core purpose, the second explains a critical constraint, and the third gives usage guidance. Every sentence provides value, 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?
Given the tool's generic nature and the existence of an output schema, the description covers the essential context: when to use it, argument limitations, and preferable alternatives. The only notable gap is the unexplained 'path' parameter, which reduces completeness slightly. Overall, it is sufficient for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'method' and 'args' semantics (literals, positional), but 'path' is never mentioned or defined. This leaves the path parameter ambiguous, and since the schema provides no descriptions either, the agent cannot infer the correct usage for this parameter.
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: 'Call an explicitly named PLAXIS method with literal positional arguments.' It uses a specific verb (call) and resource (PLAXIS method), and distinguishes itself from siblings by directing users to prefer list_objects, model_state, and first-class tools for exploration.
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 usage guidance is provided: 'Use this only for methods whose PLAXIS command reference shows purely literal parameters; prefer list_objects, model_state, and the first-class tools over probing with dump.' This tells the agent when to use the tool and what alternatives to prefer, giving clear contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals the operation is not read-only. The description adds specific behavioral context by explaining how relative paths resolve against the working directory and that the result returns the resolved absolute path, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the primary action, and uses a second sentence to clarify path behavior. Every sentence contributes meaningful information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an existing output schema, the description covers the core behavior, path resolution, and the output. It doesn't address side effects like replacing the current project, but the destructiveHint annotation covers the general safety profile, making this description adequate for effective use.
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 single parameter 'filename' is only minimally described in the schema (type string, minLength 1). The description thoroughly explains the semantics: absolute path used as-is, bare filename resolves against working directory, and the result reports the resolved path. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource statement ('Open a PLAXIS project') and elaborates on path resolution, making the tool's function unambiguous. It stands apart from siblings like new_project, close_project, and recover_project because 'open' is clearly distinct in this context.
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 operational details about how absolute vs relative paths are handled, which guides the user on correct invocation. However, it does not explicitly state when to prefer this over new_project or recover_project, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior context beyond the destructiveHint annotation: it clarifies that vertices can be coordinates or paths of existing points, and that the angle/relative/vector sub-command is not supported. This provides useful behavioral detail without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tightly written sentences. The first front-loads the core purpose, the second explains the vertex structure, the third states a limitation. No filler 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 single-parameter creation tool with an existing output schema, the description covers the main functionality, vertex format, and limitations. Minor gaps exist around the exact string path syntax and any coordinate system details, but overall it is sufficiently complete for correct tool selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the 'vertices' parameter: each vertex is either an [x, y] coordinate or the path of an existing point. It still leaves some ambiguity about the string path format, but adds substantial meaning over 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 states a specific verb ('Create') and resource ('a line, or a polyline'), clearly distinguishing it from sibling tools like create_point and create_polygon. It also clarifies the vertex count requirement, giving precise scope.
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 clearly states the tool is for creating lines/polylines and explicitly notes that only the vertex-list form is implemented, indicating a when-not use case. However, it does not name alternative tools for the non-implemented sub-command forms, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description does not contradict that. It adds valuable behavioral context beyond annotations: property names are validated against PLAXIS 2D V22 and are case-sensitive, and 'Identification' renames the material's path for all future operations.
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 purpose and then provides necessary detail. Some redundancy exists between the parenthetical example and the later sentence about PLAXIS property names, but overall it is compact and information-dense.
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 2-parameter tool with an output schema, this description covers all the necessary usage context: placeholder vs. fully specified creation, property name validation, case-sensitivity, and the 'Identification' renaming side-effect that affects future calls. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates well: it explains the 'properties' parameter shape, acceptable value types, name matching, case sensitivity, and the special 'Identification' behavior. The 'kind' parameter is left to the schema enum, which is sufficient given its simplicity.
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 'Create a material set' and clearly distinguishes creation from usage by explaining placeholder versus usable materials. It also ties to sibling tools by noting that later calls like assign_material must use the resulting path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance on when to omit properties vs. provide a full property map, and explains the consequence of using 'Identification' for later calls. It does not explicitly mention alternative tools, but the context strongly implies this is the material creation step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description does not need to belabor mutability. It adds valuable insight beyond annotations by warning that setting Identification renames the object, which invalidates the path for subsequent calls. This goes beyond what the structured metadata conveys.
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 primary action, and each subsequent sentence adds essential caveat detail. No filler words or redundant content. It reads cleanly and efficiently.
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 setter tool with two parameters, relevant annotations, and an output schema, the description covers the key semantic differences versus siblings and the main usage pitfall. It could improve by explicitly noting that only scalar values are accepted or by giving a minimal example path, but the existing warning about renaming and materials meets most contextual needs.
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 schema refers to path and value, with value already described as a scalar and reference guidance. The description adds that path is a dotted path and that material references are not valid via this tool, which partially compensates for the path property's missing schema description. However, it does not fully specify path structuring or property naming conventions, leaving some ambiguity.
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 tool sets a writable PLAXIS property via a dotted path. It explicitly distinguishes itself from the assign_material sibling, calling out the material reference scenario and directing users to the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-not-to-use guidance for material references, explicitly naming assign_material as the correct alternative. It also flags the path-changing consequence of setting Identification, giving the user a critical context for avoiding future errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, but the description adds context beyond that by specifying accepted vertex forms and noting the unimplemented polycurve variant. It does not contradict annotations, though it omits details about return behavior 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 concise, using two sentences to convey the core purpose, input format, and a key limitation. It is front-loaded with the action and resource, earning every word.
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 one-parameter tool with an output schema and annotations, the description sufficiently covers the input format, minimum count (3 vertices), and a major limitation. 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?
With schema description coverage at 0%, the description compensates by explaining that each vertex is either an [x, y] coordinate or a path to an existing point. This adds meaningful meaning to the 'vertices' parameter beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a polygon from 3 or more vertices.' It specifies the resource (polygon) and the required input (vertices), distinguishing it from sibling tools like create_point and create_line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating polygons and excludes scenarios by stating 'Only the vertex-list form is implemented; the polycurve-based form is not.' This provides a clear limitation, though it does not explicitly name alternative tools for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's 'Read-only' is redundant. However, it goes beyond annotations by explaining the return contents (mesh status, phase flags, unassigned material features) and the crucial distinction between 'blocking' and 'unknown' – preventing a false sense of safety. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose, then adds necessary detail in a compact, layered manner. Every sentence contributes: the 'blocking'/'unknown' explanation is essential for correct interpretation. No wasted words or redundancy beyond the harmless 'Read-only' repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an output schema, and strong annotations, the description covers all necessary context: what it returns (mesh, phases, unassigned features), what 'blocking' means, and the critical 'unknown' caveat. An agent can safely invoke this tool and interpret results without further documentation.
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 100% coverage (vacuously). The description correctly focuses on behavior rather than parameter syntax, which is appropriate. Baseline for 0 params is 4, and nothing in the description detracts from that.
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: 'Report whether the model can be calculated, and what is stopping it.' This clearly distinguishes it from siblings like 'calculate' (which performs the calculation) and 'view_results' (which shows outcomes). The scope 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use as a pre-calculation check ('what is stopping it' before a calculate call) and provides clear context for when to invoke it. It does not name specific alternatives or explicitly say 'when not to use', but the intended context is evident from the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a concrete behavioral constraint: force_new_intersection is rejected for certain modes. Annotations already cover idempotency and non-read-only, so the description adds value by explaining the parameter rejection, though it doesn't describe other side effects of switching modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the core purpose, the second adds a critical constraint. No filler, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mode-switching tool with a clear schema and an output schema, the description covers the essential behavior and the one non-obvious parameter constraint. It doesn't need to explain return values due to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds significant meaning to force_new_intersection by specifying valid modes and rejection behavior. The mode parameter is self-explanatory via its enum, so the description effectively compensates for the lack of coverage on the only ambiguous parameter.
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 'Switch' and clearly identifies the resource as 'the PLAXIS Input working mode,' which distinguishes this tool from sibling tools like set_property or calculate. It also hints at scope with the mode restriction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that force_new_intersection is only meaningful for mesh, water, or stages modes and is rejected for soil or structures, providing a clear conditional guideline. However, it does not discuss alternatives or when to use this tool versus other setter tools, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: it explains the Output application's state-dependent behavior, the absence of open_project in the Output role, and the prerequisite that the phase must be calculated. It does not contradict annotations (readOnlyHint=false, idempotentHint=true) and coherently describes an open/state-changing 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?
Three sentences, no filler. The first sentence states the action, the second gives architectural rationale, and the third provides a clear usage directive. Every sentence adds value and the description is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full workflow: prerequisite (calculated phase), the state of the Output application, and next steps (read results through Output server). With an output schema present, the description does not need to explain return values. This is complete for a single-parameter tool with strong annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'phase' with no description (0% coverage). The description partially compensates by stating the phase must have status 'calculated', but it does not clarify the expected format (e.g., ID vs name) or how to obtain it. Given the minimal schema, some additional parameter detail would be expected.
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 ('Open') and resource ('a calculated phase in the PLAXIS Output application'). It clearly distinguishes itself from siblings by noting it is 'the only route from a calculated Input model to the Output endpoint's results', differentiating it from open_project and calculate.
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 provided: 'Call this for a phase whose status is "calculated"'. It also explains the architectural context (Output role has no open_project) and gives a sequential instruction ('then read results through the Output server'). This clearly tells the agent when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true), the description discloses important behavioral details: relative filenames resolve against the session's working directory rather than PLAXIS's own directory, and the result reports the resolved absolute path. This adds operational context not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, each earning its place. The first states the primary purpose, the second covers the omission case, the third clarifies path resolution, and the fourth states the output. No redundancy or filler.
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 one-parameter tool with an output schema present, the description is complete. It covers all essential behaviors: when to omit the filename, how paths are interpreted, and what the result reports. No other aspects (e.g., error cases) are needed for this simple operation.
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 a nullable string with default null, and schema description coverage is 0%. The description fully compensates by explaining that omitting filename saves in place, while providing a filename saves to a specified path, including the crucial distinction between absolute and relative paths and their resolution behavior.
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 active project' with an optional new path, using a specific verb and resource. This distinguishes it from sibling project tools like new_project, open_project, and close_project, which are about creation/opening/closing rather than saving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two usage modes (in-place save when filename is omitted, save to a new path when provided) and clarifies how relative paths are resolved. While it doesn't explicitly name alternatives or exclusions, the context is clear and prevents common mistakes about working directories.
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:

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

Score Badge

Copy to your README.md:

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

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