AxMeep_generate_code

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

No annotations exist, so the description carries the full burden, and it delivers rich behavioral context: the generated script imports meep and calls export(name, obj) for each result; scalar results should be requested as printed output because plain Python floats return as opaque pickle; and retry should patch the specific failure rather than regenerate from scratch. These details materially shape what the agent can expect and how it should phrase requests.

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 front-loaded with purpose and output, then packs non-execution, retry behavior, export conventions, and a concrete scalar-output caveat into a compact set of sentences. Every sentence earns its place and no redundant phrasing exists.

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 that an output schema exists, the description does not need to explain return structure; it still covers the essential invocation context: what the tool generates, that it must be followed by execute_code, how to handle a failed run, and how to phrase problem descriptions for better results. This is complete for a code-generation tool of this complexity.

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 100%, so the baseline is 3; the description adds meaningful semantics beyond the schema by explaining how previous_code and previous_error should be paired for failed-run patching and by advising that naming desired results in problem_description improves output. This goes beyond the schema's straightforward parameter descriptions without providing full syntax-level detail.

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: 'Generate a complete Meep FDTD simulation script from a natural-language problem description.' It clearly differentiates from siblings by naming Meep specifically and by explicitly saying it does not execute anything, which distinguishes it from AxMeep_execute_code and AxTidy3D_generate_code.

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?

Provides explicit when-to-use and when-not-to-use guidance: 'it does NOT execute anything — run it with execute_code.' It also gives conditional retry guidance by instructing the agent to pass previous_code and previous_error when a run failed, and practical tips for describing desired results, all of which help the agent decide how to invoke the tool correctly.

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