adversary-gate

Overview Schema Source Related Servers Discussions Admin

Show the gate policy

gate_policy

Read-onlyIdempotent

Inspect the gate's verification policy—baseline, floors, interpreter, and caller controls—before or after a merge check. Read-only, explains how a verdict was reached.

Instructions

Show the verification policy this server enforces: floors, baseline, interpreter, and what the caller may set.

When to call: before ``verify_repo``, to learn whether the baseline is
pinned by the operator or chosen by you, which interpreter runs the tests,
and which floors a merge has to clear -- or after an inconclusive or block
answer, to explain it.

Read-only and fast: it runs no tests and changes nothing. The policy comes
from the server's environment (ADVERSARY_GATE_POLICY, _BASE_REF, _PYTHON),
set by whoever configured the server; no tool can change it.

Returns ``version``, ``operator_flags``, ``defaults``, ``baseline``,
``python`` and ``agent_controls`` (the arguments of ``verify_repo`` you
decide). An invalid operator policy returns ``error`` instead.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.8.0Oct 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing that no tests run, nothing changes, the policy is sourced from server environment variables (ADVERSARY_GATE_POLICY, _BASE_REF, _PYTHON), no tool can mutate it, and an invalid operator policy yields an 'error' payload instead. That is exactly the kind of context annotations cannot convey.

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?

Front-loaded purpose sentence followed by clearly labeled 'When to call', read-only, and returns sections — scannable and mostly waste-free. The final enumeration of return keys largely duplicates the existing output schema, a small redundancy.

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 zero-parameter read tool with full annotations and an output schema, this covers every decision an agent must make: when to call it, that it is safe and fast, and where the values come from. Nothing needed 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.

Parameters4/5

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

The tool takes zero parameters, so the baseline of 4 applies. The description compensates by explaining where the policy values originate (operator environment) rather than from caller input, clarifying why no arguments exist.

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?

Opens with a specific verb+resource — 'Show the verification policy this server enforces' — and enumerates the substance of that policy (floors, baseline, interpreter, agent-settable knobs). It is immediately distinguishable from its only sibling, verify_repo, which runs tests rather than reporting policy.

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?

Contains an explicit 'When to call' clause naming two concrete triggers: before verify_repo to learn the baseline/interpreter/floors, or after an inconclusive/block answer to explain it. The alternative (verify_repo) and the condition selecting this tool are stated outright.

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

Deploy Server