lmcp: 1.1.0 -> 1.1.1 (bug fix: empty inputSchema.properties) #24

Merged
marfrit merged 1 commits from claude-noether/marfrit-packages:noether/lmcp-1.1.1 into main 2026-05-17 22:48:00 +00:00
Contributor

Tracks upstream lmcp v1.1.1 (commit 9707f7a). Single-bug-fix release.

What's fixed

lmcp:tool() now normalises empty inputSchema.properties by dropping the key entirely. The same json.lua empty-table-as-array gotcha that bit ping in v1.0.0-rc1 was re-surfacing on tool inputSchemas declared with properties = {} — spec-strict MCP clients (Zod-based, like Claude Code's) rejected the entire tools/list response with:

expected: record, code: invalid_type,
path: [tools, N, inputSchema, properties],
message: "Invalid input: expected record, received: array"

JSON Schema permits omitting properties on type:object (means "any object — no constraints"), so dropping the key is both correct and what fixes the wire shape.

Discovery

Live on hertz-tools deployment. Two custom no-arg tools (lxc_list, network_status) registered with properties = {} caused Claude Code to mark the endpoint as disconnected. Hertz was hand-patched in-place before this PR went up; once this lands, pacman -Syu lmcp cleans up that drift.

Surface

Arch:

  • pkgver=1.1.1, no schema change
  • new sha256

Debian:

  • PKGVER=1.1.1, UPSTREAM_TAG=v1.1.1
  • changelog entry

Tarball sha256: 80c2e815aa61a2d3baab051c51cd247bdefa9dd03d72c4867b99c49b6eae9cb9

Test plan

  • CI build (arch + debian) succeeds with new sha256
  • pacman -Syu lmcp on hertz upgrades cleanly; service restarts
  • tools/list against hertz-tools now passes Zod validation in Claude Code (/mcp reload should show all 17 tools, no errors)
Tracks upstream lmcp v1.1.1 (commit `9707f7a`). Single-bug-fix release. ## What's fixed `lmcp:tool()` now normalises empty `inputSchema.properties` by dropping the key entirely. The same `json.lua` empty-table-as-array gotcha that bit `ping` in v1.0.0-rc1 was re-surfacing on tool inputSchemas declared with `properties = {}` — spec-strict MCP clients (Zod-based, like Claude Code's) rejected the entire `tools/list` response with: ``` expected: record, code: invalid_type, path: [tools, N, inputSchema, properties], message: "Invalid input: expected record, received: array" ``` JSON Schema permits omitting `properties` on `type:object` (means "any object — no constraints"), so dropping the key is both correct and what fixes the wire shape. ## Discovery Live on hertz-tools deployment. Two custom no-arg tools (`lxc_list`, `network_status`) registered with `properties = {}` caused Claude Code to mark the endpoint as disconnected. Hertz was hand-patched in-place before this PR went up; once this lands, `pacman -Syu lmcp` cleans up that drift. ## Surface **Arch:** - `pkgver=1.1.1`, no schema change - new sha256 **Debian:** - `PKGVER=1.1.1`, `UPSTREAM_TAG=v1.1.1` - changelog entry **Tarball sha256:** `80c2e815aa61a2d3baab051c51cd247bdefa9dd03d72c4867b99c49b6eae9cb9` ## Test plan - [ ] CI build (arch + debian) succeeds with new sha256 - [ ] `pacman -Syu lmcp` on hertz upgrades cleanly; service restarts - [ ] `tools/list` against hertz-tools now passes Zod validation in Claude Code (`/mcp` reload should show all 17 tools, no errors)
claude-noether added 1 commit 2026-05-17 22:47:35 +00:00
Tracks upstream lmcp v1.1.1 (commit 9707f7a). Single-bug-fix
release: lmcp:tool() now normalises empty inputSchema.properties
by dropping the key, so Zod-strict MCP clients don't reject
tools/list with "expected: record, received: array".

Discovered live on a hertz-tools deployment where two custom
no-arg tools tripped the check and caused Claude Code to mark
the endpoint as disconnected.

New tarball sha256:
  80c2e815aa61a2d3baab051c51cd247bdefa9dd03d72c4867b99c49b6eae9cb9

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
marfrit merged commit 4820e53b18 into main 2026-05-17 22:48:00 +00:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/marfrit-packages#24