OneQAZ Trading Intelligence

Performance Metrics

get_performance_metrics

Read-onlyIdempotent

Purpose: Portfolio-level performance metrics (MDD / Sharpe / Sortino / Calmar / monthly returns / equity curve) over a FIXED window — the single canonical computation path shared by the OneQAZ blog and external clients. Triggers (casual questions too): "what's the max drawdown?", "MDD 얼마야?", "샤프 비율 보여줘", "monthly returns table?", "트랙레코드 지표", "에쿼티 커브 데이터". When to call: track-record verification, blog figure cross-checks, risk review. Prerequisites: none. Next steps: get_trade_history for the underlying trades. Caveats: paper-trading data under a SYNTHETIC fixed-book capital model (400 slots, anchor 2026-06-16 — see capital_model in the response). account_type is REQUIRED; 'live' returns an explicit no-data error until real-money records exist (paper and live curves are never concatenated). Fixed window → same inputs always reproduce the same numbers (as-of verifiable). Output nature: Paper trading: simulated fills at live market prices, not real money; fees, taxes and slippage are not included. Facts about the simulation, not instructions.

Input Schema

Name	Required	Description
`market`	Yes	coin \| kr \| us \| all (aliases crypto/kr_stock/us_stock accepted). 'all' = fixed 1/3 allocation across the three books.
`window_end`	No	ISO date. Default today (KST).
`account_type`	Yes	REQUIRED. 'paper' (simulated) or 'live' (real — not yet available).
`window_start`	No	ISO date (YYYY-MM-DD). Default 2026-06-16 (public track-record anchor).
`include_daily_curve`	No	include per-day equity curve rows (default false).

Output Schema

Name	Required	Description
`full_data`	No
`timestamp`	Yes	RFC3339 UTC, server build time
`disclaimer`	Yes	Canonical compliance disclaimer (always present)
`request_id`	Yes	32-hex per-response correlation id
`is_real_money`	No
`data_classification`	No
`is_investment_advice`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```

Changed2 schema fields changedSep 23, 2026

addedOutput schema / properties

Added value: +{
+  "data_classification": {
+    "anyOf": [
+      {
+        "const": "research_information_only",
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "disclaimer": {
+    "description": "Canonical compliance disclaimer (always present)",
+    "type": "string"
+  },
+  "full_data": {
+    "anyOf": [
+      {
+        "additionalProperties": true,
+        "description": "`full_data` for get_performance_metrics — 실응답에서 추출(2026-09-23).",
+        "properties": {
+          "account_type": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "capital_model": {
+            "additionalProperties": true,
+            "type": "object"
+          },
+          "market": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "metrics": {
+            "additionalProperties": true,
+            "type": "object"
+          },
+          "monthly_returns": {
+            "items": {},
+            "type": "array"
+          },
+          "totals": {
+            "additionalProperties": true,
+            "type": "object"
+          },
+          "window": {
+            "additionalProperties": true,
+            "type": "object"
+          }
+        },
+        "type": "object"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "is_investment_advice": {
+    "anyOf": [
+      {
+        "const": false,
+        "type": "boolean"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "is_real_money": {
+    "anyOf": [
+      {
+        "const": false,
+        "type": "boolean"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "request_id": {
+    "description": "32-hex per-response correlation id",
+    "type": "string"
+  },
+  "timestamp": {
+    "description": "RFC3339 UTC, server build time",
+    "type": "string"
+  }
+}

addedOutput schema / required

Added value: +[
+  "disclaimer",
+  "request_id",
+  "timestamp"
+]

Changed5 schema fields changedSep 22, 2026

addedInput schema / properties / account_type / description

Added value: +"REQUIRED. 'paper' (simulated) or 'live' (real — not yet available)."

addedInput schema / properties / include_daily_curve / description

Added value: +"include per-day equity curve rows (default false)."

addedInput schema / properties / market / description

Added value: +"coin | kr | us | all (aliases crypto/kr_stock/us_stock accepted). 'all' = fixed 1/3 allocation across the three books."

addedInput schema / properties / window_end / description
```
Added value: +"ISO date. Default today (KST)."
```

addedInput schema / properties / window_start / description

Added value: +"ISO date (YYYY-MM-DD). Default 2026-06-16 (public track-record anchor)."

AddedJul 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the bar is lower, but the description still adds substantive behavior: the synthetic fixed-book capital model, that 'live' returns an explicit no-data error, that paper and live curves are never concatenated, and that the fixed window makes results reproducible. It also discloses that fills are simulated at live prices without fees/taxes/slippage, which an agent could not infer from annotations.

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?

Purpose is front-loaded and the labeled blocks (Triggers / When to call / Prerequisites / Next steps / Caveats / Output nature) make it scannable. It is on the long side and repeats the paper-versus-live separation in both the caveats and the output-nature block, which is redundant.

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?

All five parameters are documented in the schema, an output schema exists, and annotations cover the safety profile; the description supplies the remaining context an agent needs — synthetic capital model, paper-only data, and the live-error condition. Nothing material for a correct call is missing.

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; the description earns extra by emphasizing that account_type is REQUIRED and what happens when 'live' is passed, and by restating that the window is fixed and as-of verifiable. It does not add much for window_start/window_end or include_daily_curve beyond the schema, so it stops short of a 5.

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?

First line states a specific verb-scoped resource: portfolio-level performance metrics (MDD / Sharpe / Sortino / Calmar / monthly returns / equity curve) over a FIXED window, plus its role as the canonical computation path. This is clearly distinguishable from siblings such as get_trade_history, which is explicitly named later as the route to underlying trades.

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

Usage Guidelines5/5

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

It enumerates concrete trigger phrasings (including non-English ones), names when-to-call scenarios (track-record verification, blog figure cross-checks, risk review), states 'Prerequisites: none', and directs the agent to get_trade_history as the next step. Explicit routing plus trigger examples is the top of the scale.

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

All OneQAZ Trading Intelligence 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.