Skip to main content
Glama
Sign In

Problee

by com.problee
OverviewDiscussionsAdmin

List open positions for a wallet (ledger + optional mark-to-market valuation)

problee_get_positions
Read-onlyIdempotent

Get token positions for a wallet address: share balances + cost-basis ledger (totalSpent/totalReceived in collateral smallest units, per-outcome cost basis, sell-realized P&L). Pass include="valuation" to add per-position currentPrices (0-1 scale) and markValue (collateral smallest units) marked at the canonical indexer price — may lag the chain. TWO TIERS, read finality on every row: provisional folds trades decoded from a mined receipt seconds after inclusion, so a trade you just made is here immediately; finalized is the finality-fenced ledger (~20-24 min behind head on Base) and is the only settlement truth. Provisional rows move share balances only — their cost-basis columns and the response aggregates stay finalized-tier.

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": {
      "walletAddress": "<walletAddress>"
    },
    "name": "problee_get_positions"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
cursorNo
chainIdNo
includeNoSet to "valuation" to add currentPrices (0-1) and markValue per position.
marketAddressNo
walletAddressYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / $defs / PositionsResponse / properties / positions / items / properties / marketReference
      Added value: +{
+  "pattern": "^mkt_[\\da-f]{8}-[\\da-f]{4}-[\\da-f]{4}-[\\da-f]{4}-[\\da-f]{12}$",
+  "type": "string"
+}
    • addedOutput schema / $defs / PositionsResponse / properties / positions / items / properties / outcomes
      Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "outcome": {
+        "type": "string"
+      },
+      "shares": {
+        "pattern": "^(?:0|[1-9]\\d*)(?:\\.\\d{1,6})?$",
+        "type": "string"
+      }
+    },
+    "required": [
+      "outcome",
+      "shares"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedOutput schema / $defs / PositionsResponse / properties / positions / items / properties / realizedPnlPm
      Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^-?(?:0|[1-9]\\d*)(?:\\.\\d{1,6})?$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
    • addedOutput schema / $defs / PositionsResponse / properties / positions / items / properties / valuePm
      Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^(?:0|[1-9]\\d*)(?:\\.\\d{1,6})?$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare the read-only/idempotent profile, and the description goes well beyond them: it discloses the two-tier finality model, that provisional rows fold mined-receipt trades immediately, that finalized is the only settlement truth (~20-24 min lag on Base), and that provisional updates affect share balances only while cost-basis and aggregates stay finalized-tier. That is exactly the kind of non-obvious behavioral context an agent needs.

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 purpose, then progressively adds valuation and finality detail. Dense but every sentence carries distinct information; only the parenthetical "0-1 scale"/units repetition slightly pads.

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?

An output schema exists so return values need not be restated, and the description covers finality semantics and valuation opt-in thoroughly. The remaining gap is that half the input parameters (pagination and filtering) are unexplained for a tool whose schema documents almost nothing.

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 coverage is only 17%, so the description must compensate. It does explain include="valuation" and the semantics of the returned valuation fields, but limit, cursor, chainId, marketAddress, and walletAddress remain undocumented in both schema and description. Partial compensation, not full.

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?

States a specific verb+resource ("Get token positions for a wallet address") and enumerates the concrete payload it returns: share balances, cost-basis ledger, per-outcome cost basis, and sell-realized P&L. This is clearly distinguishable from wallet-level siblings like problee_get_balance.

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?

Usage is implied through the include="valuation" opt-in and the finality-tier explanation, which tells the agent when provisional rows are useful. However, it never names alternatives (e.g., get_balance, list_trade_fills) or states when NOT to use this tool, so routing guidance is left to inference.

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

All Problee toolsInspect
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