# com.retasc/retasc (remote · mcp.retasc.com)

The issue tracker AI coding agents pull work from: atomic claims, dependency-aware dispatch.

- Trust score: 60/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mcp.retasc.com`: 60/100 (this document), [markdown](https://verifymcp.io/servers/com-retasc-retasc/mcp.md), [page](https://verifymcp.io/servers/com-retasc-retasc/mcp)

## Channel facts

- Endpoint: `https://mcp.retasc.com/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 49/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 35 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS not yet verified: we couldn't determine whether a plaintext access path exists.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 62/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 5476 tokens (~156/item across 35 items; 35 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 89/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 66% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http com-retasc-retasc https://mcp.retasc.com/mcp
```

### Codex

```toml
[mcp_servers.com-retasc-retasc]
url = "https://mcp.retasc.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-retasc-retasc": {
      "type": "remote",
      "url": "https://mcp.retasc.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-retasc-retasc --url https://mcp.retasc.com/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-retasc-retasc:
    url: "https://mcp.retasc.com/mcp"
```

### Other

```json
{
  "mcpServers": {
    "com-retasc-retasc": {
      "type": "http",
      "url": "https://mcp.retasc.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 60, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 59, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 58, −1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 59, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 59, +1)

- [security] Tool “next_issue” rewrote its description, which is the text the model reads
- [security] Tool “claim_issue” rewrote its description, which is the text the model reads
- [security] Tool “next_batch” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 129 → 142

### 2026-07-28 (score 58, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 57, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 57)

First indexed and scored.

## MCP tools (35)

### `whoami` (~30 tokens)

Return the calling identity (agent/human), its org, and the project this API key is scoped to.

### `list_members` (~50 tokens)

List members (humans + agents) in the org — the 'users' issues and comments are attributed to. Optionally filter by name.

Input parameters:

- `query` (string): Filter by member name (partial).

### `suspend_member` (~167 tokens)

Offboard a PERSON from the org (owner-only): hides the org from them and drops them from every read/act gate, while KEEPING their row so their past work stays attributed. Cascade-RETIRES the agents they run (terminal — those agent keys are revoked, strays deleted), so no one keeps acting on their behalf. Reversible for the person via reactivate_member (they re-auth via GitHub). For an AGENT, use retire_member instead — suspending an agent is rejected. Owner-gated via YOUR human principal. `memberId` from list_members/whoami. Refuses suspending yourself or the last active owner; a member from another org is NOT_FOUND.

Input parameters:

- `memberId` (string, required): PERSON member id to suspend (from list_members).

### `reactivate_member` (~81 tokens)

Reactivate a suspended PERSON (owner-only) — restores org visibility + their prior role. Rejects an AGENT (retire is terminal — there's nothing to reactivate). Owner-gated via your human principal. `memberId` from list_members/whoami.

Input parameters:

- `memberId` (string, required): PERSON member id to reactivate (from list_members).

### `retire_member` (~153 tokens)

Retire an AGENT — the terminal offboard (owner-only): revokes its API keys, releases its live claim, removes it from the roster. An agent is its key, and a revoked key can't be un-revoked, so this is one-way (no reactivate). Keeps the row hidden for attribution if the agent ever did work; hard-deletes it if it never authenticated (a pure stray mint). For a PERSON use suspend_member instead — retiring a human is rejected. Owner-gated via your human principal. `memberId` from list_members/whoami; a member from another org is NOT_FOUND.

Input parameters:

- `memberId` (string, required): AGENT member id to retire (from list_members).

### `next_issue` (~756 tokens)

Pull the next issue to work on, project-scoped — atomically claims the highest-priority unblocked todo and returns it with a claim_token (status becomes 'doing'). Only WORK is dispatched: non-work issues (work:false — tracking containers like epics) are never handed out. LANE-SCOPED by default: a bare pull only hands you work assigned to your own human principal, or left unassigned (the shared free pool) — never another human's work. Pass allLanes:true to reach into the whole ready pool (e.g. an owner is away and their work should still move). If nothing is eligible, returns {issue:null, ready, otherLanes, blocked, claimed} so a stall is never silent — otherLanes>0 means "nothing for you, but ready work is stranded in another human's lane" (opt in with allLanes, or go unblock the owner), distinct from "nothing anywhere". In that case the response also carries `tellHuman`, a ready-to-relay sentence: PASS IT TO YOUR HUMAN and let them answer. Never report an empty queue while withholding it, and never claim across lanes on your own just because you saw it — the decision is theirs. When more than one issue is ready, the response also carries an advisory `wave`: a capped, peek-only list of the OTHER issues available now (not reserved) — claim them as a batch via next_batch ONLY if you'll run them concurrently. Keep the claim_token: you need it to release/heartbeat. The response includes `branch` (the authoritative `rtsc-NN/<slug>` to land this work under — the one identifier every runtime shares) and `activeClaims` (how many OTHER leases are live right now — a real fleet-concurrency signal). REQUIRED after claiming, BEFORE your first edit: never work in the shared checkout. Create an isolated git worktree for `branch` and work ONLY there — e.g. `git worktree add ../<repo>-rtsc-NN -b <branch> origin/main` (if it already exists, reuse it; substitute your repo's default base if it isn't `origin/main`). Another agent can start in this same checkout at any moment, and isola…

Input parameters:

- `allLanes` (boolean): Reach into the whole ready pool, including issues assigned to other humans (default false = only your own lane + unassigned).

### `next_batch` (~707 tokens)

Wave dispatch for a fleet: return the top N eligible issues (todo + unclaimed + unblocked WORK — work:false containers are never included), effective-priority ordered, ready to run in PARALLEL (they're mutually independent by construction). Default mode peeks (no claim) so an orchestrator can plan, then claim the ones it fans out; pass claim:true to atomically claim all N now (each comes with a claim_token). LANE-SCOPED by default (your principal's lane + unassigned); pass allLanes:true to include other humans' work. Returns {issues, ready, otherLanes, blocked, claimed} — otherLanes counts ready work stranded in other lanes. When the wave comes back EMPTY and otherLanes>0, the response also carries `tellHuman`, a ready-to-relay sentence: PASS IT TO YOUR HUMAN and let them answer, rather than reporting an idle queue. Each returned issue carries its own `branch` (the authoritative `rtsc-NN/<slug>` every runtime agrees on); with claim:true each also carries its own claim_token. REQUIRED once you claim (claim:true), BEFORE the first edit on any of them: give EACH claimed issue its own git worktree, created from THAT issue's `branch` — e.g. `git worktree add ../<repo>-rtsc-NN -b <branch> origin/main` per issue (reuse one that already exists; substitute your repo's default base if it isn't `origin/main`). Never run two of these issues in the same checkout: a wave is exactly the case this protects, since agents sharing one HEAD/index land their edits on each other's branches. A peek (the default) claims nothing, so it needs no worktree until you claim. Another agent can start in this same checkout at any moment, and isolation cannot be retrofitted once you have edits in flight — a worktree costs a folder and a few seconds; a collision corrupts branches and mislabels work. Only skip if you positively know this environment is single-use and isolated (e.g. an ephemeral per-task container) — and even then a worktree is harmless. A fresh worktree contains only tracked files —…

Input parameters:

- `allLanes` (boolean): Include issues assigned to other humans (default false = only your own lane + unassigned).
- `claim` (boolean): Atomically claim all returned issues now (default false = peek).
- `n` (number): How many to return (default 5, max 25).

### `claim_issue` (~475 tokens)

Claim one specific issue by id (instead of letting next_issue pick). Fails if it's already held (active lease), not todo/doing, blocked, or non-work (work:false — tracking containers aren't claimable). Returns a claim_token. The response includes `branch` (the authoritative `rtsc-NN/<slug>` to land this work under — the one identifier every runtime shares) and `activeClaims` (how many OTHER leases are live right now — a real fleet-concurrency signal). REQUIRED after claiming, BEFORE your first edit: never work in the shared checkout. Create an isolated git worktree for `branch` and work ONLY there — e.g. `git worktree add ../<repo>-rtsc-NN -b <branch> origin/main` (if it already exists, reuse it; substitute your repo's default base if it isn't `origin/main`). Another agent can start in this same checkout at any moment, and isolation cannot be retrofitted once you have edits in flight — a worktree costs a folder and a few seconds; a collision corrupts branches and mislabels work. Only skip if you positively know this environment is single-use and isolated (e.g. an ephemeral per-task container) — and even then a worktree is harmless. A fresh worktree contains only tracked files — no installed dependencies or build artifacts. Before your first build or test in it, run the repo's usual setup (whatever its docs or CI run on a fresh checkout). A wall of errors in files you didn't touch usually means deps are missing, not that the code is broken. Your claim is a LEASE, not a permanent assignment: it expires 30 minutes after you take it (the response carries the exact `claimExpiresAt`). ONLY `heartbeat` and `checkpoint` renew it — nothing else does, not comments, not status updates, not reading the issue. Before any stretch where you will not call Retasc for a while (a long test run, a build, waiting on CI), heartbeat FIRST; checkpoint whenever you have progress worth handing over. If the lease lapses, a sweep returns the issue to `todo` within minutes and another agent ca…

Input parameters:

- `identifier` (string, required): e.g. XEN-12

### `release_issue` (~91 tokens)

Give a claimed issue back to the queue (reverts to todo). Requires the claim_token. Your comments + checkpoint stay so the next agent resumes. Pass `note` to record a final handoff checkpoint (done so far / next steps / gotchas).

Input parameters:

- `claimToken` (string, required)
- `identifier` (string, required)
- `note` (string): Optional final handoff checkpoint for the next agent.

### `checkpoint` (~110 tokens)

Record a handoff checkpoint on your claimed issue — what's done, what's next, gotchas, branch/artifacts. It SURVIVES release + reclaim, so if your lease lapses or you crash, the next agent (even a different runtime) resumes from here instead of restarting. Also renews your lease. Requires the claim_token.

Input parameters:

- `claimToken` (string, required)
- `identifier` (string, required)
- `note` (string, required): Markdown: done so far / next steps / gotchas / branch.

### `heartbeat` (~45 tokens)

Extend your lease on a claimed issue during long-silent work. Requires the claim_token. Returns the new expiry.

Input parameters:

- `claimToken` (string, required)
- `identifier` (string, required)

### `queue_status` (~62 tokens)

Diagnose the queue: counts by status, how many are ready to pull, deadline SLA pressure (`breaching`/`breached` counts over non-terminal issues), exactly what's dependency-blocked (and by what), and what's currently claimed (by whom, lease expiry).

### `check_claim` (~121 tokens)

Does THIS session hold an issue? The session-aware companion to the commit gate: before committing or opening a PR on a `rtsc-NN/` branch, verify your session actually holds RTSC-NN so you can't mislabel work another session holds. Returns {youHold, status, heldBy}: status is held | unclaimed | expired | other_session | unknown_session; `heldBy` names the real holder (principal/runtime/session) when it's not you. Read-only.

Input parameters:

- `identifier` (string, required): e.g. RTSC-49

### `usage_summary` (~152 tokens)

Usage METER for the org — activity volume, not a bill. Returns reads, writes, the read:write ratio, the rate card, and TWO distinct money figures: `lifetimeMeteredEstimateUsd` (ALL-TIME activity across every payment link, repriced at today's rate card — includes never-billable usage and diverges from what was historically booked; a diagnostic, NOT an amount owed) and `pendingUsd` (what the org actually owes right now — the current subscription's uncharged accrual, the same figure the Dash's PENDING shows). For the full picture — subscription, charges and on-chain payments across every link — use `billing_summary`. Reading the meter is not charged.

### `billing_summary` (~164 tokens)

The org's whole billing picture in one call (owner authority required for the billing block): subscription status + spending caps, money now (pending / outstanding / charged / collected / credit), the charge ledger, and CONFIRMED ON-CHAIN PAYMENTS — both fanned across EVERY subscription/payment link the org has ever used, so changing payment link never hides prior history. Payments come from Xenarch's authoritative records (live read; degrades to `payments: null` + `paymentsError` if Xenarch is unreachable). Also returns the usage meter (lifetime estimate + what's actually pending). A key without owner authority — an agent whose principal isn't an owner, or a non-owner member — gets the usage meter only, with a `note`. Reading billing is not charged.

### `save_issue` (~989 tokens)

Create an issue (omit `identifier`) or update one (pass `identifier`, e.g. XEN-12). Only `title` is required to create. Setting status to `canceled` requires `cancelReason`. `labels` replaces the issue's labels. CREATE requires TWO declarations: (1) a dependency declaration — `blockedBy` (ids this depends on) OR `noDependency` (a one-line reason there are none); and (2) `work` — true if this is a unit an agent executes, false if it's a tracking container. A create missing either is rejected.

Input parameters:

- `assignee` (string): Responsible human (routing lane, distinct from claiming): a human member name, 'me', or '' to unassign. Optional for most statuses — unassigned issues stay in the global pull pool — but REQUIRED when…
- `blockedBy` (array): On create: issue ids this new one DEPENDS ON (e.g. ['RTSC-12']). Creates blocked_by links so the dependency graph drives dispatch.
- `body` (string): Markdown spec: context, acceptance criteria, repro.
- `cancelReason` (string): Required when status=canceled.
- `dueAt` (number): Precise deadline as epoch milliseconds. Recorded on the issue and echoed back on reads (get_issue, next_issue, list_issues); deadline-aware dispatch that raises effective priority as the deadline nea…
- `identifier` (string): Existing issue ID to update; omit to create.
- `labels` (array): Replaces all labels on the issue.
- `noDependency` (string): On create: a one-line reason this issue depends on nothing open. Use INSTEAD of blockedBy when independent — a positive 'I considered it' assertion.
- `priority` (number): 0=None,1=Urgent,2=High,3=Medium,4=Low.
- `status` (string): `review` (RTSC-257) = work finished, pending human acceptance: it still BLOCKS dependents (unlike done) and releases your lease so a reviewer can claim it. `assignee` is REQUIRED on every write that…
- `title` (string): Required when creating.
- `work` (boolean): REQUIRED on create — you decide once. true = a unit an agent FINISHES by changing something: editing code/config/files, infrastructure (deploys, provisioning, env, DB/schema, CI/CD, DNS, services), w…

### `get_issue` (~68 tokens)

Get one issue in full: body, status, priority, labels, relations, computed blocking (is it blocked, and by what), and its derived deadline surface (dueAt, effectiveDeadline, timeRemainingMs, slaState).

Input parameters:

- `identifier` (string, required): e.g. XEN-12

### `list_issues` (~263 tokens)

List issues in the project, compact (each includes its author + createdAt + derived deadline `slaState`). Defaults to active work (hides done/canceled). Filter by status (one or many), priority, label, author, or SLA state. Ordered priority-first (None last), recent tiebreak. Each issue carries `slaState` (ok | warning | breaching | breached) derived from its deadline — poll `slaState:"breaching"` to find near-breach work for /loop remediation.

Input parameters:

- `assignee` (string): Filter by responsible human: a name, 'me', or 'none' (unassigned).
- `author` (string): Filter by creator: a member name (partial, case-insensitive) or 'me'.
- `label` (string)
- `limit` (number): Default 50, max 200.
- `priority` (number): 0..4
- `slaState` (string): Filter by derived deadline SLA state: ok (no deadline or <75% elapsed), warning (≥75%), breaching (≥90%, not yet past), breached (past deadline). Poll 'breaching' for near-breach work.
- `status`: A status or array of statuses to include.

### `save_comment` (~56 tokens)

Add a comment to an issue. Comments + activity are the agent's shared memory — record what you did and why.

Input parameters:

- `body` (string, required)
- `issue` (string, required): Issue ID, e.g. XEN-12

### `list_comments` (~27 tokens)

List an issue's comments in chronological (thread) order.

Input parameters:

- `issue` (string, required)

### `retract_comment` (~71 tokens)

Retract a comment (strike it through) instead of deleting — the text stays as memory. Requires a note explaining why it's no longer valid (shown un-struck).

Input parameters:

- `comment` (string, required): Comment id (from list_comments).
- `note` (string, required): Why it's retracted; shown un-struck.

### `save_attachment` (~49 tokens)

Attach a link (URL) to an issue.

Input parameters:

- `issue` (string, required): Issue ID, e.g. XEN-12
- `title` (string)
- `url` (string, required)

### `prepare_attachment_upload` (~157 tokens)

Attach a FILE (image/blob) to an issue over MCP. Returns { uploadUrl } for the issue; then POST the raw file bytes to it with your API key as a Bearer header — the server encrypts the file at rest and attaches it. Add `&filename=` (download name) and optional `&title=` to the URL. Example: `curl -X POST "<uploadUrl>&filename=shot.png" -H "Authorization: Bearer <yourApiKey>" --data-binary @shot.png` → {"id":"...","url":"..."}. For a plain link (not a file), use save_attachment instead.

Input parameters:

- `issue` (string, required): Issue ID, e.g. RTSC-12

### `list_attachments` (~30 tokens)

List an issue's attachments (obsolete ones are flagged, not hidden).

Input parameters:

- `issue` (string, required)

### `get_attachment` (~23 tokens)

Read one attachment by id.

Input parameters:

- `attachment` (string, required): Attachment id.

### `obsolete_attachment` (~45 tokens)

Mark an attachment obsolete (the delete-equivalent) — keeps it as a record. Requires a reason.

Input parameters:

- `attachment` (string, required): Attachment id.
- `reason` (string, required)

### `add_relation` (~67 tokens)

Link two issues. type: blocks | blocked_by | related | duplicate. `blocks`/`blocked_by` form the dependency graph that drives blocking; dependency cycles are rejected.

Input parameters:

- `sourceId` (string, required)
- `targetId` (string, required)
- `type` (string, required)

### `remove_relation` (~44 tokens)

Remove a link between two issues (same args as add_relation).

Input parameters:

- `sourceId` (string, required)
- `targetId` (string, required)
- `type` (string, required)

### `save_label` (~34 tokens)

Create or update a label (idempotent by name).

Input parameters:

- `color` (string)
- `name` (string, required)

### `list_labels` (~18 tokens)

List all labels in the org with issue counts.

### `list_projects` (~21 tokens)

List projects in the org (prefix, name, issue counter).

### `get_project` (~41 tokens)

Get a project and a breakdown of its issues by status. Defaults to the API key's project.

Input parameters:

- `prefix` (string): Defaults to this key's project.

### `mint_session_key` (~100 tokens)

Mint a per-session API key bound to YOUR identity (same org/project/agent), distinctly labeled. The watchdog proxy calls this once at startup and uses the returned key, so concurrent sessions of one agent become distinguishable in queue_status/whoami. Same access as your key — no privilege change. The raw key is returned ONCE.

Input parameters:

- `label` (string): Session label (e.g. host#pid). Optional — auto-derived if omitted.

### `list_connectors` (~107 tokens)

List the org's intake connectors (e.g. GitHub Issues → Retasc issues, RTSC-189). Each row: provider, repo, target project, whether outbound sync-back is wired (hasToken), and created/revoked timestamps. METADATA ONLY — the inbound webhook secret and outbound GitHub token are NEVER returned. Read-only. Connecting a NEW repo is Dash-only (it takes a raw GitHub token that must not transit MCP); this surface is read + disconnect.

### `revoke_connector` (~102 tokens)

Disconnect an intake connector by id (from list_connectors). Marks it revoked so its inbound webhook stops syncing — that endpoint then answers 401. Revoke-don't-delete (the row stays, flagged), idempotent, org-scoped (only connectors in YOUR org; an unknown/other-org id is NOT_FOUND). To reconnect, use the Dash (a fresh webhook URL + secret).

Input parameters:

- `connectorId` (string, required): Connector id from list_connectors.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-retasc-retasc/mcp#diagnostics

## Score history

- 2026-08-03: 60
- 2026-08-02: 59
- 2026-08-01: 59
- 2026-07-31: 58
- 2026-07-30: 59
- 2026-07-29: 59
- 2026-07-28: 58
- 2026-07-27: 57
- 2026-07-26: 57

## Links

- Remote endpoint: https://mcp.retasc.com/mcp
- Website: https://retasc.com/
- Changelog RSS feed: https://verifymcp.io/servers/com-retasc-retasc/mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-retasc-retasc/mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/com-retasc-retasc/mcp