[zmofei]

A review of every --help and --schema description turned up text that was cut off, rendered as raw Markdown, wrong, or unusable as written. One commit per kind of change:

• Trailing optional positionals (static get-image, get-tile, tilesets get-tile) can be left off instead of passed as "". feedback moves to the Maps and data help group.
• Boolean flags take =false. Before this, a flag could only send true, so attribution, logo, autocomplete, dedupe and continue_straight, which default to true, could never be turned off. The bare flag still sends true, and in a workflow step false still leaves the flag out. directions --snapping-include-* now take one value per coordinate (true;false); the old switch sent a single true, which the API rejects with a 422.
• --help shows each parameter's whole description, not just its first sentence. A command's or service's own description shows its opening prose as plain text, followed by a Docs: link, instead of the whole Markdown page (geocoder batch was 113 lines). --schema still carries the full text.
• --schema now fills env and default for arguments that read them in code, and adds a top-level groups list with what each command group's own help says. --id on a non-API command is now a usage error (exit 2) instead of being ignored; before, history show --id x showed the newest run.
• Wording fixes in hand-written commands and custom-openapi/. docs.tsv now ranks 23 queries first, up from 22. issues.tsv top-3 is 66, one below its recorded 67 and within the slack; the point was lost when usage --help stopped linking the issue tracker.

Compatibility: the --id error and the snapping change are the only behavior changes for an existing command. The snapping switch never produced a working request, and --id used to be silently ignored. The --schema additions don't bump schema_version. All changes are in CHANGELOG.

Verified against the production API: static get-image --attribution=false drops the attribution. --dedupe=false, --autocomplete=false and --continue-straight=false reach the request as false; I didn't check what each one changes in the response. snapping_include_closures=true;true is accepted and a lone true is a 422. A comma-separated matrix sources is a 422. For feedback create, plain base64 screenshot is a 400 and a data URI is accepted; the feature coordinates aren't validated or returned. That test left three "please ignore" feedback items on a test account.

Not verified: the mcp install long help says the hosted server asks the agent to sign in on first use. I haven't tested that.

[mattpodwysocki]

Thanks, this is a really nice cleanup. I checked the true/false flag change against a build from main. --flag and leaving the flag off behave exactly as before, --flag=false and --flag=true used to be usage errors and now work, and --flag false is still rejected, so nothing that worked before changes meaning. Tests, fmt and clippy all pass locally.

Two small things, neither blocking:

1. In --schema the snapping flags go from a boolean flag to a string option. I agree it's a fix since the old form always got a 422. Just flagging it so we're deliberate about calling it that.
2. In workflow/runner.rs a step's false still drops the flag, so a workflow can't turn off attribution or logo. The comment's reasoning (an API reading presence rather than value) applies equally to --flag=false on the command line. Maybe a doc note or a follow-up issue?

Looks good to me otherwise.

[zmofei]

Thanks! Rebased on main. Both addressed in d4154f6: the CHANGELOG snapping entry now calls out the --schema shape change as a fix, and workflow/README.md notes that a step's false leaves the flag out, so a step can't turn off a default-true flag (a script step can, via $MAPBOX_CLI ... --attribution=false). I also corrected the runner comment: the real reason is keeping existing workflows' requests unchanged, not presence-reading APIs. Actually sending false from a step could be a follow-up if anyone needs it.