MCP-ADAPTER

feko_lua_template

Generate ready-made Altair Feko Lua script templates to build/solve a dipole, export impedance CSV or farfield .ffe, and run monostatic RCS sweeps.

Instructions

[Altair Feko: computational electromagnetics (MoM/MLFMM/FEM/PO/UTD hybrids) for antennas, antenna placement on platforms, RCS, EMC] Ready-made Lua scripts to adapt: 'dipole' (CADFEKO build + solve), 'export_source_data' (POSTFEKO impedance CSV), 'export_farfield' (POSTFEKO .ffe export), 'rcs_sweep' (CADFEKO plane-wave monostatic RCS).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>"
    },
    "name": "feko_lua_template"
  }
}

Input Schema

Name	Required	Default
`kind`	Yes
`model`	No	D:/feko/model.cfx
`output`	No	D:/feko/result.csv
`frequency_hz`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 27, 2026

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It says nothing about whether the returned scripts are written to disk (overwriting model/output paths?), whether a Feko installation is required, or side effects of running them. Only the template content is described.

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

Conciseness3/5

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

The bracketed product context is front-loaded and the template list is compact, but the single run-on sentence crams domain jargon, four template names, and their outputs together, making it harder to scan than a short bulleted form would be.

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

Completeness2/5

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

An output schema exists so return values need not be explained, but with zero annotation coverage and 0% schema coverage across four parameters, the description leaves the tool's operating behavior (file writing, toolchain prerequisites) and three parameters unaddressed.

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

Parameters3/5

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

Schema description coverage is 0% and the schema has no enums, so the description's enumeration of kind values ('dipole', 'export_source_data', 'export_farfield', 'rcs_sweep') is genuinely valuable for the required parameter. However, model, output, and frequency_hz are undocumented in both schema and description.

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

Purpose4/5

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

The description names a concrete resource (ready-made Lua scripts) and enumerates four specific template kinds with their purpose (dipole CADFEKO build+solve, impedance CSV export, farfield export, monostatic RCS sweep). It is not differentiated from the sibling altium_script_template, but the Feko-specific template names make the resource scope unmistakable.

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?

It lists which templates exist but gives no guidance on when to reach for this tool versus feko_parse_out, altium_script_template, or the other script/output tools. There are no preconditions, exclusions, or alternative routing statements.

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