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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds substantial behavioral detail beyond that: returns a descriptor with generation URL, ETag, counts, expiry, and sync_cursor; may inline small results; and compresses the artifact with gzip. There is no contradiction with the annotations.

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 the main export action, followed by the return contract, view/format options, and operational advice. Every sentence adds value, but the single dense paragraph with many semicolon-clauses would benefit from more structuring; it is efficient but slightly heavy.

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?

Since there is no output schema, the description supplies the essential return contract: descriptor fields, ETag behavior, sync_cursor usage, rows_inline, view names, format defaults, and a concrete example. An agent has enough information to invoke the tool correctly and interpret its response.

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?

With only 25% schema description coverage, the description carries the parameter burden and mostly compensates. It explains the view enum values (manifest, summary, full), the defaults for view and format, and rooftop_slug as an optional single-rooftop export. Country has schema-level description and is reinforced by the CA example, though the exact output semantics of 'summary' and 'full' remain somewhat terse.

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 specific verb and resource: 'Export the whole network catalog ... as one gzip artifact.' It also scopes the optional single-rooftop export and clearly differentiates this bulk-export tool from siblings by framing it 'instead of paging' and referencing network_search and inventory_get rows as views.

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 context: use this export instead of paging, re-download only when the ETag changes, and poll inventory_changes with sync_cursor to stay current. It also provides a parameter condition with 'Pass country=CA for Canadian dealers,' so an agent knows when to adjust the call.

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