Skip to main content
Glama
DeltaX-Public

DeltaX Preflight

Official
by DeltaX-Public
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

preflight_check

Read-onlyIdempotent

Check candidate actions against owner policy and proposal-bound evidence to return pass, selection, refusal, or missing-evidence outcomes before agent or CI/CD steps.

Instructions

Check concrete candidate actions against owner-controlled policy and separately obtained evidence. Returns {result, handoff}: PASS_SINGLE means one proven option, SELECTION_REQUIRED means multiple, REFUSE means none, and EVIDENCE_REQUIRED means at least one remains unproven. Handoff is null except for SELECTION_REQUIRED. Invalid documents return a tool error with no partial report.

When to use

  • Before an agent action or CI/CD step when a concrete proposal, owner policy, and proposal-bound evidence are available.

  • To identify admissible options or missing evidence.

When NOT to use

  • Do not use for natural-language prompt filtering or content moderation.

  • Do not use to rank or choose among multiple admissible options.

  • Do not use to authenticate supplied facts, execute actions, or call DeltaX Evaluate.

Input Schema

NameRequiredDescriptionDefault
policyYesOwner-controlled Preflight v2 policy object with hard constraints over candidate or context evidence. Supported op values: eq, in, lte, gte, exists. Keep policy separate from the proposer.
decisionYesPreflight v2 object with schema_version "2", a decision_id, context, and 1-100 candidates with unique IDs and payloads. Candidate claims are proposals, not proof.
evidenceYesPreflight v2 evidence object from an authorized fact source. Its decision_hash must match this exact decision; missing facts remain unproven. The example source is illustrative, not authenticated.

Output Schema

NameRequiredDescriptionDefault
resultYesThe unchanged Preflight v2 validation report; it never authorizes execution.
handoffYesThe original local handoff only for SELECTION_REQUIRED; otherwise null. It is not an API request.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.4
    • addedInput schema / properties / decision / examples
      Added value: +[
+  {
+    "candidates": [
+      {
+        "id": "review",
+        "payload": {
+          "action": "review"
+        }
+      }
+    ],
+    "context": {},
+    "decision_id": "example-review",
+    "kind": "decision",
+    "schema_version": "2"
+  }
+]
    • changedInput schema / properties / evidence / description
      Previous value: -"Preflight v2 evidence object from an authorized fact source. Its decision_hash must match this exact decision; missing facts remain unproven."New value: +"Preflight v2 evidence object from an authorized fact source. Its decision_hash must match this exact decision; missing facts remain unproven. The example source is illustrative, not authenticated."
    • addedInput schema / properties / evidence / examples
      Added value: +[
+  {
+    "candidates": [
+      {
+        "facts": {
+          "approved": true
+        },
+        "id": "review"
+      }
+    ],
+    "context": {},
+    "decision_hash": "bc34498f36f54ad1a06b56079f41ac90d8cfd6cf6a647f812f0078b765d544f7",
+    "evidence_id": "example-evidence",
+    "kind": "evidence",
+    "schema_version": "2",
+    "source": "example-source"
+  }
+]
    • changedInput schema / properties / policy / description
      Previous value: -"Owner-controlled Preflight v2 policy object with hard constraints over candidate or context evidence; keep it separate from the proposer."New value: +"Owner-controlled Preflight v2 policy object with hard constraints over candidate or context evidence. Supported op values: eq, in, lte, gte, exists. Keep policy separate from the proposer."
    • addedInput schema / properties / policy / examples
      Added value: +[
+  {
+    "constraints": [
+      {
+        "id": "approved",
+        "op": "eq",
+        "path": "/approved",
+        "source": "candidate",
+        "value": true
+      }
+    ],
+    "kind": "policy",
+    "policy_id": "example-policy",
+    "schema_version": "2"
+  }
+]
  2. Changed3 schema fields changedv0.1.3
    • addedInput schema / properties / decision / type
      Added value: +"object"
    • addedInput schema / properties / evidence / type
      Added value: +"object"
    • addedInput schema / properties / policy / type
      Added value: +"object"
  3. Changed4 schema fields changedv0.1.2
    • changedInput schema / properties / decision / description
      Previous value: -"Preflight v2 decision JSON document; the core validator checks its fields."New value: +"Preflight v2 object with schema_version \"2\", a decision_id, context, and 1-100 candidates with unique IDs and payloads. Candidate claims are proposals, not proof."
    • changedInput schema / properties / evidence / description
      Previous value: -"Preflight v2 evidence JSON document, bound to the exact decision_hash."New value: +"Preflight v2 evidence object from an authorized fact source. Its decision_hash must match this exact decision; missing facts remain unproven."
    • changedInput schema / properties / policy / description
      Previous value: -"Preflight v2 policy JSON document from the workflow owner."New value: +"Owner-controlled Preflight v2 policy object with hard constraints over candidate or context evidence; keep it separate from the proposer."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "handoff": {
+      "description": "The original local handoff only for SELECTION_REQUIRED; otherwise null. It is not an API request.",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "result": {
+      "description": "The unchanged Preflight v2 validation report; it never authorizes execution.",
+      "properties": {
+        "admissible_candidate_ids": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "candidates": {
+          "items": {
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "counts": {
+          "properties": {
+            "admissible": {
+              "minimum": 0,
+              "type": "integer"
+            },
+            "received": {
+              "minimum": 0,
+              "type": "integer"
+            },
+            "rejected": {
+              "minimum": 0,
+              "type": "integer"
+            },
+            "unproven": {
+              "minimum": 0,
+              "type": "integer"
+            }
+          },
+          "required": [
+            "received",
+            "admissible",
+            "rejected",
+            "unproven"
+          ],
+          "type": "object"
+        },
+        "receipt": {
+          "properties": {
+            "algorithm": {
+              "const": "sha256"
+            },
+            "decision_hash": {
+              "description": "Canonical SHA-256 digest.",
+              "pattern": "^[a-f0-9]{64}$",
+              "type": "string"
+            },
+            "evidence_hash": {
+              "description": "Canonical SHA-256 digest.",
+              "pattern": "^[a-f0-9]{64}$",
+              "type": "string"
+            },
+            "policy_hash": {
+              "description": "Canonical SHA-256 digest.",
+              "pattern": "^[a-f0-9]{64}$",
+              "type": "string"
+            },
+            "result_hash": {
+              "description": "Canonical SHA-256 digest.",
+              "pattern": "^[a-f0-9]{64}$",
+              "type": "string"
+            }
+          },
+          "required": [
+            "algorithm",
+            "decision_hash",
+            "policy_hash",
+            "evidence_hash",
+            "result_hash"
+          ],
+          "type": "object"
+        },
+        "status": {
+          "description": "One proven option, multiple proven options, none allowed, or missing evidence.",
+          "enum": [
+            "PASS_SINGLE",
+            "SELECTION_REQUIRED",
+            "REFUSE",
+            "EVIDENCE_REQUIRED"
+          ]
+        }
+      },
+      "required": [
+        "status",
+        "counts",
+        "admissible_candidate_ids",
+        "candidates",
+        "receipt"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "result",
+    "handoff"
+  ],
+  "type": "object"
+}
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: a {result, handoff} return contract with all four result values enumerated, handoff null except for SELECTION_REQUIRED, and the failure mode that invalid documents produce a tool error with no partial report. It also warns that evidence must be separately obtained and that the illustrative source is not authenticated — a provenance caveat no annotation conveys.

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?

Front-loads purpose and return contract in the first two sentences, then uses tight labeled bullets for eligibility and exclusions. No sentence is redundant; even the failure-mode note earns its place by ruling out partial reports.

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?

Despite nested objects and a three-way document contract, the description covers input provenance (policy vs. evidence vs. proposal), the verdict vocabulary, the handoff rule, and error behavior. With an output schema present, nothing an agent needs to call this 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?

Schema coverage is 100%, so the baseline is 3; the description adds real semantic constraints on top — that policy is owner-controlled and must stay separate from the proposer, that evidence is bound to this exact decision via decision_hash, and that missing facts stay unproven. It does not, however, restate the supported constraint ops or the 1-100 candidate limit in prose, leaving those to 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?

States a specific verb (check) and precise resources (concrete candidate actions, owner-controlled policy, separately obtained evidence), plus what the outcome space looks like. The scope is narrow enough that it is clearly distinct from the preflight_hash_* siblings, which only produce hashes rather than a decision verdict.

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?

Has explicit 'When to use', 'When NOT to use' lists with concrete triggers (before an agent action or CI/CD step; identifying admissible options or missing evidence) and explicit exclusions (not prompt filtering, not ranking/choosing, not authentication or execution, not DeltaX Evaluate). This is the full when/when-not/alternative triad.

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

Deploy Server

Other Tools