fix: WebMCP execution input compatibility for v0.5.1 - #15
Conversation
TueJon
left a comment
There was a problem hiding this comment.
skills/webmcpify/templates/webmcp.spec.ts:71 and skills/webmcpify/references/verify.md:76 — the remaining runner guidance still says native getTools() always returns a stringified inputSchema, while this release correctly documents and supports object-shaped schemas in current native implementations. The shipped parsing logic already handles both shapes, so this is non-blocking, but these comments can mislead agents adapting the template.
Closure checklist:
- Update the
listToolscomment inskills/webmcpify/templates/webmcp.spec.tsto describe older-string/current-object compatibility. - Update the LLM-runner bullet in
skills/webmcpify/references/verify.mdto say nativeinputSchemamay be either shape.
|
Resolved the documentation-consistency caveat at b8a4881:
Verification: |
TueJon
left a comment
There was a problem hiding this comment.
No blocking findings. The prior two-item schema-shape documentation checklist is fully closed, with no regression in the compatibility adapter or release surfaces.
Verified with npm run check (43/43), native Chrome 150 proof, and the Workbench browser matrix.
Summary
executeTool()inputEvidence
anyinput objectVerification
npm run check— 43/43npm run workbench:verify— Chromium desktop/mobile/native/CSP gates passnpm run proof:verify— native Chrome 150, detected JSON-string mode, UI delta/invalid input/cleanup passnpm audit --omit=dev— 0 vulnerabilitiesNo merge, tag, release, package publication, or directory mutation is part of this PR.