Skip to main content
Glama
evidence-ledger-mcp

evidence-ledger-mcp

update_records

Update fields of multiple ledger records in one call, applying changes in order and writing all affected files atomically; if any item is refused, no changes are saved.

Instructions

Change fields of several records in one call and return each item's record in its final state (two items on one record return the same, fully updated record). updates is a list of {"id": "R-0001", "changes": {...}}; each changes works as in update_record, and provenance stays as it was. Updates apply in order, so a later one sees an earlier one (a duplicate id is allowed), and claim-level changes are copied to the claim's other records, also in the related ledgers (pass the same list every time). Every affected record is checked against the final state of all ledgers. If any item is refused, the error lists all refusals, each prefixed with the item index and record id, and nothing is written; otherwise the changed ledgers are rewritten together, related ones first and the edited one last: all files or none (on a write error the files already replaced are restored).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>",
      "updates": "<updates>"
    },
    "name": "update_records"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes
relatedNo
updatesYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so exceptionally well. It discloses sequential application, claim-level propagation, provenance preservation, final-state validation, aggregated refusal errors, no writes on refusal, coordinated ledger rewriting, and restoration after partial write failures.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and result behavior are front-loaded, and the dense material is operational rather than filler. However, the long single paragraph and several heavily overloaded sentences make ordering, propagation, validation, and failure semantics harder to scan than they would be in short bullets.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex multi-ledger mutation, it covers the invocation model, returned records, update ordering, cross-ledger effects, validation, and transactional failure behavior; the output schema further reduces the need for return documentation. The remaining gaps are primarily the undocumented `path`, the exact contents and source of `related`, and reliance on another tool for `changes` semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, it supplies the `updates` item shape (`id` plus `changes`), explains ordering and duplicate IDs, and gives `related` a concrete role in claim propagation. It does not explain `path` or the expected format of `related` entries, and the contents of `changes` are delegated to `update_record`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb, resource, and scope: changing fields of several records in one call. The reference to `update_record` and the explicit batch-oriented `updates` format distinguish it from the singular sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly establishes the multi-record use case and explains when duplicate IDs and related ledgers matter. It does not explicitly state when to prefer the singular `update_record` or list prerequisites and exclusions, so selection guidance is strong but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.