Skip to main content
Glama
DeltaX-Public

DeltaX Preflight

Official
by DeltaX-Public
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
preflight_checkA

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.

preflight_hash_decisionA

Validate a Preflight v2 decision and return {decision_hash}, its canonical SHA-256 digest. Invalid decisions return a tool error, not a hash.

When to use

  • Before an evidence producer binds facts to the exact proposal it checked.

When NOT to use

  • Do not treat the hash as proof of facts, approval of an action, or a substitute for preflight_check when policy and evidence are ready.

preflight_hash_policyA

Validate a Preflight v2 policy and return {policy_hash}, its canonical SHA-256 digest. Invalid policies return a tool error, not a hash.

When to use

  • To pin owner-controlled rules outside an untrusted proposal.

When NOT to use

  • Do not treat a caller-supplied hash as proof of policy ownership. Use preflight_check to evaluate candidates once policy and evidence are ready.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.7/5.0

Scored across 3 tools

Disambiguation5/5

The three tools target clearly distinct operations: evaluating candidate actions, hashing a decision, and hashing a policy. Although the two hash tools share the 'hash' verb, their inputs and purposes are unambiguous, and the descriptions explicitly separate them.

Naming Consistency5/5

All tools use the same snake_case convention with a consistent 'preflight_' namespace prefix. The action suffixes are readable and predictable despite the slight grammatical difference between 'check' and 'hash_*'.

Tool Count5/5

Three tools are well-scoped for a narrow preflight validation server. Each tool earns its place: one evaluation operation and two canonical hashing operations for the objects the server manages.

Completeness4/5

The surface covers the core lifecycle of checking candidates and pinning policies/decisions with canonical hashes. A minor gap is that there is no separate evidence/proposal hashing or inspection tool, but the stated workflow does not strictly require one.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources