feat(mcp): surface the 'author your own operator' posture to the LLM

[jeffcrouse]

Problem

The MCP server already understands the operator library deeply and accurately — list_operators/find_operators/find_params read the live registry with per-param semantic hints (intent/tag/unit), and the full authoring loop exists (scaffold_operator_package, scaffold_project_shader_operator, build_/reload_operator_package, clone_operator). What was missing: it never told the driving LLM when to author. So an agent that couldn't find a fitting built-in would force-fit one — the opposite of Vivid's north star (built-ins are teaching examples; the plumbing to author your own is the product).

Change (bridge-only, pure Python — no control-server change, parity unaffected)

1. FastMCP(instructions=…) — server-level posture the client sees up front: authoring is first-class and the encouraged default when a built-in doesn't match intent; the discover → author → compose → verify workflow.
2. find_operators nudge — a no-match reply now carries an authoring_suggestion pointing at get_operator_authoring_guide + the scaffold tools (and the docstring says so).
3. get_operator_authoring_guide() — a new guide: when to author vs reuse, the two op kinds (C++/GPU vs WGSL/GLSL shader), the scaffold→build→reload loop, and the real gotchas (project ops ship with the project and compile on load_project; build failures now surface via get_health.errored_ops; WGSL smoothstep edge-order UB; relaunch if a project op renders black after churn).

Verification

test_mcp_parity + test_mcp_arg_parity PASS; the nudge fires only on count==0 (not when there are matches); the guide returns its six sections; FastMCP accepts instructions.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QB6eSNJE55ru3g4vsL77GT