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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'checks' status and coefficients, implying a read-only operation, but does not explicitly mention that it is non-destructive, how it behaves if the job does not exist, or any polling/blocking behavior. This lack of detail leaves significant behavioral ambiguity.

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

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

The description is a single concise sentence, front-loaded with the action ('Check') and efficiently conveys the tool's purpose without unnecessary words. Every word contributes to meaning, making it highly efficient.

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

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

For a simple tool with one parameter and an output schema, the description is minimally adequate, but it lacks guidance on when to use it relative to siblings and does not disclose behavioral specifics (e.g., job lifecycle). The schema covers parameters and output, but the absence of annotations and usage context makes it less complete than ideal.

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

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

The schema has 100% description coverage for the single parameter job_id, with a helpful description indicating it is returned by run_cfd_solver or run_airfoil_workflow. This provides meaning beyond the parameter name, but the tool description itself adds no additional parameter semantics, so the baseline 3 is appropriate.

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

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

The description clearly states the tool checks the current status and coefficients of an existing CFD job, using a specific verb ('Check') and resource ('current status and coefficients'). This distinguishes it from sibling tools that generate geometry, mesh, run the solver, visualize results, or get visualization artifacts.

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

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

Usage is implied rather than explicitly stated. The mention of 'existing CFD job' suggests it should be used after a job is created, and the parameter description clarifies that job_id comes from run_cfd_solver or run_airfoil_workflow. However, there is no explicit 'use this when' or exclusion of alternatives, relying on the agent to infer the workflow order.

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

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

No annotations are provided, so the description must disclose behavior. It only says 'Generate a 2D mesh' and does not mention that it invokes a Gmsh subprocess, can be time-consuming, or has side effects like creating mesh files. The output format and dependencies (e.g., valid geometry_id) are not described, leaving a significant 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.

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

The description is a single, concise sentence (15 words) that starts with action and object. It contains no filler and effectively communicates the core purpose.

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

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

With 12 parameters and no annotations, the description should provide more high-level context about prerequisites, runtime, and workflow position. It mentions geometry_id but does not explicitly state that the geometry must be generated first or that this mesh is required for subsequent solver calls. The output schema exists, mitigating the need to describe return values, but gaps in workflow context remain.

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

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

The input schema covers 100% of parameters with detailed descriptions (e.g., domain_size, growth_rate, target_y_plus). The tool description adds only the workflow context and mentions geometry_id, which is already in the schema. Since the schema does the heavy lifting, the description provides marginal added value, fitting the baseline of 3.

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

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

The description clearly states the tool's function: generating a 2D mesh from a geometry_id for NeuralFoil or SU2 workflows. It uses a specific verb ('Generate') and resource ('2D mesh'), and the mention of geometry_id distinguishes it from geometry-generation and solver tools. The sibling tools reinforce its role as the meshing step in the pipeline.

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

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

The description implies the tool is used after generate_airfoil_geometry (via geometry_id) and before solver tools (for NeuralFoil or SU2 workflows). It provides context but does not explicitly state when not to use it or name alternatives. The guidance is clear enough for an agent familiar with the workflow, but lacks explicit exclusions.

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

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

With no annotations, the description carries the full burden, but it only states the basic action and output. It does not disclose side effects, persistence behavior, error conditions, or safety aspects, beyond implying the geometry is stored for reuse.

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

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

The description is a single, focused sentence that front-loads the primary action and output, with no unnecessary detail.

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

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

Given the tool's moderate complexity (four parameters) and the presence of detailed parameter schemas and an output schema, the description is mostly sufficient. The only gap is the lack of usage guidance, which is already penalized in that dimension.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter meaning, aligning with the baseline of 3.

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

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

The description clearly states the tool's action: 'Generate a NACA 4/5-digit airfoil geometry' and the output: 'return a reusable geometry_id'. This specific verb and resource distinguish it from sibling tools like mesh generation or solving.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention downstream steps, exclusions, or prerequisites, leaving the agent to infer usage from the tool's name and the mention of a 'reusable geometry_id'.

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

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

With no annotations, the description carries the full burden. It does disclose the output behavior (MCP image result), but it does not mention related traits such as whether the artifact is consumed, what happens if the ID is invalid, or any prerequisites. This is minimal but non-contradictory.

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

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

The description is a single, front-loaded sentence with no unnecessary words. Every element contributes to understanding the tool's function and output.

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

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

The description is too sparse for a tool in a multi-step workflow. It lacks context about where the artifact comes from (likely from visualize_cfd_results), what to do if the artifact doesn't exist, and how the returned MCP image result should be used. The absence of an output schema and annotations increases the need for descriptive context.

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

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

The input schema has one required parameter (artifact_id) with 0% schema description coverage. The description does not elaborate on what artifact_id means, how to obtain it, or any format expectations, completely failing to compensate for the missing schema documentation.

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

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

The description clearly states the tool loads a previously generated visualization artifact and converts it to an MCP image result. This specific verb-resource pairing distinguishes it from sibling tools like visualize_cfd_results, which generate artifacts, while this one retrieves them.

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

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

The phrase 'previously generated' implies usage after a generation step, but it does not explicitly mention when to use this tool vs alternatives, nor does it exclude scenarios. There is no explicit guidance or naming of prerequisite tools like visualize_cfd_results.

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

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

With no annotations provided, the description must disclose behavioral traits, but it only lists the three steps without mentioning runtime expectations, resource consumption, side effects like intermediate file writes, or any caveats about the workflow. For a complex multi-stage tool, this is a significant 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.

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

The description is a single, direct sentence that efficiently communicates the core purpose without any redundant or irrelevant information. It is appropriately front-loaded and concise.

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

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

Despite having a full input schema and an output schema, the description is far too sparse for a tool orchestrating three complex simulation stages. It omits any information about what the workflow returns, expected execution time, or how it differs from chaining the sibling tools manually, leaving substantial gaps for an AI agent.

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

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

The schema fully documents all 26 parameters with descriptions, so the baseline is 3. The description adds no extra semantic context about how parameters relate to the workflow or any non-obvious interactions, but the schema carries the load.

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

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

The description clearly states that the tool runs a composite workflow of geometry generation, mesh generation, and CFD simulation in one MCP call. It distinguishes itself from sibling tools like generate_airfoil_geometry and run_cfd_solver by being the aggregate workflow.

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

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

The description provides no explicit guidance on when to use this tool versus invoking the sibling tools separately. It does not mention scenarios where a full workflow is preferred or when individual steps should be used instead, leaving usage entirely implied by the name.

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

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

With no annotations, the description carries the full burden. It discloses synchronous execution for NeuralFoil and background job submission for SU2, but omits side effects, job lifecycle, result retrieval mechanisms, and failure behavior. This is minimal behavioral context for a complex solver tool.

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

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

The description is a single sentence with no wasted words, front-loading the verb and backend modes. However, given the tool's complexity, the brevity borders on under-specification rather than elegant conciseness.

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

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

This is a high-complexity tool with 19 parameters, dual backend modes, and asynchronous behavior, yet the description is one sentence. It does not explain the background job workflow, how results are obtained, or tie into sibling tools like check_solver_results. The presence of an output schema helps but does not compensate for missing operational context.

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

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

All 19 parameters have detailed schema descriptions (100% coverage), so the baseline is 3. The description adds only backend-mode context (synchronous vs. background), which is useful but does not significantly enhance parameter understanding beyond the schema.

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

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

The description uses the specific verb 'Run' and clearly names 'NeuralFoil' and 'SU2' backends, scoped 'from a mesh_id.' It does not explicitly differentiate from sibling tools like run_airfoil_workflow or check_solver_results, but the core purpose is identifiable.

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

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

No when-to-use or alternative guidance is provided. The phrase 'from a mesh_id' implies a prerequisite, but there is no instruction on choosing between NeuralFoil and SU2 backends or how this relates to run_airfoil_workflow or check_solver_results.

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

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

With no annotations provided, the description carries the burden. It clearly states the tool creates an artifact and returns its artifact_id, which is a key behavioral trait. However, it does not disclose potential limitations, error conditions (e.g., what happens if the job is not converged), or persistence details. This is adequate for a simple creation tool 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.

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

The description is a single, front-loaded sentence that states the action, condition, and return value without any filler. Every word earns its place.

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

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

Given the tool's moderate complexity (6 params) and the existence of an output schema (which likely documents the artifact_id return), the description is sufficient for an agent to select and invoke the tool. The only minor gap is the lack of explicit relationship to sibling tools like get_visualization_artifact for retrieving the artifact, but this is not critical.

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

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

The input schema provides 100% coverage with descriptions for all six parameters. The description adds no additional parameter semantics beyond what the schema already states, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Create') and a clear resource ('a visualization artifact for a converged job'), and explicitly mentions returning an 'artifact_id'. It clearly distinguishes from siblings like get_visualization_artifact (which retrieves) and run_cfd_solver (which runs the simulation).

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

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

The phrase 'for a converged job' implies the tool should be used after a solver job has completed, but there is no explicit mention of when not to use it or alternatives. The job_id parameter description in the schema provides more context, but the description itself offers limited usage guidance.

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