provetrade-mcp

Compare deployed vs local commit

provetrade_deploy_status

Read-only

Compare the live gateway's build SHA with your local git HEAD to see if production matches your code. Use it to identify deployment mismatches before debugging unexpected behavior.

Instructions

Answer "is what is live the code I have?" — compares the gateway's reported build sha with local git HEAD, and reports how many commits ahead local is.

Call it before debugging a production behaviour against local source: a mismatch explains a surprising difference immediately and saves the whole investigation.

Reads git via execFile with an argument array — no shell. Read-only, no cost, changes nothing in the repository.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`repo_path`	No	Path to the local ProveTrade clone. Defaults to the working directory. Relative paths resolve against the allowed root; anything outside it is refused with PATH_DENIED.

Output Schema

TableJSON Schema

Name	Required	Description
`reason`	No	Why commits_behind could not be determined.
`in_sync`	Yes	True only when the deployed sha identifies local HEAD.
`deployed_sha`	Yes	The version string from the gateway /health. Null when it is absent or not a sha (e.g. "dev").
`commits_behind`	Yes	Commits from the deployed sha to local HEAD. NULL, never 0, whenever the count is not meaningful — a 0 would read as "in sync", and that is the one wrong answer that gets acted on. Read `reason` when this is null.
`dirty_worktree`	Yes	True when git status --porcelain reports anything.
`local_head_sha`	Yes	Full 40-character sha of local HEAD.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 10, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only, no cost, changes nothing in the repository' and adds implementation detail ('Reads git via execFile with an argument array — no shell'). This adds value beyond the structured annotations.

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?

Three sentences, each earning its place: purpose, usage context, and behavioral note. The purpose is front-loaded in the first sentence, making it immediately scannable.

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?

The description covers purpose, usage, behavior, and safety. An output schema exists so return format is not needed. It doesn't mention how the gateway sha is obtained or network requirements, but for a simple read-only tool with one optional param, this is sufficient.

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 coverage is 100% for the single parameter, so the schema already fully documents repo_path. The description adds no parameter-specific details beyond the schema, but it does provide overall operational context. Baseline 3 is appropriate.

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 states a clear, specific verb and resource: compares the gateway's reported build sha with local git HEAD and reports commit difference. It distinctly separates this from sibling tools (engine, csv validation, health, audit, metrics) which serve different purposes.

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 when-to-use context: 'Call it before debugging a production behaviour against local source'. It doesn't mention exclusions or name alternatives, but the scenario is clearly defined and distinct from siblings.

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

Deploy Server