Skip to main content
Glama

Change Trace MCP

Change Trace MCP is a local-first, model-neutral MCP server for collecting and normalizing change-scoped release evidence. The user's existing Agent makes semantic judgments; this package keeps evidence preparation deterministic and reviewable.

M1–M5 are complete. The M6 runtime path accepts strict, pre-produced manifests through one confined repository file read. Pinned offline JUnit-style, Playwright-JSON, API-smoke, and staging-summary fixtures exercise that path without claiming general format support or live compatibility. The external-adapter path continues to accept explicit references through bounded Host-configured commands. The currently exposed MCP tools are:

  • get_server_info reports process and runtime metadata;

  • get_compatibility_fixture returns a byte-stable fixture for Host smoke tests;

  • get_change_scope returns a deterministic, bounded Git change summary for an explicit repository root and two refs;

  • collect_local_evidence returns bounded, provenance-rich excerpts from configured repository document roots;

  • collect_external_evidence returns normalized, redacted, and untrusted_external evidence for explicit references through one exact Host-configured adapter;

  • collect_runtime_evidence normalizes one explicit, pre-produced runtime manifest beneath the verified Git root without executing tests, browsers, probes, deployments, or artifact fetches;

  • get_review_bundle combines change and document evidence into a bounded, indexed bundle with deterministic facts, external/runtime collections, and missing-evidence records;

  • validate_findings validates Agent output against the shared schema and the bundle's evidence/source indexes;

  • write_report renders validated findings and a complete retained evidence-source catalog as a deterministic Markdown and JSON report pair inside a repository-relative output directory.

Requirements

  • Node.js 22 or newer.

Related MCP server: local-evidence-mcp

Local development

npm install
npm run check
npm test

Run the stdio server from a local checkout:

npm run build
node dist/cli.js

The server reserves stdout for MCP JSON-RPC messages. Structured operational logs are emitted to stderr.

write_report usage

write_report accepts a validated ReviewBundle, a FindingValidationResult, reviewer metadata, and a repository-relative output path. It renders a deterministic Markdown report and a structured JSON report as a pair of files:

  • <reportName>.md — human-readable Markdown with safe code fences, escaped HTML, and bounded structure;

  • <reportName>.json — machine-readable report conforming to the versioned Report JSON Schema.

The tool requires:

  • repositoryRoot — an absolute path to the repository working directory;

  • outputDirectory — a path relative to repositoryRoot. Absolute paths, .. traversal, .git metadata paths, and symlink escapes are rejected;

  • reportName — a safe basename ([A-Za-z0-9][A-Za-z0-9._-]{0,127}) that determines the output filenames;

  • bundle — a validated ReviewBundle from get_review_bundle;

  • validationResult — the matching FindingValidationResult from validate_findings. The validation result's bundleId must equal the bundle's ID;

  • reviewMeta — caller-supplied reviewer identity, required createdAt timestamp (ISO 8601), optional tool version, notes, and declared limitations; identical inputs including createdAt produce byte-identical reports;

Optional parameters:

  • overwrite — when true, existing report files are replaced. The default (false) refuses the write if either report file exists;

  • maxReportSizeBytes — an output size bound. The default is 10 MiB; the absolute hard maximum is 100 MiB. The write fails instead of silently truncating findings.

The tool returns a structured result with reportId, absolute paths to the written files, and their byte sizes. Error responses are bounded and do not expose report content.

Example MCP call flow:

get_change_scope ─┬→ collect_local_evidence ───────────────┐
                  └→ collect_external_evidence (optional) ├→
                     collect_runtime_evidence (optional) ─┤
                     get_review_bundle → validate_findings → write_report

External adapters are registered by the Host through CHANGE_TRACE_EXTERNAL_ADAPTERS_FILE; executable configuration and credentials are never MCP tool input. See the packaged external-adapter guide, its practical authoring checklist, and copyable configuration. Runtime conversion remains Host/CI-owned. See the packaged runtime-evidence guide, converter authoring guide, and its strict normalized manifest examples.

Security and privacy

This pre-beta package is a local stdio server and does not provide a sandbox. Read the Security Policy, security documentation index, threat model, privacy and telemetry statement, and executable control inventory before using it with sensitive repositories, adapters, models, or CI artifacts.

Contributing

Read CONTRIBUTING.md for public issue, pull request, testing, documentation, security, and changelog guidance. The repository-only docs/CONTRIBUTING_WORKFLOW.md describes assigned coordinator/worker work; it is intentionally not included in the installed package.

Versioning and changes

Read VERSIONING.md for package and Schema version boundaries, and CHANGELOG.md for unreleased public changes.

Versioned schemas

The package exports strict Zod schemas and deterministic Draft 2020-12 JSON Schema documents for EvidenceItem, ChangeScope, LocalEvidenceCollection, ExternalAdapterRequest, ExternalAdapterResponse, ExternalEvidenceCollection, ReviewBundle, Finding, RuntimeEvidenceManifest, RuntimeEvidenceCollection, FindingValidationResult, and Report:

import {
  evidenceItemSchema,
  exportCoreJsonSchemas,
} from "change-trace-mcp";

const evidence = evidenceItemSchema.parse(input);
const jsonSchemas = exportCoreJsonSchemas();

Host-specific setup and the current compatibility matrix live in docs/smoke-tests/.

The packaged provider-neutral advisory CI runner and examples are mechanics-only integration guidance. They do not bundle a Host, provider, or semantic review capability.

See docs/ROADMAP.md for milestone scope and docs/PROJECT_DECISIONS.md for accepted product and architecture decisions.

License

Apache-2.0. See LICENSE.

Available Tools

1 tool
write_reportWrite a versioned review reportA
Destructive

Render validated Agent findings as a deterministic Markdown and JSON report pair inside a repository-relative output directory. The report preserves confirmed, suspected, and inconclusive findings, evidence coverage, bundle limits/truncation, and validation warnings.

ParametersJSON Schema
NameRequiredDescriptionDefault
bundleYes
overwriteNo
reportNameYes
reviewMetaYes
repositoryRootYes
outputDirectoryYes
validationResultYes
maxReportSizeBytesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
jsonFileYes
reportIdYes
reportPathYes
markdownFileYes
jsonSizeBytesYes
markdownSizeBytesYes

TDQS

A3.8/5.0
Behavior3/5

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

Annotations declare destructiveHint=true, consistent with writing files. The description adds that the report pair is deterministic and preserves certain elements, but omits behavioral details like overwrite behavior, directory creation, or versioning meaning. With annotations providing core safety info, the description adds moderate context.

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 concise sentences: the first states the primary action and format, the second lists preserved content. No redundant information; every word adds value.

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

Completeness3/5

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

Given high complexity (8 params, nested objects, output schema exists), the description provides a high-level summary but lacks details on parameter semantics, overwrite behavior, versioning, file path conventions, and max size handling. The output schema covers return values, but the description does not fully cover the tool's operational context.

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

Parameters2/5

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

Schema description coverage is 0%, requiring the description to compensate. It mentions 'Markdown and JSON report pair inside a repository-relative output directory' (hinting at outputDirectory and repositoryRoot) and 'confirmed, suspected, and inconclusive findings' (hinting at bundle/validationResult). However, it fails to describe other critical parameters like bundle, reviewMeta, overwrite, and maxReportSizeBytes, providing minimal added meaning over the schema.

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 title 'Write a versioned review report' and description clearly state the verb 'Render' and the resource 'Markdown and JSON report pair'. It specifies the output is deterministic and what findings are preserved. No sibling tools exist, so differentiation is not needed.

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 description implies use after validation ('Render validated Agent findings'), providing clear context. No sibling tools exist to compare against, and no explicit when-not or alternative guidance is necessary given this.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.0.0-dev.1
    • First observedwrite_report

TDQS

A3.8/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools.

Naming Consistency5/5

With a single tool, naming is trivially consistent; the name 'write_report' is clear and follows a verb_noun pattern.

Tool Count3/5

A single tool is borderline appropriate for a server focused solely on report generation, but the narrow scope suggests the server may be too minimal for broader use cases.

Completeness2/5

The tool only writes reports but does not include tools for managing findings or inputs, leaving gaps that would require external systems to function.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    Provides local codebase intelligence as an MCP server, enabling AI agents to query dependencies, assess change impact, and produce tamper-evident change evidence packets.
    514
    Apache 2.0
  • A
    license
    A
    quality
    B
    maintenance
    A local-first MCP server for retrieving a small evidence set and recording reviewed conclusions, policy-gated and redacted without giving an agent general filesystem access.
    5
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    A local-first, auditable code review MCP server that freezes Git changes, creates immutable ReviewBundles, provides role-isolated contexts for correctness, security, architecture, and test reviewers, validates structured findings, and generates deterministic JSON/Markdown reports.
    11
    1
    Apache 2.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Canlendula/change-trace-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server