Contextual surfacing is the right instinct — it's essentially dynamic tool windowing. The interesting design question is what signals you use to determine relevance: URL pattern, page content category, prior agent action, or something else?
I've been packaging reusable MCP tool schema definitions (the JSON spec layer, not implementations) as a way to give agents a consistent vocabulary across different harnesses. The hallucination problem you're solving at the surfacing layer is related but distinct from the schema consistency problem — both matter for reliable tool use in production.
The supervisor sidepanel concept is the right mental model — I've found that the biggest problem with agent-driven browsers isn't the automation itself, it's the human not knowing where the agent is in its reasoning loop when things go wrong.
Curious about the MCP tool schema design: with 40+ tools, are you using a flat tool registry or do you have any grouping/namespacing? I've run into issues where agents get confused when they have too many tools with similar-sounding names and start hallucinating tool calls that don't exist.
The MCP server connection support is the most interesting part to me. One pain point I keep running into when integrating MCP tools is that there's no canonical schema for the tool definitions themselves — every team reinvents the JSON structure for things like web-search, memory, file-system, etc.
Are you planning to include any standard tool definition library with OpenHarness, or is the intent to stay lightweight and let users bring their own tool schemas?