fix-spec

Fix an OpenAPI Specification

Step 1: Preview fixes with dry run

Always start with a dry run to see what would change:

{
  "spec": {"file": "<path>"},
  "dry_run": true
}

Include any specific fix flags the user requested:

• fix_schema_names -- Rename generic names like Object1, Model2 to meaningful names
• fix_duplicate_operationids -- Deduplicate operationId values
• prune -- Remove empty paths and unused schemas
• stub_missing_refs -- Create stub schemas for missing $ref targets

If no specific flags are given, the tool applies the default fixes: adding missing path parameters, and setting required: true on path parameters that omit it.

Step 2: Present the preview

Show the user a clear summary of planned fixes:

• Number of fixes that will be applied
• For each fix: what it changes, where (JSON path), and why

Paginating large fix lists

Results are paginated (default limit: 100). When returned < fix_count, there are more fixes:

{"spec": {"file": "<path>"}, "dry_run": true, "offset": 100, "limit": 100}

✅ Page through all fixes so the user gets a complete picture before confirming. Group fixes by type for readability (e.g., "842 missing path parameters, 12 duplicate operationIds").

Ask the user to confirm before proceeding. If they want to exclude certain fixes, adjust the flags accordingly.

Step 3: Apply fixes and persist

Run the fix tool without dry_run, using output to write the result to disk:

{
  "spec": {"file": "<path>"},
  "output": "<output-path>",
  "fix_schema_names": true
}

⚠️ Important: The fix tool does not modify the input file. Without output, the fixed document only exists in the response (when include_document: true). Always use output to persist the result for subsequent steps.

For in-place updates, set output to the same path as the input file. Add "include_document": true if the user also wants to see the full corrected spec in the response.

Step 4: Validate the result