fem_modal

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

With no annotations, the description carries the burden and does well: it discloses the concrete state it mutates (AnalysisType='frequency', EigenmodesCount=n_modes) and the required follow-up calls. It omits whether the target analysis must pre-exist or how existing settings are affected, but the core behavioral picture is present.

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?

Four short, front-loaded sentences with no filler; the primary purpose leads and each subsequent line adds distinct information (settings, range semantics, workflow).

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 configuration tool with no annotations and no output schema, it supplies purpose, parameter meaning, and the run/read workflow. Gaps remain around prerequisites (does an analysis object need to exist first?) and mutation side effects, but it is nearly complete.

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 0%, so the description must compensate. It explains the units and role of f_low/f_high (Hz, bounding the requested mode range) and maps n_modes to EigenmodesCount. Only the required 'analysis' handle is left unexplained, but its meaning is largely evident from context.

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?

States a specific verb and resource: 'Configure analysis for modal (frequency) extraction.' It names the exact solver setting being configured, which cleanly distinguishes it from the sibling analysis-configuration tools like fem_buckling and the fem_results family.

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?

Gives explicit workflow ordering: the caller still calls fem_run and then fem_modal_results to read frequencies. This tells the agent the correct sequence, though it does not state exclusions or name alternative analysis-config tools for other physics types.

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