Skip to main content
Glama
Sign In
hermeschoosenone-debug

synthex-mcp-server

by hermeschoosenone-debug
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Is that track record real, or did you find it by looking? (PAID $3.00)

v1_edge_replication

Validates strategy track records by computing Sharpe, CAGR, and max drawdown from return data, comparing claimed figures, and adjusting for the number of trials attempted.

Instructions

Is that track record real, or did you find it by looking? (PAID $3.00)

Remote route: POST /v1/edge/replication (3.00 USD x402/base/usdc on eip155:8453).

Input Schema

NameRequiredDescriptionDefault
claimedNoOptional: {sharpe, cagr, max_dd} — your stated figures. When supplied they are compared against the computed ones and a mismatch is a named finding.
returnsNoThe return series, as a JSON list of numbers. EITHER this or 'returns_csv_b64' is required, never both. At most 200000 observations; a longer series is a 400 naming the limit. NaN and infinity are rejected — they are not a return series.
frequencyNo'daily' or 'per_trade'. REQUIRED. A daily series is annualised with sqrt(252); a per_trade series is reported PER TRADE and is never annualised, because a per-trade series has no knowable trades-per-year.
strategy_shapeNoOptional: {type, instrument, timeframe}. 'type' is one of trend | mean_reversion | breakout | other and selects the calibration bucket; 'instrument' selects the instrument-class bucket. Instruments are NORMALISED (EUR/USD == EUR_USD == eurusd).
returns_csv_b64NoThe return series as a base64-encoded CSV, one number per row. The alternative to 'returns'. Decoded size is capped at 1 MB.
trials_attemptedNoHow many configurations you tried before keeping this one. REQUIRED, and must be >= 2. This is the number that makes the Deflated Sharpe meaningful: a Sharpe of 2.0 found after 500 tries is priced for what it is. We never assume trials = 1.

Output Schema

NameRequiredDescriptionDefault
statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.4/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds useful context beyond annotations: it is a PAID $3.00 route via x402 on Base USDC using POST /v1/edge/replication. It does not explain side effects, auth requirements, or failure behavior beyond payment, so this is moderate.

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

Conciseness2/5

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

The description is only two sentences, but the first is a rhetorical hook that repeats the title and does not help an agent select or invoke the tool. The second is payment routing. It is short but under-specified rather than appropriately concise.

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

Completeness2/5

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

For a paid financial backtest replication tool with six parameters and an output schema, the description omits what it computes, what inputs are required, and when to use it. Only the payment route is supplied; the core functional context is missing.

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%, and all six parameters have detailed schema text (returns vs returns_csv_b64 exclusivity, frequency annualization rules, trials_attempted >= 2, etc.). The description itself adds no parameter guidance, but the schema does the heavy lifting; baseline 3 is appropriate.

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

Purpose2/5

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

The title and description are a rhetorical question ('Is that track record real, or did you find it by looking?') plus a route/payment line. There is no explicit verb+resource statement such as 'computes a deflated Sharpe ratio' or 'audits a backtest for overfitting'; the agent must infer purpose from the name and schema. This is vague rather than a clear purpose.

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

Usage Guidelines2/5

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

The description gives no when-to-use, when-not-to-use, or alternative-tool guidance. Siblings such as v1_quant_significance, v1_strategy_verdict, and v1_edge_prior are never mentioned. Only payment mechanics are supplied.

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

Deploy Server

Other Tools