An agent-friendly program needs discoverable operations, exact targets and a way to inspect work already started. I did not measure convenience by the size of an unrestricted execution opening. Revisiting Northstar's contracts shows where that convenience comes from and which operations still require a different level of trust.
Give each operation the inputs it actually needs
ToolCall uses strict schemas discriminated by the tool name. File description takes IDs; upload takes an observed reference and fileIds; outcome verification takes a tab and bounded wait. One generic text box does not interpret a path, script and intention as interchangeable authority.
The policy unit test rejects browser.evaluate and an arbitrary-path artifact.write as public ToolCall inputs. That does not mean every program lacks JavaScript or file writes. It closes an arbitrary-execution entry in this browser-action contract. Other features retain their own contracts and executors, which must be read before making claims about their authority.
Reuse a discovered capability instead of recreating it
The current external workflow inspects context, lists and inspects enabled plugins, then reuses a suitable one. Run starts the existing Python or notebook executor and returns a run ID; status inspects that execution. It does not install a permanently judging internal model beside every operation.
Tool families expand on demand so the caller can discover detailed input contracts without resending every definition at every step. Convenience comes from searchable capabilities, explicit inputs and a stable execution identity. A successful start response still differs from a verified business outcome. The API should make that distinction easy to inspect rather than require the caller to remember it from a prompt.
An observed target still belongs to a particular task
Browser actions pass ActionBroker checks for tab owner, profile, workspace and URL scope. Changed execution generation or non-running status is rejected. Reading a page does not grant permission to write through any tab, and an accurate reference still needs the current ownership relationship.
I therefore do not describe opening raw CDP or arbitrary caller JavaScript as the default repair for a contract failure. Internally running a fixed DOM-reading function differs from exposing a public operation accepting arbitrary code. A convenience improvement should preserve the original checks and explain which one failed instead of quietly routing around the contract.
State the authority of Python execution plainly
External MCP also reads, saves, runs and stops an existing project notebook. Its documentation explicitly says Python retains the person's local permissions. That is a boundary for trusted programs and requested execution, not a safe sandbox that an arbitrary webpage may invoke at will.
The absence of a generic shell method in the browser API does not imply that Python can never touch a shell or files. Preserving user cells and staying within the actual request still matter. Explain which restrictions are structural and which operations execute trusted code, so users do not assign the narrower browser contract's guarantees to the entire local runtime.
A convenient tool also makes uncertain results inspectable
A disconnected client must not assume the previous action was unsent. Read the run ID and current context, then use the outcome path when delivery is uncertain. In the current product, new AI judgment belongs to the connected external conversation while the app retains execution and state. Retired embedded repair is not advertised as a present convenience.
This account compares current contracts, documentation and refusal tests without invoking a new model or operational program. The reusable design is a flow where capability discovery, exact target, trust level and result evidence are all readable. Clear failure reasons and next checks can improve the experience for both agent and person without increasing authority.