delta_preflightPaid via x402 or MPP: $0.01 USDC on Base. Send the exact order venue, side, and size immediately before submission to obtain a signed PASS, BLOCK, or UNKNOWN from live availability, spread, freshness, depth, slippage, and divergence checks. Fail closed on BLOCK or UNKNOWN.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | Yes | Execution policy for one intended USD-pair spot order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the padegocal cost, the network, the fact that the verdict is signed, the live checks performed, and fail-closed behavior. This is useful but it doesn't describe return format or what the LLM must do with the signed PASS.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 3 front-loaded sentences with no filler: cost, exact inputs, desired output, and fail-sf safety behavior. Every sentence earns its place and critical info appears early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the absence of an output schema and annotations, the description covers cost, network, input cardinality, possible outcomes, and fallback behavior. It doesn't explain how the signed value should be used by the caller or how the mechanism relates to delta_pekeek, but for selecting and invoking the tool it declares enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already high, so the baseline is 3, but the description adds a meaningful focus instruction: send exact venue, side, and size and immediately before submission. It also maps the checks to the threshold parameters included in the nested trade object, helping the agent understand which values matter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific, action-oriented language: 'Gate a first crypto order before submission' and explains the tool returns a signed PASS, BLOCK, or UNKNOWN by running live checks. This is clearly distinguishable from a passive peek type tool, especially with the verb 'gate' and the pre-submission context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says to send the exact order venue, side, and size immediately before submission, and states the tool fails closed on BLOCK or UNKNOWN. This gives a clear context for the pre-trade gating use case though it never explicitly compared to delta_peek or says 'do not use elsewhere'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The two tools are unmistakably distinct: delta_peek provides a free preview of coverage and price, while delta_preflight executes the full paid check returning a signed PASS/BLOCK/UNKNOWN. No overlap in purpose or output.
Both tools follow the same 'delta_' prefix with a descriptive lowercase verb ('peek', 'preflight'), maintaining a clear and predictable snake_case convention. The naming style is perfectly consistent.
With only 2 tools, the set feels thin for a full service, but it matches a narrowly scoped purpose (preflight checks). It is borderline given the typical 3-15 tool range, but not extreme.
The tools cover the core workflow: a free peek to inspect basics and a paid full preflight for live checks. Minor gaps exist (e.g., no batch check or historical query), but the primary use case is fully supported.