export_schedule

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states the file format, default output location, path allowlist, and the overwrite=true requirement for replacing existing files. It does not describe error behavior when path constraints are violated, but the main safety-relevant behavior is covered.

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?

Three dense sentences with the core purpose front-loaded and operational constraints following. There is no filler, tautology, or restatement of schema fields; every clause adds information an agent needs.

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 4-parameter export tool with no annotations, the description covers path and overwrite behavior well. Yet it omits explanation of the required 'kind' argument and optional 'level' argument, and it does not address when to choose this tool over sibling export tools. These gaps make the definition functional but not fully self-sufficient.

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 for parameter meaning. It adds useful semantics for path (default and allowed locations) and overwrite (replacement only when true). However, it does not explain the required 'kind' parameter or the optional 'level' filter beyond the raw enum values in the schema, leaving a meaningful semantic gap.

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 opens with 'Save a schedule as a CSV file', giving a specific verb, resource, and output format. The parenthetical '(semicolon-separated, opens in Excel/LibreOffice)' makes the deliverable concrete. It does not explicitly differentiate from sibling export tools such as export_pdf or export_dxf, though the CSV format makes the distinction largely inferable.

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?

The description provides useful operational context: default path next to the FreeCAD document, restricted allowed directories, and the overwrite=true requirement. However, it never explicitly states when to prefer this tool over get_schedule or the other export_* siblings, so selection guidance is only implied by the CSV format and tool name.

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