The artifact database tool takes db_op: "batch" with a writes array, so several set, update and delete operations commit together under a single approval instead of prompting once per call. Each entry can supply its document inline or point at a local JSON file to read it from. The tool description now tells the model to prefer a batch over separate calls when it has more than a couple of documents to write.
- each entry in
writesnames an op of set, update or delete, pluscollection,doc_id, and exactly one ofdata(the document inline) orfile_path(a local file holding a JSON object to use as the document) - a batch is capped at a fixed number of entries
- where the server supports batch writes the whole batch commits all-or-nothing; where it does not, the entries are applied one at a time in order, the result states which of the two modes ran, and a failure part-way through names the entries already written
- two entries targeting the same document in one batch are refused with the error
db_batch_duplicate - reading a
file_pathgoes through the normal Read permission rules, and the approval is re-checked before the batch runs so entries cannot be added, removed or switched between inline and file after you approved it - collection paths were tightened from 1-31 to 1-15 slash-separated segments, each segment allowing letters, digits and
_ - . ~ : @ +, so subcollections nest likeboards/b1/columns - available wherever the artifact tool is offered, with no separate flag or setting to turn it on
applied one at a time in order (this server has no batch write yet); a failure part-way leaves earlier entries written, such writes at once, Database collection path: 1-15 "/"-separated segments (letters, digits, _ - . ~ : @ + per segment), so subcollections nest like "boards/b1/columns". Required for read_db and write_db.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.