docs(spec): tool.json's parameters note records the post-#13317 reality

.changeset/tool-liveness-parameters-note-post-13317.md

@@ -0,0 +1,32 @@
+---
+'@objectstack/spec': patch
+---
+
+liveness ledger: `tool.json`'s `parameters` note now records the post-#13317 reality (#13345)
+
+The `_note` on `ToolSchema`'s `parameters` entry asserted, in substance, that
+`registerToolFromDefinition` registered every bridged tool with **no**
+`inputSchema` — "so this key never reaches an MCP client" — and cited that as
+the asymmetry with `name` / `description` (filed as #13271). PR #13317
+(`e29fc212`, merged 2026-08-30T04:42:09Z) fixed exactly that: `parameters` is
+now converted through zod@4's `fromJSONSchema`
+(`packages/mcp/src/mcp-server-runtime.ts#toolInputSchema`) and forwarded as
+the SDK `inputSchema`
+(`registerToolFromDefinition`), so the key reaches `tools/list` too. The old
+sentence was stale and, left as-is, would have mis-described the current
+framework MCP bridge.
+
+The note is corrected to record the fix and keep a sharper nuance than "no
+schema" ever captured: the pre-fix behaviour was the SDK synthesising
+`EMPTY_OBJECT_JSON_SCHEMA` (`{"type":"object","properties":{}}`) for a
+schema-less registration — a positive claim that the tool takes no arguments,
+not silence.
+
+The grade does not move: `parameters` was `live` before this change and stays
+`live` — the cloud LLM path (`vercel-adapter.ts#buildVercelOptions`) has read
+it all along, and that's what the verdict has always rested on. This closes an
+asymmetry between two consumers, not a change in liveness status.
+
+Data-only: no schema, no runtime, no authoring surface changes. `liveness/` is
+in this package's `files` array, so this ledger ships in the npm tarball and
+this is published data.

packages/spec/liveness/tool.json

@@ -31,7 +31,7 @@
  "verifiedAt": "2026-08-29",
  "evidenceScope": "cross-repo",
  "evidence": "cloud @15f55df: packages/service-ai/src/adapters/vercel-adapter.ts#buildVercelOptions wraps it with the SDK jsonSchema helper and passes it as the tool's inputSchema, which is what constrains the arguments the model may emit",
- "note": "LLM function schema. Re-closed 2026-08-29 against cloud @15f55df. ⚠ Deliberately NOT co-cited to the framework MCP bridge, and the asymmetry with `name` / `description` is the finding: registerToolFromDefinition registers each bridged tool with NO inputSchema, and the annotations it does pass carry only destructiveHint / readOnlyHint / openWorldHint — so this key never reaches an MCP client, while its own docblock claims the JSON Schema is passed as annotations metadata. Filed as #13271. The verdict rests on the cloud LLM path alone, where it is unambiguously live."
+ "note": "LLM function schema. Re-closed 2026-08-29 against cloud @15f55df. The verdict itself never moved — this row was `live` throughout on the cloud LLM path alone (vercel-adapter.ts#buildVercelOptions), which is what the asymmetry below was measured against. ⚠ 2026-08-30 (#13345): the asymmetry this note used to record — registerToolFromDefinition registered each bridged tool with NO inputSchema, so this key reached the cloud LLM but not an MCP client, contradicting its own docblock — is CLOSED, by #13317 (`e29fc212`, merged 2026-08-30T04:42:09Z, filed as #13271). `packages/mcp/src/mcp-server-runtime.ts#toolInputSchema` (L223-242) now converts `AIToolDefinition.parameters` through zod@4's `fromJSONSchema`, and `registerToolFromDefinition` (L998) forwards the result as the SDK `inputSchema` (L1005), which the SDK converts straight back to JSON Schema for `tools/list` — the key reaches MCP clients too, now on both consumers. The pre-fix behaviour was NOT silence, and the replaced wording overstated it as such: a schema-less registration made the SDK synthesise `EMPTY_OBJECT_JSON_SCHEMA` (`{\"type\":\"object\",\"properties\":{}}`) — a positive claim that the tool takes NO arguments, sharper than an absent key would have been. #13317 closes the asymmetry, not the grade."
  },
  "objectName": {
  "status": "live",