v0.14.3

Added

• MCPServer.add_view(name, html=... | path=...) (AGNT5-1569): ship your own MCP App view with a hosted server and show it for a tool's results in clients that render MCP Apps (ChatGPT, Claude, Cursor, VS Code). A view is one self-contained HTML file (for example built with Vite and vite-plugin-singlefile), read when it is added. add_view returns an MCPView (name, sha256, size); pass it, or its name, as view= to add_function, add_workflow or add_agent. Any mode can show a view, sync tools too, and it replaces the run card for that tool. The view gets the tool's structuredContent and text; a call that hands off gives it the run handle in _meta["com.agnt5/run"], and it can poll get_run through the host. Clients without MCP Apps still read the text. Up to 2 MB per view (a larger file is refused before it is read). Views travel in the worker's registration, so the views of all the servers a worker publishes may take up to 3 MB of it, measured JSON-escaped as they travel (registration_size); add_view holds one server to that, and a worker past it refuses to register, naming each view's size. View names follow the server-name rule, and run and none are reserved. A missing file, an oversized bundle, or a view= naming a view the server doesn't have raises ValueError where it is written.
• ctx.progress(progress, total=None, message=None) on function, workflow and agent contexts (AGNT5-1569). It writes a progress.update record to the run's journal: Studio and get_run show the latest report, the AGNT5 run card draws a bar when total is known, and an MCP client that sent a progress token on the tool call hears each report as notifications/progress. It never blocks, works from sync handlers too, and is cheap to call in a loop: each run writes at most one report a second, always the latest, appended at once rather than held until the run completes, shared across the run's contexts (a workflow, its ctx.task children, agents). When the run completes or fails, the latest report is written before the record that ends it; a cancelled execution writes nothing more. Progress never goes backwards: within an execution a report below the last one is dropped, and one with the same figure goes out only when its message or total changed; across executions of a run (a retry, a resumed workflow) the MCP edge and get_run ignore a report below the run's last figure. A progress or total that isn't a number, or a message that isn't a string, raises TypeError; a value that isn't finite or a total that isn't positive raises ValueError. Locally and workerless a report is checked, then dropped. ProgressUpdate gains a progress field and its total is a float. Reports reach MCP clients on runtimes with the matching MCP edge.

Fixed

• Server, tool and view names ending in a newline are refused. The name checks used re.match with $, which matches before a trailing newline, so MCPServer("support\n") passed valid_server_name and add_function("lookup\n", ...) was accepted; they now match the whole name. The bundle travels in the server's definition (views[].html) with its SHA-256; needs a control plane and runtime with custom views, and older control planes refuse servers that publish one.