CoinRithm/coinrithm-agent-trading

Official

by CoinRithm

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Get positions

get_positions

Read-only

Lists open and closed futures or prediction-market positions for a chosen venue, returning unrealized P&L/mark values and an asOf timestamp so you can poll only changes.

Instructions

List open + historical positions for a venue. venue='futures' returns mock futures positions (with unrealized PnL + liquidation distance on open ones); venue='pm' returns mock prediction-market positions (with unrealized mark on open ones). Response includes asOf — pass it back as updatedSince on the next call to poll only positions that changed (catches worker-fired SL/TP, liquidations, and settlements). Paper trading only (virtual mUSD). Fills follow paper_execution_v1 with a disclosed execution cost; see executionModel in quote/trade results.

Input Schema

TableJSON Schema

Name	Required	Description
`venue`	Yes	Which venue's positions to list.
`agentTrace`	No	Optional private trace metadata stored in the caller's ledger.
`updatedSince`	No	ISO 8601 cursor: only positions whose row changed since this instant. Pass the previous response's asOf back here.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`body`	No
`httpStatus`	Yes
`ledgerStatus`	No
`ledgerEventId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.1.23Oct 2, 2026

removedOutput schema / properties / body / description

Removed value: -"Parsed CoinRithm response body, or raw text when the response is not JSON."

removedOutput schema / properties / httpStatus / description

Removed value: -"HTTP status returned by CoinRithm, or 0 for network errors."

removedOutput schema / properties / ledgerEventId / description

Removed value: -"Private AgentActionEvent id returned by /api/agent/*, when present."

removedOutput schema / properties / ledgerStatus / description

Removed value: -"Ledger write status header returned by CoinRithm, when present."

removedOutput schema / properties / ok / description

Removed value: -"True when CoinRithm returned a successful 2xx response."

Changed3 schema fields changedv0.1.8Jun 12, 2026

addedInput schema / properties / agentTrace

Added value: +{
+  "additionalProperties": false,
+  "description": "Optional private trace metadata stored in the caller's ledger.",
+  "properties": {
+    "confidence": {
+      "description": "Optional confidence score from 0 to 1.",
+      "maximum": 1,
+      "minimum": 0,
+      "type": "number"
+    },
+    "decisionId": {
+      "description": "Agent decision id for quote/write attribution.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "rationaleSummary": {
+      "description": "Optional concise rationale summary. Do not include chain-of-thought, secrets, or account identity.",
+      "maxLength": 1200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "runId": {
+      "description": "Agent run id for grouping.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "strategyLabel": {
+      "description": "Short strategy label, self-reported by the caller.",
+      "maxLength": 120,
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / ledgerEventId

Added value: +{
+  "description": "Private AgentActionEvent id returned by /api/agent/*, when present.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / ledgerStatus

Added value: +{
+  "description": "Ledger write status header returned by CoinRithm, when present.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed1 schema field changedv0.1.6Jun 10, 2026

addedInput schema / properties / updatedSince

Added value: +{
+  "description": "ISO 8601 cursor: only positions whose row changed since this instant. Pass the previous response's asOf back here.",
+  "type": "string"
+}

Changed1 schema field changedv0.1.5Jun 10, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "body": {
+      "description": "Parsed CoinRithm response body, or raw text when the response is not JSON."
+    },
+    "httpStatus": {
+      "description": "HTTP status returned by CoinRithm, or 0 for network errors.",
+      "type": "integer"
+    },
+    "ok": {
+      "description": "True when CoinRithm returned a successful 2xx response.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "httpStatus",
+    "ok"
+  ],
+  "type": "object"
+}

First observedv0.1.4Jun 10, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already cover the read-only/non-destructive safety profile, and the description layers on substantial extra context: paper-trading-only (virtual mUSD), the venue-specific payload composition, the cursor round-trip contract, and the paper_execution_v1 cost model with a pointer to executionModel. This is well beyond what the structured fields disclose.

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?

Front-loaded with the core action and scope, then progressively the venue branches and cursor mechanics. Dense but every sentence carries information; minor cost is that the paper-trading/execution-model caveat is packed onto the end.

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

Completeness4/5

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

With an output schema present, return-value detail is not needed, and the description still covers venue behavior, the polling cursor, and the paper-trading constraint. Complete enough for correct invocation; only the sibling-routing gap keeps it from top marks.

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 meaning the schema lacks: it explains the asOf/updatedSince round-trip pattern tying the response cursor to the input param, and characterizes what each venue enum value returns.

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?

States a specific verb (List) plus resource (open + historical positions) and scope (for a venue), then differentiates the two venue modes with concrete return contents. It is clearly distinguishable from order/trade tools by resource, though it never names a sibling (e.g. get_portfolio, get_my_trades) to route the agent explicitly.

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

Usage Guidelines3/5

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

Provides real usage mechanics: pass the response's asOf back as updatedSince to poll only changed rows, and notes this catches SL/TP fires, liquidations and settlements. However it gives no when-to-use-vs-alternative guidance, so an agent must infer this tool's place against get_portfolio, get_my_trades and list_open_orders.

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