Batch version of update_metadata. Applies many metadata changes in a single .scrivx write, reducing the conflict window and the per-call overhead. Each entry has the same {uuid, changes} shape as update_metadata. UUIDs not found in the binder are reported in the response rather than throwing. Wil...
AI agents use batch_update_metadata to create or update resources in Scrivener — usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Scrivener environment.
This tool modifies document metadata within Scrivener projects reversibly. While it performs bulk writes to the project file (.scrivx), the changes are not destructive—metadata can be updated again. The risk is medium rather than high because metadata modifications have limited blast radius compared to Execute operations (which could run arbitrary code) or Destructive operations (which erase data).
From the tool's definition Tool description states it 'Applies many metadata changes in a single .scrivx write', explicitly indicating modification of metadata. The operation is reversible (metadata can be updated again or reverted) and does not delete or destroy data.
Attacks that exploit this kind of access
Batch version of update_metadata. Applies many metadata changes in a single .scrivx write, reducing the conflict window and the per-call overhead. Each entry has the same {uuid, changes} shape as update_metadata. UUIDs not found in the binder are reported in the response rather than throwing. Will fail with a clear error if Scrivener has the project open. It is categorised as a Write tool in the Scrivener MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
Register the Scrivener MCP server in PolicyLayer and add a rule for batch_update_metadata: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Scrivener. Nothing to install.
batch_update_metadata is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the batch_update_metadata rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for batch_update_metadata. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
batch_update_metadata is provided by the Scrivener MCP server (sschmitt-cg/scrivener-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Every MCP server has a record like this.
Type a name, get the same breakdown: verified identity, auth posture, risk grade, capabilities, recommended policy.
Teams ship this data inside their own products. See what a licence covers →