DeltaSignal ATLAS-7

DeltaSignal Synthetic ETF audit payload

deltasignal_synthetic_etf_audit

Read-onlyIdempotent

Use this read-only audit tool when the user asks what factors drive the Delta Signal Synthetic AI 10 ETF state, asks for raw audit evidence, or asks whether the current pressure state is a full four-level ATLAS-7 verdict. It returns current and previous buckets, bucket comparison, factor-history rows, audit-window z-scores including basis_pressure_z, a threshold contract, threshold flags, canonical event status/reasons/blockers, event classification, four-level coverage, bounded constituent contribution rows, presentation-parity status, TRIDENT/liquidation-gradient availability, per-question readiness, provenance, caveats, and quality flags. Parameters: product is required and accepts AI10, Synthetic AI10 ETF, AI-PERP-INTX, Tech100, or TEK-19DEC30-CDE; optional source-date filters override window_days; optional limit and offset paginate factor-history rows. Behavior: read-only and idempotent with no destructive side effects; it must label partial coverage explicitly and must not convert a linked-market read into issuer truth, exchange-native microstructure truth, a trade signal, or investment advice.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum factor-history rows to return. Defaults to 100 and is capped at 100 through MCP.
`offset`	No	Pagination offset over factor-history rows used for audit.
`product`	Yes	Required Synthetic ETF or linked product identifier, for example AI10, Synthetic AI10 ETF, or AI-PERP-INTX.
`source_date`	No	Optional exact source date in YYYY-MM-DD format. Overrides window_days.
`window_days`	No	Default audit lookback when no source-date filters are supplied. Defaults to 7 and is capped at 30.
`include_export`	No	Whether to include export availability metadata. Defaults true.
`source_date_to`	No	Optional inclusive source-date upper bound in YYYY-MM-DD format.
`source_date_from`	No	Optional inclusive source-date lower bound in YYYY-MM-DD format.

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	Audit-grade DeltaSignal Synthetic ETF payload.
`provenance`	Yes	Traceability information for the MCP tool response.
`mcp_summary`	Yes	Concise high-signal summary of the tool response. Maximum 140 characters.
`usage_metadata`	No	Performance and estimated cost metadata for this MCP tool call.
`suggested_follow_ups`	Yes	Concrete next MCP calls an agent can run to continue the workflow.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed4 schema fields changedJul 2, 2026

addedOutput schema / properties / data / properties / constituent_contributions

Added value: +{
+  "additionalProperties": true,
+  "description": "Bounded constituent attribution rows. Current implementation exposes weight-only contribution rows and missing per-constituent pressure fields instead of inferring drivers.",
+  "type": "object"
+}

addedOutput schema / properties / data / properties / presentation_parity

Added value: +{
+  "additionalProperties": true,
+  "description": "Rendered artifact parity status. Returns requires_artifact until a rendered HTML/article artifact is provided for comparison.",
+  "type": "object"
+}

addedOutput schema / properties / data / properties / question_readiness

Added value: +{
+  "additionalProperties": true,
+  "description": "Per-question answerability map for agents: current state, drivers, canonical event, seven-day history, constituent attribution, presentation parity, TRIDENT, and publication safety.",
+  "type": "object"
+}

addedOutput schema / properties / data / properties / trident

Added value: +{
+  "additionalProperties": true,
+  "description": "TRIDENT and liquidation-gradient availability boundary. Returns unavailable unless explicit liquidation-gradient evidence is persisted.",
+  "type": "object"
+}

Changed5 schema fields changedJul 1, 2026

addedOutput schema / properties / data / properties / bucket_comparison

Added value: +{
+  "additionalProperties": true,
+  "description": "Side-by-side current/prior ST, LSI, FDI, FEI, ECS proxy, basis pressure, and deltas.",
+  "type": "object"
+}

addedOutput schema / properties / data / properties / canonical_event

Added value: +{
+  "additionalProperties": true,
+  "description": "Canonical event status, type, reason, blockers, linked state, and evidence boundary.",
+  "type": "object"
+}

addedOutput schema / properties / data / properties / threshold_contract

Added value: +{
+  "additionalProperties": true,
+  "description": "Versioned release-event threshold contract used by audit-mode threshold flags.",
+  "type": "object"
+}

changedOutput schema / properties / data / properties / z_scores / description

Previous value: -"Audit-window z-score fields for ECS, LSI, FDI, FEI, ST, MP, and AP."New value: +"Audit-window z-score fields for ECS, LSI, FDI, FEI, ST, MP, AP, and basis pressure."

changedOutput schema / properties / data / required

Previous value: -[
-  "audit_status",
-  "current_bucket",
-  "threshold_flags",
-  "four_level_coverage"
-]New value: +[
+  "audit_status",
+  "current_bucket",
+  "threshold_flags",
+  "canonical_event",
+  "four_level_coverage"
+]

AddedJul 1, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful context: it must explicitly label partial coverage and must not reinterpret linked-market reads as issuer truth or investment advice. This goes beyond the crude safety profile provided by annotations. The description also enumerates the exact categories of data returned, which clarifies the tool's behavior in terms of output composition.

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?

The description is moderately long but well-structured: it opens with the primary use case, lists return contents, then summarizes parameters, and ends with behavioral constraints. Each sentence has a distinct purpose, though the phrase 'read-only and idempotent with no destructive side effects' is partially redundant with the annotations. Overall, it is appropriately sized for a complex audit tool and front-loaded with action guidance.

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?

The description is remarkably complete given the tool's complexity: it covers when to use, what will be returned (a comprehensive list), required and optional parameters, and critical behavioral constraints (labeling partial coverage, avoiding conversion to investment advice). With a full output schema and annotations providing safety hints, the description adds all essential context for an agent to select and invoke the tool confidently. Even without an output schema, the return list would be sufficient for basic understanding.

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, but the description adds semantic relationships not obvious from the schema: it lists explicit accepted values for product (AI10, Synthetic AI10 ETF, AI-PERP-INTX, Tech100, TEK-19DEC30-CDE), states that source-date filters override window_days, and explains that limit/offset paginate factor-history rows. These enrich the parameter understanding beyond individual schema descriptions.

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?

The description clearly states it is an audit tool for the Delta Signal Synthetic AI 10 ETF, with specific use cases: understanding factor drivers, raw audit evidence, and verifying a four-level ATLAS-7 verdict. It lists a detailed set of returned data, distinguishing it from sibling tools like deltasignal_synthetic_etf_pressure_state or general signal tools. The verb 'audit' and resource scope are explicit and specific.

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

Usage Guidelines4/5

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

The description provides explicit conditions for use ('when the user asks what factors drive...', 'asks for raw audit evidence', or 'asks whether the current pressure state is a full four-level ATLAS-7 verdict'). It does not explicitly name alternative tools or when-not-to-use cases, but the when-conditions are clear enough to guide an agent away from pressure-state or signal tools. The 'must not convert' sentence also sets usage boundaries by outlining that it does not produce investment advice or exchange-native truth.

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

All DeltaSignal ATLAS-7 tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?