evidence-ledger-mcp

Overview Schema Source Related Servers Discussions Admin

move_record

Move a record, including withdrawn ones, between evidence ledgers while keeping its id, claim link and provenance. Validates the record against the destination and related ledgers, rewriting both files all or none.

Instructions

Move a record (withdrawn ones too) from the ledger at path to the ledger at to, keeping its id, claim_id and provenance, and return it. Refused when both are the same file, the id is missing from path or already used in to, or the record fails the checks of add_record against to and the related ledgers (header text, claim text or importance of its claim). The claim may then span both ledgers: pass the project's other ledgers as related to later calls so it stays consistent. Both files are rewritten together, to first, all or none (on a write error the one already replaced is restored). The id is not reused as long as related lists every ledger of the project each time.

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>",
      "id": "<id>",
      "to": "<to>"
    },
    "name": "move_record"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes
`to`	Yes
`path`	Yes
`related`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Nov 3, 2026

TDQS

A4.6/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 discharges it: it discloses that withdrawn records are included, that both files are rewritten with `to` first, that the operation is all-or-none with a compensating restore on write error, and the specific validation rules inherited from add_record. It also notes the return value (the moved record) and the condition under which the id is not reused.

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 action and its scope are front-loaded, and each subsequent sentence adds a distinct constraint (refusals, cross-ledger consistency, atomicity, id reuse) rather than restating prior text. The final sentence about id reuse is somewhat convoluted and could be tightened, but nothing is filler.

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

Completeness5/5

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

For a four-parameter mutating tool with no annotations, the definition covers the operation, refusal conditions, failure/rollback behavior, cross-ledger consistency obligations, and validation dependencies on add_record. An output schema exists, so the brief mention of returning the record is sufficient rather than redundant.

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?

Schema description coverage is 0%, so the description must compensate, and it does: `path` is the source ledger, `to` the destination, `id` the record identifier, and `related` the project's other ledgers used for validation and id-reuse safety. It stops short of specifying path format (relative vs absolute, file naming), which is the only remaining ambiguity for a caller.

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 description opens with a specific verb and resource: move a record from the ledger at `path` to the ledger at `to`, and states what is preserved (id, claim_id, provenance). That scope is clearly distinct from siblings such as update_record, add_record, and withdraw_record, so an agent can select it without opening another schema.

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 gives explicit refusal conditions (same file, id missing from `path` or already present in `to`, failed checks against `to`/`related`) and tells the caller how to keep a cross-ledger claim consistent by passing the project's other ledgers as `related`. It does not directly compare against alternatives like update_record or add_record, so routing is implied by the semantics rather than spelled out.

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

Deploy Server