DevTime MCP server

DevTime

DevTime verifies what your repository can actually prove.

A file named stripe/webhook.ts looks like proof that a repo handles Stripe webhooks. It might be a handler that only returns 404. DevTime checks statements about a repository against its implementation, tests, configuration, and recorded decisions, then reports what is supported, what is contradicted, what is missing, and what went stale.

No cloud. No telemetry. No code execution. No AI required.

Prefer video? Watch the 2-minute demo: DevTime scans a repo locally, explains concepts from evidence, surfaces uncertainty, catches a risky diff, and shows how a corroborated decision improves understanding.

Try DevTime in 60 seconds

pipx install devtime-ei
dtc demo init
cd devtime-demo-saas
dtc init
dtc scan
dtc verify

On the demo repo that ends with billing webhook signature verification SUPPORTED, JWT authentication SUPPORTED, and route test association WEAK, naming the routes with no test importing them. Point it at your own repository and the answers change:

cd your-repo
dtc init && dtc scan && dtc verify

The PyPI distribution is devtime-ei. The Python package remains devtime, and the CLI command remains dtc. dtc demo init copies a small static example repo into ./devtime-demo-saas so you can try DevTime without cloning this repository.

From source

git clone https://github.com/Shakargy/devtime.git
cd devtime
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
cd examples/demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

On Windows PowerShell:

git clone https://github.com/Shakargy/devtime.git
cd devtime
python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -e ".[dev]"
cd examples/demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

You should see Billing Webhooks explained from evidence, including supported claims, file references, uncertainty, Understanding Score, and Understanding Debt.

To test risk review, make a local change first, then run:

dtc risk --diff

A full, copy-pasteable walkthrough (including the risk-diff and corroborated-decision steps) is in DEMOSCRIPT.md**.

Verify claims (experimental)

A claim is a statement about the repository. Verification answers it with a status and receipts, never with confidence the evidence cannot back.

Status: CONTRADICTED

Contradictions:
  - The billing webhook endpoint cannot verify signatures
    because it is a disabled stub.
      claimed:  pages/api/stripe/webhook.ts is named and routed
                as a billing webhook endpoint.
      observed: The handler's only behavior is a 404/501 response.

• SUPPORTED - required behavior evidence exists in the current scan
• WEAK - the surface exists, but the proving evidence is missing
• CONTRADICTED - credible evidence conflicts with the claim, both sides shown
• UNKNOWN - the surface exists but coverage cannot responsibly decide
• NOTAPPLICABLE** - the repository has no surface this claim is about

Four built-in claims ship: route test association, admin authorization, billing webhook signatures, and JWT authentication. dtc verify leads with what it can actually verify in your repository, and when nothing applies it says what would make a claim verifiable instead of dead-ending.

Truth and freshness are separate: when a file behind a verified claim changes, the claim goes STALE and names the file. dtc risk --diff reports which verified claims a diff destabilizes.

See VERIFICATION.md for the full model and its limits.

Why this exists

Shortened. The full README is on GitHub.