adversary-gate

by Sanflow10

Overview Schema Source Related Servers Discussions Admin

Python

Local

Verify a repository change

verify_repo

Judge the working tree of a git repository against a baseline, by running its tests.

Instructions

Judge the working tree of a git repository against a baseline, by running its tests.

When to call: after changing code in ``repo`` and before reporting the task
as done. Call ``gate_policy`` first if you need to know the floors or
whether the baseline is pinned. Python/pytest only; changes in other
languages come back inconclusive.

What it does: writes the baseline commit's tree (every file as committed),
diffs it against the working tree (uncommitted and untracked files
included), runs the suite under coverage.py, then runs the gate: the
claims on the baseline and on the patch, the baseline's copy of any test
the patch rewrote, and mutation testing on the changed lines. Nothing is
committed or reverted.

Side effects: the repository's tests execute -- its code runs, so they may
do whatever they do when you run pytest yourself. The coverage run uses the
repository as working directory; the gate's own files go to a temporary
directory that is removed afterwards. It can take minutes. A run longer
than ``timeout_seconds`` (default 3600: the gate's own full-suite run may
take 900 alone) returns inconclusive, never a pass, and its
``next_steps`` names ``timeout_seconds`` as the limit to raise.

Arguments: ``repo`` is a path inside the git repository. ``claims`` are
pytest node ids (``path::test``) to verify; empty -> discovered from the
tests that executed a changed line. ``pytest_args`` are test paths or node
ids the coverage run collects (default: the whole suite); options such as
``-k`` are refused. ``base_ref`` is used only when the operator did not pin
ADVERSARY_GATE_BASE_REF.

Returns ``decision`` (merge / block / inconclusive), ``mergeable``,
``fix_proven``, ``reason``, per-claim results with the oracle used,
``diff_coverage``, ``suite_strength``, ``next_steps`` and the full
artefact. merge permits a human review, not a release; block means fix the
code, not the tests; inconclusive means something was not measured -- say
what. ``next_steps`` lists what would earn a MERGE (cover these lines, kill
this surviving mutant, add a new test, fix the code); do them and call
again. It never asks you to edit an existing test, a harness file or a
floor, and doing so does not help: the baseline's tests are the oracle.

Input Schema

Name	Required	Default
`repo`	Yes
`claims`	No
`base_ref`	No	HEAD
`pytest_args`	No
`timeout_seconds`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.0.5Oct 14, 2026
- changedInput schema / properties / timeout_seconds / default
```
Previous value: -900New value: +3600
```
First observedv2.8.0Oct 4, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false); the description adds far more: repo test code actually executes with its own side effects, coverage runs with the repo as cwd, gate files land in a temp dir that is deleted, nothing is committed or reverted, the run can take minutes, and a timeout yields inconclusive rather than a pass.

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?

Long but dense and well front-loaded (purpose, when-to-call, what-it-does, side effects, arguments, returns). Nearly every sentence carries operational weight, though the Returns paragraph partially restates what the output schema already exposes and could be tightened.

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?

For a slow, side-effecting, open-world verification tool, the description covers invocation timing, prerequisites, cost, failure modes (timeout -> inconclusive), the semantics of the decision output, and what next_steps will and will not ask for. Nothing an agent needs to call it correctly is missing.

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 the full burden and does: repo is a path inside the git repo, claims are pytest node ids (path::test) with an empty->discovered rule, pytest_args defines what the coverage run collects and refuses options like -k, base_ref only applies when ADVERSARY_GATE_BASE_REF is unpinned, and timeout_seconds has default 3600 with the 900s full-suite note.

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?

States a concrete verb+resource+method: judge a git working tree against a baseline by running its tests. It also scopes the tool (Python/pytest only) and implicitly separates it from the sibling gate_policy, which only reports floors/pinning.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-call (after changing code, before declaring done), an explicit alternative and its trigger (call gate_policy first if you need floors or pin status), and an explicit exclusion (non-Python changes come back inconclusive). Nothing is left to inference.

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

Deploy Server