How it's built
How CP-MCP is built
A focused connector: one tool, a PDF-derived index, and a few Cloudpath quirks solved once.
A PDF, an index, and one tool
Cloudpath publishes its API only as a 214-page PDF user guide. I wrote a Python extractor to turn that into a slim bundled JSON index of 175 operations, organized by surface and tag, plus a fuller spec with property tables stored in R2 and loaded on first use.
That index is what lets Claude find the right endpoint without me writing 175 individual tool definitions. Claude writes a short server-side script, the sandbox runs it against your Cloudpath, and the result comes back in one round trip. The same pattern handles pagination and cross-tag queries, so 'list every DPSK pool with its policies' completes in one ask.
What a live instance taught me
I tested against a Cloudpath cloud instance to find the things the PDF does not say. The API expects the session token in Authorization without a Bearer prefix. Expiry timestamps carry a bracketed time-zone suffix that must be stripped before parsing. Both 401 and 406 mean the token has expired, so the client retries once.
Binary uploads for portal logos had a different gap: the multipart form-field names are not in the PDF. I found them by testing; a wrong field name returns 200 OK and silently clears the stored image. The AI model outputs a square by default, so I add a composition hint to keep the subject inside the 4:1 crop, then lay text over it with Satori.
Size and state
The Worker is about 3,960 lines of TypeScript; the React dashboard is about 2,660. Most of the initial product came together over five days in April 2026, followed by a hardening pass in September that ported SSRF protections from a sibling product. Two test files cover host validation and the retention sweep; I run them locally. Built alongside R1-MCP and SZ-MCP, same connector pattern, different platform.