murphy-mcp

Overview Schema Source Related Servers Discussions Admin

What actually changed since a checkpoint

evidence_since

Read-onlyIdempotent

Rescan a workspace against a checkpoint to report every added, modified, or deleted file and git move, providing an observed record independent of agent claims.

Instructions

Rescans the workspace and reports every file added, modified or deleted since the checkpoint, together with what moved in git. This is the observed record. It does not know and does not ask what any agent intended or reported.

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": {
      "root": "<root>",
      "checkpointId": "<checkpointId>"
    },
    "name": "evidence_since"
  }
}

Input Schema

Name	Required	Description
`root`	Yes	Absolute path to the workspace to observe. Use the project root the agent is working in.
`ignore`	No	Extra directory names to skip, matched on a single path segment.
`maxFiles`	No	Stop the walk after this many files. Default 50000.
`checkpointId`	Yes	The id returned by checkpoint.
`maxFileBytes`	No	Do not hash files larger than this. Default 8388608.
`noDefaultIgnores`	No	Also scan .git, node_modules and .murphy. Off by default.

Output Schema

Name	Required	Description	Default
`to`	Yes
`git`	Yes
`from`	Yes
`root`	Yes
`counts`	Yes
`caveats`	Yes
`changes`	Yes
`checkpointId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so safety is covered structurally. The description adds genuine context beyond that: the result is a fresh rescan rather than a cached diff, and it deliberately ignores agent intent. However it says nothing about the cost or limits of a full rescan, even though maxFiles/maxFileBytes exist, and nothing about checkpoint lifetime or whether a stale checkpointId fails.

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

Conciseness5/5

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

Two sentences, zero waste, with the core action front-loaded before the positioning statement. The contrast sentence is short and load-bearing rather than filler.

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?

An output schema exists, so return shape need not be explained, and the description correctly conveys the semantic of the result (observed changes, not claims). The remaining gap is operational: for a full workspace rescan with hashing limits, the description gives no hint about scan cost, failure modes, or what happens with an invalid checkpoint id.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter including root, checkpointId, ignore, maxFiles and maxFileBytes is already documented in the schema. The description only implies the checkpointId relationship ("since the checkpoint") and adds nothing about ignore matching or scan limits beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb+resource: rescans the workspace and reports files added, modified or deleted since a checkpoint, plus git moves. The second sentence explicitly positions it against the claim-oriented siblings ("does not know and does not ask what any agent intended or reported"), so an agent can tell it apart from check_claims without opening either 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?

The framing "This is the observed record" versus agent-intended/reported data gives clear routing logic: use this for ground truth on disk changes, use the claim-oriented sibling when you want what an agent said it did. It stops short of naming check_claims or any sibling explicitly and offers no explicit when-not conditions.

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

Deploy Server