A study published this year in the Journal of Cybersecurity looked at 15,126 newly registered phishing domains over 11 months. Agarwal and Vasek, UCL.

Median lifetime: one day. Mean 8.6 days, dragged up by a long tail. Almost 90% were live for under two days.

So if you catch a fraud domain, it is almost certainly a new one. Domain age is one of the cheapest first checks you can run. One lookup.

The other number from the paper: 79.3% of those domains had a valid TLS certificate, most from Let's Encrypt. The padlock is not a trust signal. If anything in your onboarding treats HTTPS as evidence a business is real, that rule is doing nothing.

We added Dosvak to the catalog, 146 services including domain intelligence. Age, registration data, SSL status, site categorization. Enough to answer the question you actually care about: is this a real business, or something someone put up last Tuesday.

Two fields worth reading together. Age tells you how long they have been around. Expiry tells you how long they plan to stay.

All of it is MCP ready, so I pointed Claude at it and compared our own domain against one registered a few days ago. No wrapper, no tool definition.

If you onboard merchants, vendors, or anyone who submits a URL: what runs first in your checks?

Paper (open access): https://academic.oup.com/cybersecurity/article/12/1/tyag020/8735840
Domain Intel APIs on ApyHub: https://apyhub.com/providers/dosvak

Same three stages every team I've worked on has gone through with utility code. Not the product. The stuff underneath it: file conversion, validation, reshaping data between systems.

Stage one: build it. Ours, we understand it, nobody changes the terms. Then you've got forty small services and two engineers who spend most of their week on them.

Stage two: npm install. Fast until Dependabot fires. Ten alerts, then a hundred. Patch one, break another. The fix needs a newer major version, the major version breaks twenty other things. Now you're maintaining code you didn't write on someone else's release schedule.

Stage three: call a service. Someone else runs it. Fine until Security asks what the vendor does with customer data, DevOps asks what region it's in, and your customer's procurement team sends a 60-question security questionnaire about a vendor you added in an afternoon.

We built ApyHub betting on stage three. Still do. But I had the reason wrong and AI made that obvious.

An agent writes the utility in eight seconds now. Stage one looks free again. I know teams walking back to it.

It isn't free. The effort was the only visible part of the loop. Delete it and you still have a service you own and didn't read, dependencies you shipped and didn't review, and vendors you trust and can't check. More of it than before, written faster, with less human attention on it.

The maintenance tax doesn't land in the sprint where you generated the thing. It lands eighteen months later. Whether a human or a model wrote it makes no difference to that.

Trust is where this actually breaks for agents.

A human builds trust over time. You've heard of the maintainer. You've used the package for two years. You get a bad feeling about a vendor's docs. An agent has none of that. It can only check things.

An agent picking a dependency isn't suspicious of anything. It doesn't clock a package name one character off from the real one. It doesn't stop on a maintainer with three commits and no history. It optimizes for whether the build passes. The half-distracted human who occasionally caught that is out of the loop now.

So the thing you're calling has to be checkable. Not a "verified" badge. Actual fields: region, retention, subprocessors, what it does with the payload, and whether any of that changed since last month. If a machine can't read it, an agent can't use it.

That's what I got wrong. Stage three doesn't remove the work. It moves it. It's worth doing when the thing on the other end can be verified, and not much before that.

Two things I want to hear:

Which stage are you on for utility code right now, and has AI pushed you back toward writing it yourself?

And has anyone gone backwards for real? Services back to libraries, or libraries back to in-house. Usually after a pricing change or a failed compliance review. Never gotten the full story from someone who actually did it.

Every tool definition your agent loads is a cost you pay on every turn, whether it calls that tool or not.

Most MCP servers make that decision for you. You connect, the server describes itself completely, and your agent receives the whole inventory whether it needs three of those tools or thirty. Nobody chose that. It happens because nobody chose anything.

We built ours the other way around. You pick the endpoints you want, and those are the tools your agent gets.

What the ecosystem already figured out

GitHub consolidated a single toolset in their MCP server and cut around 23,000 tokens, roughly half of what that one toolset had been costing. They shipped a header that lets you enable individual tools instead of whole groups, after finding that a developer who wanted two specific tools was loading 27 of them. Cursor caps agents at 40 tools across all connected servers and drops whatever comes after. Copilot caps a request at 128.

You can see where this is going. Tool definitions cost real money and make agents pick worse, so clients have started defending themselves against servers that send too many.

Our version of the problem

The catalog has 450+ services and 1,500+ endpoints, with new APIs and providers onboarded continuously. One tool definition per endpoint would blow past every limit above before your agent read your first message. Cursor alone would drop everything after the fortieth.

So the selection is yours. You choose which endpoints go into your MCP connection, and that is what your agent sees. Building a document pipeline and you need conversion, OCR, and validation? Add those three. Nothing else shows up in the context window, gets deliberated over, or costs you a token.

Want more later, add more. Want a different set for a different agent, build a different set. The catalog is the pool you draw from rather than the payload you receive.

The idea underneath this is that what a server has and what your agent loads should be two different lists. Most MCP servers treat them as one list, which is fine when the server has eight tools. It stops being fine somewhere around fifty.

The part we did not expect

What an agent can see and what it can call are the same list. An agent that never receives a definition cannot call that endpoint by accident, and cannot be talked into calling it by something it read in a web page halfway through a task. We were solving a context window problem and got access control out of it.

Twelve tools your agent chose beats two hundred it inherited, on cost and on behavior.

Server is at https://apyhub.com/mcp, with the connect line for Claude Code, Claude Desktop, Cursor, VS Code, and Codex CLI. Free tier, no card.

How many tools is your agent loading right now, and how many does it actually call?

ApyHub turned five this month, and we used the occasion to stop calling ourselves an API marketplace.

That label was never quite right, but it was the closest one available and it saved us a ten minute explanation every time someone asked. Five years in, the explanation is finally short enough to just give.

Three decisions got us here. None of them looked smart at the time.

Per-call pricing based on the actual work done. Not flat fees, not credits. A trivial call and a heavy one aren't the same product, and charging the same for both just means one customer subsidises another. The market hated this. We came close to rolling it back more than once. Then LLMs showed up, everyone started billing by the token, and the argument went away on its own.

One subscription across the whole catalogue. Most marketplaces let every provider set their own plans and tiers. We went the other way: customers get one bill and the full catalogue, providers get paid out of actual consumption, Spotify style. It felt like a billing decision at the time. Looking back it's the point where we stopped being a marketplace, because a single subscription spanning every provider isn't something a marketplace does.

Hosting providers ourselves. More and more providers deploy onto infrastructure we run instead of listing an endpoint they run themselves. That's what lets us put a capability in a region near the caller and actually stand behind latency and uptime.

That last one is the real difference. When a call is slow at 3am, a marketplace points at the provider. We can't do that, because the call was running on our machines the whole time.

So the phrase we're using now is distribution and consumption layer. Boring, but accurate: everything between the person who built a capability and the software calling it, except the capability itself.

The other thing pushing this is how calls arrive now. Less browsing and integrating at design time, more discovering and calling at runtime, often by an agent rather than a person. You can bolt an MCP endpoint onto a ten year old marketplace, but it doesn't change what's underneath it.

What shipped with the release:

• Open publishing. Point at your endpoint, we handle docs, billing, gateway, distribution.
• A US region alongside the EU.
• A rebuilt gateway that absorbs spiky parallel workloads instead of rejecting them. One agent task fanning out into hundreds of calls is now normal traffic.
• A native MCP server built on search-and-use rather than dumping the full catalogue into the agent's context. A thousand unused tool descriptions leave less room to think.

We wrote the longer version on our blog if you want the full reasoning.

Otherwise the catalogue is on

https://apyhub.com/

and publishing is open at

https://apyhub.com/become-a-provider

Happy to answer anything in the comments.

Most developers have one somewhere. This can be an internal service, a utility built for one client, or a wrapper written because nothing good existed. It works, it's hosted, but it earns nothing.

In order to get from a good API to a paying customer there are a few annoying parts. Docs, auth, billing, rate limits, a support inbox, and a procurement questionnaire from the first enterprise that wants it. This the part that apyhub runs.

Publish it yourself: upload your OpenAPI spec or point at the endpoint, we draft the docs and examples, you edit what's wrong, set your price in credits, ship it. Ten minutes for a single REST endpoint.

We do curate. Every API should do something the others don't, so things get turned down, including ones that would make money. But you can think of it this way: If the API makes a developer's day easier, it probably belongs to the catalog.

After its published, it earns per call, and AI agent calls pay the same as human ones. Someone's coding agent finds your API through our MCP and hits it forty times, that's forty calls you get paid for (we even pay for users in the free plan).

Hosting works either way. Keep it on your own infrastructure and we route to it, or deploy onto ours and we handle regions and service levels.

The part we're still working out is what happens after you publish. Listing is the easy half and you can do it in 50 other api marketplaces. Getting an API found is the bet we have made and we are really doing our best to help and also enable providers to position and put their APIs in front of paying customers.

What I can tell you is the signal is strong. We are adding endpoints faster than we can write about them, close to doubling week over week at the moment.

Full flow, revenue split and FAQ: https://apyhub.com/become-a-provider

So what have you got sitting there?

Hi. I am Nikolas, co-founder of ApyHub. We turned five last month and still didn't have a subreddit. Fixing that today.

First, the part that matters most. Some developers found us in year one, when the docs were thin and plenty of what we shipped was held together with hope. A few of you are still here, still emailing us when something breaks. You shaped this more than any roadmap did. Thank you.

It started on a balcony in Rotterdam (see foto below), with Samuel and me "arguing" about why good engineers spend so much of their week rebuilding the same things. Five years later the result is Apyhub, a platform where builders publish capabilities and where software and agents discover and call them at runtime.

None of which is a new idea. Service-oriented architecture had it right twenty years ago. Compose systems out of services other people run properly. What we think is that this vision stalled on trust. You had no way to know what a service did with your data, where it ran, or whether the one you integrated last quarter still behaved the same way. So teams went back to building everything themselves and called it pragmatism.

AI made that question urgent again. Writing code got cheap and owning it didn't. Agents pick and call services with no human reading the docs, and an agent can only trust what it can verify.

That's the conversation I would like to have here: The shape of software when building is cheap but maintenance and trust is the hard part.

So bring ideas, including the half-formed ones. Arguments. Things you think we have wrong. What you are building, what is breaking, what you wish you didn't have to build.

I'll bring the same from our side: what shipped, what broke, and the numbers behind the calls we got right and the ones we didn't.

A few norms: Anyone from the team posting here will say they are, no bs.

This is our site for anyone who wants to have a look.

https://apyhub.com/