How are you finding people willing to help maintain the provider layer?

[flyoung588]

I noticed MetaSearchMCP is taking the “agent contract first” route rather than cloning browser-oriented metasearch UX: stable JSON, provider-level metadata, timeout isolation, deduplication, and MCP over stdio.

The provider surface is also pretty wide already — direct Google scraping with consent-cookie/locale handling, SerpBase/Serper fallback, plus DuckDuckGo, Bing RSS, GitHub, Stack Overflow, npm, PyPI, Wikipedia, etc. My outside read is that the hard part may become less “can this work once?” and more “who keeps each provider adapter healthy when HTML/API behavior changes?”

I’m Ray, a founder working in an adjacent devtool/open-source space. This is a genuine question, not a pitch:

For a project like MetaSearchMCP, have you found any channel that actually works for finding contributors who will take ownership of a provider/integration area, or is it mostly manual outreach and waiting for drive-by PRs?

A short reply is plenty — I’m trying to understand whether solo technical maintainers are already feeling this contributor-recruiting problem in practice.

[gefsikatsinelou]

Thanks, this is exactly the maintenance problem I'm thinking about.

My current view is that provider ownership has to be split into two layers:

1. community / best-effort providers, where occasional breakage is acceptable and contributors can own small adapters;
2. stable fallback providers, where the contract needs to keep working even when HTML layouts or upstream behavior change.

For Google specifically, I don't think direct scraping alone is a sustainable long-term answer. It is useful as a local / experimental path, but it needs hosted fallbacks like SerpBase or Serper so the MCP contract does not break every time the page changes or a datacenter IP gets blocked.

On contributors: I haven't found a magic channel yet. My best guess is to make provider ownership very small and explicit: one adapter, one fixture set, one health check, one documented contract. Then it becomes easier for someone to "own GitHub search" or "own PyPI search" without becoming responsible for the whole project.

So the plan is probably:

• keep the core schema stable;
• add provider-level tests and fixtures;
• mark unstable providers clearly;
• make adapter ownership low-friction;
• use hosted APIs for high-value providers where reliability matters more than ideological purity.

Still early, but yes, I think this is the real long-term problem for projects like this.