Ask should be able to use an external MCP connector

[NickPitas]

Problem

Ask only searches sources and notes that already live in the notebook. Open Notebook can already act as an MCP server, so another assistant can read a notebook. It cannot act as an MCP client. A connector that already exists somewhere else (documentation, tickets, another corpus) stays invisible to Ask unless it is copied in as sources.

Outcome

An operator can point Ask at one Streamable HTTP MCP server. Each Ask search term is also sent to one tool on that server, and the snippets are mixed with the local hits. With the URL unset, Ask behaves exactly as it does today. If the connector is down, times out, or returns an error, Ask still answers from local results.

Constraints

• Opt-in. The search term leaves the machine only when the operator sets the URL.
• No new model provider, no notebook import, and no change to notebook chat or source chat.
• Connector snippets must not be mistaken for source:, note: or insight: records.

Possible direction

A small client on the MCP Python SDK's Streamable HTTP transport, configured with environment variables. It calls one tool (default name search) with {query, limit}. Returned ids are prefixed with external:, so they show up as labels in the answer and are not links to notebook records.

There is a draft implementation on NickPitas:feat/external-mcp-retriever. It is a draft on purpose: this is a feature, and the contributing guide says the design should be agreed here before it is treated as approved work.

[NickPitas]

Draft implementation, opened so the code can be looked at without treating it as approved work: #1498