Kratos MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation5/5
Each tool targets a distinct resource and action, from environment setup, entity listing, case creation, modification, validation, simulation running, job management, to result analysis and graph conversion. Even closely related tools like list_templates and create_project_parameters have clear boundaries, and no two tools appear to do the same thing.
Naming Consistency3/5
The naming is readable but mixed: many tools use kratos_verb_noun (e.g., kratos_list_applications), while others drop the prefix (list_templates, create_project_parameters) and several use noun_verb (mdpa_inspect, job_status, results_list). This inconsistency across groups reduces coherence, though the pattern is somewhat predictable within each group.
Tool Count2/5
With 40 tools, the server exceeds the rubric's 'too many' threshold of 25+. While the broad Kratos multiphysics domain justifies a large surface, the sheer number feels heavy and could overwhelm agents, even though each tool earns its place.
Completeness4/5
The tool surface covers the full simulation lifecycle: installation, environment introspection, case scaffolding, parameter modification, validation, mesh generation, running simulations, job monitoring, results extraction, and Flowgraph conversion. Minor gaps exist, such as the lack of a tool to remove or update existing boundary conditions in a ProjectParameters.json, but these are workaroundable by regenerating or editing files directly.
Average 4.2/5 across 40 of 40 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 37 commits in the last 12 weeks
- Last stable release on August 7, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses important behaviors, such as which parameters are required per format (e.g., 'vtk' needs output_path, 'point' needs position and output_file) and the default for variables. However, it does not describe return values, side effects on the file, or error conditions, so transparency is only partially addressed.
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 and front-loaded with the purpose. It efficiently packs format-specific requirements and defaults into a single, readable passage. The only minor issue is the slightly run-on phrasing, but it remains clear and unscattered.
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 7 parameters, no annotations, and an output schema, the description is reasonably complete: it covers the core formats and required inputs, and notes the default for variables. Yet it leaves 'model_part' unexplained and does not address how the output schema might influence expected return values, so the overall context falls short of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the meaning of several parameters (format, output_path, output_file, position, variables) and ties them to specific formats. However, it omits any explanation for 'model_part' and does not explicitly state that 'parameters_file' is the target file path, leaving some parameters underspecified.
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: 'Add an output process to a ProjectParameters.json.' It uses a specific verb ('add') and resource ('output process'), and enumerates supported formats with their distinct characteristics. This effectively distinguishes it from sibling tools like 'add_boundary_condition' by focusing on output configuration.
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 clear context about when to use the tool (to add an output process to a ProjectParameters.json) and explains format-specific requirements. However, it does not mention any alternatives or explicitly state when not to use this tool, leaving the user to infer distinctions from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It explains that the tool lists known solver_type values per analysis type and also scans for *_solver.py modules, which is informative. However, it does not disclose the effect of the optional analysis_type parameter (whether it filters results) or what happens when it is null, leaving a transparency gap.
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 sentence that packs a lot of information: it lists the analysis types, the pairing with Python modules, and the additional scan for all *_solver.py files. It is front-loaded with the core action and avoids unnecessary words, but the sentence is somewhat long and could be split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description conveys the main output: solver_type per analysis type and modules found. However, it fails to explain the role of the analysis_type parameter, which is a critical part of using the tool correctly. Given the output schema exists, return values are covered, but the missing parameter behavior leaves the description incomplete for a robust understanding.
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 input schema has one optional parameter (analysis_type) with 0% description coverage. The tool description does not mention this parameter at all, nor does it clarify whether providing an analysis_type filters the listing or how the default null behaves. This leaves the parameter's semantics unexplained, requiring the agent to infer from the tool name and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource: solver_type values per analysis type (structural, thermal, fluid, potential_flow), plus Python modules. This distinguishes it from sibling list tools like kratos_list_elements or kratos_list_variables, which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that this tool is for enumerating known solver types and their implementing modules, giving the agent enough context to select it when needing solver information. However, it does not explicitly mention when not to use it or point to alternatives, so a small deduction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the demo mesh is wired to template defaults so the case runs out of the box, and that it returns created file paths and next steps. However, it does not mention potential side effects such as overwriting an existing directory or whether the operation is limited to an empty directory, leaving a transparency gap for a file-creating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no filler. Every clause adds value: the file types created, the optional demo mesh behavior, and the return value. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (5 params, no annotations, output schema present). The description covers the main artifacts, the demo mesh option, and the return format, but omits guidance on how 'overrides' works or how to choose a template (e.g., referencing list_templates). It is adequate but not fully complete for a scaffolding tool.
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 only clarifies two parameters: 'template' implicitly (from a template) and 'create_demo_mesh' explicitly (optional demo mesh). It does not explain 'overrides' (a complex customization parameter), 'directory', or 'name', leaving three of five parameters largely undocumented.
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 ('Scaffold') and a specific resource ('complete Kratos case directory'), and explicitly names the files created (ProjectParameters.json + Materials.json). This clearly distinguishes it from sibling tools like create_project_parameters or create_materials, which focus on individual files.
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 context is clear: use this when you want a complete, runnable case from a template. It implies a higher-level alternative to the more granular sibling tools, though it does not explicitly name alternatives or say when NOT to use it. The optional demo mesh detail also signals the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation by using 'List' and gives examples, but it does not explicitly mention absence of side effects, error behavior, or any special constraints. For a simple listing tool, the description adds some clarity but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that includes purpose, examples, and a filter reference. Every clause adds value and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The existence of an output schema covers return values, and the low complexity of a list tool reduces informational needs. However, the lack of parameter semantics leaves a notable gap in the overall context. The reference to kratos_list_elements partially mitigates this, but the description is not fully self-sufficient.
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 by explaining the parameters. It only says 'optional filters' without detailing what the 'application' and 'name_filter' parameters do or which filters are supported. The reference to kratos_list_elements is indirect and does not make up for the lack of explicit 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 clearly states the action ('List'), the specific resource ('constitutive law names registered in Kratos'), and provides concrete examples (LinearElastic3DLaw, Newtonian2DLaw). It distinguishes itself from sibling tools like kratos_list_elements by targeting constitutive laws specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with optional filters as in kratos_list_elements' explicitly references a sibling tool to indicate how filters are used, providing clear contextual usage. It implies this tool is for constitutive laws and that filter behavior matches an existing pattern, though it doesn't formally contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation by using 'Check' and 'report', and specifies what information is returned. However, it does not explicitly address side effects, error behavior, or system requirements beyond the basic check. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the main purpose ('Check that Kratos Multiphysics is available') and lists the key outputs. No unnecessary words are included, and it is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description provides sufficient context for an agent to understand its function. It covers what the tool checks and reports, and since there are no parameters or complex side effects, no additional detail is necessary. The presence of an output schema means return values need not be spelled out.
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 takes zero parameters, so the baseline is 4. The description adds value by describing what the tool reports (version, paths, thread count, compiled applications), which clarifies the output semantics beyond the empty schema. It does not need to explain parameters because there are none.
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 names a specific verb ('Check') and resource ('Kratos Multiphysics'), and clearly lists what it reports (version, paths, thread count, compiled applications). This distinguishes it from siblings like kratos_list_applications by focusing on installation availability rather than just listing.
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. There is no mention of prerequisites, follow-up actions, or why an agent would choose this over kratos_install or kratos_list_applications. The description only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what the output will include (descriptions, required applications, placeholder defaults), which is helpful. However, it does not explicitly state that the operation is read-only or free of side effects, though 'list' strongly implies it. More explicit safety disclosure would improve the 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 a single concise sentence that is front-loaded with the primary action and resource. It includes useful examples without unnecessary elaboration, and every word contributes to understanding.
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 tool with no parameters and an existing output schema, the description fully covers the purpose and the nature of the returned data. It mentions the types of templates and the information provided with each, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it correctly adds context about what is listed. No deficiencies in parameter documentation are present.
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 specifies the tool's action ('List') and resource ('available case templates'), and provides concrete examples of template types (structural_static, thermal_transient, fluid_transient). This distinguishes it from sibling list tools that target different entities (applications, elements, etc.).
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. It does not mention typical use cases (e.g., before creating a project) or when not to use it, nor does it reference sibling tools. The usage context is only implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It explicitly mentions the SIGTERM signal escalating to SIGKILL after a grace period, giving insight into the termination process. However, it does not discuss side effects such as partial results or reversibility, which are relevant for a cancellation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and the target. It provides essential behavioral detail (signal escalation) with no wasteful words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter cancellation tool, the description covers the core action and the signal escalation behavior. It does not explain the return value or error handling, but the output schema exists and the operation is straightforward. The sibling tools provide enough context for an agent to understand its role.
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?
There is only one parameter, job_id, and its meaning is clear from the schema property title 'Job Id'. The description does not explicitly elaborate on the parameter, but the tool's purpose makes it obvious that job_id identifies the job to cancel. Since schema coverage is 0%, the description adds no explicit compensation, but the parameter is self-explanatory.
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 'Cancel' and clearly identifies the resource as 'running simulation job'. This distinguishes it from sibling tools like job_status, job_list, and job_logs, which serve different purposes in the job lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for stopping a running simulation job, but it does not explicitly state when to use it versus alternatives or mention any exclusions. There is no guidance on what to do if the job is not running or whether other tools like job_status should be used first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds useful behavioral details like case-insensitivity of the grep filter and the meaning of 'tail' lines, but does not mention side effects, permissions, or error behavior. As a read-only log tool, this is adequate but not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the primary action and all key information. There is zero waste, and every clause adds value.
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 log-retrieval tool, the description covers the core functionality effectively. An output schema exists, so not describing return structure is acceptable. It does not mention edge cases like invalid job IDs or very large logs, but these are secondary for such a straightforward 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?
Despite the schema having 0% description coverage, the description explains the purpose of 'tail' (number of lines) and 'grep' (case-insensitive substring) in context. It does not explicitly mention job_id, but its purpose is obvious from the tool's name, and the schema marks it as required. This adds meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return'), identifies the resource ('job's simulation log'), and specifies the tail and grep behavior. It clearly distinguishes itself from sibling tools like job_status and job_cancel by focusing on log content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting recent log lines, but does not explicitly state when to use this over alternatives like job_status or results_* tools. There are no exclusions or alternative tool references, so it relies on the reader to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool inspects the source tree and reports compiled status, but it does not explicitly state that the operation is non-mutating or mention any prerequisites (e.g., a valid source tree). This is acceptable for a list operation but lacks explicit safety/behavioral notes.
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 main action ('List all Kratos applications') and then adds a useful qualifier. Every word contributes meaning; there is no redundancy or unnecessary detail.
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 simplicity of the tool (no parameters) and the presence of an output schema, the description is quite complete. It explains both the scope (source tree) and the distinguishing behavior (compiled flag). It could possibly add a note about typical invocation scenarios, but overall it 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, so the baseline is 4. The description adds no parameter-level detail, but none is needed since the schema is already complete with 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing all Kratos applications found in the source tree. It also adds a distinctive detail—flagging which ones are compiled/importable—which differentiates it from sibling tools that list elements, variables, or solvers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to see available Kratos applications and their build status) but does not explicitly state when to prefer it over alternatives or provide any exclusion criteria. This is adequate but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavioral traits. The verb 'List' strongly implies a read-only operation, but the description does not explicitly confirm safety, state side effects (if any), or mention output format/pagination. It adds the filter availability but lacks detail on edge cases or permissions. For a simple listing tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main purpose, and includes only essential clarifying details. Every word earns its place; there is no fluff or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return values. It provides the resource type, the category of conditions, and the presence of filters. Given the simple nature of a list operation and the reference to sibling behavior, the description is complete enough for an agent to decide whether to invoke and understand the gist of what it returns.
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 mentions 'optional filters' and references the sibling tool for filter semantics, which adds some meaning. The parameter names 'application' and 'name_filter' are self-explanatory in the schema, but the description does not explicitly explain their allowed values or how they interact. The reference to kratos_list_elements is a helpful pointer, but not a full explanation.
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 lists condition type names registered in Kratos, with a specific scope (surface/line/point conditions used for loads and boundary terms). The verb 'List' and resource 'condition type names' are specific, and the parenthetical adds useful context. It distinguishes from the sibling kratos_list_elements by the resource type, even though it references the sibling for filter behavior.
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 when to use this tool: when you need to enumerate condition types. The phrase 'optional filters as in kratos_list_elements' provides a pointer to sibling tool behavior, which is useful guidance. However, it does not explicitly state exclusions or alternative tools for other use cases, though the resource type itself makes the primary use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the truncation behavior and the limit mechanism, which is useful. However, it does not mention side effects (e.g., read-only nature), error handling, or behavior when both sub_model_part and node_ids are provided, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and then lists key options. Every phrase adds value and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values are covered externally. The description explains input parameters and optional filters, which is adequate for a read tool. It could note the interaction between sub_model_part and node_ids, but this is a minor gap. Overall, it is sufficiently complete for an AI agent to invoke the tool effectively.
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 description coverage is 0%, so the description must compensate. It clearly explains sub_model_part (dotted path examples), node_ids (explicit id list), and limit, but does not elaborate on 'path' (though it's inherently understood from context). This provides meaningful meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returning node ids and coordinates from a .mdpa file. It further specifies optional filtering by submodelpart or explicit id list and a limit with truncation flag, making it distinct from sibling tools like mdpa_inspect or mdpa_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case (extracting nodes from an mdpa file) but provides no explicit guidance on when to prefer this tool over alternatives like mdpa_inspect, nor does it state exclusions or prerequisites. The context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature implicitly with 'Inspect' and lists the output details, but does not explicitly state that no modifications are made, nor does it mention potential side effects, prerequisites, or error behavior. This is adequate but not rich.
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 front-loads the action and resource, then lists the delivered information compactly. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, read-only) and the description lists all key outputs. An output schema exists, so return values need not be detailed further. It is complete for practical use, though it could mention error handling or file access requirements, but those are not essential given the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter 'path' with 0% description coverage. The description compensates by stating it inspects a '.mdpa mesh file', making clear that 'path' refers to the mesh file location. This adds meaning beyond the bare schema and is sufficient for a single, self-explanatory 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 starts with the specific verb 'Inspect' and clearly identifies the resource as a 'Kratos .mdpa mesh file'. It enumerates exactly what information is provided (node/element/condition counts, bounding box, property ids, SubModelPart tree), which distinguishes it from sibling tools like mdpa_validate or mdpa_get_nodes.
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 through the verb 'Inspect' and the listed outputs, but does not explicitly state when to use this tool versus alternatives such as mdpa_validate or mdpa_get_nodes. There are no exclusion criteria or alternative guidance, so it relies on the user inferring the tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it does well: it discloses the specific validation checks and the deep=true behavior of round-tripping through Kratos ModelPartIO. It does not state side effects, but validation implies read-only, and the output schema covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by a clear mode distinction. Every word earns its place, with no redundant 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?
The description covers the main functionality and the deep-mode option, and the presence of an output schema handles return values. It could mention prerequisites for deep mode (Kratos installation), but the 'real Kratos ModelPartIO' phrase implies this. Overall, it's complete for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the deep parameter clearly (round-trip through real Kratos), while path is self-explanatory as the .mdpa file path. It adds meaning beyond the raw schema but could be more explicit about path format.
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 validates .mdpa files and lists specific checks (dangling references, empty submodelparts). This distinguishes it from siblings like validate_project_parameters and mdpa_inspect by focusing on MDPA file integrity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (validating .mdpa files, optionally in deep mode) and hints at a lightweight use case with 'pure-Python lint'. However, it does not explicitly state when to choose this over alternatives or mention 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?
No annotations are provided, so the description carries the full burden. It explains the two input modes and the extracted metrics, but omits important behavioral details such as whether at least one parameter is required, what happens if both are provided, and error conditions. For a read-only tool this is acceptable but not fully transparent.
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 that efficiently conveys the verb, resource, input alternatives, and output details. It is front-loaded with 'Extract' and contains no filler, earning a perfect score.
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 (two optional parameters, no annotations, and an output schema), the description covers the main functionality and output components well. The only notable gap is the lack of clarification about parameter requirements or precedence, but overall it provides enough context for an agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does clarify that job_id refers to a job identifier and log_file to a log file path, adding meaning beyond the schema's bare property names. However, it leaves ambiguity about whether one is required and how the two parameters interact, only partially compensating.
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 'Extract' with a clear resource 'convergence information from a simulation log' and lists specific outputs (per-step nonlinear iteration counts, residual ratios, convergence status). This distinguishes it well from sibling results_* tools like results_summary or results_probe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when convergence information from a simulation log is needed. It mentions the two invocation modes (job_id or log_file), but does not explicitly contrast with alternatives or state when not to use it. Still, the specificity makes the use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses recursive search behavior and sorting by name for timestep ordering, which adds useful context beyond the schema. It does not mention error conditions or empty results, but the output schema likely covers the return format.
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, compact sentence that front-loads the action ('Discover result artifacts'), lists specific file types, and includes key behavioral details (recursive, sorted). No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and an output schema, the description is reasonably complete. It specifies the scope (case directory), the object types, and sorting behavior. It does not describe edge cases or usage constraints, but these are less critical given the tool's simplicity and presence of an output schema.
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 only parameter case_dir is implicitly referenced by 'in a case directory', but the description does not explicitly map the parameter or explain its format (e.g., absolute path, directory existence). With 0% schema coverage, the description provides minimal compensation, though the parameter name and title offer some clarity.
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: discovering result artifacts in a case directory. It enumerates specific file types (VTK/VTU, GiD post files, HDF5, JSON, .dat/.csv), which distinguishes it from sibling result tools like results_probe or results_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the listing nature of the tool, but there is no explicit guidance on when to use this tool versus alternatives such as results_probe or results_summary. It lacks exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the two selection modes and that actual coordinates are returned, acknowledging approximation. However, it omits behavior for conflicting or missing point/node_index inputs, and does not mention error handling or precedence, leaving behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and followed by the two selection modes and return value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the primary functionality and return value. Minor gaps remain regarding parameter constraints and error cases, but the presence of an output schema reduces the need to detail return structure.
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 clearly explains 'point' and 'node_index' by defining selection modes. However, 'file' and 'variable' are left implicit, and the expected interplay between optional parameters (whether exactly one must be provided) is not specified.
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 reads a variable's value at a specific location, distinguishing it from overview tools like results_summary and rendering tools like results_render. It specifies the exact mechanism (nearest point or node index), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'at one location' clearly implies this tool is for single-point probing, distinct from broader result exploration tools. However, it does not explicitly mention alternatives or when not to use it, leaving some room for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It clearly indicates that the tool modifies an existing JSON file by inserting a block, and it goes further by explaining that load types using modulus+direction behave differently from those using a value. It omits some details like validation behavior or error handling, but the core side effects are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the main action stated first followed by a necessary list of kinds and a clear distinction between parameter usage. Every sentence carries useful information, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (8 parameters, no annotations, no schema descriptions), the description provides a solid overview but remains incomplete. It covers kind selection and value/modulus semantics, yet omits important usage details for interval, process_list, model_part, and parameters_file. The presence of an output schema reduces the need to explain return values, but the missing parameter guidance still creates gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantic information beyond the bare schema by enumerating valid 'kind' values and explaining when to use 'modulus'+'direction' versus 'value'. However, it leaves several parameters unexplained—including interval, process_list, model_part, and parameters_file—and the schema itself has no descriptions, so the agent must rely on parameter names alone for those.
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 ('Insert') and the resource ('boundary condition / load process block into an existing ProjectParameters.json'), which distinguishes it from sibling tools like create_project_parameters or add_output_process. It further enumerates the supported kinds, making the tool's scope very specific and identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by specifying that the insertion targets an existing ProjectParameters.json, implying it is for modifying already-created project files rather than creating new ones. However, it does not explicitly name alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses installation time, download size, immediate importability, and platform limitations. It does not mention what happens if an existing installation is present or overwritten, but it covers the key behavioral aspects beyond the bare action.
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 several sentences long but each sentence adds distinct value, from the core install action to platform caveats to post-install behavior. It is front-loaded with the main purpose and avoids unnecessary filler, though it could be trimmed slightly without losing essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (platform constraints, package options, time/resource implications) and the presence of an output schema, the description provides strong contextual coverage: it tells the user what to expect during install, which platforms are supported, and that no restart is needed. The only gap is the undocumented 'upgrade' param and a lack of explicit return-value details, but the output schema partially covers the latter.
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 explain the parameters. It thoroughly explains 'applications' with examples and 'all' as a switch to the omnibus package, but it does not explain the 'upgrade' parameter at all. This leaves one of three parameters ambiguous, so the description only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Install Kratos Multiphysics via pip into this server's own Python environment'. It clearly distinguishes this from sibling tools like kratos_check_installation and kratos_list_applications by describing an installation action with a defined target environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool, including platform constraints (macOS requires a local build) and a preference for naming only needed applications to avoid large downloads. It does not explicitly name alternatives, but the guidance about when not to use it (macOS) and when to use the 'all' option is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains that the simulation runs as a background job, how analysis class is resolved (from analysis_stage, solver_type, analysis_type, or analysis_class), and that wait_seconds causes polling with a possible final status return. This gives meaningful insight beyond a simple 'run simulation', though it omits error handling or side-effect details.
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 sentences, front-loaded with the core purpose and return value. It packs resolution logic, polling behavior, and follow-up tool guidance into a compact, well-structured paragraph with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow and references job_status/job_logs for tracking, and an output schema exists to document return values. However, it omits any mention of the required case_dir parameter and does not state prerequisites such as a validated case or existing project parameters, which are relevant for a complex simulation-launching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the semantics of analysis_type, analysis_class, and wait_seconds, but does not mention the required case_dir or the parameters_file parameter. Since schema coverage is 0% and the schema itself provides only titles/defaults, the description partially compensates but leaves the most important parameter (case_dir) and the input file unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Start a Kratos simulation as a background job and return its job_id', clearly identifying the action and output. It also distinguishes from sibling tools by directing 'Track progress with job_status/job_logs', making it unambiguous what this tool does relative to others.
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 conditional guidance such as 'If wait_seconds > 0, poll up to that long' and explains how to override analysis selection. It points to job_status/job_logs for subsequent tracking, implying when to use those instead. However, it does not explicitly contrast with validation tools like validate_case or list when NOT to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It details the specific checks performed, including file existence verification and comparison against solver defaults, and the conditional deep behavior. It does not state whether the tool is read-only or what happens on failure, but the listed behaviors give a solid picture for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently packs multiple validation aspects without unnecessary words. It is front-loaded with the core purpose, but the long enumeration of checks could be slightly better structured (e.g., using a list). Overall, it is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters and an output schema exists, the description provides a complete picture of the tool's scope and behavior. It covers the main validation steps, prerequisites for deep validation, and the target file. It does not need to explain return values due to the output schema. The only minor gap is the lack of explicit usage guidance, already captured in dimension 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the 'deep' parameter explicitly ('(deep=true, needs Kratos)') and implies 'parameters_file' as the ProjectParameters.json to validate. This provides sufficient semantic meaning for both parameters, though the file parameter could be more explicitly linked.
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 identifies the verb (Validate) and the resource (ProjectParameters.json), and enumerates specific validation checks (syntax, required keys, file existence, model part names, solver_settings). This distinguishes it from sibling tools like mdpa_validate and validate_case, which target different files or broader validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (validate a ProjectParameters.json before running a simulation) and mentions the prerequisite 'deep=true, needs Kratos', but it does not explicitly state alternatives or when not to use this tool. Since the tool is focused on a specific file type, the usage context is clear but not formally contrasted with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains the tool reads an existing file and returns a structured summary with specific contents, also noting multi-stage cases are summarized per stage. It does not explicitly state it is read-only, but 'Parse' implies non-mutating behavior. Missing error handling or side-effect details, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with action, and every phrase adds value. The first sentence organizes the exposed information clearly, and the second provides a concise usage directive with no 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 complexity (parsing JSON, multi-stage support) and the existence of an output schema, the description covers the key aspects: what it parses, what it returns, and when to use it. It does not explain the output schema details, but that is covered by the schema itself. The description is complete enough for an agent to select and invoke the tool correctly.
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 `parameters_file` with no description (0% coverage). The description partially compensates by identifying it as an existing ProjectParameters.json, but does not specify path format, file vs. content, or other nuances. This is adequate but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Parse... and return a structured summary') and a detailed resource (ProjectParameters.json). It enumerates the config aspects covered (analysis type, solver, etc.) and distinguishes itself from sibling tools like validate_project_parameters or create_project_parameters by focusing on understanding existing files.
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 explicit usage context: 'Use this to understand a case you did not scaffold before editing or running it.' It implies the tool is for analysis before modifications, but does not explicitly name alternatives or state when not to use it, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns the parameters and writes to output_file when provided, which covers the main behavioral traits. It does not mention error handling or overwrite semantics, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. Each sentence adds distinct information: the conversion purpose and the return/write plus round-trip behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and two simple parameters, the description covers the core purpose, both parameters, and the return/write behavior. It lacks details on error cases or specific format requirements, but for a conversion tool this is sufficient.
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 coverage is 0%, so the description must clarify parameter meaning. It identifies graph_file as the Flowgraph graph.json source and output_file as the destination when writing. This adds value beyond the bare titles, but it could explicitly name both parameters in one place for extra clarity.
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 ('Convert') and identifies both input (Flowgraph graph.json) and output (ProjectParameters.json), clearly distinguishing this from sibling tools. The round-trip note with export_case_to_flowgraph further differentiates it.
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 round-trip mention implies this is the inverse of export_case_to_flowgraph, giving clear context on when to use it. However, it stops short of explicitly stating when not to use it or naming alternative tools beyond that sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that an optional extra is required, frames are ordered by numbers, one shared color/crop/camera is applied, small GIFs are returned inline, and the file path always returned. This goes beyond schema details and gives useful operational context, though it doesn't mention side effects like file creation explicitly.
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 sentences, front-loaded with the main action, then clarifies the key input and output behavior. Every sentence earns its place, with no redundant filler or repetition of schema details.
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 12 parameters, no output schema, and no annotations, the description covers the essential points: purpose, prerequisite, input semantics, shared configuration, and output format. It leverages the sibling results_render to avoid repeating option semantics. It doesn't explain every parameter but provides enough for an agent to select and invoke the tool correctly, especially with descriptive parameter names.
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 explains 'files' in detail (directory or glob, numeric ordering) and references 'Coloring/warping/crop_bounds options as in results_render,' which helps for those parameters. However, many parameters like fps, max_frames, show_edges, warp_factor, window_size, and gif_path are not individually described. The names and defaults are somewhat self-explanatory but the description does not add substantial meaning beyond the schema for them.
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+output: 'Render a time series of VTK/VTU results into an animated GIF.' It clearly distinguishes from sibling results_render (static rendering) by focusing on time series animation, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the prerequisite (requires pyvista 'viz' extra) and explains what 'files' should be (directory or glob with numeric ordering). The reference to 'as in results_render' implies shared options, and the existence of results_render as a sibling provides clear context for when animation is intended versus a single-frame render. It doesn't explicitly say 'use this instead of results_render for animations,' but the distinction is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for disclosing behavior. It openly explains what is returned (counts, variables, per-variable statistics) and the optional variable restriction. It does not mention edge cases (e.g., invalid file, unsupported format), but for a summarization tool the core behavior is transparent enough.
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 packs all key information: resource, what is summarized, and the optional restriction. No redundant or misleading words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers the essential inputs and behavior, and is sufficiently complete for a straightforward summarization tool. It could add caveats about file access or variable name syntax, but these are not critical for a summary function.
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 description coverage is 0%, so the description must compensate. It adds meaningful context to both parameters: 'VTK/VTU result file' clarifies the expected file type, and 'optionally restrict to one variable' explains the purpose of the variable parameter. This goes beyond the basic schema by giving usage context, though it does not specify exact path formats or validation rules.
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 ('Summarise') and resource ('VTK/VTU result file'), and enumerates the exact summary contents (points/cells, variables, per-variable statistics). It clearly distinguishes itself from sibling tools like results_probe or results_list by focusing on aggregated statistics.
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 through its purpose but does not explicitly state when to choose this tool over siblings such as results_list or results_probe. There is no mention of alternatives or conditions like 'use for overview, use results_probe for point sampling.' This is a clear but implicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the status is 'parsed from its log', a useful behavioral detail, and enumerates the possible states. It doesn't mention error handling or side effects, but the operation is clearly read-only and safe.
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 conveys the tool's purpose and return values. There is no redundancy or filler, making it highly concise and easy to parse.
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 status tool with an output schema present, the description is complete: it specifies what to pass, what the tool returns, and even hints at the underlying mechanism (log parsing). No additional context is necessary for correct invocation.
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 only parameter (job_id), so the description must compensate. It adds context by referring to 'a simulation job' and 'its log', but does not explain the value's origin, format, or how to obtain it. This is minimal compensation, though the parameter name is self-descriptive.
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 specifies the verb 'Get' and the resource 'state of a simulation job', listing the exact statuses and additional fields (elapsed time, current step/time). This distinguishes it from sibling tools like job_list and job_logs which handle different concerns.
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 clear usage: use this tool to obtain the status, elapsed time, and step/time of a simulation job. It does not explicitly mention when not to use it or name alternatives, but the scope is well-defined and distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that the list is parsed from C++ macros, which adds source transparency. But it does not mention behavior like no results handling, whether it requires a local Kratos installation, or that it is a read-only operation (though 'list' implies read-only). The disclosure is adequate but not rich.
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 verb first, no redundant information. It efficiently explains the tool's purpose and both optional filters with examples, achieving high density of useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, two optional parameters, and the presence of an output schema (which handles return values), the description is nearly complete. It covers purpose and all parameters. The only gap is not explicitly linking to sibling list tools, but this is minor since the resource type is clearly named.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for the two parameters (0% coverage). The description compensates fully by explaining 'application' as a filter by application name with an example, and 'name_filter' as a substring filter with a concrete example. This provides meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List element type names registered in Kratos', and clarifies the source ('parsed from KRATOS_REGISTER_ELEMENT macros in the C++ sources'). This clearly distinguishes it from siblings like kratos_list_conditions and kratos_list_variables by focusing on elements and the macro source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need a list of element types. It also explains the optional filters, giving concrete examples for application name and name substring. However, it does not explicitly exclude alternatives or direct users to sibling tools, but the purpose is unambiguous among the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavioral nuances. It discloses the best-effort nature of parsing defaults, the effect of 'with_defaults=true', and that modules failing to parse are still listed without defaults. However, it does not explicitly state whether the operation is read-only (though implied by 'list') or mention any potential performance implications.
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 four sentences, front-loaded with the primary purpose, and each sentence adds value: scope, usage context, default behavior, and an alternative tool reference. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, the optional defaults behavior, and points to a related tool for deeper schema needs. Since an output schema is provided, the lack of explicit return format is acceptable. Minor gaps remain around the filter parameters and whether the list is sorted, but overall it is reasonably 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?
Input schema provides only titles (Application, Name Filter, With Defaults) with no descriptions, and schema coverage is 0%. The description explains the behavior of 'with_defaults' in detail but says nothing about 'application' or 'name_filter', leaving meaning heavily reliant on parameter names alone.
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 specifies the verb 'list' and the resource 'Python process modules', and adds context about their use as 'python_module' values. It also distinguishes itself from sibling tools like kratos_get_process_defaults by explicitly pointing to that tool for single-module schemas.
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?
It states when to use the tool: when you need processes usable in ProjectParameters process lists. It also provides an explicit alternative: 'Use kratos_get_process_defaults for a single module's full schema', which clarifies the boundary between the two tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly states 'dry-run' and 'without running the time loop', conveying non-invasiveness. It also lists the exact checks performed, which is transparent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's scope and specific checks. It is well-structured with a colon-led list, containing no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained. The description covers the dry-run scope and the validation items. It does not mention prerequisites or explicit side effects, but 'dry-run' implies none. Slightly more detail on when to use it could elevate completeness.
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 mention case_dir or parameters_file. While parameter names are somewhat self-explanatory, the description fails to compensate for the lack of schema descriptions, leaving potential ambiguity about parameters_file's role.
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 performs a 'dry-run check of a case directory' and enumerates specific validation steps (JSON validity, required keys, file existence/parsing, model references, solver settings). This distinguishes it from siblings like run_simulation or validate_project_parameters.
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 pre-run validation without launching the time loop, which is clear context. However, it does not explicitly name alternatives or exclusions, though sibling tool names suggest such comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does well by disclosing the orchestration mechanism (SequentialOrchestrator) and the nuanced mesh-sharing behavior: first stage imports mesh, later stages either reuse via matching model_part_name or import separately. It doesn't cover side effects like directory overwrites, but the key behavioral trait is well documented.
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: it opens with the core purpose, then gives the stage format, then the orchestration context, and finally the mesh-sharing rule. Every sentence adds necessary information without redundancy. It is compact yet covers the essential details for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 5 parameters and an output schema, but the description explains the most critical input semantics (stage structure and mesh sharing) in sufficient detail. It doesn't describe return values, but the presence of an output schema reduces that burden. Some parameter details are underexplained, but overall it is adequate for a knowledgeable user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description adds critical meaning by defining the 'stages' element structure: {"name": "<stage_id>", "template": "<template>", "overrides": {...}}. It also clarifies the role of model_part_name in mesh sharing. However, it doesn't explain 'create_demo_mesh' or 'stage_checkpoints', leaving some parameters unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Scaffold a Kratos multi-stage (orchestrated) case that chains several analyses in sequence.' It also gives concrete examples (continuation run, coupled workflow) and implicitly distinguishes from the sibling 'create_project' by focusing on multi-stage orchestration.
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 usage context by describing when to use the tool (for chained analyses) and how stages are structured. It also explains the mesh-sharing rule for selecting model_part_name, which guides correct setup. However, it doesn't explicitly state alternatives or exclude single-stage cases, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses key behaviors: generation from a template, overrides replacing defaults, conditional file writing, and that content is always returned. It does not mention overwrite behavior or error conditions, but it covers the main 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?
Three concise sentences, front-loaded with purpose, each providing actionable information without unnecessary words. The description is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and lack of annotations, the description covers the core workflow: template selection, overrides, writing to file, and return value. It could mention prerequisites or edge cases in more detail, but overall it is complete enough for the agent.
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 description coverage is 0%, so the description must compensate. It explains template sourcing, the overrides format with a concrete example, and the output_file conditional. This adds meaningful semantics beyond the raw schema property types and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a ProjectParameters.json from a template', identifying the specific verb and resource. It distinguishes itself from sibling tools like create_project and create_materials by focusing on parameter file generation, and references list_templates for sourcing templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: use list_templates to find templates, use overrides to customize defaults, and use output_file to write to disk. It does not explicitly name alternatives or exclusions, but the workflow is well implied and the tool's role is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, and the state filter is disclosed. However, it does not detail the response format, ordering, scope of 'known' jobs, or any other behavioral traits, limiting transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, and every word contributes meaning. There is 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?
This is a simple tool with one optional parameter, and the description covers its purpose and filtering capability. An output schema exists, so return values do not need to be described. The description is complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), but the description compensates fully by explaining the 'state' parameter and enumerating its allowed values (queued, running, succeeded, failed, cancelled). This adds essential meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('simulation jobs'), clearly stating the tool's scope ('all known') and an optional state filter. This distinguishes it from sibling tools like job_status, job_logs, and job_cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to list jobs, optionally filtered by state). However, it does not explicitly mention alternatives or when not to use it, though sibling tool names imply such 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?
No annotations are provided, so the description carries the burden. 'Return' and 'as reported by GetDefaultParameters()' clearly imply a read-only query with no side effects. It doesn't discuss permissions or error handling, but for a getter this is acceptable and the output schema covers return details.
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, front-loaded with the primary action, and no redundant information. Every clause earns its place, making it efficient and easy to process.
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, the presence of an output schema, and the clear parameter guidance, the description is sufficiently complete. It could mention prerequisites like solver installation, but that is handled by sibling tools and is not critical for a getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds meaning by explaining analysis_type as one of structural/thermal/fluid/potential_flow and solver_type as a value from kratos_list_solvers with examples. This compensates well for the schema gap.
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 and resource: 'Return the complete default solver_settings parameters for a solver'. It clearly distinguishes from a sibling tool like kratos_get_process_defaults by focusing on solver defaults, not process defaults.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context by listing valid analysis_type values and directing to kratos_list_solvers for solver_type values. It implies when to use (to fetch solver defaults) but does not explicitly contrast with alternatives like kratos_get_process_defaults or state 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?
With no annotations provided, the description carries a higher burden. It goes beyond simple file-writing by explaining how presets fill constitutive_law and default variables, how user-supplied variables override preset defaults, and the optionality of constitutive_law. This adds meaningful behavioral context, though it does not mention file existence/overwrite behavior or potential 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 compact and front-loaded, starting with the action. The sentences are concise and each adds necessary detail: entry requirements, options, override behavior, and exception for thermal problems. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of the nested materials structure and the presence of an output schema (so return values are covered), the description is largely complete for the tool's inputs. It does lack explicit statement about whether it overwrites existing files, but this is a minor gap for a write tool. Overall it provides sufficient context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so effectively by thoroughly specifying the structure of each entry in the materials array, including required model_part_name, the choice of preset or constitutive_law, and the variables object with an example. It also implies the output_file parameter via the phrase 'Write a Kratos Materials.json'. This is far more informative than the generic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Write a Kratos Materials.json', which is a specific verb+resource pair. It clearly distinguishes this tool from siblings like create_project_parameters, which writes a different file type. The additional detail about entries and presets further clarifies its 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 provides clear guidance on how to choose between a preset and an explicit constitutive_law, referencing the sibling tool list_material_presets for preset names. It also explains when constitutive_law is optional (thermal problems). However, it does not explicitly exclude use cases or mention scenarios where using an alternative tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns the graph and optionally writes it to output_file, and describes the round-trip behavior. It does not mention error cases or side effects beyond the explicit file write, but for this simple conversion it is adequately transparent.
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 concise sentences, each providing distinct value: the conversion action, the return/write behavior, and the round-trip relationship. It is front-loaded with the primary purpose and contains no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters, and the description covers the input, output, optional file writing, and the inverse operation. Given the presence of an output schema, the return value is adequately addressed, and no significant context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that parameters_file is the ProjectParameters.json input, and that output_file is an optional destination for writing the graph. This adds meaning beyond the raw schema, though it does not specify that these are file paths.
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 converts a ProjectParameters.json into a Flowgraph graph.json for the Kratos FlowGraph editor. It names the specific action, input, output format, and differentiates from the sibling import_flowgraph_to_case by mentioning round-trip compatibility.
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 context is clear: this exports a case to a visual node editor graph. It mentions the round-trip with import_flowgraph_to_case, which serves as an alternative, but does not explicitly state when to use one over the other or list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that the list is 'introspected from the live build,' which is a key behavioral detail indicating the data reflects the current runtime state. It also explains grouping and filtering, providing useful context beyond a bare operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and immediately conveys the resource, grouping, source, and filter semantics. It is front-loaded with the core verb and object, and every phrase provides value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail the return structure. It sufficiently covers the source (live build), the grouping, and both filtering parameters. For a straightforward introspection/list tool, this is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explicitly explains both parameters: type_filter selects a group and name_filter is a substring. This adds meaning beyond the bare schema. It does not mention edge cases like how the filters combine when both are provided, but the core semantics are clear.
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 ('List') and a clear resource ('Kratos variables') with examples of what is listed (DISPLACEMENT, TEMPERATURE) and how it is organized (by type). It clearly distinguishes this tool from sibling tools like kratos_list_elements and kratos_list_applications, which list different Kratos entities.
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 when to use the tool: whenever you need to inspect available Kratos variables and filter them by type or name. It provides clear context but does not explicitly name alternatives or state when not to use the tool, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly indicates a listing operation, enumerates available presets, and explains the output's applicability as drop-in settings blocks. This goes beyond a bare 'list' by revealing the structure and purpose of the returned data.
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: one lists the presets, the second explains the drop-in usage. It is front-loaded, concise, and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an output schema, the description is complete. It identifies the tool's purpose, enumerates the presets, and explains how the outputs are intended to be used in ProjectParameters. No critical context is missing.
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 need not add parameter details. The schema is already complete (100% coverage). A baseline score of 4 is appropriate; the description does not need to compensate for any missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List curated linear_solver_settings presets' – a specific verb and resource. It enumerates the exact preset names for serial and MPI/Trilinos, distinguishing it from sibling tools like list_material_presets or list_templates.
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 states that each settings block is a drop-in for solver_settings.linear_solver_settings in a ProjectParameters, providing clear context for when this tool is useful. It does not explicitly name alternatives or exclusions, but the intended usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses that each preset includes a constitutive_law name and default Variables, and warns that law names should be cross-checked with the compiled build via kratos_list_constitutive_laws. This is a meaningful behavioral detail. It does not mention return format or side effects, but for a list tool these are largely implicit.
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, front-loaded with the core purpose. The second sentence adds valuable cross-check guidance. No filler or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema present, the description is complete: it explains what the presets are, what they contain, and how they should be used in a larger workflow (create_materials) while pointing to a validation step. It covers the essential context without over-explaining.
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 0 parameters, so the baseline is 4. The input schema is empty and schema coverage is trivially 100%. The description adds no parameter-specific semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('List') and resource ('curated material presets'), with a clear usage context ('usable as preset in create_materials'). It also mentions that each preset carries a constitutive_law name and default Variables, distinguishing it from sibling list tools like list_linear_solver_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context: the presets are to be used as 'preset' in create_materials. It also instructs the agent to cross-check law names with kratos_list_constitutive_laws for the compiled build, which suggests a complementary tool. However, it does not explicitly contrast with all related list tools (e.g., list_linear_solver_presets), so it lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that the tool writes a .mdpa file, includes a 'domain' submodelpart, attaches boundary conditions to boundary parts, and provides default element/condition types. It does not cover error scenarios or file-overwrite behavior, but the key side effects and structural output are well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat dense but well-organized: it front-loads the primary purpose, then breaks down variants and defaults. Every sentence contributes useful information, but the use of parentheses and list-like structures makes it slightly harder to parse quickly. It is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, multiple mesh variants), the description is complete: it covers all required parameters for each kind, optional parameters, defaults, submodelpart structure, and the fact that an output file is written. The presence of an output schema means return values need not be described. The agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It thoroughly explains the meaning of 'size' and 'divisions' for each variant (e.g., size=[W,H], divisions=[nx,ny] for rectangle), the optional 'triangles' flag, and the defaults for 'element_name' and 'condition_name'. Path, while not explicitly described, is self-evident from the verb 'write it as .mdpa'. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate a structured mesh and write it as .mdpa.' It further specifies three distinct geometric variants (line, rectangle, box), which distinguishes it from sibling tools like mdpa_inspect or mdpa_validate. The verb 'generate' and resource '.mdpa' file make 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when a structured mesh is needed, and it details the supported kinds (line, rectangle, box) and their configurations. It does not explicitly contrast with alternatives or state when not to use it, but there are no direct sibling tools for mesh creation, and the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the parsing source (ValidateAndAssignDefaults block), the exact return contents, and error conditions (source unavailable, module not found, non-standard declaration). This is substantial behavioral context, though it doesn't mention performance or file-system dependencies.
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 action ('Return...'), uses a compact dash list for contents, and includes only essential context (purpose, parameter source, error cases). No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and no annotations, the description covers purpose, usage, parameter derivation, return contents, and error behavior. The presence of an output schema means return values need not be repeated. It's complete for an introspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'python_module' with a title 'Python Module' and no description. The tool description compensates by explaining it takes a value from kratos_list_processes and provides concrete examples, giving the agent the needed 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 names a specific action ('Return a Kratos process' default settings') and details the contents (parameter names, default values, types, model-part references). It differentiates from sibling tools like kratos_get_solver_defaults by explicitly tying to process defaults and referencing kratos_list_processes as the source of python_module.
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 explains the tool provides the schema needed to author a process block in a ProjectParameters process list, which is a clear use case. It points users to kratos_list_processes to find valid python_module values, but does not explicitly state when not to use this tool in favor of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It discloses that the image is returned inline, saved next to the input file unless image_path is given, that vector variables default to magnitude or can pick a component, that warping scales by warp_factor, and that crop_bounds clips before framing the camera. This is rich operational detail beyond the schema.
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 dense but every sentence adds value: output format, dependency, coloring, warping, camera, crop bounds rationale, and output file behavior. It is front-loaded with the core purpose and does not repeat schema information verbatim.
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 10-parameter tool with no annotations and no output schema, the description covers most behavior thoroughly, including the critical crop_bounds use case. However, it omits show_edges and window_size details and does not explicitly discuss return values or potential failure modes, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well for many parameters: file type, variable, component, warp_by (via DISPLACEMENT example), warp_factor, camera presets, crop_bounds format, and image_path. However, it does not explain show_edges or window_size behavior, leaving those parameters underdocumented.
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+output: 'Render a VTK/VTU result file to a PNG screenshot'. This clearly distinguishes results_render from sibling tools like results_list, results_probe, results_summary, and results_animate, all of which have different purposes (listing, probing, summarizing, animating).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful usage context: it warns about the optional 'pyvista' extra, explains variable coloring, warping, camera presets, and highlights crop_bounds as essential for small bodies in huge domains. However, it does not explicitly state when NOT to use this tool or name an alternative like results_animate for motion visualization.
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:

[![Kratos-MCP-Server MCP server](https://glama.ai/mcp/servers/loumalouomega/Kratos-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/loumalouomega/Kratos-MCP-Server)

Score Badge

Copy to your README.md:

[![Kratos-MCP-Server MCP server](https://glama.ai/mcp/servers/loumalouomega/Kratos-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/loumalouomega/Kratos-MCP-Server)

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/loumalouomega/Kratos-MCP-Server'

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