BYOK search onboarding, Windows MCP compatibility, and incomplete Chinese localization

[Parcheal]

Existing issues

• I searched open and closed issues for this idea.

Related: #481. This request concerns search configuration and onboarding, rather than reopening the earlier empty-search-result bug.

What problem are you trying to solve?

I use OpenScience for scientific research on Windows, with my own third-party OpenAI-compatible and Anthropic-compatible API providers. I also already have search MCP services configured for other clients. I would like the path from a working model connection to a useful research workspace to be clearer, and the Simplified Chinese interface to be more complete.

Environment: OpenScience 2.0.141, Windows x64, npm CLI/browser workspace. I also encountered configuration friction while using the Windows desktop app of the same version.

1. Clarify and improve web search for users bringing their own API provider

What is the intended web-search architecture for these users: provider-hosted model search, OpenScience's own research tools, external MCP search servers, or a combination? How much of the research/search experience is intended to work independently of the model provider?

I can see that OpenScience already has dedicated capabilities, including research_search, literature, and webfetch. In particular, research_search is made available when Firecrawl or Ace is connected. My concern is discoverability: connecting an API key successfully does not make it clear which web-search capabilities are available, which need separate credentials, and how to reuse existing search services.

2. Complete Simplified Chinese localization and review translation quality

As a Chinese-speaking user, I find parts of the wording unnatural and encounter mixed Chinese/English screens. Beyond that general feedback, the following normal settings controls are still hard-coded English in the source:

• Models/connections: Provider API keys, Add key, and Save key in ProviderKeys.tsx.
• Connectors: the page heading, description, search placeholder, add button, and remote/local connection types in Connectors.tsx.
• Connector connection/authentication status labels in the same component.

Suggested verification: select Simplified Chinese and review Models/connections and Connectors, including status messages, empty states, validation errors, and dialogs. The examples above were verified in source; this report does not include a screenshot-based audit of every screen. The corresponding connector strings also remain hard-coded in the current main branch.

3. Compatibility friction encountered while adding existing search MCPs

• The remote MCP URL validator rejects all query parameters. My existing Exa connection selects tools with https://mcp.exa.ai/mcp?tools=web_search_exa,web_fetch_exa,agent_run,web_search_advanced_exa. Authentication is supplied separately in a header; this query contains tool selection, not credentials. The URL cannot be entered unchanged in OpenScience. See the validator.
• I tried Exa's official local MCP package as an alternative, launched directly with Node. On this Windows installation, OpenScience refused to start it because no sandbox backend was available. The error text included “Running the command WITHOUT isolation,” but the connector remained failed, which was confusing.
• Using the remote Exa URL without query parameters works. With my API key it exposes search, fetching, and agent_run, but not web_search_advanced_exa. This is a usable workaround, with a smaller tool selection than the existing configuration.
• The provider-key form also lacks a custom Base URL field. Third-party provider setup required editing the configuration file. Explaining the expected Base URL format would help, especially when different client SDKs handle /v1 differently.

Proposed change

• Show model connectivity and search connectivity separately, including which search tools are available and which credentials are missing.
• Provide a clear, documented route for adding an existing search MCP, with examples for common providers and actionable authentication/quota errors.
• Document whether provider-hosted search is supported for custom Responses-compatible providers, and how it relates to OpenScience's own search tools.
• Support legitimate MCP tool-selection query parameters, or offer an equivalent supported configuration mechanism.
• Provide a supported Windows local-MCP setup path and make unavailable-sandbox errors accurately describe whether a process was started.
• Add custom provider Base URL entry and protocol guidance to the model settings UI.
• Move the remaining user-facing English strings into the localization system, review Chinese terminology for naturalness and consistency, and check complete workflows rather than only the main navigation.

Alternatives considered

External search MCPs already help: AnySearch search and Monid endpoint discovery were successfully invoked through OpenScience. Exa connects inside OpenScience, and direct MCP search/fetch calls to the configured endpoint also succeeded. The request is to make these capabilities easier to discover and configure, and to reduce the compatibility work required to reuse existing services.

Tavily connected but returned an account usage-limit error during a search. That is a service/account limitation, so I am not reporting it as an OpenScience defect.

No API keys or private configuration are included in this report.

[ishaan1124]

Thanks for the detailed write-up. v2.0.145 (out now) addresses three parts of it:

• Simplified Chinese: every visible string in the Models (provider keys) and Connectors settings now goes through localization, with Chinese translations, including the connection and authentication statuses you listed. Validation errors in the connector form are still English and will follow.
• Remote MCP URLs with query parameters: non-secret parameters such as Exa's ?tools=web_search_exa,web_fetch_exa,... are accepted now. Parameters whose names look like credentials (api_key, token, Authorization, ...) are still refused by name, with a pointer to use a header instead, because the URL is saved in config and shown in logs.
• Windows local MCP error: the server was refused, never started. The message now says that plainly and points to Customize → Sandbox → Fallback behavior (set it to Warn & run to run local MCP servers without isolation on Windows) or to the server's remote URL. Note that Action approval doesn't affect local MCP servers; the connectors docs now say so.

Still open from your list: a Base URL field in the provider-key form (for now, custom providers are configured in openscience.json, see the custom providers docs page) and showing search connectivity separately from model connectivity. I'm leaving this issue open for those.

[aayambansal]

Reviewed the remaining scope. The earlier v2.0.145 fixes cover the query-parameter validator, misleading Windows sandbox error, and the main Models/Connectors translations. This is still open for a custom provider Base URL field, separate visibility of model/search connectivity, and complete validation/dialog localization. Those need workflow-level UI verification; the bug-fix batches merged today do not complete this request.

[aayambansal]

The remaining items are now implemented and merged in #908:

• Provider keys can save a custom API Base URL, with explicit OpenAI Responses or Chat Completions selection and endpoint validation.
• Model credentials and research-search configuration are shown separately. The settings and docs explain Firecrawl/Ace research search, built-in literature and scientific-database tools, and Exa/Tavily MCP setup.
• Model connection controls, connector form errors, confirmation controls, and settings navigation are localized in Simplified Chinese.

The earlier MCP tool-selection query fix and accurate Windows sandbox status remain in place. CUA checks covered the Chinese workflow, endpoint save/refill/reset, and validation; real HTTP tests covered both protocols. All PR checks now pass, including the full frontend suite and affected backend tests. This also fixes an empty-provider-config edge case found in CI.

Available on main for the next release. Saving a credential is not a live provider/quota check. Closing this report as resolved; a new report with the failing provider response is welcome if a particular gateway needs further compatibility work.