Synthex Forge — x402 Paid Agent Services

Get Edge Prior

get_edge_prior

Read-onlyIdempotent

What has actually been tested on this instrument, timeframe and strategy type. use it rather than assess_market_regime for edge prior, not market regime; an object with 10 fields including accepted_fields, detail.

Input Schema

Name	Required	Description
`family`	No	The strategy family, e.g. 'breakout'. Case and separator insensitive.
`free_text`	No	A free-text description, matched on normalised token overlap against the entry's name, type, family and edge_type. Generic words ('strategy', 'backtest', 'using') are stopwords and carry no matching signal.
`timeframe`	No	The timeframe to look up, e.g. 'H1'. NORMALISED: 60m == H1, 1h == H1, 4h == H4, 1d == D1.
`instrument`	No	The instrument to look up, e.g. 'USD_JPY'. NORMALISED: USDJPY, USD/JPY, usd-jpy and USD_JPY are all one instrument. Aliases: XAUUSD/gold -> XAU_USD, XAGUSD/silver -> XAG_USD, SPX500 -> SPX500_USD, NAS100 -> NAS100_USD.
`strategy_type`	No	The strategy type, e.g. 'donchian_breakout'. Case and separator insensitive: 'Donchian Breakout' == 'donchian_breakout'.

Output Schema

Name	Required	Description
`error`	No	The machine-readable error code, when the operation failed.
`detail`	Yes	Human-readable explanation of the verdict.
`family`	No	The `family` field of the response.
`free_text`	No	The `free_text` field of the response.
`timeframe`	No	The `timeframe` field of the response.
`instrument`	No	The `instrument` field of the response.
`x402Version`	No	The `x402Version` field of the response.
`strategy_type`	No	The `strategy_type` field of the response.
`accepted_fields`	No	The `accepted_fields` field of the response.
`field_descriptions`	No	The `field_descriptions` field of the response.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedOct 31, 2026

addedOutput schema / properties / accepted_fields

Added value: +{
+  "description": "The `accepted_fields` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / detail

Added value: +{
+  "description": "Human-readable explanation of the verdict.",
+  "type": "string"
+}

addedOutput schema / properties / error

Added value: +{
+  "description": "The machine-readable error code, when the operation failed.",
+  "type": "string"
+}

addedOutput schema / properties / family

Added value: +{
+  "description": "The `family` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / field_descriptions

Added value: +{
+  "description": "The `field_descriptions` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / free_text

Added value: +{
+  "description": "The `free_text` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / instrument

Added value: +{
+  "description": "The `instrument` field of the response.",
+  "type": "object"
+}

removedOutput schema / properties / status

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / strategy_type

Added value: +{
+  "description": "The `strategy_type` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / timeframe

Added value: +{
+  "description": "The `timeframe` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / x402Version

Added value: +{
+  "description": "The `x402Version` field of the response.",
+  "type": "object"
+}

addedOutput schema / required
```
Added value: +[
+  "detail"
+]
```

AddedOct 31, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds only a brief note that the return is an object with 10 fields including `accepted_fields` and `detail`. Since an output schema exists, that return hint is largely redundant and no additional behavioral traits are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, and the description is short. However, the second sentence is grammatically awkward and partly spends words on output fields that the output schema already documents. It is compact but not fully polished or economical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given five optional parameters, full schema coverage, existing annotations, and an output schema, the description is minimally adequate. It supplies the key sibling routing and confirms the tool's output shape, but it does not explain what an 'edge prior' contains or how the result should be interpreted. It is sufficient for invocation but not complete for confident interpretation.

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?

Schema description coverage is 100%, so the schema already explains all five parameters and their normalization rules. The description mentions instrument, timeframe, and strategy type but adds no parameter detail beyond what the schema provides, and omits family and free_text entirely. A baseline 3 is appropriate when the schema carries parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a specific lookup resource: what has been tested for a given instrument, timeframe, and strategy type. It also explicitly contrasts itself with `assess_market_regime` by saying this returns edge prior, not market regime. It does not distinguish itself from other edge-related siblings such as `verify_edge_evidence` or `evaluate_edge_replication`, which keeps it below a 5.

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 gives a clear routing instruction: use this rather than `assess_market_regime` for edge prior. That is useful when-to-use guidance. It does not state explicit when-not conditions or mention alternative edge tools, so it falls short of a 5.

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

All Synthex Forge — x402 Paid Agent Services 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.