Dipole Resonance

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

Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds substantial behavior beyond the annotations: it explains this is a closed-form correlation with 'fidelity='banded'', quantifies the ~±3% tolerance over the shortening range, describes end-effect shortening physically, and lists the full return payload including valid_range_ok, warnings, and escalate_to. This gives the agent a realistic model of the tool's analytic fidelity and limitations.

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 dense but every clause earns its place: the core distinction ('NO solver, banded') comes first, followed by the exact-input rule, then the model and formula, then the fidelity/band context, and finally the return contract. Despite being rich, it remains a single compact block with no filler or repetition.

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 zero schema description coverage, no output schema, and a three-parameter tool with non-obvious physics, the description is remarkably complete. It covers input selection, parameter meaning, accuracy bounds, validity ranges, relationship to the sibling full-wave tool, and a full list of return fields. There is no critical information an agent would need to invoke or interpret this tool correctly that is missing.

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 carries full responsibility for explaining the parameters. It clearly explains the complementarity of `length_mm` and `freq_ghz`, precisely defines `shortening` as end-effect shortening k with typical values k≈0.48 and ≈0.475, and ties the meaning of parameters to the governing formula L = k·λ, f_r = k·c/L. This fully compensates for the empty schema descriptions.

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 states a precise calculation target — 'Thin centre-fed half-wave dipole first resonance' — with the key distinction 'NO solver, banded' and names the sibling `em_fullwave_submit` as the FDTD counterpart it is gated against. An agent can immediately tell exactly what this tool computes and how it differs from the full-wave solver.

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?

It gives an explicit invocation rule: 'Give EXACTLY ONE of length_mm or freq_ghz' and maps each input to its output direction. It also frames when this analytic estimate is appropriate versus when the FDTD S11 sweep (`em_fullwave_submit`) must be used, including the banding correlation and the requirement that the sweep resonance must fall inside the returned band.

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