@50arms/platform-mcp 0.1.443 → 0.1.444

package/README.md

@@ -1,6 +1,6 @@
 # @50arms/platform-mcp
 
-Stdio MCP server fronting the 50 Arms dashboard HTTP API. Since DX-3465 it exposes three generic tools (`50arms_api`, `50arms_api_list`, `50arms_api_spec` — see "Tool surface" below) that reach any route the caller's credential may reach, plus a few dedicated tools for what no route call can do (`plan_connect`, `request_permission`, `attach_file`, `50arms_slack_reply`) — there is no per-operation tool any more, and since DX-4525 no dispatch-callback tool either: `50arms_api` is every agent's primary channel to the dashboard (ending a dispatch, gate sign-off, Slack update, thread link, Slack recovery, evaluator summary and template-app load/save are all `50arms_api` calls to the routes in `src/dispatch/callback-routes.ts`). The server instructions and the `50arms_api_spec` description tell an agent to read the spec before its first call to a route it has not called before.
+Stdio MCP server fronting the 50 Arms dashboard HTTP API. Since DX-3465 it exposes three generic tools (`50arms_api`, `50arms_api_list`, `50arms_api_spec` — see "Tool surface" below) that reach any route the caller's credential may reach, plus a few dedicated tools for what no route call can do (`session_connect`, `request_permission`, `attach_file`, `50arms_slack_reply`) — there is no per-operation tool any more, and since DX-4525 no dispatch-callback tool either: `50arms_api` is every agent's primary channel to the dashboard (ending a dispatch, gate sign-off, Slack update, thread link, Slack recovery, evaluator summary and template-app load/save are all `50arms_api` calls to the routes in `src/dispatch/callback-routes.ts`). The server instructions and the `50arms_api_spec` description tell an agent to read the spec before its first call to a route it has not called before.
 
 `50arms_api` is Zod-validated at the MCP boundary, fetches under the hood, and passes the server response back to the agent verbatim. Refusal envelopes (`{error, ...extra}` with `failed_gate`, `non_terminal_phases`, `offending_keys`, etc.) come through as `{ok: false, status, body}` so the agent can pick the right next action without guessing. 5xx and network failures throw.
 
@@ -9,20 +9,20 @@ Stdio MCP server fronting the 50 Arms dashboard HTTP API. Since DX-3465 it expos
 | Var | Purpose |
 |---|---|
 | `DANXBOT_DASHBOARD_URL` | Dashboard base, e.g. `http://danxbot-dashboard:5555` (inside compose) or `http://localhost:5555` (host). An operator session gets it from the 50arms plugin: its `dashboard_url` option (default the hosted dashboard), chosen per session folder: see the repo's `.claude/rules/dashboard-api-access.md`, the one owner of that rule |
-| `DANX_DASHBOARD_CREDENTIAL` | A DISPATCH's credential: the bearer verbatim, substituted into the materialized `.mcp.json` from its overlay (DX-2862, `src/credential.ts`). Authoritative when set; it never signs out. An operator session sets nothing: with no credential the server boots SIGNED OUT, every tool except `plan_connect` returns one "not signed in" halt, and `plan_connect` requests access (below). `restart_notice` uses the same resolver, so a session's tools and its predecessor lookups can never sign in as two different identities; the relay in this server (`plan_events_wait`) signs in with the server's own credential |
-| `DANXBOT_TEAM` | OPTIONAL, non-secret (DX-4446): the team slug (or id) whose approvers see this session's access request in their danxbot site. Set it in your shell or a repo's committed `.claude/settings.json` `env` block. Unset, the request is answered by link only. A value that is not a team slug fails at boot; a team the dashboard does not know makes `plan_connect` answer `unknown_team` (fix `DANXBOT_TEAM`), never a silent link fallback |
+| `DANX_DASHBOARD_CREDENTIAL` | A DISPATCH's credential: the bearer verbatim, substituted into the materialized `.mcp.json` from its overlay (DX-2862, `src/credential.ts`). Authoritative when set; it never signs out. An operator session sets nothing: with no credential the server boots SIGNED OUT, every tool except `session_connect` returns one "not signed in" halt, and `session_connect` requests access (below). `restart_notice` uses the same resolver, so a session's tools and its predecessor lookups can never sign in as two different identities; the relay in this server (`plan_events_wait`) signs in with the server's own credential |
+| `DANXBOT_TEAM` | OPTIONAL, non-secret (DX-4446): the team slug (or id) whose approvers see this session's access request in their danxbot site. Set it in your shell or a repo's committed `.claude/settings.json` `env` block. Unset, the request is answered by link only. A value that is not a team slug fails at boot; a team the dashboard does not know makes `session_connect` answer `unknown_team` (fix `DANXBOT_TEAM`), never a silent link fallback |
 | `DANXBOT_BOARD_ID` | OPTIONAL (DX-4555, DX-5512): the dispatch's board, the board's ref, the positive integer that numbers it within its team (never its database id; the dispatch injects it). Anything else exits at boot. Unset (the 50arms plugin's own server) the server has no default board: a call that needs a board must carry its `board` argument or the dashboard answers 400 (plan and plan-session routes take their boards from the plan and need none) |
 
 BOARD-ONLY (DX-1171): board is the first-level concept; repo is DERIVED from board server-side, never passed. At boot the package reads the dispatch's board ref from `DANXBOT_BOARD_ID` and appends it as `?board=<ref>` (and `body.board` on create) to every `/api/issues/*` request, except `GET /api/issues` (the list), whose board is OPTIONAL (DX-4542): there it sends a board only when the caller names one, because no board is the team's whole list across every board. Each tool exposes an optional `board` arg - a board ref, the number (or its decimal text) - that overrides it per-call for cross-board reads/writes (unknown board -> 404). The dashboard owns board->repo resolution; this package never sends `repo`.
 
 ## Signing in (DX-4390): request and approve
 
-An operator session has no stored credential. Signed out, `plan_connect` (optionally with `title`, the session's own Claude title) posts `POST /api/access-requests` and answers at once `{state: "approval_required", approvalUrl, confirmCode, expiresAt, instruction}`: show the user the code and open the URL; they approve in the dashboard. The server polls `POST /api/access-requests/claim` in the background, so the key is stored when the approval lands; the next `plan_connect` waits up to about 45 seconds for it, then connects, or answers `approval_pending`. One tool call never blocks for minutes. `denied` is reported once; a request that lapsed (the dashboard deletes it within about a minute of expiry, so a claim answers 404) starts a fresh one on the next call.
-- **A machine secret and an auto-approved request (DX-6764, PLAN-128).** Every `session` access request also sends `machineSecret`: one random secret per machine and per dashboard, made the first time it is needed in `~/.config/danxbot/machine-secrets/<sha12(dashboard url)>.json` (mode 0600, written durably, then hard-linked into place so two sessions starting at once on a fresh machine end up with the same one; an unusable file is a loud error, never replaced). The dashboard keeps only its hash, so a person can let later sessions from this machine sign in by themselves; it is never sent to another dashboard, and the `machine` daemon's request and a dispatched agent's credential are unchanged. When the create answer says `autoApproved: true` no person decides the request: the first claim is not delayed, `plan_connect` waits up to about 45 seconds for the key and answers signed in with no `approvalUrl` or `confirmCode`; a claim slower than that answers `{state: "signing_in"}`, still with no link. `autoApproved` is required in the create answer: a dashboard that does not send it fails the request loudly. A request left pending behaves as above.
-- **A launch token (DX-6801, DEC-522).** `plan_connect` and `card_connect` take an optional `launch_token`: the one-use token the session that started this one passed in its prompt. A signed-out session given one redeems it once per process through the public `POST /api/access-requests/claim` with `{secret: <token>, labelId: <this session's id>}` (`labelId` is sent only on a redeem); `approved` stores the key like an approval and answers signed in, with no access request. Any other answer (`claimed`, `expired`, 404, 409 `launch_grant_refused` with its `reason`, 429) spends the token and falls through to the usual person's request, the answer carrying a `note` that names why the token was not used. A signed-in session ignores the token.
+An operator session has no stored credential. Signed out, `session_connect` (optionally with `title`, the session's own Claude title) posts `POST /api/access-requests` and answers at once `{state: "approval_required", approvalUrl, confirmCode, expiresAt, instruction}`: show the user the code and open the URL; they approve in the dashboard. The server polls `POST /api/access-requests/claim` in the background, so the key is stored when the approval lands; the next `session_connect` waits up to about 45 seconds for it, then connects, or answers `approval_pending`. One tool call never blocks for minutes. `denied` is reported once; a request that lapsed (the dashboard deletes it within about a minute of expiry, so a claim answers 404) starts a fresh one on the next call.
+- **A machine secret and an auto-approved request (DX-6764, PLAN-128).** Every `session` access request also sends `machineSecret`: one random secret per machine and per dashboard, made the first time it is needed in `~/.config/danxbot/machine-secrets/<sha12(dashboard url)>.json` (mode 0600, written durably, then hard-linked into place so two sessions starting at once on a fresh machine end up with the same one; an unusable file is a loud error, never replaced). The dashboard keeps only its hash, so a person can let later sessions from this machine sign in by themselves; it is never sent to another dashboard, and the `machine` daemon's request and a dispatched agent's credential are unchanged. When the create answer says `autoApproved: true` no person decides the request: the first claim is not delayed, `session_connect` waits up to about 45 seconds for the key and answers signed in with no `approvalUrl` or `confirmCode`; a claim slower than that answers `{state: "signing_in"}`, still with no link. `autoApproved` is required in the create answer: a dashboard that does not send it fails the request loudly. A request left pending behaves as above.
+- **A launch token (DX-6801, DEC-522).** `session_connect` takes an optional `launch_token`: the one-use token the session that started this one passed in its prompt. A signed-out session given one redeems it once per process through the public `POST /api/access-requests/claim` with `{secret: <token>, labelId: <this session's id>}` (`labelId` is sent only on a redeem); `approved` stores the key like an approval and answers signed in, with no access request. Any other answer (`claimed`, `expired`, 404, 409 `launch_grant_refused` with its `reason`, 429) spends the token and falls through to the usual person's request, the answer carrying a `note` that names why the token was not used. A signed-in session ignores the token.
 
 - **Storage.** `~/.config/danxbot/session-keys/<sha12(dashboard url)>/<session id>.json`, mode 0600, written write-then-rename, pruned after 7 days. One file per dashboard and per session; this server reads it at boot, and `restart_notice` reads the same file through the `session-key` credential source and proves the fingerprint. The key lapses on the dashboard after 24 hours without use (every authenticated call, the relay's heartbeat included, renews it), and is revocable from the account page.
-- **A 401 on the stored key** deletes the file and returns the sign-in halt (in `plan_connect`: a new request in the same call). That is a key that lapsed. A key a PERSON revoked is answered `401 key_revoked` (DX-4418): the key file is deleted and EVERY dashboard tool, `plan_connect` included, returns one stop halt (who revoked it and when; commit work in progress and end; a dispatched agent makes no further call), for the rest of the process. No access request is made. The worker finds the revocation itself and ends the dispatch as revoked (every dashboard route, the dispatch-complete one included, refuses a revoked key). `plan_events_wait` answers `stopped` with the reason `key_revoked` the same way. **A 404 on create** means the dashboard predates request-and-approve and says so.
+- **A 401 on the stored key** deletes the file and returns the sign-in halt (in `session_connect`: a new request in the same call). That is a key that lapsed. A key a PERSON revoked is answered `401 key_revoked` (DX-4418): the key file is deleted and EVERY dashboard tool, `session_connect` included, returns one stop halt (who revoked it and when; commit work in progress and end; a dispatched agent makes no further call), for the rest of the process. No access request is made. The worker finds the revocation itself and ends the dispatch as revoked (every dashboard route, the dispatch-complete one included, refuses a revoked key). `plan_events_wait` answers `stopped` with the reason `key_revoked` the same way. **A 404 on create** means the dashboard predates request-and-approve and says so.
 - A dispatch's `DANX_DASHBOARD_CREDENTIAL` skips all of this. There is no token-file credential source.
 
 ### Asking for one more permission (DX-4434)
@@ -35,11 +35,11 @@ The hint: every dashboard result that is `403 {error: "forbidden", permission}`
 
 A session is shown only the tools it can call. `src/tool-access.ts` declares, for every tool, what makes it usable, and its one function `toolsFor({permissions, callbacks})` maps what a session holds to the tool names it advertises. `src/tool-surface.ts` applies it with the SDK's `tool.enable()` / `disable()`, so `notifications/tools/list_changed` is sent and Claude Code refetches; nothing else decides visibility, and the danxbot service's budgets (`src/tokens/mcp-surface.ts`) read the same function.
 
-- **Bootstrap set**, for every session and the whole of a signed-out one: `plan_connect`, `request_permission` and the `50arms_api` trio.
+- **Bootstrap set**, for every session and the whole of a signed-out one: `session_connect`, `request_permission` and the `50arms_api` trio.
 - **Permission tools** (`attach_file` needs `cards.edit` for both targets): shown once the key holds the permission the tool's dashboard route needs.
 - **Callback tool** (`50arms_slack_reply`, the only one, DX-4525): shown when the worker injected its URL (`DANXBOT_SLACK_REPLY_URL`, `<dashboard>/api/slack/reply`, no dispatch id) AND the key holds `slack.threads.post`, so a non-Slack dispatch never sees it. It posts with the dispatch's own credential (`DANX_DASHBOARD_CREDENTIAL`), the same one `50arms_api` uses.
-- **When it is applied.** At boot, as a session with no key; then, if the session holds a key (a dispatch's env credential, or a stored session key), right away from `GET /api/auth/permissions`; a dispatch retries that read three times and fails the boot rather than start without its tools. After `plan_connect` signs a session in. And again when a person approves a `request_permission` grant: the dashboard ends the key's open `/api/stream` with `event: end {reason: "permissions_changed"}`, this process holds one stream open on the key-self topic `key:self` (`src/permission-watch.ts`; any key may subscribe with no permission, because a dispatch's agent role holds no read-floor key), and after EVERY (re)connect re-reads the key's permissions (a failed read is retried with bounded backoff) and enables what is newly allowed in ONE `list_changed`. It reconnects with backoff after a drop, and stops when stdin closes. A grant that adds no tool, and a repeated read, switch nothing and send no notification, because a changed tool list costs the session its prompt cache.
-- A stream the dashboard refuses (any 4xx) is logged and ends the watch; that session's grants then show their tools at its next `plan_connect`. A permission read the dashboard refuses (401/403, other than the Terms halt) fails a dispatch's boot rather than quietly narrowing its tools.
+- **When it is applied.** At boot, as a session with no key; then, if the session holds a key (a dispatch's env credential, or a stored session key), right away from `GET /api/auth/permissions`; a dispatch retries that read three times and fails the boot rather than start without its tools. After `session_connect` signs a session in. And again when a person approves a `request_permission` grant: the dashboard ends the key's open `/api/stream` with `event: end {reason: "permissions_changed"}`, this process holds one stream open on the key-self topic `key:self` (`src/permission-watch.ts`; any key may subscribe with no permission, because a dispatch's agent role holds no read-floor key), and after EVERY (re)connect re-reads the key's permissions (a failed read is retried with bounded backoff) and enables what is newly allowed in ONE `list_changed`. It reconnects with backoff after a drop, and stops when stdin closes. A grant that adds no tool, and a repeated read, switch nothing and send no notification, because a changed tool list costs the session its prompt cache.
+- A stream the dashboard refuses (any 4xx) is logged and ends the watch; that session's grants then show their tools at its next `session_connect`. A permission read the dashboard refuses (401/403, other than the Terms halt) fails a dispatch's boot rather than quietly narrowing its tools.
 
 ## Tool surface (DX-3465 — one generic tool, not one per operation)
 
@@ -59,7 +59,7 @@ All exposed as `mcp__platform__<name>` once wired through the workspace `mcp.tem
 
 There is no dedicated `resource_fields` tool (removed DX-3465 — it was a thin wrapper `50arms_api` already reaches with no agent-specific behavior earning it its own tool). What an opt-in field TREE may name for one resource (`{resource, description, always, hashes, fields, relations}`) is `50arms_api({method:"GET", path:"/api/resources/<resource>/fields"})` — install-global, no `board`; `resource: "issue"` is the root, and a relation's own `resource` in the response is what to call this again with, one level deeper.
 
-A dedicated tool survives only for something no `50arms_api` call can do, never a card/plan/dispatch-callback operation: `request_permission` (asks for a permission its key lacks), `plan_connect` (binds the session to a plan; the plugin's relay loop starts on it), `card_connect` (DX-5553: holds ONE card that is on no plan instead, or lets it go; `POST|DELETE /api/plan-sessions/me/card`; the same relay then carries that card's and its descendants' events), and the two that read LOCAL files, `attach_file` and `50arms_slack_reply` (`files[]`, see `src/lifecycle.ts`). The live list is always `tool-defs.json` in this package, regenerated by `npm run gen-tool-defs` — read it rather than trusting a list copied into prose.
+A dedicated tool survives only for something no `50arms_api` call can do, never a card/plan/dispatch-callback operation: `request_permission` (asks for a permission its key lacks), `session_connect` (DX-6917: binds the session to ONE plan (`target: "PLAN-n"`) or ONE card on no plan (`target: "<card id>"`, DX-5553), or lets it go with `disconnect: true`; `POST|DELETE /api/plan-sessions/me/connect`, which resolves the target; the plugin's relay loop starts on it and carries the plan's, or the card's and its descendants', events), and the two that read LOCAL files, `attach_file` and `50arms_slack_reply` (`files[]`, see `src/lifecycle.ts`). The live list is always `tool-defs.json` in this package, regenerated by `npm run gen-tool-defs` — read it rather than trusting a list copied into prose.
 
 Card and plan reads/writes go through `50arms_api` against the issue/plan route families documented in `GET /api/openapi` (via `50arms_api_spec`) — `POST /api/issues`, `GET /api/issues/:id` (or `/batch` for many at once, DX-2727), `PATCH /api/issues/:id/edit`, `POST /api/issues/:id/transition`, the problems/solutions/dependencies/comments/quality-gates/retro sub-resource routes, and the equivalent `/api/plans/*` family (`GET /api/plans/:planId` — cheap scalars by default, `fields` opts into `cards`/`records`/`architecture`/`session_history`/`worker_dispatches`; `GET /api/plans` for the list, with an optional `status` filter over the same computed `complete`/`awaiting-session`/`building`/`planning` value `GET /api/plans/:planId` returns when asked: `status` is opt-in, so request it with `fields={status:true}`).
 
@@ -85,7 +85,7 @@ The contract the plugin builds against:
 
 ## `restart_notice` — what a restarted session was working on (DX-3928, DX-4632)
 
-A tool for the 50arms plugin's session-start hook, not for a model, advertised only on a person's session (never a dispatch) and **usable before sign-in**: a restarted Claude Code session gets a new session id, no plan binding and, until a person approves its first call, no dashboard key of its own, so nothing else could tell it that the plan it had been working was unattended. `plan_connect` writes the session's working directory into its connection record (`projectKey`, record schema v2); `restart_notice` finds the newest OTHER sessions' records for the same project (at most ten, each within `STALE_RECORD_MS`), resolves each record's own credential, and asks `GET /api/plan-sessions/<predecessor>/restart-notice` which plan it was on and how many operator events wait there (the connect digest's own query, read-only). No arguments. Answers one of:
+A tool for the 50arms plugin's session-start hook, not for a model, advertised only on a person's session (never a dispatch) and **usable before sign-in**: a restarted Claude Code session gets a new session id, no plan binding and, until a person approves its first call, no dashboard key of its own, so nothing else could tell it that the plan it had been working was unattended. `session_connect` writes the session's working directory into its connection record (`projectKey`, record schema v2); `restart_notice` finds the newest OTHER sessions' records for the same project (at most ten, each within `STALE_RECORD_MS`), resolves each record's own credential, and asks `GET /api/plan-sessions/<predecessor>/restart-notice` which plan it was on and how many operator events wait there (the connect digest's own query, read-only). No arguments. Answers one of:
 
 - `{notice: "<text>"}`: say it (the registry's `plan_restart.waiting_events` text; this package carries no wording).
 - `{notice: null}`: nothing to say (no earlier session of this project connected a plan, the plan is archived or deleted, the record is stale, or every predecessor is still live).

package/dist/credential.js

@@ -14,8 +14,8 @@
  *     substitutes it into the materialized `.mcp.json` from the dispatch overlay. Authoritative
  *     when set, and it never signs out.
  *   - a SESSION KEY (`session-key.ts`) - the key a user approved for this one session through
- *     `plan_connect`. An operator session has no other credential: with neither of these it boots
- *     signed out, and `plan_connect` asks for access.
+ *     `session_connect`. An operator session has no other credential: with neither of these it boots
+ *     signed out, and `session_connect` asks for access.
  *
  * There is no token-file source (DX-4390): a long-lived bearer placed on disk by hand is exactly
  * what request-and-approve replaces.
@@ -60,7 +60,7 @@ export function readCredential(source, env) {
         return readSessionKeyFile(source.path);
     }
     catch (err) {
-        throw new CredentialError(`cannot read ${describeCredentialSource(source)}: ${err.message}`, "call plan_connect to request access again; the key file is written when the request is approved");
+        throw new CredentialError(`cannot read ${describeCredentialSource(source)}: ${err.message}`, "call session_connect to request access again; the key file is written when the request is approved");
     }
 }
 /**

package/dist/handlers.js

@@ -23,25 +23,24 @@
  */
 import { posix, win32 } from "node:path";
 import { readFile, stat } from "node:fs/promises";
-// ---------------- plan_connect (DX-2683) ----------------
+// ---------------- session_connect (DX-2683, DX-5553, DX-6917) ----------------
 // DX-3465 (PLN-11 R-25) — every other per-operation handler that used to
-// live in this file (issue_*, plan_* except plan_connect, brief_*,
+// live in this file (issue_*, plan_*, brief_*,
 // repo_knowledge_*, failure_category_*, dispatch_transcript_search,
 // quality_gate_instruction) is deleted: `danxbotApi`/`danxbotApiSpec` below
-// are the generic replacement. `plan_connect` stays a dedicated tool because
+// are the generic replacement. `session_connect` stays a dedicated tool because
 // it is session-bound (see `index.ts`'s own comment on this).
 const PLAN_SESSIONS_BASE_PATH = "/api/plan-sessions";
 /**
- * Connect THIS session to a plan — the same write the operator's Connect
- * action performs, reaching the same server-side code path. `me` in the URL
- * is resolved from the forwarded session id, so this can only ever bind the
- * caller's own session.
+ * Connect THIS session to a plan or to ONE stand-alone card (a card on no plan, DX-5553), or let it go: `POST|DELETE /api/plan-sessions/me/connect`. `me` in the URL
+ * is resolved from the forwarded session id, so this can only ever bind the caller's own session. The same writes the operator's Connect action performs
+ * for a plan, reaching the same server-side code path.
  *
- * A session already on another plan is MOVED, and the response says which
- * plan it left (`movedFrom`).
+ * A session already on another plan or card is MOVED, and the response says which
+ * it left (`movedFrom` / `leftPlan` / `leftCard`). The answer carries what the session missed (`missedEvents`) and the exact thread title to take (`naming`).
  *
- * IT DOES NOTHING ABOUT HEARING THE PLAN'S EVENTS, deliberately. Delivery belongs
- * to the plan event relay inside this MCP server (`plan_events_wait`, `plan-events-relay.ts`),
+ * IT DOES NOTHING ABOUT HEARING THE EVENTS, deliberately. Delivery belongs
+ * to the event relay inside this MCP server (`plan_events_wait`, `plan-events-relay.ts`),
  * which holds the session's ONE listener ticket and is started by the 50arms plugin's loop once this tool
  * succeeds. The dashboard keeps one ticket per session, so a ticket minted here
  * would end the relay's stream.
@@ -53,25 +52,20 @@ const PLAN_SESSIONS_BASE_PATH = "/api/plan-sessions";
  * The event relay keeps it current afterwards, from the transcript (DX-4461,
  * `session-title.ts`).
  */
-export async function planConnect(client, args) {
+export async function sessionConnect(client, args) {
     if (args.disconnect === true) {
         if (args.title !== undefined) {
-            return { ok: false, status: 400, body: { error: "plan_connect: `disconnect: true` takes no `title` — a leave changes no title" } };
+            return { ok: false, status: 400, body: { error: "session_connect: `disconnect: true` takes no `title` — a leave changes no title" } };
         }
-        // DX-2985 — `DELETE /api/plan-sessions/me/plan?plan_id=`: `me` is the forwarded session id, so only the caller's own session leaves.
-        return client.request({
-            method: "DELETE",
-            path: "/me/plan",
-            basePath: PLAN_SESSIONS_BASE_PATH,
-            query: { plan_id: args.plan_id },
-        });
+        // DX-2985 — `DELETE /api/plan-sessions/me/connect?target=`: `me` is the forwarded session id, so only the caller's own session leaves.
+        return client.request({ method: "DELETE", path: "/me/connect", basePath: PLAN_SESSIONS_BASE_PATH, query: { target: args.target } });
     }
     return client.request({
         method: "POST",
-        path: "/me/plan",
+        path: "/me/connect",
         basePath: PLAN_SESSIONS_BASE_PATH,
         body: {
-            plan_id: args.plan_id,
+            target: args.target,
             ...(args.title === undefined ? {} : { title: args.title }),
             ...(args.assignment_id === undefined ? {} : { assignment_id: args.assignment_id }),
         },
@@ -85,25 +79,6 @@ export async function planConnect(client, args) {
 export async function claimSessionAgent(client) {
     return client.request({ method: "POST", path: "/me/agent", basePath: PLAN_SESSIONS_BASE_PATH });
 }
-/**
- * DX-5553 - hold ONE stand-alone card (a card on no plan) instead of a plan, or let it go: `POST|DELETE /api/plan-sessions/me/card`. `me` is the forwarded session id, so only
- * the caller's own session is ever bound. Like `plan_connect`, the answer carries what the session missed (`missedEvents`) and the exact thread title to take (`naming`); the
- * session then hears that card's and its descendants' events through the same relay as a plan's.
- */
-export async function cardConnect(client, args) {
-    if (args.disconnect === true) {
-        if (args.title !== undefined) {
-            return { ok: false, status: 400, body: { error: "card_connect: `disconnect: true` takes no `title` — a leave changes no title" } };
-        }
-        return client.request({ method: "DELETE", path: "/me/card", basePath: PLAN_SESSIONS_BASE_PATH, query: { card_id: args.card_id } });
-    }
-    return client.request({
-        method: "POST",
-        path: "/me/card",
-        basePath: PLAN_SESSIONS_BASE_PATH,
-        body: { card_id: args.card_id, ...(args.title === undefined ? {} : { title: args.title }), ...(args.assignment_id === undefined ? {} : { assignment_id: args.assignment_id }) },
-    });
-}
 // DX-3465 (code-architecture gate finding, at 275f82c0d) — the dedicated
 // `resource_fields` handler (DX-3426) was deleted from here: it was a thin
 // wrapper around `GET /api/resources/:resource/fields`, which `50arms_api`

package/dist/http-client.js

@@ -60,7 +60,7 @@ export class DashboardHttpClient {
         //
         // NO TITLE HEADER (DX-2816, revised). This server has no way to read
         // Claude's own session title — see `readSessionConfig` in `index.ts`.
-        // The title travels instead as `plan_connect`'s own `title` argument,
+        // The title travels instead as `session_connect`'s own `title` argument,
         // straight in that call's body, because the AGENT (not this process) is
         // the one thing able to read it.
         if (this.config.session) {
@@ -158,7 +158,7 @@ export class DashboardHttpClient {
             // DX-4592: a board-less server (the 50arms plugin's, no DANXBOT_BOARD_ID) stamps nothing when the call names no
             // board. Whether the route NEEDS one is the dashboard's to say: a route that does (quality-gate and settings routes, the dispatch
             // verbs) answers 400 naming `board`, while a card-id, plan or plan-session route takes its board from the card
-            // or the plan. Refusing here (DX-4555) wrongly stopped every plan route, `plan_connect` first.
+            // or the plan. Refusing here (DX-4555) wrongly stopped every plan route, `session_connect` first.
             if (board !== undefined)
                 params.set("board", String(board));
         }

package/dist/index.js

@@ -14,7 +14,7 @@
  *   - 50arms_api            the generic surface for every non-agent-specific dashboard
  *                            operation (DX-3465 / PLN-11 R-25) — list/get/create/update/delete
  *                            against the uniform resource routes that used to each have their
- *                            own per-operation tool (issue_*, plan_* (except plan_connect),
+ *                            own per-operation tool (issue_*, plan_*,
  *                            brief_*, repo_knowledge_*, failure_category_*,
  *                            dispatch_transcript_search, quality_gate_instruction — all deleted
  *                            here). See `SERVER_INSTRUCTIONS` below for the calling convention.
@@ -28,9 +28,10 @@
  *                            with the approval URL and confirm code, and the grant is picked up in
  *                            the background (`permission-request.ts`). A dashboard call refused
  *                            `403 forbidden` carries a hint to call it (`forbidden-hint.ts`).
- *   - plan_connect           POST   /api/plan-sessions/me/plan — SESSION-BOUND (kept as a
- *                            dedicated tool; every plan READ or WRITE operation goes
- *                            through 50arms_api now, e.g. GET /api/plans/mine or
+ *   - session_connect        POST|DELETE /api/plan-sessions/me/connect — SESSION-BOUND (a
+ *                            dedicated tool; one tool for a plan and a card, named by its
+ *                            `target`; every plan READ or WRITE operation goes
+ *                            through 50arms_api, e.g. GET /api/plans/mine or
  *                            POST /api/plans/mine/records)
  *
  * DX-2683, updated DX-3465 — PLAN WRITES ARE SESSION-BOUND, and
@@ -40,7 +41,7 @@
  * a plan write is an ordinary `50arms_api` call to a `/api/plans/mine/...`
  * route. Reads may name any plan by id (`/api/plans/:id/...`); a WRITE
  * route instead takes NO plan id at all and acts on the plan this session
- * is connected to (`plan_connect`), resolved server-side from the session
+ * is connected to (`session_connect`), resolved server-side from the session
  * id this package forwards on every request. A session therefore cannot
  * modify a plan it is not connected to, whatever id it believes. A write
  * from an unconnected session is refused loudly (`session_not_connected`),
@@ -58,8 +59,8 @@
  *     DANX_DASHBOARD_CREDENTIAL  the bearer verbatim (a dispatch, substituted into
  *                           the materialized `.mcp.json` from its overlay)
  *     otherwise this session's approved key (`session-key.ts`), else none: the
- *                           server boots SIGNED OUT, every tool but `plan_connect`
- *                           halts, and `plan_connect` requests access (`session-access.ts`)
+ *                           server boots SIGNED OUT, every tool but `session_connect`
+ *                           halts, and `session_connect` requests access (`session-access.ts`)
  *   DANXBOT_TEAM            OPTIONAL (DX-4446), non-secret: the team slug (or id) whose
  *                           approvers see this session's access request in their danxbot
  *                           site. Set it in your shell or a repo's committed `.claude/settings.json` `env` block.
@@ -103,7 +104,7 @@ import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"
 import { z } from "zod";
 import { boardRefArgSchema, parseBoardRefText, repoNameArgSchema } from "./board-id.js";
 import { DashboardHttpClient } from "./http-client.js";
-import { cardConnect, claimSessionAgent, planConnect, danxbotApi, danxbotApiList, danxbotApiSpec, attachFile, DANXBOT_API_METHODS, } from "./handlers.js";
+import { claimSessionAgent, sessionConnect, danxbotApi, danxbotApiList, danxbotApiSpec, attachFile, DANXBOT_API_METHODS, } from "./handlers.js";
 import { miniAppPublish } from "./mini-app-publish.js";
 import { miniAppRestore } from "./mini-app-restore.js";
 import { pluginPublish } from "./plugin-publish.js";
@@ -180,7 +181,7 @@ let listenerReminder;
  * DX-4390 — this server's credential: a dispatch's env bearer, this session's approved key, or
  * none (signed out). The plan event relay in this server signs in with it directly (`access.currentToken()`).
  * `restart_notice` runs against other sessions' credentials and cannot see it, so `access.connection()` (the URL, where the credential is, its
- * fingerprint; never the credential itself) is written to the session's connection record on a successful `plan_connect`
+ * fingerprint; never the credential itself) is written to the session's connection record on a successful `session_connect`
  * for it.
  */
 let access;
@@ -308,7 +309,7 @@ async function readHeldPermissions() {
 /**
  * How hard a failed permission read is for this session. A dispatch cannot work without its tools, so it retries a few times (a
  * dashboard blip at spawn must not cost it its MCP server) and then fails the boot; an operator session logs it and keeps the
- * bootstrap set until its next `plan_connect` or the permission stream's next connect.
+ * bootstrap set until its next `session_connect` or the permission stream's next connect.
  */
 function syncPolicy() {
     const isDispatch = access.connection()?.source.kind === "env";
@@ -327,7 +328,7 @@ async function syncToolsWithPolicy() {
 }
 /**
  * DX-4523 - show the tools the key's permissions allow, and watch for a grant. Called at boot and again whenever a
- * `plan_connect` finds the session signed in, which is the moment a first approval or a re-approved key takes effect.
+ * `session_connect` finds the session signed in, which is the moment a first approval or a re-approved key takes effect.
  */
 async function syncToolsAfterSignIn() {
     if (!access.isSignedIn())
@@ -336,7 +337,7 @@ async function syncToolsAfterSignIn() {
     permissionWatch.start();
 }
 /**
- * DX-6157 - a person created the agent this session proposed, and the dashboard signed the session in as it (and connected it to its plan or card) without a `plan_connect` from the session. The
+ * DX-6157 - a person created the agent this session proposed, and the dashboard signed the session in as it (and connected it to its plan or card) without a `session_connect` from the session. The
  * session therefore never saw a connect answer, so this does here what one that binds does: it opens the agent gate (`50arms_api` stops answering `agent_needed`), shows the tools the key's
  * permissions allow, restarts the listener reminder's health read and, for a session now on a plan or card, writes the local connection record `restart_notice` and the listener reminder read.
  * Called by the relay's listener as it writes the notice; a failure is a stderr line, never silence (the notice itself still reaches the session).
@@ -346,7 +347,7 @@ function adoptCreatedAgent(created) {
     listenerReminder.invalidate();
     const connection = access.connection();
     if (created.plan !== null || created.card !== null) {
-        // DX-6157: the frame arrived over this key's own stream, so no credential here is a broken invariant: said loudly, as plan_connect throws on it.
+        // DX-6157: the frame arrived over this key's own stream, so no credential here is a broken invariant: said loudly, as session_connect throws on it.
         if (connection === null) {
             console.error("agent created: no credential after the dashboard signed this session in; the local connection record was not written");
         }
@@ -405,8 +406,8 @@ function resolveInitialCredential(dashboardUrl, sessionId) {
  * MCP-server-reachable signal carries Claude's own session title — this
  * SERVER genuinely cannot read it. The AGENT can, though (a Desktop-side
  * `get_session` tool this server has no access to), and the agent is what
- * calls `plan_connect` — so the title travels as that tool's own `title`
- * argument (see `handlers.ts#planConnect`) at connect time, not as a header
+ * calls `session_connect` — so the title travels as that tool's own `title`
+ * argument (see `handlers.ts#sessionConnect`) at connect time, not as a header
  * stamped here. DX-4461: the session's TRANSCRIPT carries every rename as a
  * `custom-title` record, so the event relay in this server reads it from
  * there and reports it on its heartbeat (`session-title.ts`) and a later rename needs no
@@ -420,7 +421,7 @@ function readSessionConfig() {
         return undefined;
     return { id };
 }
-// DX-5549: whether this session holds a team agent; closed by a plan_connect answer of `agent_needed` / `agent_limit_reached`, opened only by one carrying an agent.
+// DX-5549: whether this session holds a team agent; closed by a session_connect answer of `agent_needed` / `agent_limit_reached`, opened only by one carrying an agent.
 const agentGate = new AgentGate();
 /**
  * DX-3465 (PLN-11 R-25) — the conventions shared by every `50arms_api` call,
@@ -473,7 +474,7 @@ function connectedDashboard() {
     return dashboardIdentity(config.baseUrl);
 }
 /**
- * DX-4390 — `plan_connect`'s answer while access is not in place: the request (or why there is none),
+ * DX-4390 — `session_connect`'s answer while access is not in place: the request (or why there is none),
  * an error when it names a failure. `note` says why a new request was needed.
  */
 function accessReply(ready, note) {
@@ -862,52 +863,50 @@ strictTool("request_permission", "Ask a person to grant this key ONE MORE permis
     }
     return jsonResult(asked.answer);
 });
-// ---------------- plans (DX-2683) ----------------
+// ---------------- session connect (DX-2683, DX-5553, DX-6917) ----------------
 // THE BINDING ASYMMETRY IS IN THE SCHEMAS, NOT IN PROSE. `GET /api/plans/:planId`
 // takes a plan id in its path; the plan records, plan cards and
 // architecture-section routes under `/api/plans/mine/...` take NO plan id in
 // any form, so a connected session cannot even express "write to that other
-// plan". `plan_connect` takes a plan id because binding a session to a plan
-// is the one operation that is ABOUT a plan id — and it can only ever bind
+// plan". `session_connect` takes a target (`PLAN-n`, or a card's id) because binding a session
+// is the one operation that is ABOUT a plan or card id, and it can only ever bind
 // the caller's own session. `POST /api/plans` also takes no plan id, but for
 // a different reason: it MAKES a plan rather than acting on one, so there is
 // no existing plan for an id to name yet.
-strictTool("plan_connect", 
+strictTool("session_connect", 
+// DX-6917 - the one connect tool: what used to be `plan_connect` (a plan) and `card_connect` (DX-5553, a card on no plan). The dashboard resolves `target`; this package never parses it.
 // DX-4493 — the `naming` block carries the thread title the session must take before it connects.
 // DX-4318 — states only what to do with the reply. What it used to add arrives where it is used: a rejected
 // action's rule in the event line itself (`listen.ts`), the mantra in the reply's own `reminders[]` text.
 // DX-4390 — signed out, this is also how the session asks for access.
-"Connect THIS session to a plan; one call is enough to start. Signed out, it requests access instead: " +
+// DX-4608 / DX-5549: a title in the format naming another agent than the held one is refused.
+"Connect THIS session to ONE plan or card, named by `target`: `PLAN-n`, or a card's id for a card on no plan. One call is enough to start; omit `target` only to sign in (it still takes your team agent). Signed out, it requests access: " +
     "the reply is `state: approval_required` or `approval_pending` with an `approvalUrl` and `confirmCode` " +
-    "(show the code, open the URL, then call again; it waits until this session ends; a call re-asks an expired one). " +
-    "Signed in, the reply carries `owedComments` (person comments no agent has answered yet: read first, answer each, ack then reply) and `missedEvents` (operator " +
-    "events no session had been told about: read next), " +
-    "`browserInstruction` (do it now), `briefing` (goals, rules, caveats, architecture " +
-    "titles and a first page of open cards) and `listenerHealth` (when its `state` is not `healthy`, do its " +
-    "`nextStep`), and `docsLandJob` (on a docs land assignment: the conflict job's text, or `unavailable` with why). A session is on at most one plan: connecting elsewhere moves it (`movedFrom` names the " +
-    "plan it left). A plan holds one live session: another on it refuses the connect (`plan_has_live_session`, " +
-    "naming that session); do not retry: tell the person and connect elsewhere. A session whose plan another took while it was quiet is refused its next `/api/plans/mine/...` call: connect elsewhere or ask the person. Afterwards `50arms_api` calls to `/api/plans/mine/...` act on this plan, no plan id. " +
-    "Connecting signs you in as a team agent (`agent`, `agentInstruction`). " +
-    "No agent to sign in as: `agent_needed` (none exists for you; propose one) or `agent_limit_reached` (the cap on agent sessions is full; the person ends another or raises it), nothing connects: follow its `instruction`, " +
-    "no other dashboard work until `plan_connect` holds an agent. A `naming` block (status `needed`) gives the exact " +
-    "`title`, `{Name}: PLAN-NNN {short title}`; rename this thread to it (`set_session_title`, or ask for `/rename`), then connect again with that `title`. " +
-    // DX-4608 / DX-5549: a title in the format naming another agent than the held one is refused.
+    "(show the code, open the URL, then call again; a call re-asks an expired one). " +
+    "Signed in, the reply carries `owedComments` (person comments no agent has answered yet: read first, answer each, ack then reply), `missedEvents` (operator " +
+    "events no session had been told about: read next), `naming` and `listenerHealth` (when its `state` is not `healthy`, do its `nextStep`); " +
+    "for a plan also `browserInstruction` (do it now), `briefing` (goals, rules, caveats, architecture, open cards) and `docsLandJob` (a docs land assignment's job). " +
+    "A session holds a plan or a card, never both: connecting elsewhere moves it (`movedFrom` names the plan it left). " +
+    "A plan holds one live session: another on it refuses the connect (`plan_has_live_session`); do not retry. " +
+    "A card is refused `card_on_plan` when it or a card above it is on a plan (connect to that plan) and `card_held` when another live session holds it; holding one assigns it to you, like a manual pickup. " +
+    "Afterwards `50arms_api` calls to `/api/plans/mine/...` act on your plan, no plan id. Connecting signs you in as a team agent; with none to sign in as: `agent_needed` or `agent_limit_reached` (the cap is full: ask the person), nothing connects: follow its `instruction`, " +
+    "no other dashboard work until `session_connect` holds an agent. A `naming` block (status `needed`) gives the exact " +
+    "`title`, `{Name}: PLAN-NNN {short title}` or `{Name}: {CARD-ID} {card title}`; rename this thread to it (`set_session_title`, or ask for `/rename`), then connect again with that `title`. " +
     "A `title` in that format naming another agent than yours is refused `session_title_not_agent_name` with the title to use.", {
-    plan_id: z
-        .number()
-        .int()
-        .positive()
+    target: z
+        .string()
+        .min(1)
         .optional()
-        .describe("The plan's number within your team (the `n` of `PLAN-n`; a plan's `ref` in `50arms_api` `GET /api/plans`). Omit only to sign in (it still takes your team agent)."),
+        .describe("What to hold: `PLAN-n` (a plan's `ref` in `50arms_api` `GET /api/plans`) or a card's id as the board shows it, for a card on no plan. Omit only to sign in (it still takes your team agent)."),
     title: z
         .string()
         .min(1)
         .optional()
         .describe(
     // DX-4608: stored as sent; a wrong one does not refuse the connect, the reply's `naming` says what to rename it to.
-    'The `naming` block\'s exact `{Name}: PLAN-NNN {short title}`, after renaming this thread. Omit on the first connect.'),
+    'The `naming` block\'s exact `{Name}: PLAN-NNN {short title}` or `{Name}: {CARD-ID} {card title}`, after renaming this thread. Omit on the first connect.'),
     assignment_id: z.number().int().positive().optional().describe("The assignment this connect answers, when a person's assignment message names one. Refused `assignment_ended` once it is over: then do nothing more about it."),
-    disconnect: z.boolean().optional().describe("true = leave `plan_id` (your current plan); no `title`."),
+    disconnect: z.boolean().optional().describe("true = leave `target` (the plan or card you hold); no `title`."),
     launch_token: z
         .string()
         .min(1)
@@ -921,21 +920,21 @@ strictTool("plan_connect",
     "Set only by the plugin's Sign in button when a person presses it; an agent never sets it. On a session whose key a person revoked it lifts the stop and starts a new access request a person must approve; any call without it still answers the stop."),
 }, 
 // DX-2862 — the connect is also the moment the session's connection record is written for `restart_notice` and the listener reminder: of the
-// dashboard MCP servers a session may have configured, the one that connected the plan is the one whose credential they
+// dashboard MCP servers a session may have configured, the one that connected the plan or card is the one whose credential they
 // must resolve (the relay needs none of this: it lives in each server, with that server's own credential).
 async (args) => {
     // DX-6894 — a person's Sign in press leaves the revoked stop; every call without it still answers that stop.
     if (args.person_sign_in === true)
         access.personSignIn();
-    // DX-4390 — a leave names the plan it leaves, and needs a key like any other call.
-    if (args.disconnect === true && args.plan_id === undefined) {
-        return haltResult("plan_connect: `disconnect: true` needs `plan_id`, the plan this session is currently on");
+    // DX-4390 — a leave names what it leaves, and needs a key like any other call.
+    if (args.disconnect === true && args.target === undefined) {
+        return haltResult("session_connect: `disconnect: true` needs `target`, the plan or card this session currently holds");
     }
     // DX-4390 — no key yet: ask for one (or wait for the approval already asked for).
     const ready = await access.ensureAccess(args.title, args.launch_token);
     if (!ready.signedIn)
         return accessReply(ready);
-    if (args.plan_id === undefined) {
+    if (args.target === undefined) {
         // DX-4523 - signed in (possibly just now): show the tools this key's permissions allow.
         await syncToolsAfterSignIn();
         // DX-5549: signing in takes a team agent. The dashboard's answer (the agent and the instruction to use its name, or why there is none) is the reply.
@@ -950,11 +949,11 @@ async (args) => {
             void reportCheckoutDocsRoot();
         return jsonResult({
             ...claimed.body,
-            ...(agentGate.current() === null ? { instruction: "This session is signed in. Call `plan_connect` with `plan_id` to connect it to a plan." } : {}),
+            ...(agentGate.current() === null ? { instruction: "This session is signed in. Call `session_connect` with `target` to connect it to a plan or a card." } : {}),
         });
     }
     // DX-6089: the role text lands in a local file; the reply names it (`role-instruction-file.ts`).
-    const result = spillRoleInstruction(await planConnect(client, { ...args, plan_id: args.plan_id }));
+    const result = spillRoleInstruction(await sessionConnect(client, { ...args, target: args.target }));
     // DX-4418 — a person revoked this key: the stop halt, and nothing asks again.
     const revokedHalt = access.refusalHalt(result);
     if (revokedHalt !== null)
@@ -963,12 +962,12 @@ async (args) => {
     if (result.status === 401 && access.dropKey(result)) {
         return accessReply(await access.ensureAccess(args.title), "the dashboard no longer accepted this session's key");
     }
-    return finishConnect("plan_connect", result, args.disconnect === true);
+    return finishConnect("session_connect", result, args.disconnect === true);
 });
 // DX-6735: started by each connect that holds an agent, and never awaited by it.
 const reportCheckoutDocsRoot = createCheckoutDocsRootReporter(() => client, process.cwd());
 /**
- * What `plan_connect` and `card_connect` do with a connect answer once the key is known good (DX-6157 - one path, so a wiring test through either tool covers it), and `50arms_api` with a manual pickup that connected (DX-6556).
+ * What `session_connect` does with a connect answer once the key is known good (DX-6157 - one path for a plan and a card), and `50arms_api` with a manual pickup that connected (DX-6556).
  * DX-5549: the dashboard connects only a session that holds a team agent. With none it answers why (`agent_needed` / `agent_limit_reached`) and binds nothing: that answer is handed to the agent
  * unchanged and every other dashboard tool stays closed until a later connect finds an agent. The tools are shown and the listener reminder reset BEFORE that block is handed back (DX-4523, DX-3997),
  * so a session whose key was just approved can run `plan_events_wait` and hear the person's Create. A leave (DX-2985) drops the local connection record; a connect writes it.
@@ -1001,43 +1000,6 @@ async function finishConnect(tool, result, disconnect) {
         }),
     });
 }
-// ---------------- card_connect (DX-5553) ----------------
-strictTool("card_connect", 
-// DX-5553 - the stand-alone counterpart of `plan_connect`: one card on no plan instead of a plan.
-"Hold ONE card that is on no plan instead of a plan: for a one-off, a quick fix or an epic that is not a plan. You then hear that card's and its descendants' events, " +
-    "and no other card's. The reply carries `owedComments` (every person comment on it no agent has answered yet, oldest first: read them first and answer each, ack then reply), `missedEvents` (operator events no session had been told about on it: read them next), `naming` and `agent`/`agentInstruction`. " +
-    "Refused `card_on_plan` when the card or any card above it is on a plan (connect to that plan with `plan_connect`), `card_held` when another live session holds it. " +
-    "A session holding no team agent is first signed in as one, as `plan_connect` does: with none free the answer is `agent_needed` (propose one) or `agent_limit_reached`, and nothing is held. " +
-    "Holding it assigns the card to you, like a manual pickup; a card " +
-    "with children is held as a whole and its children are picked up normally. A session holds a plan or a card, never both: connecting to either lets go of the other. " +
-    "A `naming` block (status `needed`) gives the exact `title`, `{Name}: {CARD-ID} {card title}`; rename this thread to it (`set_session_title`, or ask for `/rename`), then connect " +
-    "again with that `title`. A card later added to a plan moves you off it: you are told on your next plan call.", {
-    card_id: z.string().min(1).describe("The id of the card to hold, as the board shows it."),
-    title: z
-        .string()
-        .min(1)
-        .optional()
-        .describe("The `naming` block's exact `{Name}: {CARD-ID} {card title}`, after renaming this thread. Omit on the first connect."),
-    assignment_id: z.number().int().positive().optional().describe("The assignment this connect answers, when a person's assignment message names one. Refused `assignment_ended` once it is over: then do nothing more about it."),
-    disconnect: z.boolean().optional().describe("true = let go of `card_id` (the card you hold); no `title`."),
-    launch_token: z
-        .string()
-        .min(1)
-        .optional()
-        .describe("The one-use token the session that started this one passed in its prompt. With it a signed-out session signs in with no person approving it; a token that cannot be used says why and the session asks a person as usual. Omit it otherwise."),
-}, async (args) => {
-    const ready = await access.ensureAccess(args.title, args.launch_token);
-    if (!ready.signedIn)
-        return accessReply(ready);
-    const result = spillRoleInstruction(await cardConnect(client, args));
-    const revokedHalt = access.refusalHalt(result);
-    if (revokedHalt !== null)
-        return haltResult(revokedHalt);
-    if (result.status === 401 && access.dropKey(result)) {
-        return accessReply(await access.ensureAccess(args.title), "the dashboard no longer accepted this session's key");
-    }
-    return finishConnect("card_connect", result, args.disconnect === true);
-});
 // ---------------- plan_events_wait (DX-4233) ----------------
 strictTool("plan_events_wait", 
 // DX-4882 - `plan_id` is null for a signed-in session on no plan: its stream still carries its account's pacing and resume messages.

package/dist/key-revoked-halt.js

@@ -26,5 +26,5 @@ export function keyRevokedHalt(revocation, dispatched) {
     return (`STOP ALL WORK NOW. ${revocation.revokedBy} revoked your access to the 50 Arms dashboard at ${revocation.revokedAt}.\n\n` +
         "Commit your work in progress now (commit what you have; do not run agent-finalize.sh and do not merge). " +
         `${ending}\n\n` +
-        "Do not call plan_connect or any other 50 Arms dashboard tool again, do not request access again and do not look for another route.");
+        "Do not call session_connect or any other 50 Arms dashboard tool again, do not request access again and do not look for another route.");
 }

package/dist/listen.js

@@ -613,7 +613,7 @@ export function formatAgentCreatedLine(event) {
     const held = event.plan !== null ? "this agent and plan" : event.card !== null ? "this agent and card" : "this agent";
     const ownCalls = thread !== "" || event.rolePointer !== null ? "; the steps below keep their own calls" : "";
     const parts = [
-        `${LINE_PREFIX} The person created your team agent ${oneLine(event.agent.name, 60)}: this session is now signed in as it${where}. Taking ${held} needs no \`plan_connect\`${ownCalls}.`,
+        `${LINE_PREFIX} The person created your team agent ${oneLine(event.agent.name, 60)}: this session is now signed in as it${where}. Taking ${held} needs no \`session_connect\`${ownCalls}.`,
         oneLine(event.agentInstruction, 800),
         thread === "" ? "" : oneLine(thread, 800),
         event.owedComments === null ? "" : oneLine(event.owedComments),

package/dist/machine-secret.js

@@ -27,7 +27,7 @@ export function machineSecretPath(dashboardUrl, home = homedir()) {
     return join(home, ".config", "danxbot", "machine-secrets", `${dashboardHash(dashboardUrl)}.json`);
 }
 function unusable(path, why) {
-    return new Error(`[platform-mcp] the machine secret file ${path} is unusable: ${why}; fix or delete it, then call plan_connect again`);
+    return new Error(`[platform-mcp] the machine secret file ${path} is unusable: ${why}; fix or delete it, then call session_connect again`);
 }
 /** The secret in `path`, or null when the file is absent. A file that is there but of another shape throws. */
 function readSecret(path, dashboardUrl) {

package/dist/machine-toolkit.js

@@ -250,7 +250,7 @@ function resolveToolkitVersion(stamped, readManifest) {
   return stamped ?? readManifest();
 }
 var readOwnManifest = () => JSON.parse(readFileSync2(new URL("../../package.json", import.meta.url), "utf8")).version;
-var TOOLKIT_VERSION = resolveToolkitVersion(false ? void 0 : "0.1.443", readOwnManifest);
+var TOOLKIT_VERSION = resolveToolkitVersion(false ? void 0 : "0.1.444", readOwnManifest);
 function envelope(now) {
   return { contract_version: CONTRACT_VERSION, toolkit_version: TOOLKIT_VERSION, profile: PROFILE, measured_at: now.toISOString() };
 }

package/dist/permission-watch.js

@@ -90,7 +90,7 @@ export class PermissionWatch {
             });
             if (response.status >= 400 && response.status < 500 && !RETRYABLE_REFUSALS.has(response.status)) {
                 this.deps.log?.(`[platform-mcp] the dashboard refused the permission stream (HTTP ${response.status}): a permission granted ` +
-                    `mid-session shows its tools at the next plan_connect instead`);
+                    `mid-session shows its tools at the next session_connect instead`);
                 await response.body?.cancel();
                 return { kind: "refused" };
             }

package/dist/restart-notice.js

@@ -5,10 +5,10 @@
  * WHY IT EXISTS. A restarted session gets a NEW session id, no plan binding and, until a person approves its first call, no
  * dashboard key of its own: its MCP server boots signed out. Nothing told it (or the operator) that the plan it had been
  * working was unattended: six operator answers sat unread for an hour on 2026-10-01. The session's own connection record cannot
- * help (it does not exist yet); the PREVIOUS session's record can, found by the project key `plan_connect` wrote into it
+ * help (it does not exist yet); the PREVIOUS session's record can, found by the project key `session_connect` wrote into it
  * (`findPredecessorCandidates`). So this asks the dashboard about each predecessor as the predecessor, with the credential
  * that predecessor's record names (`resolveDashboardAuth`, the resolver `session-options.ts` holds), which a signed-out
- * session needs no key of its own to do. The tool is therefore usable signed out: it is declared like `plan_connect` (no
+ * session needs no key of its own to do. The tool is therefore usable signed out: it is declared like `session_connect` (no
  * permission) and only on a person's session (`tool-access.ts`).
  *
  * THE ANSWER (the plugin's hooks module reads it through `$.mcp.call`):

package/dist/result-limit.js

@@ -6,7 +6,7 @@ import { writeFileDurable } from "./durable-write.js";
  * DX-4400 — the most characters one `50arms_api`, `50arms_api_spec` or `50arms_api_list` result may carry
  * back to the agent. Every character is context the agent pays for on every later call, and Claude Code itself
  * saves a larger result to a file with only a short preview, after the cost is paid. A deliberate, narrow
- * exception to PLAN-11 rule R-25 (verbatim forwarding): `plan_connect` and the lifecycle tools never pass here.
+ * exception to PLAN-11 rule R-25 (verbatim forwarding): `session_connect` and the lifecycle tools never pass here.
  */
 export const MCP_MAX_RESULT_CHARS = 100_000;
 const FILE_INSTRUCTION = "The reply was over the inline limit, so its body is this file, whole: read it with Read (in parts with offset and limit when it is long), or grep it.";

package/dist/role-instruction-file.js

@@ -1,6 +1,6 @@
 /**
  * DX-6089 - a session's role text reaches it as a local file, never inline. The dashboard answers `roleInstruction: {profile, text}` on
- * `plan_connect`, `card_connect` and `GET /api/plan-sessions/me/role`; the text runs to tens of KB, and a tool reply that large is
+ * `session_connect` and `GET /api/plan-sessions/me/role`; the text runs to tens of KB, and a tool reply that large is
  * saved to a file by the client with only a short preview, which also hides every field after it (the briefing, the agent instruction, the
  * reminders). So this server writes the text to `<tmp>/danx-role/<profile>-<content hash>.md` and answers `{profile, path, bytes, instruction}`
  * in its place, leaving every other field inline, as `docs_read` does for a docs page (`docs-tools.ts`). The name carries the content hash, so a

package/dist/session-access.js

@@ -6,17 +6,17 @@
  *   - `env`         a dispatch declared `DANX_DASHBOARD_CREDENTIAL`; this never signs out.
  *   - `session-key` a user approved this session's access request; the key is stored per session
  *                   (`session-key.ts`) and a 401 on it deletes the file (`dropKey`).
- *   - signed out    no credential. Every tool but `plan_connect` halts; `plan_connect` asks.
+ *   - signed out    no credential. Every tool but `session_connect` halts; `session_connect` asks.
  *
  * DX-4418: a fourth state, REVOKED, ends all three. The dashboard answers `401 key_revoked` to a key a person revoked
- * (as opposed to one that lapsed); this object then remembers it, every dashboard tool (and `plan_connect`) returns the one stop
+ * (as opposed to one that lapsed); this object then remembers it, every dashboard tool (and `session_connect`) returns the one stop
  * halt (`key-revoked-halt.ts`), and no new access request is made. A session's key file is deleted; a dispatch's credential is
  * left to its dispatch, but the halt is the same. DX-6894: the one way out is `personSignIn`, the call a PERSON's Sign in press
- * makes (`plan_connect` with `person_sign_in: true`); nothing an agent calls lifts the stop.
+ * makes (`session_connect` with `person_sign_in: true`); nothing an agent calls lifts the stop.
  *
- * ASKING NEVER BLOCKS FOR MINUTES. The first signed-out `plan_connect` posts the request and
+ * ASKING NEVER BLOCKS FOR MINUTES. The first signed-out `session_connect` posts the request and
  * answers at once with the approval URL and confirm code. From then on THIS object polls claim in
- * the background, so the key is stored the moment the user approves, and the next `plan_connect`
+ * the background, so the key is stored the moment the user approves, and the next `session_connect`
  * waits at most `awaitMs` (about 45s) for it before answering `approval_pending`. The secret the
  * poll needs lives only in this process's memory; a restarted session asks again.
  *
@@ -32,7 +32,7 @@ import { keyRevocationOf, keyRevokedHalt } from "./key-revoked-halt.js";
 import { machineSecretFor } from "./machine-secret.js";
 import { deleteSessionKey, writeSessionKey } from "./session-key.js";
 import { McpOutdatedError } from "./version-floor.js";
-/** Longest a `plan_connect` call waits for an approval already asked for. */
+/** Longest a `session_connect` call waits for an approval already asked for. */
 export const AWAIT_APPROVAL_MS = 45_000;
 /** A live server rewrites its key file this often, so an in-use key never ages out of the 7-day prune. */
 const KEEP_KEY_FILE_EVERY_MS = 60 * 60 * 1000;
@@ -40,22 +40,22 @@ const KEEP_KEY_FILE_EVERY_MS = 60 * 60 * 1000;
 const REFUSAL_LOG_LIMIT = 300;
 /** The request's title when the agent gave none: the session id's first characters. */
 const TITLE_FALLBACK_LENGTH = 8;
-export const SIGN_IN_HALT = "Not signed in to the 50 Arms dashboard. Call `plan_connect` (with `plan_id`) to request access; the user approves it in their browser, then this tool works.";
+export const SIGN_IN_HALT = "Not signed in to the 50 Arms dashboard. Call `session_connect` (with `target`) to request access; the user approves it in their browser, then this tool works.";
 /** DX-4418: the session's key lapsed (a day unused) or the dashboard does not know it; a PERSON's revoke is `keyRevokedHalt` instead. */
 export const KEY_LAPSED_HALT = "The dashboard no longer accepts this session's key (it lapsed after a day unused), so this session is signed out. " +
     SIGN_IN_HALT;
 const APPROVAL_REQUIRED_INSTRUCTION = "Show the user the confirm code and open the approval URL in their browser; they check the code " +
-    "matches and approve. Then call `plan_connect` again: it waits up to about 45 seconds for the approval. " +
+    "matches and approve. Then call `session_connect` again: it waits up to about 45 seconds for the approval. " +
     "The request stays open until this session ends, however long the user takes.";
 const APPROVAL_PENDING_INSTRUCTION = "Still waiting for the user to approve; the request stays open until this session ends. Remind them of the " +
-    "confirm code and the URL, then call `plan_connect` again.";
+    "confirm code and the URL, then call `session_connect` again.";
 /** DX-6764: a machine grant approved the request; nothing for the user to open or confirm, the next call picks the sign-in up. */
-const SIGNING_IN_INSTRUCTION = "This machine's auto-approval signs the session in; no approval link is involved. Call `plan_connect` again in a moment.";
-const AUTO_APPROVED_EXPIRED_ERROR = "the dashboard approved this request by itself, but it expired before this process claimed the key; call plan_connect again";
-const DENIED_INSTRUCTION = "The user denied the request. Do not retry unless they ask; a new `plan_connect` makes a new request.";
+const SIGNING_IN_INSTRUCTION = "This machine's auto-approval signs the session in; no approval link is involved. Call `session_connect` again in a moment.";
+const AUTO_APPROVED_EXPIRED_ERROR = "the dashboard approved this request by itself, but it expired before this process claimed the key; call session_connect again";
+const DENIED_INSTRUCTION = "The user denied the request. Do not retry unless they ask; a new `session_connect` makes a new request.";
 const DASHBOARD_OUTDATED_ERROR = "this dashboard does not support request-and-approve yet (POST /api/access-requests answered 404): " +
     "it must be updated before this session can sign in";
-const RATE_LIMITED_ERROR = "too many access requests from this address; wait, then call plan_connect again";
+const RATE_LIMITED_ERROR = "too many access requests from this address; wait, then call session_connect again";
 const unknownTeamError = (team) => `the dashboard has no team "${team}" (DANXBOT_TEAM); fix DANXBOT_TEAM in this server's env (your shell, or a repo's committed .claude/settings.json env block) and restart the session`;
 const NO_SESSION_ID_ERROR = "this server has no CLAUDE_CODE_SESSION_ID, so it cannot request a session key";
 const CLAIMED_LOST_ERROR = "the dashboard says this request was already claimed, but this process never received the key; " +
@@ -105,7 +105,7 @@ export class SessionAccess {
     // DX-4418: set once the dashboard says a person revoked the key. Only `personSignIn` clears it (DX-6894); a restarted server is a new process.
     revoked = null;
     pending = null;
-    // DX-4390: two concurrent signed-out plan_connect calls must not each post a request.
+    // DX-4390: two concurrent signed-out session_connect calls must not each post a request.
     ensureQueue = Promise.resolve();
     lastKeyFileWrite = 0;
     // DX-6801: a launch token is redeemed at most once per process, whatever the answer.
@@ -235,7 +235,7 @@ export class SessionAccess {
     }
     /**
      * Make sure this session holds a key. Signed in: `{signedIn: true}`. Otherwise the answer
-     * `plan_connect` returns: the request just made, the one still pending (after waiting up to
+     * `session_connect` returns: the request just made, the one still pending (after waiting up to
      * `awaitMs` for it), or why there is none. Calls run one at a time.
      *
      * DX-6801 / DEC-522: a signed-out session given the `launchToken` the session that started it passed in its prompt redeems it

package/dist/session-connection.js

@@ -8,7 +8,7 @@
  * dropped silently (the card's incident). The plan event relay (`plan_events_wait`) needs none of this: it runs inside the
  * server, with the server's own credential. The listener reminder reads this record too.
  *
- * WHAT IS WRITTEN, AND WHAT IS NOT. On a successful `plan_connect` the server
+ * WHAT IS WRITTEN, AND WHAT IS NOT. On a successful `session_connect` the server
  * writes the dashboard URL, the credential SOURCE (a session key file path, or the name of
  * an env var — never a credential) and the credential's FINGERPRINT. A reader
  * (`restart_notice`) reads that record, resolves the SAME source through the same resolver
@@ -16,7 +16,7 @@
  * identically. A rotated file or a session environment that disagrees with the
  * server's therefore fails loud instead of reporting as somebody else.
  *
- * WHY `plan_connect` AND NOTHING ELSE WRITES IT. A session can have several
+ * WHY `session_connect` AND NOTHING ELSE WRITES IT. A session can have several
  * dashboard MCP servers configured (gpt-manager has a deployed one and a local
  * one). The server that CONNECTED the session to a plan is, by construction,
  * the one whose credential owns that session's stream — so the connect is the
@@ -143,7 +143,7 @@ export function readSessionConnection(sessionId, options = {}) {
     return parsed;
 }
 /**
- * Record the connection a successful `plan_connect` just made, and say so in
+ * Record the connection a successful `session_connect` just made, and say so in
  * that tool's own answer when it could not be recorded.
  *
  * FAIL LOUD, IN THE ONE PLACE THE AGENT IS LOOKING. A connect whose record is
@@ -179,14 +179,14 @@ export function recordSessionConnectionAfterConnect(result, inputs, write = writ
     }
 }
 /**
- * DX-6556 — a manual pickup, which goes through the generic `50arms_api`, can connect the session as `card_connect` does; the dashboard marks that answer, and it is then
+ * DX-6556 — a manual pickup, which goes through the generic `50arms_api`, can connect the session as a card connect does; the dashboard marks that answer, and it is then
  * handled as a connect, so no record or tool sync is missed.
  */
 export function isPickupConnect(result) {
     return result.ok && typeof result.body === "object" && result.body !== null && result.body.connectedByPickup === true;
 }
 /**
- * DX-2985 — drop this session's local connection record after a successful leave (`plan_connect {disconnect: true}`), so
+ * DX-2985 — drop this session's local connection record after a successful leave (`session_connect {disconnect: true}`), so
  * nothing on this machine still treats the session as plan-connected (the listener-reminder reads this record). A refused
  * leave keeps it: the session is still on its plan. Never throws for an absent record.
  */
@@ -202,7 +202,7 @@ export function invalidRecordReason(value) {
     const r = value;
     if (r.schemaVersion !== SESSION_CONNECTION_SCHEMA_VERSION) {
         return (`schemaVersion is ${JSON.stringify(r.schemaVersion)}, not ${SESSION_CONNECTION_SCHEMA_VERSION} — ` +
-            "a session connected by an older MCP server wrote it; call plan_connect again to rewrite it");
+            "a session connected by an older MCP server wrote it; call session_connect again to rewrite it");
     }
     for (const field of ["sessionId", "projectKey", "dashboardUrl", "fingerprint", "connectedAt"]) {
         if (typeof r[field] !== "string" || r[field] === "")

package/dist/session-title.js

@@ -2,7 +2,7 @@
  * DX-4461 - a session's live Claude title, read from its own transcript with no help from the agent.
  *
  * WHY THE TRANSCRIPT. The dashboard stores a plan session's title, and until now it arrived only as the `title`
- * argument of `plan_connect`, so a session renamed afterwards showed a stale name until the agent happened to connect
+ * argument of `session_connect`, so a session renamed afterwards showed a stale name until the agent happened to connect
  * again. DX-2816 found no env var, hook input or MCP-reachable signal carrying the title, but Claude Code writes every
  * title change into the session's transcript as a `{"type":"custom-title","customTitle":"..."}` line the moment the
  * rename happens, even while the session is idle (observed on session 952f0739: 76 records of the old title, then the

package/dist/stop-fixes.js

@@ -13,26 +13,26 @@
  * is no separate process to restart.
  */
 const RESTART_NOTICE_STOP_LEAD = "continue without it";
-const RESTART_NOTICE_STOP_TAIL = "call plan_connect to connect this session to a plan";
+const RESTART_NOTICE_STOP_TAIL = "call session_connect to connect this session to a plan or a card";
 export const STOP_FIXES = {
-    no_connection_record: "call plan_connect again in this session — its platform MCP server records the connection that restart_notice and the listener reminder read " +
+    no_connection_record: "call session_connect again in this session — its platform MCP server records the connection that restart_notice and the listener reminder read " +
         "(a server older than the one that introduced the record writes none)",
-    credential_unavailable: "call plan_connect again to request access: this session's key file is missing or unreadable",
-    credential_mismatch: "restart this Claude Code session so its MCP server resolves its credential afresh, then call plan_connect again",
-    not_connected: "call plan_connect to connect this session to a plan",
-    plan_archived: "the plan was archived or deleted, so this session was disconnected; ask the operator to restore it, then call plan_connect again",
-    unauthorized: "the dashboard no longer accepts this session's key (it lapsed after a day unused): call plan_connect again to request access",
+    credential_unavailable: "call session_connect again to request access: this session's key file is missing or unreadable",
+    credential_mismatch: "restart this Claude Code session so its MCP server resolves its credential afresh, then call session_connect again",
+    not_connected: "call session_connect to connect this session to a plan or a card",
+    plan_archived: "the plan was archived or deleted, so this session was disconnected; ask the operator to restore it, then call session_connect again",
+    unauthorized: "the dashboard no longer accepts this session's key (it lapsed after a day unused): call session_connect again to request access",
     key_revoked: "stop all work now, commit your work in progress and end this session: the person who owns this session's access revoked it; " +
-        "do not call plan_connect or request access again",
-    mint_refused: "check that this session is signed in to the dashboard its MCP server points at, then call plan_connect again",
+        "do not call session_connect or request access again",
+    mint_refused: "check that this session is signed in to the dashboard its MCP server points at, then call session_connect again",
     mint_bad_response: "check that DANXBOT_DASHBOARD_URL for this session's MCP server points at a 50 Arms dashboard",
     // A newer ticket exists (superseded) or another connection is already using this one (replaced): THIS listener is ending
     // because the session is already served elsewhere, not because anything is broken.
     superseded: "no action needed — a newer ticket was minted for this session, and a fresh listener is already using it",
-    replaced: "no action needed — another connection is already using this session's ticket; call plan_connect again only if that was unexpected",
-    revoked: "call plan_connect again to mint a new listener ticket for this session",
-    refused: "call plan_connect again to mint a new listener ticket for this session",
-    // DX-6272: calling plan_connect again would reconnect with the same old relay and be refused again.
+    replaced: "no action needed — another connection is already using this session's ticket; call session_connect again only if that was unexpected",
+    revoked: "call session_connect again to mint a new listener ticket for this session",
+    refused: "call session_connect again to mint a new listener ticket for this session",
+    // DX-6272: calling session_connect again would reconnect with the same old relay and be refused again.
     mcp_outdated: "restart this Claude Code session, or reconnect its platform server in /mcp, to install the current version of the MCP server; the dashboard's event stream needs a newer one than this session runs",
     // DX-3028 - this session id belongs to a worker dispatch; there is no listener ticket a worker session can ever use.
     session_is_worker: "this session id belongs to a worker dispatch; start a new session",
@@ -44,7 +44,7 @@ export const STOP_FIXES = {
     lookup_failed: `${RESTART_NOTICE_STOP_LEAD}: no earlier session's record could be checked (the detail says why); ${RESTART_NOTICE_STOP_TAIL}`,
     relay_failed: "the event relay inside this session's platform MCP server failed (the detail says why); the next call tries again, and if it keeps failing restart this Claude Code session",
 };
-export const DEFAULT_STOP_FIX = "call plan_connect again in this session to restart the listener";
+export const DEFAULT_STOP_FIX = "call session_connect again in this session to restart the listener";
 export function fixForStop(reason) {
     return STOP_FIXES[reason] ?? DEFAULT_STOP_FIX;
 }

package/dist/tool-access.js

@@ -9,7 +9,7 @@
  * Three kinds of tool, by what makes them usable:
  *
  *   - bootstrap   `{permission: null, callback: null}` - what a session needs BEFORE it holds a key, or to ask for more:
- *                 `plan_connect` (sign in, bind to a plan), `request_permission`, and the `50arms_api` trio.
+ *                 `session_connect` (sign in, bind to a plan or a card), `request_permission`, and the `50arms_api` trio.
  *   - permission  `{permission}` - the dashboard route the tool calls needs this permission, so a key without it can
  *                 never succeed. Shown once the key holds it, which includes a grant a person approves mid-session.
  *   - callback    `{callback}` - the tool posts to a per-dispatch URL the worker injected (`lifecycle.ts`), so it is usable
@@ -35,9 +35,7 @@ const needsAndPostsTo = (permission, callback) => ({ permission, callback });
  * here, and `tool-access.test.ts` fails when an entry names no registered tool.
  */
 export const TOOL_ACCESS = {
-    plan_connect: BOOTSTRAP,
-    // DX-5553 - `POST|DELETE /api/plan-sessions/me/card` (`cards.edit`: it assigns the card to the session's agent): the session holds a card on no plan.
-    card_connect: needs("cards.edit"),
+    session_connect: BOOTSTRAP,
     request_permission: BOOTSTRAP,
     "50arms_api": BOOTSTRAP,
     "50arms_api_list": BOOTSTRAP,
@@ -70,7 +68,7 @@ export const TOOL_ACCESS = {
     // `src/tokens/tool-defs.ts`) granted to the `orchestrator` profile alone, not this table.
     plan_events_wait: needs("plans.view"),
     // DX-4632 - the plugin's session-start hook asks which plan the session this one replaced was working. A restarted session boots
-    // signed out, so it holds no permission: like `plan_connect` it is a bootstrap tool, and a person's session's only (a dispatch
+    // signed out, so it holds no permission: like `session_connect` it is a bootstrap tool, and a person's session's only (a dispatch
     // never loads the plugin that calls it). The lookup asks the dashboard as the predecessor, with the credential the predecessor's
     // record names.
     restart_notice: OPERATOR_SESSION_BOOTSTRAP,

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@50arms/platform-mcp",
-  "version": "0.1.443",
-  "description": "Stdio MCP server fronting the 50 Arms dashboard API for agents (operator sessions and dispatched workers alike): the generic 50arms_api/50arms_api_list/50arms_api_spec tools reach any route the caller's credential may call, plus dedicated agent-specific tools (plan_connect, request_permission, attach_file, and 50arms_slack_reply) (DX-3465, PLN-11 R-25).",
+  "version": "0.1.444",
+  "description": "Stdio MCP server fronting the 50 Arms dashboard API for agents (operator sessions and dispatched workers alike): the generic 50arms_api/50arms_api_list/50arms_api_spec tools reach any route the caller's credential may call, plus dedicated agent-specific tools (session_connect, request_permission, attach_file, and 50arms_slack_reply) (DX-3465, PLN-11 R-25).",
   "license": "MIT",
   "type": "module",
   "main": "dist/index.js",