33 tools with significant structural gaps. All tools have descriptions (10-50 chars, mostly generic), but parameter descriptions are sparse or missing. Input schemas present but lack depth: most use generic 'object' types with minimal field-level documentation. No output schemas documented. Error handling absent. Tool names follow verb_noun pattern but lack specificity (e.g., 'catalog_export_basic' vs 'export_catalog_to_csv'). No tool annotations (readOnlyHint, destructiveHint). Composition is reasonable (single responsibility per tool), but parameter naming inconsistency (export_data as opaque object) forces LLMs to guess payload structure. Baseline: 549 production tools average 194-char descriptions and 100% param documentation; this server averages ~30 chars and ~40% param coverage.

• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Use catalog_export_basic for standard product fields; use catalog_export_custom to select specific fields'). Reference pattern:tool-description.
• Replace opaque 'export_data' and 'template_data' objects with explicit nested schemas. Document required fields, enums for known values, and format constraints. Example: export_data: {type: object, properties: {format: {enum: [csv, json]}, include_images: {type: boolean}}}.
• Add output schemas to all tools. Document response structure, field types, and pagination (if applicable). Example: catalog_export_basic returns {export_id: string, status: enum, created_at: ISO8601}.
• Add tool annotations: mark catalog_custom_import_delete_template with destructiveHint=true; mark all read-only tools with readOnlyHint=true. Enables agents to reason about side effects.
• Add error handling guidance to WRITE/DESTRUCTIVE tools. Example: 'If import fails with validation error, call catalog_basic_import_get_template to download the correct format. If network timeout, retry after 30 seconds.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry