NythosX Market Data

get_trigger_status

Status of a trigger armed with arm_price_trigger (free). Returns {id, status, symbol, direction, price, created_at, expires_at, fired_at, fired_price, delivered_at, cancelled_at, delivery_attempts, last_error}, where status is one of armed, fired_delivering, delivered, delivery_failed (after 5 webhook attempts), expired or cancelled (via disarm_price_trigger). Returns 404 if id is unknown or its payment never settled.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "get_trigger_status"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Trigger id returned by arm_price_trigger, format trg_<24 hex chars>

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026
- addedInput schema / properties / id / description
```
Added value: +"Trigger id returned by arm_price_trigger, format trg_<24 hex chars>"
```
First observedOct 20, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it enumerates returned fields, defines every status value including delivery_failed after 5 webhook attempts, and discloses the 404 condition. This gives an agent enough context to interpret both success and failure responses.

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?

The description is front-loaded with the core action and then supplies compact, necessary return and status details. Every sentence earns its place, and no space is wasted on redundant or vague phrasing.

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?

There is no output schema, but the description fully documents the return object’s fields and status values. It also covers the key error case, so an agent has everything needed to invoke and interpret the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The single id parameter has 100% schema description coverage, including its trg_<24 hex chars> format and its origin from arm_price_trigger. The description does not add parameter detail beyond what the schema already provides, so the baseline 3 is appropriate.

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 states a specific verb and resource: it returns the status of a trigger armed by arm_price_trigger. It also ties the tool directly to its sibling workflow, making it distinguishable from listing or market tools.

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?

It clearly indicates this is for checking a trigger created by arm_price_trigger and notes the 404 condition when the id is unknown or payment never settled. It does not explicitly say when not to use it versus siblings, but the intended lifecycle context is clear.

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

All NythosX Market Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?