Generate Anthropic tool-call schemas from the IR

[DaveHudson]

Context

Contexture already emits Convex schema, Zod, JSON Schema, schema-index, and per-table CRUD from the IR. This adds another emit target: Anthropic tool-call schemas — the input_schema JSON every AI engineer currently hand-authors when wiring up tool calls or structured outputs.

Problem statement

Hand-authoring input_schema JSON for every tool duplicates shape information that already lives in the IR. Every IR change has to be reflected by hand; the tool-call schema drifts most often because it's pure JSON nobody runs locally.

Solution

Opt in via an IR flag (project-level on/off plus per-type opt-in for granularity, since not every entity is a tool). For each opted-in entity, emit <TypeName>.tool.json with the input_schema as Anthropic's API expects, plus a tools.ts barrel exporting { name, description, input_schema } triples ready to drop into client.messages.create({ tools: [...] }). Description comes from the IR's type-level description; name is snake_case(typeName).

Open questions

• Refs vs inline: does Anthropic's tool-call input_schema support $ref / $defs? Verify against current API docs at implementation time. Default to inlining nested types; fall back to $ref only if explicitly supported.
• Empty-description handling: validation warning (current default) versus block emission entirely. Lean toward warning — descriptions are encouraged but not load-bearing for the API.

Out of scope

• Frame extractor scaffolds (the calling code) — that's Generate structured-extraction code for any entity #169.
• OpenAI / Gemini equivalent emitters — separate work if demanded.
• Runtime tool-routing code. Users wire it.

Relationship to other PRDs

• Generate structured-extraction code for any entity #169 (frame extractors) consumes the tools.ts barrel and the <TypeName>.tool.json files this emitter produces.
• Catch hand-edits to any generated file #160 (drift detection) automatically covers the new files — they go in the manifest like any emit target.
• Reconcile drift in any generated file, not just the Convex schema #161 (reconcile any generated file) automatically covers them too.

[DaveHudson]

This was generated by AI during triage.

Confirming the scope of this slice for triage clarity: this is a user-visible feature, not an internal performance or typing improvement.

It ships a new code-generation target — <TypeName>.tool.json per opted-in type plus a tools.ts barrel — alongside the existing Zod / Convex schema / JSON Schema emitters. The user-visible value is that an AI engineer stops hand-authoring input_schema JSON for every tool: they import { tools } from "./tools" and pass it straight to client.messages.create({ tools }). The IR becomes the single source of truth for tool-call shapes.

One small design call worth flagging:

• This slice introduces a per-type tool: true flag, orthogonal to the existing set_table_flag (Convex entity vs value-object). A type can be a Convex table and an Anthropic tool, or one but not the other, or neither. The flags don't conflict, but their interaction across the canvas inspector (two checkboxes per type? grouped under "Outputs"?) is a small UX decision the triage step should surface.

[DaveHudson]

This was generated by AI during triage.

Dependency note: this PRD's user stories reference "entities" and "value-objects" as if they need #156 first. They don't — #156 has been closed because the entity-vs-value-object distinction is already fully wired (`table?: boolean` on object type defs, `set_table_flag` op, Convex emitter filters on it, canvas inspector has the toggle). The Anthropic tool-call emitter can read `type.kind === 'object' && type.table === true` directly when deciding what to emit.

The new `tool: true` per-type opt-in flag this slice introduces is orthogonal to `table: true`. A type can be a Convex table and an Anthropic tool, or one but not the other, or neither. UX for surfacing both checkboxes in the canvas inspector is still the small open question flagged earlier.