Export an ArchiMate model as an Open Exchange File

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

No annotations are provided, so the description carries the full disclosure burden. It does state the core side effect — writes a file to disk — which is the most safety-relevant behavior for an export tool, and names the XML standard. However, it leaves implicit whether the export mutates the model (it reads as non-destructive but never says so) and does not describe overwrite/conflict behavior beyond the schema parameter. Adequate but not rich.

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?

Both language blocks open with the core purpose, then the format, then the interoperability value, then the sibling pointer — every sentence earns its place and the key facts are front-loaded. Bilingual duplication doubles the length, but it is symmetric and a deliberate pattern for this tool family, costing one point.

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 tool with 9 optional parameters, a 100%-covered schema, and no output schema, the definition is reasonbly complete: purpose, output format, destination, and input parity with a sibling are all stated. The main gaps — what a successful call returns (file path?) and explicit alternative-routing — are not cripling because the schema covers parameters and the description covers the tool's nature.

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 100% with bilingual per-parameter descriptions (including the relations/relationships aliasing and the 'no line is drawn without relations' caveat), so the schema does the heavy lifting and the baseline 3 applies. The description adds one genuinely useful cross-reference — 'Same inputs as export_archimate_csv' — which lets agents transfer knowledge from the sibling, but it contributes no per-parameter 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?

The description names a specific verb and resource ('Write an ArchiMate model to disk'), pins the exact format (Open Exchange File / XML), and adds the interoperability value proposition ('the interchange format other ArchiMate tools read'). This clearly differentiates it from the CSV sibling by format and consumption context.

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 phrase 'the interchange format other ArchiMate tools read' gives clear context for when this tool is the right choice, and 'Same inputs as export_archimate_csv' links the closest sibling, telling agents their existing input knowledge transfers. It stops short of an explicit when-to-use versus when-not-to-use statement (e.g., 'use export_archimate_csv for tabular/ spreadsheet consumption'), so it does not reach a 5.

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