Cursor's plugin.json puts agent tool scope where a code reviewer can diff it

Registering a tool as a Python function or a TypeScript method binds it at import time. The scope of what that tool can reach is whatever the module can reach, and the only record is the call graph. The manifest approach moves the declaration into a file: name and category, description, entry point, dependencies, and orchestration hints, according to the dev.to write-up ^[3]. That file sits in the plugin's own directory at `.cursor-plugin/plugin.json` ^[2], where a reviewer can diff it and a CI job can parse it.

The hints are hints. Flags like `parallel: true` tell the orchestrator how to fan work out ^[4], and the post says the structure prevents scope creep, with a security auditor that does not accidentally pull in unrelated tools as the example ^[5]. A directory boundary and a dependencies list are declarations. Until a loader refuses an undeclared import, the manifest documents scope without bounding it, and the write-up does not say what validates the manifest or whether anything enforces the list ^[17]. It does say the orchestrator reads the flags to decide whether to block on verification or stream partial results ^[6].

The thermos plugin is where the concurrency shows. Three subagents run in parallel: one scanning for SQL injection, XSS and auth bypass, one for race conditions and memory leaks, one for style and documentation coverage ^[8]. Each writes to a shared state object, described as a JSON file at `.cursor-plugin/state/thermos.json` with keys like `security_findings` and `correctness_issues` ^[9]. The orchestrator reads that state and decides whether to block the merge or surface warnings ^[10]. The write-up says nothing about a lock, a queue or a per-subagent file in that write path ^[19].

The memory plugin trades one growth problem for a different one. Transcript chunks go through a lightweight LLM call, the extracted bullets append to `AGENTS.md` under a timestamped section, and other plugins read that file to adjust behaviour ^[12]. The manifest names the location in a `state_file` field ^[13]. The post frames this as avoiding context explosion, where every agent call carries the full conversation history ^[14]. The write-up describes no pruning step, so the file only ever gets longer ^[20].

One detail decides how much of this you should code against. The write-up names the verification flag as `requires_verification: true` in its field list ^[4] and as `verification_required: true` when it describes orchestrate's manifest ^[15]. Those are different keys, so at least one of them is wrong ^[16]. That is an argument for reading the repository's own manifests before writing a parser against a secondhand schema description. The post calls the release "plumbing" and not "a framework pitch" ^[18], which is fair, and the repository has 7,421 stars ^[1].

For the governance claim to transfer to your setup, three things have to hold: the runtime has to consult `dependencies` and fail closed, the state files have to survive parallel writers, and the field names have to match a published schema. The orchestrate flow the post describes covers the first two only at the planning layer, where a planner splits the task, workers return JSON with file paths, diffs and status, and a verifier checks for conflicts and missing coverage before the merge ^[7].