Proxy configuration is exactly the kind of object where a bad write takes traffic down and the previous state is what you urgently need. Keeping revisions means a change is recoverable by pointing back rather than by remembering what was there. Per-component counters alongside the incoming events feed is the other useful pairing — one tells you what arrived, the other what each component did with it, and edge debugging usually needs both. This is a large administrative surface with real deletion in it, so what the token is allowed to do matters more than usual.
A full administrative client for the Edgee edge platform, structured the way the platform is: organisations containing projects, projects carrying domains, proxy settings and components, and telemetry hanging off both.
- Organisations with complete lifecycle plus user management — list, update and remove users within one.
- Projects with the same completeness, and getProjectCounters for the statistics on one.
- Domains as their own objects under a project: list, create, update, delete and fetch individually.
- Proxy settings kept as revisions rather than a single mutable blob — listProjectProxySettings returns the revision history, and updates target a revision.
- Components with their own lifecycle and per-component counters, so an edge component's traffic is attributable.
- getIncomingDataCollectionEvents returns what is actually arriving at the project, which is the question behind most edge debugging.
EDGEE_TOKEN. The surface includes deletion of organisations, projects, domains and components, so the token's scope is what bounds an agent here.
One command plus a key — npx @edgee/mcp-server-edgee, then supply credentials