@battlegrid/mcp-server 31.2.50 → 31.2.51

package/README.md

@@ -24,6 +24,51 @@ Seeing package `31.x` alongside handshake `battlegrid@33.x` — the package **be
 
 **What this changes for you:** nothing about how you call anything. Upgrading the package no longer waits on a server deploy, and a server deploy no longer strands you on a package that names the wrong contract — reconnect and the announcement follows. **Contract breaking-change notes are no longer keyed to package versions**, since a contract move is no longer a release here; the v11-and-earlier notes below are kept as history, and the live vocabulary is always discovery.
 
+## Contract history — v69 (Radar multi-agent duty)
+
+**Breaking: one input removed from two tools, three outputs reshaped.** A Radar policy carries no
+timeframe. Every rule whose conditions match puts its agent on duty at once, and each rule's regime
+condition is read at that agent's own regime timeframe. A coin still holds one position at a time: at
+most one fire per coin per pass, offered in rule priority.
+
+### Rejected input — something you send is no longer accepted
+
+- **`preview_radar_resolution`'s `SLOTS` request refuses `deploymentTimeframe`** as an unrecognized key.
+  Send `{ kind: "SLOTS", slots }`.
+- **`stage_radar_deployment_draft` refuses the `DEPLOYMENT_TIMEFRAME` axis** the same way. Stage only
+  `RULES` and `DEFAULT_SLOT`.
+
+### Reshaped output — something you read has a new shape
+
+- **`resolvesNow`** on `get_radar_deployment`, `list_radar_deployments` and `preview_radar_resolution` is
+  the coin's state (`section`, `isIdle`, `rotating`, one `reason`, the open-position owner) plus
+  **`onDuty`**: one row per agent on duty, in priority order. Each row carries its slot, its regime reading
+  at its own regime timeframe, its qualification verdict and gate, cooldown, block, `edgeSpent`, last flip
+  and fire, and its own `closeDecision`. The single-winner fields (`onDutyAgentId` and its display pair,
+  `matchedSlot*`, `regimeUsed`, and the per-agent fields the rows now carry) are gone. Render every row in
+  the order served, and never pick one yourself.
+- **`preview_radar_resolution`'s `conditionReach`** is one flat list, each entry naming its `agentId` and
+  `agentDisplayName`.
+- **Each deployment slot gains `agentRegimeTimeframe`**, the timeframe its rule's regime is read at.
+
+### Removed output — a field you read is gone
+
+- **`deploymentTimeframe`** on a Radar policy, and the **`DEPLOYMENT_TIMEFRAME`** axis in the radar
+  draft's `content` and `axesMeta` on `get_radar_deployment_draft`, `list_radar_deployment_drafts` and the
+  stage result.
+
+### Wider enums — a value you may now receive
+
+- **`closeDecision.outcome` gains `CLAIMED`**: the agent's close qualified, but a higher-priority agent
+  took the coin's one fire that pass. Its edge is preserved, and it fires at a later close only if it
+  still qualifies there.
+- **`get_radar_activity` and `get_radar_activity_summary`** gain the events `ON_DUTY_JOINED` and
+  `ON_DUTY_LEFT` (duty is journaled per agent) and the fire disposition `EDGE_PRESERVED_COIN_CLAIMED`.
+  `curveDigest` describes the first agent on duty, named in `curveAgentName`.
+- **`get_trade_conversation`** may carry the `close_claimed_by_radar` card.
+
+The exported `battlegrid-radar-deployment` skill describes the v69 flow.
+
 ## Contract history — v68.1 (Arena regime sets)
 
 Purely additive in schema, with **one refusal behind unchanged ones.** An Arena rule's regime condition

package/dist/index.d.ts

@@ -49,7 +49,7 @@ import { type Implementation, type Prompt, type Resource } from '@modelcontextpr
  * being asked. Move it for a change to THIS package — a proxy fix, a dependency bump, a docs
  * correction. Never move it to track the server.
  */
-export declare const PACKAGE_VERSION = "31.2.50";
+export declare const PACKAGE_VERSION = "31.2.51";
 export declare const DEFAULT_URL = "https://mcp.battlegrid.trade/mcp";
 export interface EnvConfig {
     apiKeys: string[];

package/dist/index.js

@@ -52,7 +52,7 @@ import { ListToolsRequestSchema, CallToolRequestSchema, ListPromptsRequestSchema
  * being asked. Move it for a change to THIS package — a proxy fix, a dependency bump, a docs
  * correction. Never move it to track the server.
  */
-export const PACKAGE_VERSION = '31.2.50';
+export const PACKAGE_VERSION = '31.2.51';
 export const DEFAULT_URL = 'https://mcp.battlegrid.trade/mcp';
 const MAX_RETRIES = 3;
 const RETRY_DELAYS_MS = [2000, 4000, 8000];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@battlegrid/mcp-server",
-  "version": "31.2.50",
+  "version": "31.2.51",
   "description": "BattleGrid MCP server — play crypto prediction games from AI agents",
   "type": "module",
   "main": "dist/index.js",

package/skills/EXPORT.json

@@ -1,11 +1,11 @@
 {
   "generator": "battlegrid-app/server/scripts/export-mcp-skills.mjs",
-  "contractVersion": "68.1.0",
+  "contractVersion": "69.0.0",
   "files": {
     "battlegrid-agent-management/SKILL.md": "fbc602e9445d0f72353bfba23c30a364b478bd04a9cc6248418cfeec66717eb1",
     "battlegrid-arena-play/SKILL.md": "4cfaa92a8d0dcaf477b227abd774e7aa8642c185d72108dfd401be0cf8aecd7f",
     "battlegrid-market-analysis/SKILL.md": "22fde9c4eac0261c89a8056ab8b20b66fcbe1fd58447fa0ac84fd410b4d134d7",
-    "battlegrid-radar-deployment/SKILL.md": "87601043eb3920faa153061e4ea93f4d8618dbdb8fe8c3be52b4e47ddba18d83",
+    "battlegrid-radar-deployment/SKILL.md": "54d476e47dbdfb305a8d0d384c03eef6d6aaffba19552a7d2432a51b92d5418d",
     "battlegrid-strategy-authoring/SKILL.md": "95e91dd1ff36922b7ed0f5eb92c98def98fa39cce37c3d7447269aea1b5a017f",
     "battlegrid-strategy-doctor/SKILL.md": "d0b9e9e07648246d5a23b0c17183278b70b5bcbb5f472ac7da13d03e42a6c6c6",
     "battlegrid-strategy-examples/SKILL.md": "17e8cf8040813622bd5b82165c7af82e03287fee1f6aac974e0b6c584580dd27",

package/skills/battlegrid-radar-deployment/SKILL.md

@@ -1,12 +1,14 @@
 ---
 name: battlegrid-radar-deployment
-description: Deploy the player's agents to standing duty — per-coin Radar policies that fire real trades on confirmed regime flips, and per-preset Arena deployment policies that enter sessions automatically. Reads what is deployed now, stages a change into the player's draft, previews what it would actually resolve to, commits it only after the player has seen that preview, and un-deploys with the blast radius stated. Activate whenever the player wants an agent put on duty, wants to change or pause a deployment, asks what would fire right now or why nothing is firing, or wants to stop a coin or a preset being traded automatically.
+description: Deploy the player's agents to standing duty — per-coin Radar policies that put every matching rule's agent on duty and fire real trades at confirmed closes, and per-preset Arena deployment policies that enter sessions automatically. Reads what is deployed now, stages a change into the player's draft, previews what it would actually resolve to, commits it only after the player has seen that preview, and un-deploys with the blast radius stated. Activate whenever the player wants an agent put on duty, wants to change or pause a deployment, asks what would fire right now or why nothing is firing, or wants to stop a coin or a preset being traded automatically.
 ---
 
 # Radar & Deployment
 
-You are handing an agent **standing authority**. A Radar policy fires real trades on confirmed
-regime flips with no further human action; a deployment policy enters real sessions the same way.
+You are handing agents **standing authority**. A Radar policy puts EVERY rule whose conditions match
+on duty at once — each rule's regime read at its own agent's regime timeframe — and fires real trades
+at their confirmed closes with no further human action, at most one per coin per pass, offered in rule
+priority; a deployment policy enters real sessions the same way.
 Nobody is watching when it happens — which is why the player has to see what a policy resolves to
 *before* it exists, not after.
 
@@ -18,7 +20,7 @@ and never describe them as one thing with two modes.
 
 1. **A write with no fresh preview.** *Cue: any `commit_radar_deployment_draft`,
    `resume_radar_deployment`, `commit_deployment_policy_draft` or `resume_deployment_policy`.* The preview is the only place the
-   player sees which agent actually goes on duty and why. → steps 2–3.
+   player sees which agents actually go on duty and why. → steps 2–3.
 2. **A blind retry.** *Cue: a CONFLICT on a write.* Something moved under you — the stored policy,
    or the player's draft. Retrying overwrites an edit you never read. → step 3.
 3. **Previewing one thing and writing another.** *Cue: the player adjusts a slot, a bar, a window
@@ -69,16 +71,19 @@ If the question is *why did my radar agent not fire*, do not start from the jour
 **Radar** — the change goes into the player's draft of the coin, never straight to the policy:
 
 1. `stage_radar_deployment_draft` with `draftVersion` = the `version` you read (0 when there was
-   no draft) and only the axes you are changing, each WHOLE: `DEPLOYMENT_TIMEFRAME`, `RULES` (the
-   complete ordered rule list — first is highest priority) and `DEFAULT_SLOT` (the catch-all, or
-   null for none). Staging writes nothing live and shows the change in the player's builder as a
-   proposal. A refusal naming axes means the player changed them after your read: read again and
+   no draft) and only the axes you are changing, each WHOLE: `RULES` (the complete ordered rule list
+   — first is highest priority; every rule that matches is on duty, so priority decides only which
+   agent is offered the coin's one fire on a pass) and `DEFAULT_SLOT` (the catch-all, on duty only
+   when no rule is, or null for none). A Radar policy has **no timeframe**: each rule's regime
+   condition is read at its agent's own regime timeframe, which every slot reports as
+   `agentRegimeTimeframe`. Staging writes nothing live and shows the change in the player's builder as
+   a proposal. A refusal naming axes means the player changed them after your read: read again and
    propose against what they now have.
 2. `preview_radar_resolution` with `request: { kind: "DRAFT", draftVersion }` at the version staging
    returned. It composes the draft over the deployed policy **exactly as the commit will write it**.
 
-To try a slot set without touching the draft, preview `{ kind: "SLOTS", deploymentTimeframe, slots }` —
-it certifies nothing and cannot be committed.
+To try a slot set without touching the draft, preview `{ kind: "SLOTS", slots }` — it certifies
+nothing and cannot be committed.
 
 **Arena** — the same shape, keyed on `presetId`:
 
@@ -96,19 +101,23 @@ Both previews run the **same resolver the live sweep runs**, so the preview is t
 an estimate. Neither writes anything and neither costs the player an LLM call — so previewing
 repeatedly while iterating is free and correct.
 
-Render the preview as a card and read it out: which agent goes on duty, which slot matched and at
-what priority, the regime and conviction used, the qualification verdict, and any typed idle or
-blocked reason. **Render `section` as the server sends it — never re-derive it.** A non-null reason
-does not mean idle (`ON_DUTY_BUT_POSITION_BLOCKED` carries a reason and is not idle), so deciding
-the headline yourself gets it wrong. `enabledAfterCommit` says whether the policy will play once
-committed — a paused policy stays paused, and a first Arena deployment always plays.
+Render the preview as a card and read it out. For **Radar**: the coin's `section` and any typed idle
+or blocked reason, then every row of `resolvesNow.onDuty` in the order served — each agent, the slot
+and priority that put it on duty, its regime reading at its own `regimeTimeframe` with conviction, its
+qualification verdict and its close clock — and, for a draft, `conditionReach`, which names each
+on-duty agent's required conditions. For **Arena**: which agent goes on duty, which slot matched and at
+what priority, the regime and conviction used, and the qualification verdict. **Render `section` as
+the server sends it — never re-derive it, and never pick, rank or drop rows yourself.** A non-null
+reason does not mean idle (`ON_DUTY_BUT_POSITION_BLOCKED` carries a reason and is not idle), so
+deciding the headline yourself gets it wrong. `enabledAfterCommit` says whether the policy will play
+once committed — a paused policy stays paused, and a first Arena deployment always plays.
 
 **If anything changes after a preview, re-preview.** A preview never vouches for what it did not
 resolve.
 
 ### 3. Confirm against the preview, then commit
 
-One confirmation whose question **references what the preview showed** — the agent it put on duty and
+One confirmation whose question **references what the preview showed** — the agents it put on duty and
 the reason — and **names what the change does to the stored policy**, read from step 1:
 
 - every rule or slot the change **removes** (by agent and priority), because `RULES` and `slots` are
@@ -133,7 +142,7 @@ with the old one is refused again — only a fresh preview earns a new one.
 
 **Pause a coin's Radar** → `pause_radar_deployment({ coinId })`. No preview and no revision: stopping
 never waits on a read. The player's draft is kept. **Resume** → preview the deployed policy with
-`request: { kind: "COMMITTED" }`, tell the player what will go on duty again, and on their word
+`request: { kind: "COMMITTED" }`, tell the player which agents will go on duty again, and on their word
 `resume_radar_deployment({ coinId, previewToken, confirm: true })` with the token that preview
 returned.
 
@@ -160,8 +169,8 @@ draft** of the coin or the arena. There is no preview here, and correctly so: th
 to preview once the policy is gone. The evidence is **the deployment's own read**, which supplies the
 `expectedRevision` the delete carries — and for Arena the `expectedPolicyId` beside it.
 
-State what stops, from that read: which agents were on duty or eligible, what the policy was
-firing on, and that the slots are not recoverable. Both tools carry a schema-level `confirm: true`.
+State what stops, from that read: which agents were on duty (every row of `resolvesNow.onDuty`) or
+eligible, what the policy was firing on, and that the slots are not recoverable. Both tools carry a schema-level `confirm: true`.
 
 **If the player wants to stop trading without losing the slots, that is not a delete** — it is
 `pause_radar_deployment` for Radar and `pause_deployment_policy` for Arena. Offer that
@@ -171,14 +180,18 @@ whenever the ask sounds like "pause", "stop for now", or "take it off duty for a
 
 Three reads, cheapest first. Stop as soon as the player's question is answered.
 
-1. **`get_radar_deployment` → `resolvesNow`** for what is true **right now**: the section, the
-   blocked reason and since when, the qualification block, the cooldown, the last fire, and which
-   agent is on duty. Most "is it working?" questions end here.
+1. **`get_radar_deployment` → `resolvesNow`** for what is true **right now**: the coin's section and
+   reason, and one `onDuty` row per agent — its blocked reason and since when, its qualification
+   block, its cooldown, whether its edge is spent, its last fire and its close clock. A row whose last
+   close reads `CLAIMED` qualified but lost the coin's one fire that pass to a higher-priority agent;
+   its edge is preserved and it fires at a later close only if it still qualifies there. Most "is it
+   working?" questions end here.
 2. **`get_radar_activity_summary`** for everything else about "why is it quiet", in ONE call. It
    carries three parts and they answer three different questions, each on its own scope:
    - `groups` — which cause recurs and how often, over the window the response names. Quote the
      counts with that window; never sum them across calls.
-   - `curveDigest` — how FAR the score sits from firing, over the on-duty agent's ring. This is what
+   - `curveDigest` — how FAR the score sits from firing, over the FIRST on-duty agent's ring (the
+     lowest-numbered slot on duty now, named in `curveAgentName`). This is what
      separates "lower the minimum two points and it fires" from "this strategy does not fit this
      coin": `bestUnqualifiedScorePercent` against `latestThresholdPercent`. Its `ringStartAt` /
      `ringEndAt` describe the ring, NOT the cause window above.
@@ -186,9 +199,12 @@ Three reads, cheapest first. Stop as soon as the player's question is answered.
      a pair quiet for longer returns no groups beside populated older rows. That is correct, not a
      contradiction; each row carries its own `occurredAt`.
 
-   For about one sweep after an agent rotation the digest can name the incoming agent while the rows
-   still show the outgoing one — the two halves are read from different stores. Say "just rotated"
-   rather than reporting a contradiction.
+   The groups and rows span every on-duty agent — each row names its own — while the digest describes
+   the first one. For about one sweep after the on-duty set changes the digest can name the new first
+   agent while the rows still show the old one — the two halves are read from different stores. Say
+   "duty just changed" rather than reporting a contradiction. Joins and departures are journaled as
+   `ON_DUTY_JOINED` / `ON_DUTY_LEFT`, one row per agent, and a lost coin as
+   `EDGE_PRESERVED_COIN_CLAIMED`.
 3. **`get_radar_activity`** only for what step 2 cannot do: more rows than its ten, a FIRES-only
    view, paging back through history, or ONE occurrence's full margins. Rows are lean by default —
    pass `detail: 'FULL'` for the margin surface, and `includeCurve: true` only if something will