AIsa Finance

by one.aisa

Overview Discussions Admin

Get user activity

get_polymarket_activity

Read-onlyIdempotent

Returns user activity with pagination and filtering.

Published reference price: $0.012 USD per successful request. Account-specific pricing and final settlement may differ.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`end`	No	Upper-bound timestamp (epoch seconds) for the activity window. Omit for the default (current time); rows newer than `end` are excluded.
`side`	No
`type`	No	Comma-separated list of activity types to include. DEPOSIT and WITHDRAWAL records also require `excludeDepositsWithdrawals=false`.
`user`	Yes	User Profile Address (0x-prefixed, 40 hex chars)
`limit`	No	Page size. Values above the maximum are clamped to 500.
`start`	No	Lower-bound timestamp (epoch seconds) for the activity window. Omit or pass `0` for the default window (most recent ~3 years); pass a positive epoch (e.g. `1`) to retrieve full history. With `sortDirection=ASC`, omitting `start` already reads from the beginning of the account's history (no default window).
`market`	No	Comma-separated list of condition IDs. Mutually exclusive with eventId.
`offset`	No	Starting index for pagination. Requests past the cap are rejected with a 400 (never silently clamped). To read history deeper than offset 5000, page inside `start`/`end` windows — each window has its own offset budget.
`sortBy`	No		TIMESTAMP
`eventId`	No	Comma-separated list of event IDs. Mutually exclusive with market.
`sortDirection`	No	`DESC` (default) returns the newest rows first; `ASC` the oldest first. Both orders are stable — the same query returns the same rows at any `limit`/`offset`, so pages compose without gaps or repeats.	DESC
`excludeDepositsWithdrawals`	No	Excludes deposit and withdrawal records. The default `true` applies even when `type` requests those records, so to get deposits and withdrawals you must pass `false`.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed23 schema fields changedOct 15, 2026

removedInput schema / properties / condition_id

Removed value: -{
-  "description": "Filter activity by condition ID",
-  "example": "0x4567b275e6b667a6217f5cb4f06a797d3a1eaf1d0281fb5bc8c75e2046ae7e57",
-  "type": "string"
-}

addedInput schema / properties / end

Added value: +{
+  "description": "Upper-bound timestamp (epoch seconds) for the activity window. Omit for the default (current time); rows newer than `end` are excluded.",
+  "minimum": 0,
+  "type": "integer"
+}

removedInput schema / properties / end_time

Removed value: -{
-  "description": "Filter activity until this Unix timestamp in seconds (inclusive)",
-  "example": 1672531200,
-  "type": "integer"
-}

addedInput schema / properties / eventId

Added value: +{
+  "description": "Comma-separated list of event IDs. Mutually exclusive with market.",
+  "items": {
+    "minimum": 1,
+    "type": "integer"
+  },
+  "type": "array"
+}

addedInput schema / properties / excludeDepositsWithdrawals

Added value: +{
+  "default": true,
+  "description": "Excludes deposit and withdrawal records. The default `true` applies even when `type` requests those records, so to get deposits and withdrawals you must pass `false`.",
+  "type": "boolean"
+}

changedInput schema / properties / limit / description

Previous value: -"Number of activities to return (1-1000)"New value: +"Page size. Values above the maximum are clamped to 500."

removedInput schema / properties / limit / example
```
Removed value: -50
```
changedInput schema / properties / limit / maximum
```
Previous value: -1000New value: +500
```
changedInput schema / properties / limit / minimum
```
Previous value: -1New value: +0
```

addedInput schema / properties / market

Added value: +{
+  "description": "Comma-separated list of condition IDs. Mutually exclusive with eventId.",
+  "items": {
+    "description": "0x-prefixed 64-hex string",
+    "example": "0xdd22472e552920b8438158ea7238bfadfa4f736aa4cee91a6b86c39ead110917",
+    "pattern": "^0x[a-fA-F0-9]{64}$",
+    "type": "string"
+  },
+  "type": "array"
+}

removedInput schema / properties / market_slug

Removed value: -{
-  "description": "Filter activity by market slug",
-  "example": "bitcoin-up-or-down-july-25-8pm-et",
-  "type": "string"
-}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Starting index for pagination. Requests past the cap are rejected with a 400 (never silently clamped). To read history deeper than offset 5000, page inside `start`/`end` windows — each window has its own offset budget.",
+  "maximum": 5000,
+  "minimum": 0,
+  "type": "integer"
+}

removedInput schema / properties / pagination_key

Removed value: -{
-  "description": "Base64-encoded cursor for efficient pagination. Returned in the previous response's pagination object.",
-  "example": "eyJibG9ja190aW1lc3RhbXAiOiIyMDI1LTAxLTE5VDEyOjAwOjAwLjAwMFoiLCJzaWRlIjoiU1BMSVQiLCJ0eF9oYXNoIjoiMHgxMjM0NTY3ODkwYWJjZGVmIiwibG9nX2luZGV4IjoxMCwidG90YWwiOjE5ODkwMTc3Nn0=",
-  "type": "string"
-}

addedInput schema / properties / side

Added value: +{
+  "enum": [
+    "BUY",
+    "SELL"
+  ],
+  "type": "string"
+}

addedInput schema / properties / sortBy

Added value: +{
+  "default": "TIMESTAMP",
+  "enum": [
+    "TIMESTAMP",
+    "TOKENS",
+    "CASH"
+  ],
+  "type": "string"
+}

addedInput schema / properties / sortDirection

Added value: +{
+  "default": "DESC",
+  "description": "`DESC` (default) returns the newest rows first; `ASC` the oldest first. Both orders are stable — the same query returns the same rows at any `limit`/`offset`, so pages compose without gaps or repeats.",
+  "enum": [
+    "ASC",
+    "DESC"
+  ],
+  "type": "string"
+}

addedInput schema / properties / start

Added value: +{
+  "description": "Lower-bound timestamp (epoch seconds) for the activity window. Omit or pass `0` for the default window (most recent ~3 years); pass a positive epoch (e.g. `1`) to retrieve full history. With `sortDirection=ASC`, omitting `start` already reads from the beginning of the account's history (no default window).",
+  "minimum": 0,
+  "type": "integer"
+}

removedInput schema / properties / start_time

Removed value: -{
-  "description": "Filter activity from this Unix timestamp in seconds (inclusive)",
-  "example": 1640995200,
-  "type": "integer"
-}

addedInput schema / properties / type

Added value: +{
+  "description": "Comma-separated list of activity types to include. DEPOSIT and WITHDRAWAL records also require `excludeDepositsWithdrawals=false`.",
+  "items": {
+    "enum": [
+      "TRADE",
+      "SPLIT",
+      "MERGE",
+      "REDEEM",
+      "REWARD",
+      "CONVERSION",
+      "DEPOSIT",
+      "WITHDRAWAL",
+      "YIELD",
+      "MAKER_REBATE",
+      "TAKER_REBATE",
+      "REFERRAL_REWARD"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / properties / user / description

Previous value: -"Wallet address or user identifier. Required by the runtime route."New value: +"User Profile Address (0x-prefixed, 40 hex chars)"

changedInput schema / properties / user / example

Previous value: -"0x7c3db723f1d4d8cb9c550095203b686cb11e5c6b"New value: +"0x56687bf447db6ffa42ffe2204a05edaa20f55839"

changedInput schema / properties / user / pattern

Previous value: -"^0x[0-9a-fA-F]{40}$"New value: +"^0x[a-fA-F0-9]{40}$"

addedOutput schema / x-fastmcp-wrap-result
```
Added value: +true
```

First observedSep 15, 2026

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds only pagination/filtering presence and a pricing note — no behavior like default time windows, offset caps, or stable ordering, all of which matter for an activity query and are pushed entirely into the schema.

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?

Only one substantive sentence, with the rest being an HTML-comment pricing banner that is irrelevant to invocation. It is short but under-specified rather than concise, and the pricing block bloats the payload.

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 12-parameter tool with tricky defaults (default ~3-year window, offset 5000 cap, excludeDepositsWithdrawals overriding type), the description is far too thin. An output schema exists, so return values need not be explained, but operational pitfalls are unaddressed in prose.

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 83%, so the schema documents nearly all parameters richly (windows, caps, mutual exclusions, default quirks). The description adds no parameter guidance beyond generic 'pagination and filtering', so the baseline 3 applies.

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

Purpose3/5

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

The description says it 'returns user activity' with 'pagination and filtering' — an accurate but generic purpose statement. It doesn't name the platform (Polymarket, inferable from the tool name) or distinguish it from sibling tools like get_kalshi_trades, though those target different venues.

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?

No explicit when-to-use or when-not-to-use guidance. The description only states pagination/filtering exist; the schema carries all nuance (e.g., excludeDepositsWithdrawals caveat, ASC/start interaction). No alternatives named.

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

All AIsa Finance 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.

Resources

Need Help?