Two tools with complete input schemas and descriptions, but significant gaps in output documentation and error handling. firefly_inventory has 8 parameters with good descriptions and enum constraints (assetState). firefly_codify has 5 parameters, all described, with 4 marked required. However, neither tool documents its output schema, making it impossible for LLMs to plan downstream operations. Tool names lack action verbs (firefly_inventory vs list_assets, firefly_codify vs generate_terraform_import). No error recovery guidance, no pagination info for inventory results despite responseSize parameter suggesting large datasets. Parameter descriptions are adequate (avg ~60 chars) but lack format constraints and validation rules.

• Document output schema for firefly_inventory: return type (array of assets), per-asset fields (assetType, assetId, assetState, provider, etc.), total count, and next_cursor for pagination.
• Document output schema for firefly_codify: return type (object with import_command, resource_id, status, etc.) so agents know what to extract.
• Rename tools to action-verb form: 'list_assets' (or 'search_assets') and 'generate_terraform_import'. This lets LLMs infer intent from the name.
• Add pagination metadata to firefly_inventory response: total_count, page_size, next_cursor. Update description to state 'Returns up to 50 results per page; use next_cursor to fetch more.'
• Add error handling: return structured errors with error_code, message, and recovery_hint. E.g., 'error_code: INVALID_ASSET_TYPE, message: "aws_s3_bucket not found", recovery_hint: "Call list_asset_types() to see available types."'

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

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