A single tool that took a capability and returned a result would be easier to use and would hide the step that matters — which provider, at what price, ranked how. Splitting them means the choice is visible and the call targets something that was actually found. For a pay-per-request marketplace that distinction has a cost attached: a fabricated endpoint is a failed paid call. Worth understanding what this is: a router to other people's paid APIs, so the quality of any answer is the quality of whichever endpoint discovery ranked first.
A discovery and invocation layer for pay-per-request APIs: list the capability types available, find ranked endpoints for one, and call an endpoint you have already discovered.
- list_capabilities enumerates the kinds of API available, which is how you find out what the marketplace covers before searching it.
- discover_paid_api returns ranked endpoints for a given capability rather than a single recommendation.
- call_paid_api invokes one, and its description says explicitly that it follows discovery — so the endpoint being called is one that was found rather than one that was assembled.
Nothing to supply for discovery. Calls are pay-per-request, so invocation draws against whatever account the endpoint bills.
One command — npx @entroute/mcp-server
