I was trying to solve one problem: how do agents find the right tool? I ended up building three things. Which one do you think developers actually wanted?
Three pieces, one problem
All three grew out of the same exploration. First, skills on OpenClaw. Self-contained Python scripts, stdlib only, no pip dependencies. I learned the "no dependencies" part the hard way. OpenClaw's security scanner flags anything it can't fully trace, so if you import httpx, your skill gets marked Suspicious regardless of what it does. I published skills as I went. Search, then a researcher, then an MCP server finder. Each one reflected where my thinking was at the time. The latest one pulls MCP discovery and OpenClaw skills into a single call. The boundaries between them kept shifting because from the agent's side, they were never real boundaries to begin with.
Second, MCP server discovery. Post 1 told the crawl story. 7,500+ servers across GitHub, npm, PyPI, and the official registry. Ranked by community trust. The MCP standard is maturing. The Linux Foundation is backing it. Discovery felt like the real product, the thing developers would point their agents at. I built a dedicated /find endpoint, polished the ranking, and waited.
Third, search. I needed it to support the other two. In my head it was infrastructure, not product. I didn't even feature it on the landing page at first.
What actually happened
Over 100 agents showed up. They made nearly 3,000 searches, including my own test traffic. But the developers who configured those agents weren't pointing them at /find. They weren't browsing the skill catalog. They were calling the search endpoint.
The topics picked up where Post 1 left off. Product pricing. Regional government regulations. Crypto research. Scheduled queries running daily in multiple languages. The same pattern as before: developers building agents need their agents to find information right now, at runtime. Discovery is a configuration-time concern. Which MCP server should I wire up? Search is a runtime concern. My agent needs an answer for this task. Runtime wins because that's where the value gets delivered.
The search endpoint was the whole relationship.
One loop, not three products
Here is what I didn't see coming. Search wasn't just the most popular endpoint. It was the one that made the other two better.
When agents use the search endpoint, the system learns from what happens next. That signal feeds back into discovery and skill rankings. The details are a blend of explicit and implicit indicators, but the point is simple: usage makes the system better. The signal is accumulating. Every outcome teaches the system something about which results actually helped.
This is the thing the fragmented approach can't do. If you wire up a search API, configure MCP servers by hand, and browse a skill catalog separately, each piece works fine in isolation. But none of them learn from the others. There's no signal flowing between them. You get three tools. You don't get a system.
Skills, discovery, and search are not three products. They're one feedback loop. Search is the entry point. Usage is the signal. The loop closes itself.
What I didn't expect
I thought developers would come for discovery and stay for skills. Instead they came for search and never needed to know the other two existed. The endpoint they call every day is the surface through which the whole system learns.
I don't think this is unique to Meyhem. I think this is how agent infrastructure works in general. Developers choose products. Agents call endpoints. When the product layer disappears, what's left is the endpoint and what it returns.
The thing about configuration-time decisions is that developers make them once. They evaluate options, pick a tool, wire it up, and move on. Runtime decisions happen on every request. An agent that searches ten times a day generates ten times as much signal as a developer who configured an MCP server last Tuesday. The entry point that wins is the one in the runtime path, not the one in the setup docs.
This also explains why the skills consolidated. I started with separate skills for separate tasks. But once search became the entry point, the natural thing was a single skill that searches across everything. The product boundary between "find an MCP server" and "find an OpenClaw skill" and "search the web" stopped mattering. From the agent's side, it's all the same call.
The product is the loop. The entry point is whatever agents reach for first.
Try it
The search endpoint is open:
curl -X POST https://api.rhdxm.com/search \
-H "Content-Type: application/json" \
-d '{"query": "best database connector"}'If you want MCP server discovery specifically, the MCP server is at /mcp/:
{
"mcpServers": {
"meyhem": {
"url": "https://api.rhdxm.com/mcp/"
}
}
}Or POST to /find-capability with a query.
Agents that report selections and outcomes get results that improve over time. The docs explain how.
The loop is running. The signal is accumulating.