Perch Data

perchpermits/polymarket-weather-markets-stations

perchpermits--polymarket-weather-markets-stations

Destructive

This tool calls the Actor "perchpermits/polymarket-weather-markets-stations" and retrieves its output results. Actor description: Every Polymarket daily highest and lowest temperature ladder (50 cities worldwide) joined to the airport station its rules settle on: NYC is LaGuardia, not Central Park. High/low recomputed as the rules read it; 325 of 326 settled ladders landed in the paid bracket. Free official APIs only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`join`	No	Read the station from each market's rules and add its reports for the local day, the brackets already ruled out, the US forecast, and a verdict. Charged as joined-ladder; off returns plain ladders. Example values: true
`kind`	No	`high` for daily highest temperature ladders, `low` for daily lowest, or both. Example values: "both"	both
`cities`	No	Optional. Polymarket city slugs to keep: nyc, chicago, miami, dallas, denver, atlanta, austin, houston, seattle, los-angeles, san-francisco, toronto, mexico-city, sao-paulo, buenos-aires, london, paris, madrid, milan, munich, amsterdam, warsaw, helsinki, istanbul, moscow, tel-aviv, jeddah, karachi, lucknow, tokyo, seoul, busan, beijing, shanghai, shenzhen, guangzhou, singapore, manila, taipei, wellington, cape-town and more. Empty = every open ladder.
`dateTo`	No	Optional ISO date, inclusive. Defaults to Target date from.
`dateFrom`	No	Optional ISO date. With a date, the actor looks up each listed city's ladder for every day in the range, open or settled (settled rows carry the paid bracket). Needs Cities.
`waitSecs`	No	Max seconds (0–45, default 30) to cap the wait for the Actor run to reach terminal state. For long-running Actors the response returns at the cap with the current run status; follow `nextStep` to poll via get-actor-run. Set to 0 to fire-and-forget.
`maxEvents`	No	Stop after this many city-day ladders. Example values: 100
`requestDelaySeconds`	No	Politeness delay for the public APIs. Example values: 0.25

Output Schema

TableJSON Schema

Name	Required	Description
`runId`	Yes	Actor run ID
`stats`	No	Run statistics
`status`	Yes	Run status: READY \| RUNNING \| TIMING-OUT \| TIMED-OUT \| ABORTING \| ABORTED \| SUCCEEDED \| FAILED
`actorId`	Yes	Stable Apify Actor ID from the run record
`summary`	Yes	Past-tense summary of the run state
`exitCode`	No	Actor process exit code; populated for terminal states (especially FAILED)
`nextStep`	Yes	One primary follow-up action with identifiers interpolated
`storages`	Yes	Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry.
`actorName`	No	"username/actor-name"
`startedAt`	No	ISO timestamp when the run started
`finishedAt`	No	ISO timestamp when the run finished (terminal states only)
`statusMessage`	No	Pass-through from Apify run.statusMessage
`apifyConsoleUrl`	No	Personalized Apify Console link to the run; present only for Console sessions

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedSep 20, 2026
- changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / brackets / items / properties / liquidity / type
```
Previous value: -[
-  "null",
-  "number"
-]New value: +"number"
```
- changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / brackets / items / properties / volume / type
```
Previous value: -[
-  "null",
-  "number"
-]New value: +"number"
```
- removedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / join_error
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / note
```
Removed value: -{
-  "type": "string"
-}
```
- addedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / observations / properties
```
Added value: +{
+  "count": {
+    "type": "number"
+  },
+  "covers_day_start": {
+    "type": "boolean"
+  },
+  "day_complete": {
+    "type": "boolean"
+  },
+  "first_at": {
+    "type": "string"
+  },
+  "hourly_only": {
+    "type": "boolean"
+  },
+  "latest": {
+    "type": "number"
+  },
+  "latest_at": {
+    "type": "string"
+  },
+  "max": {
+    "type": "number"
+  },
+  "max_at": {
+    "type": "string"
+  },
+  "min": {
+    "type": "number"
+  },
+  "min_at": {
+    "type": "string"
+  },
+  "unit": {
+    "type": "string"
+  }
+}
```
- addedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / observations / type
```
Added value: +"object"
```
- changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / station / properties / icao / type
```
Previous value: -[
-  "null",
-  "string"
-]New value: +"string"
```
- addedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / station / properties / reports_source
```
Added value: +{
+  "type": "string"
+}
```
- changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / station / properties / timezone / type
```
Previous value: -[
-  "null",
-  "string"
-]New value: +"string"
```
- addedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / verdict / properties
```
Added value: +{
+  "day_complete": {
+    "type": "boolean"
+  },
+  "final_if_complete": {
+    "type": "null"
+  },
+  "forecast_lands_in": {
+    "type": [
+      "null",
+      "string"
+    ]
+  },
+  "forecast_value": {
+    "type": [
+      "null",
+      "number"
+    ]
+  },
+  "market_expected_temp": {
+    "type": "number"
+  },
+  "market_favorite": {
+    "type": "string"
+  },
+  "note": {
+    "type": "string"
+  },
+  "paid_bracket": {
+    "type": "null"
+  },
+  "running_lands_in": {
+    "type": [
+      "null",
+      "string"
+    ]
+  },
+  "running_value": {
+    "type": [
+      "null",
+      "number"
+    ]
+  }
+}
```
- addedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / verdict / type
```
Added value: +"object"
```
First observedSep 19, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already carry readOnlyHint=false, openWorldHint=true, and destructiveHint=true, so the safety profile is known. The description adds that the tool launches a remote Actor and retrieves results, plus useful data-source context ('Free official APIs only'), but it does not explain what the destructive hint means or what side effects the Actor run may have.

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?

The description is short and mostly information-dense. The first sentence is slightly generic but the Actor description earns its place by explaining the dataset's value. No significant fluff, though 'retrieves its output results' is somewhat redundant with 'calls the Actor.'

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

Completeness3/5

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

Given the tool is a complex Actor wrapper with 8 optional parameters and an output schema, the description conveys the dataset's meaning but omits operational context such as when to use it, how long runs may take, or how it relates to polling tools. The output schema covers return values, so the main gap is usage orientation.

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?

The input schema has 100% description coverage, with each parameter already documented in detail, so the description does not need to compensate. The tool description adds no param-specific meaning beyond what the schema provides, matching the baseline of 3.

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?

The description states a specific action—calls the named Actor and retrieves its output results—and the Actor description clarifies the exact data content (temperature ladders joined to settling airport stations). It is clearly distinct from generic sibling tools like get-actor-run or fetch-actor-details because it names the exact Actor and its dataset.

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 provides no guidance on when to choose this tool over alternatives such as get-actor-run or fetch-actor-details, nor any exclusions or prerequisites. The only implicit usage signal is the Actor description, but there is no explicit when-to-use statement.

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

All Perch Data 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.