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

The description clearly discloses that the tool returns file contents as text, which is not obvious from the schema or the readOnly annotation. It also explains a non-obvious behavioral detail: JSON omits fields that the batch-create endpoint does not accept, while CSV includes system facts.

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 two sentences, front-loads the primary purpose, and packs meaningful format-specific behavior into a compact space. There is no repetition of the tool name or title and no filler.

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 two parameters, a readOnly annotation, and no output schema, the description fully covers what the agent needs: what it returns (text), the two supported formats, and the behavioral difference between them. Nothing essential 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 100%, but the description enriches the 'format' parameter by explaining what each format is intended for and how their contents differ. The 'keyword' parameter is not additionally explained, but the schema already covers it adequately.

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 clearly identifies the operation ('Export') and the resource ('the fact catalog'), and it explains what each format returns. However, it does not explicitly differentiate this from sibling tools like lexq_facts_list or lexq_facts_unregistered, relying on the reader to infer the distinction.

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 gives concrete usage guidance for choosing between CSV and JSON: CSV for spreadsheet reading, JSON for feeding back into the batch-create endpoint. It does not, however, explain when to choose export over other fact-related tools, so no tool-selection guidance is provided.

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