Skip to main content
Glama
Sign In
diffcontext

diffcontext

by trakshan-mishra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

verify_retrieval

Grade your repository's retrieval quality by generating test cases from git co-change history and reporting hit/recall scores.

Instructions

Mine git history and grade retrieval quality on your repo.

Generates test cases from co-change history, runs DiffContext retrieval against them, and reports hit/recall. Prints NULL RESULT when the tool doesn't fit your repo — finding that out IS the feature.

Args: repo_path: Absolute path to the repository. If omitted, uses the --repo from server startup. n: Maximum number of test cases to generate from git history (default 20).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "verify_retrieval"
  }
}

Input Schema

NameRequiredDescriptionDefault
nNo
repo_pathNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.4

TDQS

A4.6/5.0
Behavior5/5

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

Even though no annotations were provided, the description reveals significant behavioral traits: it generates test cases from co-change history, runs DiffContext retrieval, reports hit/recall, and optionally prints NULL RESULT when the repo doesn't fit. Calling out the NULL RESULT as a feature is genuinely useful and goes beyond typical descriptions.

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?

The definition is short, front-loaded with the main purpose, then narrows to mechanism and parameters. The NULL RESULT sentence is pointed and earns its place. The Args section provides compact parameter context without re-describing what the schema already defaults.

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?

Given that there is an output schema and only two simple parameters, the description is complete: it covers what the tool does, the algorithm, output metrics, edge-case behavior, and all parameter semantics. An agent has enough information to select and invoke this tool correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries all param documentation. It clearly adds meaning by explaining repo_path as an absolute path with a startup fallback to --repo, and describes n as the maximum number of test cases with a default of 20. This covers both parameters meaningfully.

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

Purpose4/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: 'Mine git history and grade retrieval quality on your repo,' and then defines the mechanism (generate test cases, run retrieval, report hit/recall). It clearly explains what the tool does, but it does not explicitly contrast it with sibling tools like compile_context or find_impact.

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 clear context: you use this when you want to assess retrieval quality over git history, and the NULL RESULT warning indicates what to expect if the repository isn't a good fit. However, it does not state explicit when-to-use versus known sibling alternatives.

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