This is the right shape for a large collection: the catalogue is data the model reads on demand rather than schema it carries every turn, so adding utilities does not enlarge the context every conversation pays for. The trade is one extra round trip before the first call.
A hosted catalogue of small developer utilities behind a discover-then-execute pipeline. Rather than putting every utility in the tool list, it exposes three: browse the catalogue, read one utility's contract, run it. The definitions riding along on every turn stay at three no matter how many utilities sit behind them.
- The whole catalogue listed, filterable by category, by tier or by exact slug, with each entry carrying its description, input type, keywords, rate limits and endpoint — `list_tools_catalog`
- One utility's full contract read before you call it: required fields, request schema and the from/to/value fields conversion tools use — `get_tool_details`
- Any utility executed three ways — direct text input, a from/to/value conversion, or a structured options object — `execute_tool`
- Categories spanning encode-decode, colour, crypto, formatter, converter, text, image, math, network and date
- Auto-discovery through `.well-known/mcp.json`, so an MCP-aware client can find the server without being configured
A client that speaks Streamable HTTP, pointed at `https://d3v.tools/mcp/tools`. No authentication. Rate limits run 10 requests a minute anonymous, 30 registered, 1000+ on premium, and each catalogue entry carries the tier it belongs to. Some utilities run client-side: for those, `execute_tool` returns your input with `result` set to null and a note to do the processing yourself, so check the `type` field before relying on a server-side answer.
One command — npx -y mcp-remote https://d3v.tools/mcp/tools