Skip to main content
Glama
Sign In
murphy-mcp

murphy-mcp

by lucianomanetta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Hold an agent account against the observed record

check_claims
Read-onlyIdempotent

Compares what a coding agent claims it changed or fixed against actual filesystem and Git records, returning confirmed, contradicted, unreported, and unverifiable evidence.

Instructions

Takes what the agent said it did and compares it with what the machine shows. Returns four separate buckets: confirmed (claimed and observed), contradicted (claimed but nothing changed), unreported (changed and never mentioned), and unverifiable (claims a filesystem and git record cannot settle, such as 'the tests pass' or 'the bug is fixed'). The buckets are never merged, because a claim is not evidence.

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": "check_claims"
  }
}

Input Schema

NameRequiredDescriptionDefault
rootYesAbsolute path to the workspace to observe. Use the project root the agent is working in.
ignoreNoExtra directory names to skip, matched on a single path segment.
maxFilesNoStop the walk after this many files. Default 50000.
checkpointIdYesThe id returned by checkpoint.
claimedPathsNoThe files the agent said it changed. Absolute or workspace-relative.
maxFileBytesNoDo not hash files larger than this. Default 8388608.
noDefaultIgnoresNoAlso scan .git, node_modules and .murphy. Off by default.
claimedStatementsNoEverything else the agent asserted, in its own words. These are returned as unverifiable by design.

Output Schema

NameRequiredDescriptionDefault
rootYes
countsYes
caveatsYes
confirmedYes
unreportedYes
checkpointIdYes
contradictedYes
unverifiableYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description only needs to add context. It does: it discloses the classification semantics (four buckets, never merged) and that claimedStatements are deliberately returned as unverifiable. It does not mention scan cost or that the observation is a filesystem/git snapshot with inherent blind spots beyond the unverifiable bucket.

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?

Three sentences, front-loaded with the purpose and then the return shape. The closing clause ('because a claim is not evidence') is a rationale flourish but a short and useful one; nothing else is wasted.

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?

With an output schema present, the description needn't enumerate return fields, and it doesn't over-explain. For an 8-parameter observation tool it covers the essential semantics; the remaining gap is operational context such as scan scale or filesystem/git limits, which the ignore and maxFiles parameters imply but the text never discusses.

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 is already documented in structured form. The description reinforces the claimedStatements-to-unverifiable mapping but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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: it compares agent claims against observed machine state. It names the four output buckets, which makes it unmistakable against siblings like checkpoint (which creates the checkpoint referenced by checkpointId) and evidence_since.

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?

Usage context is clear from the framing ('takes what the agent said it did and compares it with what the machine shows') and the checkpointId parameter points at the prerequisite sibling tool. However, there is no explicit when-not guidance, e.g. no statement of when to prefer evidence_since directly or how this relates to list_checkpoints.

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

Deploy Server

Other Tools