cst_workflow_patch_antenna

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

No annotations are provided, so the description carries the burden. It discloses a key behavioral trait: the tool returns offline VBA if CST is not connected, which is critical. It also states it does not run the solver and builds the full setup. However, it does not disclose other behaviors like whether it overwrites an existing project, how it handles the project_path parameter, or what the output actually looks like (VBA script? built model?). Since the description covers some key points but leaves these gaps, a 3 is appropriate.

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

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

The description is relatively concise, with a bilingual twist that may confuse but is not overly long. It front-loads the main purpose ('END-TO-END / Uçtan uca') and then provides essential usage notes. It could be more concise by removing the Turkish repetition, but it's structured clearly with caveats toward the end.

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 complexity (a multi-step workflow) and the lack of an output schema, the description does a good job of explaining the scope and prerequisites. It tells the agent what to do next and what not to expect. However, it omits some details like parameter constraints (e.g., valid frequency ranges) and the exact behavior when create_project is false, but these are less 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 schema already describes several parameters (epsilon_r, height_mm, tan_delta, frequency_ghz) with 71% coverage. The description adds little beyond what the schema provides—it mentions the end-to-end components but doesn't elaborate on how each parameter influences the design. Since schema coverage is high (>80%), the baseline is 3, and the description does not add extra semantic depth, so 3 is correct.

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 purpose: to create an end-to-end rectangular microstrip patch antenna model in CST, listing all the components built (substrate, ground, patch, feed) and the setup (frequency, boundary conditions, port, monitor). This distinguishes it from siblings like cst_antenna_patch (which appears to be a template-based approach vs this building from scratch) and cst_design_patch_only (which likely only designs the patch without the full setup). It falls short of a 5 because it doesn't explicitly name the sibling tools it differs from; the reader has to infer from the sibling list.

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 strong usage context: it explicitly says 'call cst_connect first for live execution, otherwise it returns offline VBA' and tells the agent to use next steps (cst_workflow_run_and_s11 or cst_run_simulation). It also states clearly what it does NOT do (does not run the solver, does not connect to CST). However, it does not explicitly name alternative tools for when the user wants only the design without the full setup (e.g., cst_design_patch_only) or other antenna types, so it stops short of full exclusion guidance.

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