What the agent does
The agent begins by identifying the Cloudflare account and the resources its connection can read. The Cloudflare entry in rush/shared/connectors/integrations.ts names "Cloudflare (Workers Bindings)", lists KV, R2, D1 and Durable Objects, and points to https://bindings.mcp.cloudflare.com/mcp. This is an account inventory, not a source-code search: a repository's configuration file can miss resources deployed elsewhere. The agent checks the connected server's actual tool list before promising coverage of scripts, routes or every storage family.
For each visible Worker, it gathers the available route information and binding metadata. The inventory records the script identity, the binding name used inside that Worker, its resource type and the backing resource identifier when exposed. Distinct aliases for the same bucket or database should resolve to one resource rather than becoming several supposed databases. Secret bindings are described by name and type only; their values are not needed for this report and must never be copied into the artifact.
It separately lists KV namespaces, R2 buckets and D1 databases and compares their identifiers with the Worker binding references. A resource that no visible Worker binds becomes a candidate for investigation, not a deletion recommendation. It may be used by an external client or a Worker the connection cannot see. Similarly, a Worker with no custom route may still use workers.dev, a service binding, a schedule or another trigger. The report distinguishes those possibilities from a verified routing problem and marks unsupported route reads as unknown.
The output is inventory.md, with a Worker table, routing observations, storage references and coverage gaps. To execute the minimal request below against an account, explicitly add the connected Cloudflare MCP server's id in connections as documented in the developer API quickstart. Mentioning Cloudflare does not supply credentials, and resources is omitted because no repository is needed. The agent uses read operations only; if a resource class cannot be listed, it says so instead of deploying a helper or broadening permissions on its own.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the explicitly selected Cloudflare connection and inspect its available read tools. If no Cloudflare tools are available, stop and report missing access. Inventory every visible Worker, its available routes and binding metadata, plus visible KV namespaces, R2 buckets and D1 databases. Write inventory.md with account scope, one row per Worker, bindings resolved to resource ids, Workers with no observed custom route, storage no visible Worker binds, and any unsupported or unreadable resource classes. Treat missing routes and unbound storage as review candidates, not proof of disuse. Never read secret values. Read only: do not deploy, delete, change bindings or routes, or modify permissions."
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
inventory.md contains the account scope, a Worker-by-Worker binding map, a resource index and a section of items needing human investigation. Binding rows distinguish the local alias from the backing resource id. The report states whether route information was actually read and which resource classes were inaccessible. Unknown does not appear as an empty list implying that no resources exist.
A reviewer checks the flagged Workers for non-route triggers and the unbound storage for consumers outside Workers before planning any cleanup. Confirm that the connection sees the intended account and environments, and sample a binding in the Cloudflare dashboard. The report proposes no destructive action. Its source tool calls and outputs remain in the Rush session transcript, while the file artifact gives the team a readable snapshot to discuss.
Run it on every infrastructure inventory review
Use your own periodic scheduler to submit the inventory task with the Cloudflare connection explicitly selected. Name the account scope and snapshot date in input, and use an Idempotency-Key so retrying that snapshot starts no duplicate session. A completion-webhook handler can download inventory.md and compare it with the previous report. Treat new review candidates as tickets for investigation, not instructions for an automatic storage deletion.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Bindings create a graph that is tedious to reconstruct by opening dashboard pages one at a time. An agent in a Rush sandbox can assemble that graph from the connection's real responses and keep the unresolved edges visible. There is no need to export account credentials into a laptop script or assume the repository you happen to have open represents the whole deployed account.
The captured record matters when a cleanup discussion turns on whether a database was genuinely unused or merely invisible to the account selected. Independent inventories can run without sharing local files, and each result keeps its account scope and extraction context. The deliverable is an evidence-backed map with honest gaps, leaving operational changes for a separately authorized task.
Frequently asked questions
Does no route mean a Worker is unused?
No. A Worker can be invoked without a custom HTTP route, including through other triggers or services. The report flags missing observed routes for investigation and records available trigger context rather than marking the Worker safe to delete.
Will it delete unbound KV, R2 or D1 storage?
The request forbids all deletions and configuration changes. Storage with no observed Worker binding is only a review candidate. Consumers outside the visible Worker inventory can still depend on it.
Can it expose Worker secrets in the report?
The task explicitly excludes secret values. A binding's name and type are enough to describe the dependency. Keep the report internal as well, because an account's resource names and topology can still be sensitive.
What if the connection does not expose routes or Durable Objects?
The report names unsupported reads and limits its completeness claim accordingly. It does not infer missing resources from an unavailable tool. You can authorize a separately scoped investigation when additional read access is needed.