femm_line_integral

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

With no annotations, the description carries the full burden, and it does disclose what each result code computes (flux, MMF, force, torque, charge) and how the contour is discretized. However, it omits permissions, prerequisites (e.g., a solved model), and return structure, leaving the behavioral picture incomplete.

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 core definition is front-loaded, but the bulk is a dense multi-domain code table with trailing ellipses and the cryptic 'Defaults: the first three/four' that add parsing difficulty. Information density is high, though structure could be cleaner.

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?

There are no annotations and no output schema, and 3 parameters at 0% schema coverage. The codes and contour are explained adequately for invocation, but the undocumented session parameter and unclear return format leave gaps an agent would need to resolve experimentally.

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 coverage is 0%, so the description must compensate, and it documents the 'codes' parameter exhaustively per physics domain and explains the contour format and curve-following advice. The 'session' parameter is not mentioned at all, but the two substantive parameters are well covered.

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 concrete verb+resource: computing line integrals along a contour of straight pieces, with explicit coordinate format [[x,y],...]. It implicitly contrasts with the area-based femm_block_integral, but never names it, so the sibling distinction is left to inference.

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?

There is no statement of when to choose this tool over alternatives such as femm_block_integral or femm_point_values. The description is a physics-code reference dump rather than usage guidance, so the agent must infer the appropriate context.

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