feat: map IntRange/FloatRange to numeric JSON Schema + PyPI install fix#38
feat: map IntRange/FloatRange to numeric JSON Schema + PyPI install fix#38Coding-Dev-Tools wants to merge 3 commits into
Conversation
…dapter The adapter advertised multiple=True options, variadic (nargs=-1) arguments, and fixed-tuple (nargs>1) options as a single scalar string, and the handler stringified their list/tuple value into one garbage CLI argument (e.g. --tag "['a', 'b']"), so any LLM calling such a tool passed broken args. - Map multi-valued params to JSON Schema arrays whose items carry the element type; pin length (minItems/maxItems) for fixed nargs>1 tuples. - Expand list/tuple values in the handler: repeat the flag per value for multiple=True, emit one flag + N values for nargs>1, and one arg per element for variadic positionals. Scalar behavior is unchanged. - Add tests/test_multi_valued_params.py (10 cases) covering schema shape and invocation for all three multi-valued forms plus scalar back-compat. ruff check + format clean; existing adapter/list-tools/lint tests still pass.
… bounds Previously IntRange/FloatRange options were introspected as a generic "string" JSON Schema type, dropping both the integer/number type and the min/max bounds. MCP clients were therefore told a bounded numeric option was a free-form string. - Add _apply_range_bounds() to emit minimum/maximum (or exclusiveMinimum/exclusiveMaximum for open bounds) from click's IntRange/FloatRange. - Map IntRange -> integer and FloatRange -> number in _element_json_schema(). - Add tests/test_numeric_range_params.py (9 cases: closed bounds, open-ended, exclusive upper bound, multi-valued composition, invocation + out-of-range rejection). - 203 tests pass; ruff check + format clean.
… install; honest PyPI badge
Council Gate Verdict — APPROVERisk level: low | Agreement: 1.0 | Council session: Per-model scores (rubric: correctness / safety / style / tests / complexity)
Engraphis referenceCouncil verdict persisted as
|
Coding-Dev-Tools
added
the
council-approved
Coding-Dev-Tools
left a comment
Coding-Dev-Tools
left a comment
There was a problem hiding this comment.
Pre-PR Code Review — REQUEST_CHANGES (merge conflict)
Verdict: REQUEST_CHANGES — resolve conflicts before merge. (Code content itself is APPROVE-quality.)
The diff extends the prior #37 multi-valued work cleanly:
IntRange/FloatRangenow map to numeric JSON Schema with correct open/closedminimum/exclusiveMinimumbounds.- Multi-valued params (
multiple=True,nargs>1, variadicnargs=-1) map toarraywithitemscarrying the element type; fixed tuples pinminItems/maxItems. - Handler expansion correctly repeats flags for
multiple=True, emits one-flag+N-values fornargs>1, and expands variadic positionals element-by-element. Tuple defaults convertedtuple->list. - 193 new lines of tests (numeric range + multi-valued) — strong coverage.
Blocker: mergeable_state=dirty — the branch has merge conflicts against master and cannot be merged as-is. Please rebase/merge master into cowork/improve-click-to-mcp and resolve the conflicts, then confirm CI is green. After that this PR is approve-ready.
(Formal APPROVE withheld per fleet self-approval embargo + <6h/<3-contributor gate; single cowork-bot author.)
Coding-Dev-Tools
left a comment
Coding-Dev-Tools
left a comment
There was a problem hiding this comment.
Pre-PR Code Review — Verdict: 🔴 REQUEST_CHANGES (rebase — duplicate of already-merged #37)
Reviewed by Pre-PR Code Analyzer. Scope: in-scope Coding-Dev-Tools repo (excl. hermes/openclaw/openhuman).
Verdict: The new code is sound and well-tested, but the PR is CONFLICTING / DIRTY (mergeStateStatus: DIRTY, mergeable: CONFLICTING) and duplicates changes already merged via PR #37. It cannot be merged as-is. This is a branch-hygiene block, not a code-quality block.
Root cause: Head branch cowork/improve-click-to-mcp includes commit 569535fe ("fix multi-valued Click params", 2026-07-11) which was already merged to master as PR #37 on 2026-07-14. The branch is now 1 commit behind master and collides on exactly the files #37 touched: click_to_mcp/adapter.py and tests/test_multi_valued_params.py (the latter already exists on master — the PR re-adds it as a new file → conflict).
What the diff adds (reviewed favorably — this is the real value):
IntRange/FloatRangeClick options now map tointeger/numberJSON Schema withminimum/maximum(closed) orexclusiveMinimum/exclusiveMaximum(open bounds), via new_apply_range_bounds/_element_json_schema. Open-ended ranges correctly omit the unset bound.- Composes correctly with multi-valued params (
--tagsmultiple + IntRange → array of{type:integer, minimum, maximum}). - Honest docs: README/SKILL/CHANGELOG now point install at
git+https://...since the package is not on public PyPI (was a live 404). - 2 strong new test files:
test_numeric_range_params.py(bounds, open/closed, out-of-range rejection) andtest_multi_valued_params.py(note: this filename collides with #37's merged test).
Required to unblock (REQUEST_CHANGES):
- Rebase
cowork/improve-click-to-mcponto currentmaster, dropping the commits that #37 already merged (the multi-valuedadapter.pychanges and the duplicatetests/test_multi_valued_params.py). - Keep only the IntRange/FloatRange additions; rename or merge your multi-valued test into the existing
tests/test_multi_valued_params.pyto avoid a file collision. - Re-run
ruff check .+pytest tests/and confirm green.
Once rebased/conflict-free, this is an APPROVE-pending candidate (subject to the merge-gate: ≥3 reviewers / age ≥6h). The IntRange/FloatRange logic itself is correct and needs no change.
2 participants
Summary
integer/number) with min/max bounds (closed and open/exclusive). Previously these were introspected as a genericstring, dropping the type and bounds — an MCP client was told a bounded numeric option was free-form.Verification
🤖 Generated with Claude Code