Wrap the three or four calls you actually need as tools, not the vendor's whole API. Name each tool after the job an agent asks for rather than after the endpoint, keep the credential outside the code, and expect to maintain it when the vendor changes something.
The mistake is mirroring the API. An agent does not want GET /v2/contacts with
nineteen query parameters, it wants one tool called something like find a work email that takes a
name and a domain. This directory's job vocabulary is exactly that shape: 55 verbs with
objects, phrased from the agent's side, and it is a reasonable naming source for your tool
surface.
117 entries here have no server found. The more interesting cut is by job: some jobs have no tool at all with a first party server, which means every agent builder who needs that capability is currently writing the same wrapper. The list of jobs with zero official servers is published here.
Check the vendor's terms. A server that automates access in a way their terms forbid is a problem you inherit, not one you solved. And if you do publish it, tell them: a community server the vendor knows about is considerably more likely to survive their next API change.
If you build one for a tool listed here, send it in. It gets recorded as community, with your URL, and the entry stops saying none found.
Every number on this page is generated from directory.json at build time and carries the date it was baked: 2026-08-25. Nothing is typed by hand, nothing is rounded, and nothing is estimated. The underlying data is published in full. Where the honest answer is a zero, the zero is printed.