# TaScan (remote · app.tascan.io)

36 MCP tools for projects, tasks, workers, QR/NFC tags, and AI remediation. Task. Scan. Done.

- Trust score: 90/100 (high trust)
- Change this week: +2
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-20

## Components

- remote · `app.tascan.io`: 90/100 (this document), [markdown](https://verifymcp.io/servers/snowbikemike-tascan-mcp/app.md), [page](https://verifymcp.io/servers/snowbikemike-tascan-mcp/app)
- npm · `tascan-mcp`: 38/100, [markdown](https://verifymcp.io/servers/snowbikemike-tascan-mcp/tascan-mcp.md), [page](https://verifymcp.io/servers/snowbikemike-tascan-mcp/tascan-mcp)

## Channel facts

- Endpoint: `https://app.tascan.io/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `3.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-09-20.

- **Endpoint Security**: 94/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 68/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 12174 tokens (~154/item across 79 items; 79 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 100/100
  - No destabilizing schema changes in the last 30 days.
- **Tool Coverage**: 95/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 85% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 8 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 79 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

### How do I install the TaScan MCP server?

TaScan is a hosted endpoint at https://app.tascan.io/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http snowbikemike-tascan-mcp 'https://app.tascan.io/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "snowbikemike-tascan-mcp": {
      "url": "https://app.tascan.io/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "snowbikemike-tascan-mcp": {
      "type": "http",
      "url": "https://app.tascan.io/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.snowbikemike-tascan-mcp]
url = "https://app.tascan.io/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "snowbikemike-tascan-mcp": {
      "type": "remote",
      "url": "https://app.tascan.io/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add snowbikemike-tascan-mcp --url 'https://app.tascan.io/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  snowbikemike-tascan-mcp:
    url: "https://app.tascan.io/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "snowbikemike-tascan-mcp": {
      "Transport": "http",
      "Url": "https://app.tascan.io/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add snowbikemike-tascan-mcp -t streamable-http -u 'https://app.tascan.io/mcp'
```

### Other

```json
{
  "mcpServers": {
    "snowbikemike-tascan-mcp": {
      "type": "http",
      "url": "https://app.tascan.io/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-09-20 (score 90, 0)

- [security] Tool “tascan_create_cycle” rewrote its description, which is the text the model reads
- [functional] Server version: 3.14.1 → 3.15.0
- [cosmetic] “tascan_create_cycle” added an optional parameter “reviews”
- [cosmetic] “tascan_create_cycle” reworded the description of “review_brief”

### 2026-09-19 (score 90, 0)

- [security] New tool “tascan_cancel_scheduled_sms”, which the server declares destructive
- [functional] Server version: 3.13.1 → 3.14.1
- [functional] New tool “tascan_schedule_sms”
- [functional] New tool “tascan_list_scheduled_sms”
- [functional] New tool “tascan_project_digest”
- [cosmetic] “tascan_create_cycle” added an optional parameter “repo”

### 2026-09-17 (score 90, 0)

- [security] Stability: 0.97 → pass
- [security] Tool “tascan_get_build” rewrote its description, which is the text the model reads
- [security] Tool “tascan_get_build_file” rewrote its description, which is the text the model reads

### 2026-09-16 (score 90, +1)

- [security] Tool “tascan_complete_task” rewrote its description, which is the text the model reads
- [security] Tool “tascan_get_receipt” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 131 → 148
- [functional] New tool “tascan_get_build_file”
- [functional] New tool “tascan_get_cycle_report”
- [functional] New tool “tascan_post_message”
- [functional] New tool “tascan_create_cycle”
- [functional] New tool “tascan_get_build”
- [cosmetic] “tascan_get_receipt” reworded the description of “profile”

### 2026-09-15 (score 89, +1)

- [security] Tool “tascan_add_tasks” rewrote its description, which is the text the model reads
- [security] Tool “tascan_dispatch_to_agent” rewrote its description, which is the text the model reads
- [security] Tool “tascan_get_task” rewrote its description, which is the text the model reads
- [security] Tool “tascan_register_agent” rewrote its description, which is the text the model reads
- [security] Tool “tascan_update_task” rewrote its description, which is the text the model reads
- [functional] MCP protocol version: 2025-03-26 → 2025-06-18
- [functional] Server version: 3.12.0 → 3.13.1
- [functional] New tool “tascan_get_receipt”
- [cosmetic] “tascan_dispatch_to_agent” reworded the description of “agent”
- [cosmetic] “tascan_dispatch_to_agent” reworded the description of “priority”
- [cosmetic] “tascan_dispatch_to_agent” reworded the description of “task”

### 2026-09-13 (score 88, +1)

- [functional] Server version: 3.11.0 → 3.12.0

### 2026-09-12 (score 87, 0)

- [security] Tool “tascan_get_task” rewrote its description, which is the text the model reads
- [security] Tool “tascan_get_report” rewrote its description, which is the text the model reads
- [functional] Schema quality: good → excellent
- [functional] Server version: 3.9.0 → 3.11.0

### 2026-09-11 (score 87, +1)

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

## MCP tools (79)

### `tascan_list_projects` (~19 tokens)

List all TaScan projects in the organization

### `tascan_create_project` (~43 tokens)

Create a new TaScan project (top-level container for events)

Input parameters:

- `location` (string): Project location / venue
- `name` (string, required): Project name

### `tascan_get_project` (~27 tokens)

Get details of a specific project

Input parameters:

- `project_id` (string, required): Project ID

### `tascan_update_project` (~82 tokens)

Update a project (name, location, status, dates)

Input parameters:

- `end_date` (string): End date (ISO)
- `location` (string): New location
- `name` (string): New name
- `project_id` (string, required): Project ID
- `start_date` (string): Start date (ISO)
- `status` (string): Status

### `tascan_delete_project` (~41 tokens)

Delete a project and all its events, tasks, and completions. This action is irreversible.

Input parameters:

- `project_id` (string, required): Project ID to delete

### `tascan_create_event` (~158 tokens)

Create a new event (task list) within a project. Supports team_mode (shared completions) and multi_instance (each worker gets isolated copy — great for surveys, onboarding, info collection). team_mode and multi_instance cannot both be true.

Input parameters:

- `assigned_worker_ids` (array): Worker UUIDs to assign to this event. Each gets a personal tap-to-open link. Note: a worker holds one event assignment per project — assigning moves them.
- `description` (string): Event description
- `multi_instance` (boolean): Multi-instance — each worker gets isolated copy
- `name` (string, required): Event name
- `project_id` (string, required): Project ID
- `team_mode` (boolean): Team mode — shared completions

### `tascan_list_events` (~31 tokens)

List all events (task lists) within a project

Input parameters:

- `project_id` (string, required): Project ID

### `tascan_get_event` (~38 tokens)

Get details of a specific event (task list) including its tasks

Input parameters:

- `list_id` (string, required): Task list (event) ID

### `tascan_update_event` (~167 tokens)

Update an event / task list (name, description, team_mode, multi_instance, timer_mode). team_mode and multi_instance cannot both be true.

Input parameters:

- `assigned_worker_ids` (array): Worker UUIDs to assign to this event (additive — workers not named are left alone). Each gets a personal tap-to-open link. Note: a worker holds one event assignment per project — assigning moves them.
- `description` (string): New description
- `list_id` (string, required): Task list (event) ID
- `multi_instance` (boolean): Multi-instance — each worker gets isolated copy
- `name` (string): New name
- `team_mode` (boolean): Team mode — shared completions
- `timer_mode` (string): Timer mode (auto or manual)

### `tascan_delete_event` (~46 tokens)

Delete an event (task list) and all its tasks and completions. This action is irreversible.

Input parameters:

- `list_id` (string, required): Task list (event) ID to delete

### `tascan_add_tasks` (~150 tokens)

Add one or more tasks to an event (task list). Supports bulk creation. IMPORTANT: Set response_type correctly — use "text" for info collection (names, phones, emails, notes), "photo" for visual verification (inspections, serial numbers, damage checks), "checkbox" only for simple confirmations. NOTE: To dispatch tasks to an AI agent use tascan_dispatch_to_agent instead. Writing into an agent inbox list requires the agent:dispatch permission (agent:dispatch:code for CODE:/SHELL: titles) — without it the call is refused.

Input parameters:

- `list_id` (string, required): Task list (event) ID
- `tasks` (array, required): Array of tasks to create

### `tascan_dispatch_to_agent` (~328 tokens)

PREFERRED tool for sending work to an AI agent. Dispatches a task to the agent's inbox — picked up and executed automatically. No list ID needed. REQUIRES the agent:dispatch permission on this connection (CODE:/SHELL: tasks also require agent:dispatch:code) — reconnect and tick the agent checkbox(es) if refused. Routing is by TITLE PREFIX only: CODE: SHELL: PLAN: MCP: → local Claude Code on Mike's PC; RESEARCH: WRITE: REVIEW: → cloud; no prefix (DEFAULT) → local while the PC agent is alive, else cloud. The cloud agent refuses CODE/SHELL/PLAN/MCP. Use "agent" param to target a specific agent (default: claude-code-local). Use tascan_list_agents to discover available agents; track progress with tascan_get_task (its "agent" block).

Input parameters:

- `agent` (string): Agent ID or name to dispatch to (default: claude-code-local). Use tascan_list_agents to see options. An unknown agent is an error, never a silent fallback.
- `priority` (string): Priority level (default: normal). The urgent marker is placed AFTER the routing prefix so it never breaks routing.
- `task` (string, required): The full task text. START it with CODE: SHELL: PLAN: MCP: RESEARCH: WRITE: or REVIEW: for routing (prefix-only — nothing may precede it), or leave it unprefixed (DEFAULT). The whole text is stored in…

### `tascan_list_agents` (~49 tokens)

List all registered AI agents with their capabilities, inbox IDs, and status. Like reading input labels on a video matrix — discover which agents are available and what they can do before dispatching work.

### `tascan_register_agent` (~234 tokens)

Register a new AI agent in the agent registry. The agent will appear in tascan_list_agents and can receive dispatched tasks. Self-registration for AI agents joining the TaScan network. REQUIRES the agent:dispatch permission (defining a dispatch target is a dispatch permission); inbox_id must be a task list (event) in your organization.

Input parameters:

- `capabilities` (array, required): Task type prefixes this agent handles (e.g. ["RESEARCH", "WRITE"])
- `description` (string): What this agent does
- `id` (string, required): Unique agent ID (e.g. "my-agent-1")
- `inbox_id` (string, required): Task list ID this agent monitors for new tasks
- `location` (string): Where the agent runs (e.g. "AWS us-east-1")
- `model` (string): Model powering this agent (e.g. "claude-sonnet-4-6")
- `name` (string, required): Display name (e.g. "Research Bot")
- `type` (string, required): Agent type
- `worker_id` (string): TaScan worker ID for this agent

### `tascan_list_tasks` (~34 tokens)

List all tasks in an event (task list)

Input parameters:

- `list_id` (string, required): Task list (event) ID

### `tascan_get_task` (~236 tokens)

Get details of a specific task including completions and subtasks. Each completion carries photo_url (raw storage path, stable) and photo_signed_url (short-lived fetchable URL, ~1h; null when no photo) so you can actually view the photo evidence. Tasks dispatched to an AI agent also carry an "agent" block (state claimed|running|completed|failed|expired|released, attempts, current run with runner/trace_id/error) — the only place agent failures are reported. A completion with status "completed" means the executor returned and its result was recorded (a model refusal, a wrong answer or an administrative note all "complete"); it does NOT mean the requested result was accepted. Acceptance is the completion evidence_check / the receipt verification.result under a named policy, and in v0.1 no policy exists for agent tasks (exact-output and rubric policies are v0.2) — check the recorded response text yourself before treating an agent completion as success (protocol §2.6, §3.2, §8.3 C11).

Input parameters:

- `task_id` (string, required): Task ID

### `tascan_get_receipt` (~347 tokens)

Fetch the signed Action Receipt (Ed25519 JWS) for one completed task by completion_id (tascan_get_task -> completions[].id). Returns a readable summary (what, who, verification, evidence hashes, outcome, ledger chain) plus receipt_id/serial/kid, the compact JWS and the public verify URL. Verify offline against the JWKS or online by POSTing a JSON body whose jws field holds the compact receipt. Read outcome and verification separately: outcome completed = the executor returned and a result was recorded; verification.result = the verdict of a named policy; all-null verification with reason no_policy_run = no policy ran. Never treat outcome=completed as success without a policy verdict you trust (protocol 8.3 C11). Verifier: 6.8. profile=public returns the separately signed public export profile (protocol 6.10): it withholds the raw org, list, project, worker, run and trace ids (each a 16-hex id_hash) and storage locators, and binds to the full receipt - the form for anyone outside the org. Read tier.

Input parameters:

- `completion_id` (string, required): task_completions.id (UUID) - from tascan_get_task -> completions[].id
- `profile` (string): full (default) = the org view with the unsigned private block; public = the separately signed public export profile: no raw org, list, project, worker, run or trace id (each is a 16-hex id_hash), no…

### `tascan_update_task` (~272 tokens)

Update a task (title, description, response_type, flags, sort_order). A task that sits in an AI agent inbox is agent input (the runner executes title + description), so ANY edit to it needs the agent:dispatch permission — agent:dispatch:code when the task is or becomes CODE:/SHELL:.

Input parameters:

- `assigned_to` (string): Worker to assign this task to — pass the worker UUID (validated against your org and stored as the worker's name, which is how the worker portal matches "my tasks"). A plain name string is also accep…
- `description` (string): New description
- `is_safety_checkpoint` (boolean): Safety-critical flag
- `required_equipment` (string): Equipment this task depends on (free text)
- `requires_photo` (boolean): Require photo
- `response_config` (object): Response configuration. For "choice": {options: [...]}. See tascan_add_tasks.
- `response_type` (string): See tascan_add_tasks for guidance. "text" for info collection, "photo" for visual proof, "checkbox" for yes/no only.
- `sort_order` (number): Sort position
- `task_id` (string, required): Task ID
- `title` (string): New title

### `tascan_reply_with_list` (~177 tokens)

Reply to a task list WITH a task list — the two-way tasking primitive. Creates a new list linked into the parent's thread, aimed back at whoever sent the original (e.g. "Grant access — pick a window" with response_type date, or an info request with response_type text). The org gets pinged; the thread shows in both the worker portal and Simple Mode. Use tascan_get_thread-style follow-up via tascan_list_projects/tascan_get_report to read answers.

Input parameters:

- `author_name` (string): Who is replying (shown in the thread)
- `parent_list_id` (string, required): The list being replied to
- `tasks` (array, required): Items the recipient answers — each becomes a typed task
- `title` (string, required): Reply list title (e.g. "Before I can start...")

### `tascan_add_subtasks` (~136 tokens)

Add one or more subtasks to a task (bulk). Subtasks support typed responses: "number" for per-set data (reps, weight, distance), "text" for notes, "choice" for options, "checkbox" for simple steps. Set-logging example: task "Bench Press" with subtasks Set 1/Set 2/Set 3 each response_type "number" — each completed set stores its value and timestamp, giving per-set timing for progression tracking.

Input parameters:

- `subtasks` (array, required): Array of subtasks to create
- `task_id` (string, required): Parent task ID

### `tascan_list_subtasks` (~46 tokens)

List the subtasks of a task, including completion state, stored response values, and completion timestamps (per-set timing).

Input parameters:

- `task_id` (string, required): Parent task ID

### `tascan_update_subtask` (~90 tokens)

Update a subtask (title, description, response_type, response_config, requires_photo, sort_order).

Input parameters:

- `description` (string)
- `requires_photo` (boolean)
- `response_config` (object)
- `response_type` (string)
- `sort_order` (number)
- `subtask_id` (string, required): Subtask ID
- `title` (string)

### `tascan_complete_subtask` (~133 tokens)

Complete a subtask, optionally recording a typed response_value (e.g. the weight or reps for that set). Each completion is timestamped, so consecutive set completions yield per-set durations. Returns progress including all_subtasks_complete — when true, complete the parent task with tascan_complete_task.

Input parameters:

- `notes` (string): Optional notes
- `response_value` (string): Typed response value (for number/text/choice subtasks), e.g. "165"
- `subtask_id` (string, required): Subtask ID to complete
- `worker_id` (string): Worker performing the completion (optional)

### `tascan_delete_subtask` (~39 tokens)

Delete a subtask and its completions. This action is irreversible.

Input parameters:

- `subtask_id` (string, required): Subtask ID to delete

### `tascan_delete_task` (~36 tokens)

Delete a specific task and its completions. This action is irreversible.

Input parameters:

- `task_id` (string, required): Task ID to delete

### `tascan_complete_task` (~161 tokens)

Complete an ORDINARY task on behalf of a worker. Inserts a completion record and timer event. Use this to simulate or record task completions via the API. Coordination-cycle tasks (a CODE:/REVIEW: build or review, a Decision / Question / Integrate / Parked card on a project Decisions list — tasks that carry `coord`) are refused with 403 for every key tier: builds and reviews are completed by their runner, decisions only by the human on the worker page.

Input parameters:

- `notes` (string): Optional completion notes
- `response_value` (string): Response value (for text/number/choice tasks)
- `task_id` (string, required): Task ID to complete
- `worker_id` (string, required): Worker ID performing the completion

### `tascan_list_workers` (~171 tokens)

List workers (taskees) in the organization. Supports filtering by name/email/phone substring, contact-info presence, and last-activity date. Each row includes completion_count (total task completions).

Input parameters:

- `active_since` (string): ISO date/datetime — only workers with last_active_at on/after this
- `has_email` (boolean): true/false — same for email
- `has_phone` (boolean): true = only workers with a phone on file; false = only without
- `include_inactive` (boolean): true = also include inactive workers (e.g. tombstones left by a merge or delete) — useful for auditing right after tascan_merge_workers / tascan_delete_worker
- `query` (string): Substring match on name, email, or phone

### `tascan_create_worker` (~48 tokens)

Create a new worker (taskee) in the organization

Input parameters:

- `email` (string): Email
- `name` (string, required): Worker name
- `phone` (string): Phone number

### `tascan_update_worker` (~58 tokens)

Update a worker profile (name, phone, email)

Input parameters:

- `email` (string): New email
- `name` (string): New name
- `phone` (string): New phone
- `worker_id` (string, required): Worker ID

### `tascan_generate_qr` (~44 tokens)

Generate a QR code for a task list (event) that workers can scan to access tasks

Input parameters:

- `list_id` (string, required): Task list (event) ID

### `tascan_apply_template` (~63 tokens)

Apply a pre-built template to a task list, adding all template tasks

Input parameters:

- `list_id` (string, required): Task list (event) ID
- `template_slug` (string, required): Template slug (e.g. "conference-load-in", "warehouse-receiving")

### `tascan_list_templates` (~45 tokens)

List available task templates (built-in and saved)

Input parameters:

- `category` (string): Filter by category (e.g. "live-events", "hospitality", "logistics")

### `tascan_get_report` (~120 tokens)

Get completion report for a task list (event) including task status, completions, workers, and photos. Set include_responses to also return the actual submitted response data (numbers, text, choices) for each completed task plus a per-task photos list with fetchable signed URLs (short-lived, ~1h) for the photo evidence.

Input parameters:

- `include_responses` (boolean): Include the actual submitted response values for each completed task (default false — keeps the payload light)
- `list_id` (string, required): Task list (event) ID

### `tascan_query_responses` (~151 tokens)

Query one task's submitted responses across every list in a project — e.g. the same exercise repeated across many workout lists returns one chronological progression series instead of N report lookups. Match by task title pattern or exact task ID. Subtask completions interleave into the same series labeled 'Task › Subtask' (e.g. per-set values Set 1/2/3 with their own timestamps), so set-level progression chains across lists automatically.

Input parameters:

- `limit` (number): Max responses to return (default 200, max 500)
- `project_id` (string, required): Project ID
- `task` (string, required): Task title pattern (case-insensitive substring) or exact task ID

### `tascan_list_issues` (~67 tokens)

List all issues for a task list (event). Returns open, acknowledged, and resolved issues with severity, type, and category. Use this to discover issues that need AI analysis via tascan_analyze_issue.

Input parameters:

- `list_id` (string, required): Task list (event) ID

### `tascan_analyze_issue` (~119 tokens)

Step 1 of the Closed-Loop Autonomous Operations Protocol. Retrieves full issue context including worker info, message thread, project history, and recent similar issues. Use this data to reason about the root cause and generate a remediation plan. Also supports server-side AI analysis via POST (calls Anthropic API directly).

Input parameters:

- `issue_id` (string, required): Issue ID to analyze
- `server_side_ai` (boolean): If true, the server calls Anthropic API directly for AI analysis (default: false — returns raw data for MCP client to analyze)

### `tascan_recommend_fix` (~176 tokens)

Step 2 of the Closed-Loop Autonomous Operations Protocol. Post an AI-generated recommendation to an issue thread. Accepts both a text recommendation and an optional structured_recommendation object with task definitions for auto-dispatch. The recommendation is persisted in the AI audit trail.

Input parameters:

- `ai_agent` (string): Name of the AI agent posting (default: TaScan AI)
- `issue_id` (string, required): Issue ID to recommend a fix for
- `recommendation` (string, required): The AI-generated recommendation text (clear, actionable instructions)
- `structured_recommendation` (object): Optional structured recommendation with tasks for auto-dispatch. Format: { recommendation_summary, confidence_score, tasks: [{ title, description, response_type, requires_photo, is_safety_checkpoint,…

### `tascan_dispatch_instruction` (~234 tokens)

Step 3 of the Closed-Loop Autonomous Operations Protocol. Dispatches remediation to the worker via MULTI-CHANNEL delivery: (1) issue thread message, (2) in-app notification, (3) progress feed update, (4) SMS if phone on file, (5) optional remediation task list creation. Closes the loop from digital AI analysis to physical worker execution.

Input parameters:

- `ai_agent` (string): Name of the AI agent dispatching (default: TaScan AI)
- `instruction` (string, required): Clear, actionable instruction for the worker to execute
- `issue_id` (string, required): Issue ID this instruction relates to
- `recommendation_summary` (string): One-line summary for the task list description
- `remediation_tasks` (array): Optional array of tasks to create as a remediation task list. Each: { title, description, response_type, requires_photo, is_safety_checkpoint, sort_order }
- `send_sms` (boolean): Send SMS to worker (default: true if phone on file)
- `worker_id` (string): Target worker ID (defaults to the worker who reported the issue)

### `tascan_auto_resolve` (~82 tokens)

FULL Closed-Loop Autonomous Operations Protocol in one call. Server-side AI analyzes the issue, generates remediation tasks, creates a task list, and dispatches to the worker — all without human intervention. This executes Patent Claim 7: autonomous operations from issue detection through physical-world instruction delivery.

Input parameters:

- `issue_id` (string, required): Issue ID to auto-resolve

### `tascan_send_sms` (~250 tokens)

Send a transactional TaScan SMS text to a worker (by worker_id, using their phone on file) or to a raw phone number. Optionally attach a task list — the recipient gets a tap-to-open checklist link. Sends from TaScan's carrier-registered A2P number (or the org's own Twilio if BYOK). Counts against the org's monthly SMS quota unless BYOK. Messages are auto-prefixed with "TaScan:" per carrier registration; transactional/work-related content only, no marketing.

Input parameters:

- `include_link` (boolean): When a list_id is given, append the tap-to-open link to the SMS body (default true). Set false to send the message text alone — the link is still returned for you to share another way.
- `list_id` (string): Optional task list ID — appends a tap-to-open worker checklist link
- `message` (string, required): Message text. Transactional and work-related only.
- `phone` (string): Raw phone number (e.g. "+17025551234") — used when no worker_id given
- `worker_id` (string): Worker ID — sends to their phone on file (preferred over raw phone)

### `tascan_schedule_sms` (~379 tokens)

Schedule a transactional TaScan SMS for a future time (up to 90 days out): the text is sent by TaScan's own scheduler (every 5 minutes) through the same guarded lane as tascan_send_sms — recipient must be a worker of your org or a phone the org already knows, STOP opt-outs honoured, burst limits and the SMS quota apply, the "TaScan:" prefix is added, and a list_id appends a tap-to-open checklist link. Use this for reminders (e.g. "log your out time" each show night) — nothing outside TaScan needs to stay awake. Returns the scheduled row id; cancel with tascan_cancel_scheduled_sms while it is still pending. The same idempotency_key within an org returns the existing row instead of a duplicate.

Input parameters:

- `idempotency_key` (string): Optional caller key (≤ 200 chars) — replays return the existing scheduled row
- `include_link` (boolean): Append the list link (default true when list_id is given)
- `list_id` (string): Optional task list ID — appends the tap-to-open checklist link
- `message` (string, required): Message text (1-400 chars, links stripped). Transactional and work-related only.
- `phone` (string): Raw phone (E.164) — must already belong to a worker or roster entry of your org
- `send_at` (string, required): When to send — ISO 8601 with a timezone offset, e.g. "2026-09-25T18:30:00-07:00" (Las Vegas is -07:00 in September). Delivery happens on the next 5-minute tick at or after this time.
- `worker_id` (string): Worker ID — texts their phone on file (preferred over raw phone)

### `tascan_list_scheduled_sms` (~82 tokens)

List your org's scheduled texts (default: pending + sending, soonest first; status=sent|failed|cancelled to see history). Each row shows send_at, status, attempts, the Twilio sid once sent, and the last error for a failed row.

Input parameters:

- `status` (string): Filter by status (default pending + sending)

### `tascan_cancel_scheduled_sms` (~73 tokens)

Cancel a scheduled text that has not been sent yet (status pending). A row already sending, sent, failed or cancelled is refused (409) — a sent text cannot be recalled.

Input parameters:

- `id` (string, required): The scheduled_sms row id from tascan_schedule_sms / tascan_list_scheduled_sms

### `tascan_get_sms_status` (~73 tokens)

Check delivery status of a previously sent TaScan SMS by its Twilio SID (returned by tascan_send_sms). Shows queued/sent/delivered/undelivered/failed plus carrier error codes.

Input parameters:

- `twilio_sid` (string, required): Twilio message SID (SM...) from tascan_send_sms

### `tascan_send_task_email` (~154 tokens)

Send a branded TaScan task notification email via SendGrid. Can notify anyone about a specific task list or task. Includes QR code, task summary, and "Open in TaScan" button.

Input parameters:

- `include_qr` (boolean): Include QR code for the task list in the email (default: true)
- `list_id` (string, required): Task list (event) ID
- `message` (string): Optional custom message to include in the email body
- `subject` (string): Custom email subject (defaults to auto-generated)
- `task_id` (string): Optional specific task ID to highlight
- `to_email` (string, required): Recipient email address
- `to_name` (string): Recipient display name

### `tascan_register_tag` (~185 tokens)

Register a physical NFC tag to a project, task list, or specific task. When someone taps the tag, TaScan routes them to the linked resource. Tags use NTAG215 chips and are programmed with NFC Tools Pro.

Input parameters:

- `location_description` (string): Physical location of the tag
- `project_id` (string): Project ID
- `tag_hardware_id` (string, required): NFC tag hardware serial number (e.g., "04:CB:6C:51:CE:2A:81")
- `tag_name` (string, required): Friendly name (e.g., "Ballroom A Door", "Breaker Panel 3")
- `target_type` (string, required): What this tag points to
- `task_id` (string): Task ID (required for task targets)
- `task_list_id` (string): Task list ID (required for task_list/task targets)

### `tascan_list_tags` (~28 tokens)

List all registered NFC tags in the organization with their linked projects/task lists and scan counts

### `tascan_get_scan_history` (~219 tokens)

Scan accountability data. Two modes: (1) tag_id — scans of a registered NFC tag; (2) task_list_id or project_id — every QR/link page-open stamp: when the code was scanned, GPS + IP + channel (qr/nfc/sms/email/link), who the scanner turned out to be, and the scan→start delta (how long between scanning and actually identifying + starting work — the sign-in-and-vanish metric).

Input parameters:

- `limit` (number): Max results (default 50, max 200)
- `project_id` (string): Project ID — page-scan mode, all lists in the project
- `since` (string): ISO timestamp — only scans after this
- `source` (string): Filter page scans by channel: qr | nfc | sms | email | link | unknown
- `tag_id` (string): NFC tag registry ID (from tascan_list_tags) — tag mode
- `task_list_id` (string): Task list ID — page-scan mode

### `tascan_search_marketplace` (~207 tokens)

Search the cross-org Worker Marketplace: workers who opted in (discoverable=true on their passport), ranked by passkey trust tier + verified completion volume.  Skills are AI-inferred from REAL completed work, not resumes — each carries a verified_task_count and a civilian_equivalent job title.  Returns sanitized public cards only (first name + last initial, skills, stats, passport URL) — never phone, email, or org membership.

Input parameters:

- `available` (boolean): Only workers who marked themselves available on their passport
- `city` (string): Filter by the worker's opt-in home city, e.g. "Las Vegas"
- `limit` (number): Max cards (default 25, max 50)
- `min_completions` (number): Only workers with at least this many verified completions
- `q` (string): Skill, category, name, or civilian job title — e.g. "forklift", "LED wall", "AV technician"

### `tascan_invite_worker` (~165 tokens)

Invite a marketplace worker to a task list — the consented intro. TaScan texts the worker from its own number ("<Your org> wants you for <list>. Reply YES to share your contact and get the list, or NO to pass."). On YES the worker appears in your org with their name + phone, receives the list link, and you get a text + a thread message. On NO or silence (7 days) you never learn who they were. Use the worker_id from tascan_search_marketplace.

Input parameters:

- `list_id` (string, required): Task list you want them on
- `message` (string): Optional short intro prepended to the text (max 240 chars)
- `worker_id` (string, required): worker_id from a marketplace card

### `tascan_list_invites` (~60 tokens)

List marketplace invites you have sent and their status (pending / accepted / declined / expired / failed). Accepted invites include the worker's name and phone — that is the consent boundary; pending and declined never do.

Input parameters:

- `status` (string)

### `tascan_create_zone` (~616 tokens)

Create a geofenced work zone. Delivery zones route workers who open the project Site Gate (geo.html?project=...) to this zone's task list when GPS places them inside the radius. Set enforce_on_list=true to zone-lock the task list — workers cannot start it from outside the zone.

Input parameters:

- `alert_on_breach` (boolean): Email + SMS the admin on containment-exit / restricted-enter (default true)
- `auto_clock_in` (boolean): Entering the zone writes a shift_start clock-in event
- `auto_clock_out` (boolean): Leaving the zone writes a shift_end clock-out event
- `description` (string): Shown to workers on the Site Gate page
- `enforce_on_list` (boolean): Zone-lock the task list — it cannot be started from outside the radius
- `enter_message` (string): What the worker sees / is texted on entry (default is generated from the rule)
- `kind` (string): What the fence MEANS. work_site: expected here (auto clock-in, list on enter). hazard: enter allowed under conditions — required_ppe + photo checkpoint verified by AI vision, the OSHA row. containmen…
- `lat` (number, required): Zone center latitude
- `lng` (number, required): Zone center longitude
- `name` (string, required): Zone name (e.g. "Stage Left", "Loading Dock")
- `notify_email` (string): Alert recipient override — defaults to all org admins
- `notify_on_enter` (boolean): Email the manager when a worker enters this zone (danger areas)
- `notify_on_exit` (boolean): Email the manager when a worker leaves this zone (accountability — sign in then disappear)
- `polygon` (array): Polygon/rectangle zone instead of a circle: vertices as [[lat,lng], ...], at least 3.  lat/lng/radius_m are then computed (centroid + bounding radius) — still pass lat/lng but they are overridden.
- `ppe_photo_required` (boolean): Hazard zones: pop a photo checkpoint on entry (default true when required_ppe is set)
- `project_id` (string): Project this zone belongs to
- `radius_m` (number): Radius in meters (default 150, min 10, max 100000)
- `required_ppe` (array): Hazard zones: PPE the worker must show at entry (pick-list so the audit reads the same words)
- `sms_worker_on_enter` (boolean): Text the worker the rule/list on entry, even if the app is closed
- `sms_worker_on_exit` (boolean): Text the worker on exit
- `task_list_id` (string): Task list the Site Gate routes workers to when they are inside this zone
- `task_list_on_enter` (string): Task list dispatched to the worker (in-app + SMS) when they cross into the zone

### `tascan_list_zones` (~47 tokens)

List geofenced work zones, optionally filtered by project. Shows center, radius, routing target, and zone-lock status.

Input parameters:

- `project_id` (string): Filter by project

### `tascan_update_zone` (~255 tokens)

Update a geofenced zone — move the center, resize the radius, change the routing target, toggle zone-lock, or deactivate it (is_active=false).

Input parameters:

- `alert_on_breach` (boolean)
- `auto_clock_in` (boolean)
- `auto_clock_out` (boolean)
- `enforce_on_list` (boolean)
- `enter_message` (string)
- `is_active` (boolean)
- `kind` (string)
- `lat` (number)
- `lng` (number)
- `name` (string)
- `notify_email` (string)
- `notify_on_enter` (boolean)
- `notify_on_exit` (boolean)
- `polygon` (array): Replace geometry with a polygon ([[lat,lng],...], ≥3 vertices); pass null to revert to a circle
- `ppe_photo_required` (boolean)
- `radius_m` (number)
- `required_ppe` (array)
- `sms_worker_on_enter` (boolean)
- `sms_worker_on_exit` (boolean)
- `task_list_id` (string)
- `task_list_on_enter` (string)
- `zone_id` (string, required): Zone ID

### `tascan_zone_compliance` (~129 tokens)

Hazard-zone compliance audit (OSHA / insurance): every zone crossing, PPE checkpoint verdict (complied / failed with what was missing / skipped), and breach, plus injury reports cross-referenced with the worker's last PPE checkpoint before the injury. Scope by project or zone, optionally by worker and date range. Same rows the printable Evidence Pack shows.

Input parameters:

- `project_id` (string)
- `since` (string): ISO date/time lower bound
- `until` (string): ISO date/time upper bound
- `worker_id` (string)
- `zone_id` (string)

### `tascan_register_asset` (~138 tokens)

Register a physical asset (equipment, structure, vehicle, machine) in the condition ledger so it can be assessed over time. Each asset gets a longitudinal condition history with AI scoring and degradation trajectory.

Input parameters:

- `asset_type` (string): Type (e.g. "LED processor", "forklift", "scaffold")
- `description` (string): Context the AI assessor should know
- `location_description` (string)
- `name` (string, required): Asset name (e.g. "LED Wall Processor #3")
- `project_id` (string)
- `serial_number` (string): Serial number or asset tag (unique per org)

### `tascan_assess_condition` (~124 tokens)

Run an AI condition assessment of an asset from a photo. The model scores 0-100 with the asset's full assessment history in context, so it reads degradation over time — returning the Condition Delta Score vs the previous assessment, defects, wear indicators, maintenance recommendations, and a degradation trajectory. Sensor-free predictive maintenance.

Input parameters:

- `asset_id` (string, required): Asset ID (from tascan_register_asset or tascan_list_assets)
- `photo_url` (string, required): Public URL of the assessment photo
- `worker_name` (string): Who took the photo (optional)

### `tascan_condition_history` (~55 tokens)

Get an asset's longitudinal condition history — score trend over time, every assessment with grade, delta, findings, and who assessed it. The per-serial-number condition ledger.

Input parameters:

- `asset_id` (string, required): Asset ID

### `tascan_list_assets` (~51 tokens)

List registered condition-ledger assets with their latest condition scores. Use to recover an asset_id for tascan_assess_condition or tascan_condition_history.

Input parameters:

- `project_id` (string): Filter by project

### `tascan_generate_report` (~284 tokens)

Mint a shareable report and get its link. Types: completion (full proof-of-work for one list: tasks, responses, subtasks, photos, GPS + place names, timing, QR pair), service (client-facing version of a list with YOUR company branding and a Client Acknowledgment button — the ack files into the list thread), project (every list in a project rolled up), evidence (compliance Evidence Pack; admin sign-in required to view). Links are stable — the same list/project returns the same link. Optionally text the link to a phone through the TaScan SMS lane.

Input parameters:

- `company_name` (string): Service report branding (defaults to the org name)
- `list_id` (string): Required for completion / service
- `message` (string): Service report: a note to the client shown under the header
- `project_id` (string): Required for project / evidence
- `send_note` (string): Short intro for the text, e.g. "Here is your report from Love Productions:"
- `send_to_phone` (string): Text the link to this number (E.164 or 10-digit US)
- `show_issues` (boolean): Service report: include reported issues (default false)
- `show_workers` (boolean): Service report: show worker names (default true)
- `type` (string, required)

### `tascan_list_reports` (~55 tokens)

List existing report links for a list or project (completion / service / project / evidence), newest first, with client acknowledgment status for service reports.

Input parameters:

- `list_id` (string)
- `project_id` (string)

### `tascan_create_invoice` (~586 tokens)

Create a client invoice and get its shareable link. Two ways to bill: (a) pass explicit line_items, or (b) pass project_id or task_list_ids plus hourly_rate (quarter-hour billing from first→last verified completion per list) or flat_rate_per_list, and TaScan builds one line per list from VERIFIED work ("<list> — 7/7 tasks verified · Sep 1 · 1.25h"); lists with no completions are skipped. A single-list invoice also mints a client-facing Service Report (acknowledge → pay) and links it. Returns invoice number, totals, url, and the work it billed.

Input parameters:

- `attach_service_report` (boolean): Mint + link a Service Report for single-list invoices (default true)
- `billing` (object): Billing rules for auto line items. mode: hourly (default when hourly_rate given) | day_rate | flat. Overtime/double time are computed PER WORK DAY from verified completions: hours over overtime_after…
- `client_email` (string)
- `client_name` (string, required): Bill-to name (person or company)
- `client_phone` (string)
- `company_name` (string): Your company name on the attached Service Report (defaults to the org name)
- `due_date` (string): YYYY-MM-DD (default: 30 days out)
- `flat_rate_per_list` (number): Dollars per list for auto line items (used when no hourly_rate)
- `hourly_rate` (number): Dollars per hour for auto line items
- `line_items` (array): Explicit lines instead of auto-billing
- `min_hours` (number): Minimum billable hours per list (e.g. 1)
- `notes` (string): Payment terms / thank-you shown on the invoice
- `payment_options` (object): Pay-how-you-like buttons on the invoice (defaults to the org's saved handles). Keys: venmo (@handle), cashapp ($cashtag), paypal (paypal.me name), zelle (phone/email), applecash (phone), other (free…
- `project_id` (string): Bill every list in this project (auto line items)
- `status` (string): Default sent
- `task_list_ids` (array): Bill just these lists (auto line items)
- `tax_rate` (number): Fraction, e.g. 0.0825 for 8.25%

### `tascan_list_invoices` (~68 tokens)

List invoices for the org (newest first) with status, client, total, due date and share link. Filter by status (draft/sent/paid/overdue/cancelled) or project.

Input parameters:

- `project_id` (string)
- `status` (string)

### `tascan_update_invoice` (~108 tokens)

Update an invoice: mark it paid (records paid_at), overdue, cancelled, or edit client details / notes / due date.

Input parameters:

- `client_email` (string)
- `client_name` (string)
- `client_phone` (string)
- `due_date` (string)
- `invoice_id` (string, required)
- `notes` (string)
- `paid_at` (string): ISO timestamp (default now) when status = paid
- `status` (string)

### `tascan_request_payment` (~178 tokens)

Pledge a payment on a task list: when the list is verified complete (every task done + photo evidence on photo-required tasks), the payer automatically receives a Stripe pay link that routes the money DIRECTLY to the worker (0% TaScan fee). No money moves and no card is stored at pledge time. The worker must have completed payout onboarding (Get Paid on their profile).

Input parameters:

- `amount_cents` (number, required): Amount in cents ($1 min, $10,000 max)
- `memo` (string): What the payment is for (shown to the payer)
- `payer_email` (string, required): Who pays — receives the pay link on verification
- `payer_name` (string)
- `task_list_id` (string, required): Task list the payment is tied to
- `worker_id` (string, required): Worker who gets paid

### `tascan_list_payments` (~76 tokens)

List gig payments and their lifecycle status: awaiting_completion (pledged, work not verified yet), ready_to_pay (verified — pay link sent to payer), paid, canceled. Filter by task list or status.

Input parameters:

- `status` (string): Filter by status
- `task_list_id` (string): Filter by task list

### `tascan_get_worker_passport` (~73 tokens)

Get a worker's verified work passport — task counts, lists worked, photos submitted, GPS-verified hours, points, streaks, and earned merit badges, all computed from real completion data (not self-reported). Includes the shareable profile URL.

Input parameters:

- `worker_id` (string, required): Worker ID

### `tascan_server_info` (~58 tokens)

Identify exactly which TaScan server and schema this MCP session is talking to. Call this FIRST when diagnosing anything — it makes "dev server masquerading as production" and "is my fix deployed yet" one tool call instead of an inference.

### `tascan_find` (~93 tokens)

Cross-entity search: find projects, task lists, tasks, workers, or condition assets by name in one call — with ids and parent context to disambiguate. Use this instead of walking projects→lists→tasks or guessing ids from display names.

Input parameters:

- `query` (string, required): Search text (min 2 chars, case-insensitive substring)
- `type` (string): Optional: restrict to one entity type

### `tascan_get_worker` (~62 tokens)

Ungated, plain read of one worker row: name, contact, org, points, streaks, timestamps. (tascan_get_worker_passport is the rich stats view; this is the boring lookup.)

Input parameters:

- `worker_id` (string, required): Worker ID

### `tascan_find_duplicate_workers` (~145 tokens)

Find candidate same-person worker records with per-signal match detail (Patent 4 §6.25(b) signals: phone reuse, name similarity, GPS pattern correlation). Turns identity fragmentation from an accidental discovery into a monitorable metric, and feeds the merge workflow its candidate list.

Input parameters:

- `include_orphans` (boolean): Also consider org-less (orphan) worker records — off by default
- `name` (string): Or: search duplicates by display name
- `threshold` (number): Min confidence 0-1 (default 0.15)
- `worker_id` (string): Anchor worker to find duplicates OF (preferred — enables phone + GPS signals)

### `tascan_merge_workers` (~173 tokens)

Merge duplicate worker records into one canonical identity (Patent 4 identity consolidation). Reassigns every reference (completions, timer events, points, payments, rosters — 31 columns across 31 tables), backfills missing phone/email on the primary, sums points, and tombstones the duplicates (merged_into + is_active=false — NEVER hard-deletes). ALWAYS run with dry_run=true first and show Mike the counts; pass dry_run=false only after explicit confirmation.

Input parameters:

- `dry_run` (boolean): true (default) = report reassignment counts only, change nothing. false = execute atomically.
- `duplicate_worker_ids` (array, required): Worker IDs to fold into the primary (max 20)
- `primary_worker_id` (string, required): The canonical worker that survives (usually the one with a phone)

### `tascan_delete_worker` (~65 tokens)

Tombstone a worker record (is_active=false). REFUSES if the worker has any task/subtask completions or payments — merge those into the real worker with tascan_merge_workers instead. Never hard-deletes.

Input parameters:

- `worker_id` (string, required): Worker ID to delete

### `tascan_create_cycle` (~1130 tokens)

Start an unattended build-review-decide cycle (protocol v0.2). Queues T1 CODE: (or SHELL:) with your build_brief on the AI Inbox and T2 REVIEW: with your review_brief, born blocked on T1. The local executor builds, stores the exact bytes of artifact_paths as a bundle (build_ref = sha256 over the manifest), the independent reviewer reviews THAT bundle, an approve verdict mints a Decision task for the human authority (one SMS), Approve mints an Integrate task for the deploy id. Revise verdicts spawn revisions (cap max_revisions, default 3); reject, human Reject, scope violations or exhausted revisions PARK the cycle (a Parked task with Resume with notes / Close). REQUIRES agent:dispatch:code. Duplicate protection: the same idempotency_key, or the same briefs + paths, within 24 h returns the existing root instead of queueing again (created=false). Optional `reviews[]` attaches a multi-lens review panel (design item 14a) in place of the single OpenAI review — one review task mints per lens and every blocking lens must approve before the Decision task mints. Track with tascan_get_cycle_report (root_id). Nothing spawns a cycle on its own.

Input parameters:

- `artifact_paths` (array, required): Repo-relative paths the build binds (1-64). Exactly these files are stored as the bundle and hashed into build_ref; files the executor touches OUTSIDE them fail the scope check and park the cycle. No…
- `build_brief` (string, required): The executor prompt (1-40000 chars). Executed verbatim by the local Claude Code runner as a CODE:/SHELL: task — write it as a complete instruction, name the files, forbid nothing the runner already f…
- `checkpoint_description` (string): Optional description template for the Decision task; the build_ref, preview and findings summary are appended.
- `checkpoint_title` (string): Optional title template for the Decision task (default "Decision: <title>").
- `idempotency_key` (string): Optional caller key (≤ 200 chars). The same key within 24 h returns the existing cycle (created=false) instead of a duplicate dispatch.
- `integrate_description` (string): Optional description template for the Integrate task.
- `integrate_title` (string): Optional title template for the Integrate task (default "Integrate: <title>").
- `max_cost_micro_usd` (integer): Per-cycle spend cap summed over every attempt, in micro-USD (default 5000000 = USD 5). A claim that could overrun it is refused (budget_exhausted).
- `max_questions` (integer): Questions a runner may ask per task before the attempt fails (default 3).
- `max_revisions` (integer): Revision cap (default 3): at most max_revisions + 1 builds and reviews.
- `preview_url` (string): Optional https preview link shown on the Decision task.
- `project_id` (string, required): Working project (UUID). Its Decisions and Agent Questions lists are created on the first cycle (coord_ensure_lists). Requires the org human authority to be configured (coord_set_authority) — otherwis…
- `repo` (string): Which codebase on the executor the build runs in — an alias from the executor's allowlist (tascan-agent/repos.json), e.g. "tascan" (default), "merchskipper", "inkskipper", "rangerlizzy", "cardvault",…
- `review_brief` (string, required): The reviewer prompt (1-40000 chars). The reviewer reads the stored bundle (tascan_get_build / tascan_get_build_file), the task text and the filtered trail; it returns approve, revise, reject or needs…
- `reviews` (array): Optional multi-lens review panel (design item 14a) instead of today's single OpenAI review_brief lens — 1-8 entries, each: {lens: slug matching ^[a-z][a-z0-9-]{0,39}$ unique per array (e.g. "code-cor…
- `task_type` (string): T1 prefix (default CODE).
- `title` (string, required): Short human title (1-200 chars). T1 becomes "CODE: <title>", T2 "REVIEW: <title>".

### `tascan_post_message` (~460 tokens)

Post a message on a task trail (protocol v0.2 trail_messages): kind question, answer, handoff or discussion. A message never completes a task, never satisfies a gate and never pages anyone. The actor is stamped from your credential (key:<id>, actor_type "key" — a credential, never a human), never from the body; the executor and the reviewer consume a key's answers only when the key holds agent:dispatch. On an ordinary task this is write tier. On a CYCLE task (one with coord) it needs agent:dispatch (agent:dispatch:code when the task, or the asker a question task stands for, is CODE:/SHELL:) because the text can become executor prompt or reviewer input. kind=answer on a dispatcher-addressed question task answers it through coord_answer_question and releases the blocked asker; a human-addressed question is answered only on the worker page (403 here). finding (reviewer runner) and decision (human completion) cannot be posted. Body ≤ 8000 chars; idempotency_key makes a replay return the same message.

Input parameters:

- `addressee` (string): Optional, kind=question only: who the question is for (recorded; nobody is paged).
- `body` (string, required): The message text (1-8000 chars). Treated as DATA by every reader; on a cycle task it may be prepended to the executor prompt as TRAIL INPUT.
- `build_ref` (string): Optional sha256:<64 hex> the message is about (defaults to the cycle task's bound build).
- `idempotency_key` (string): Optional replay key (≤ 200 chars): the same key on the same task returns the same message id.
- `kind` (string, required): question = a question for the record (does not block anything); answer = answers a dispatcher question task and releases the asker; handoff = hand work or context to the next agent; discussion = a no…
- `reply_to` (string): Optional message id this replies to.
- `task_id` (string, required): Task ID (UUID). For an answer: the QUESTION task id (tascan_get_task on the asker shows coord.blocked_by).

### `tascan_get_build` (~181 tokens)

Manifest of a stored build bundle by build_ref (protocol v0.2 build_artifacts): the exact files the executor produced for the cycle's artifact_paths, each with sha256, byte length and whether text content is stored (binary or over-cap files keep the sha only). build_ref = sha256 over the manifest, computed in the database once; the reviewer reviews THESE bytes, the human approves THIS ref, the integrate task records THIS ref. Read tier. Use tascan_get_build_file to read a file. Truncated at 12000 chars. Reading the manifest is discovery, not a read of any file.

Input parameters:

- `build_ref` (string, required): sha256:<64 hex> (or the bare 64 hex) — from tascan_get_task (coord.build_ref / agent.runs[].build_ref) or tascan_get_cycle_report.

### `tascan_get_build_file` (~219 tokens)

Read one file from a stored build bundle by build_ref and path (protocol v0.2 build_artifacts) — the exact bytes the executor produced, not a working-tree read. Returns up to 12000 chars per call with offset/limit paging (next_offset when truncated), plus the file's sha256 and byte length. Binary or over-cap files return no content (the sha256 still binds them). Read tier; this is what the independent reviewer reads. The header lines (path, build, sha256, chars a-b of total) are the record a reviewer's read is bound to; read every chunk until the range covers the whole file.

Input parameters:

- `build_ref` (string, required): sha256:<64 hex> (or the bare 64 hex).
- `limit` (integer): Characters to return (1-12000, default 12000).
- `offset` (integer): Character offset to start from (default 0).
- `path` (string, required): Repo-relative path exactly as listed by tascan_get_build.

### `tascan_get_cycle_report` (~261 tokens)

The audit report of one coordination cycle by its root task id (protocol v0.2, get_cycle_report): every step task (build, review, checkpoint, integrate, question, parked) with its revision and state, every execution attempt with runner, outcome, build_ref and usage/cost, every completion (receipt id = completion id, receipt hash), every reviewer verdict, every human decision and answer, the full trail (messages), the ledger events and the hash-chain verdict per task, plus spend against the cap. A computed summary (stage, attempts, verdicts, decisions, receipts, spend, chains_ok) comes first; pass full=true for the complete JSON (large). Read tier. This is the ONLY per-cycle notification surface: cycle steps do not e-mail or text anyone except the one checkpoint / human-question SMS.

Input parameters:

- `full` (boolean): true = the complete report JSON (tasks, runs, completions, messages, events, bundles, chains) after the summary, capped at 12000 chars. Default: summary only.
- `root_id` (string, required): The cycle root = the T1 build task id (returned by tascan_create_cycle; a non-root cycle task returns its root_id in the error).

### `tascan_project_digest` (~111 tokens)

One call that gives a chat client (ChatGPT, Claude) a whole TaScan project in about 2,000 words: the project, every task list with task counts, open decisions and questions, the last 5 coordination cycles with verdicts and spend, the latest 5 receipts, and total spend — returned as Markdown (capped at 12,000 chars). Read tier. Use it before asking a human to paste anything.

Input parameters:

- `project_id` (string, required): Project ID (UUID).

## Diagnostics

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

## Score history

- 2026-09-20: 90
- 2026-09-19: 90
- 2026-09-18: 90
- 2026-09-17: 90
- 2026-09-16: 90
- 2026-09-15: 89
- 2026-09-14: 88
- 2026-09-13: 88
- 2026-09-12: 87
- 2026-09-11: 87
- 2026-09-10: 86
- 2026-09-09: 86
- 2026-09-08: 85
- 2026-09-07: 85
- 2026-09-06: 85
- 2026-09-05: 84
- 2026-09-04: 84
- 2026-09-03: 83
- 2026-09-02: 84
- 2026-09-01: 83
- 2026-08-31: 83
- 2026-08-30: 82
- 2026-08-29: 82
- 2026-08-28: 81
- 2026-08-27: 81
- 2026-08-26: 81
- 2026-08-25: 78
- 2026-08-24: 78
- 2026-08-23: 78
- 2026-08-22: 77

## Common questions

### What is the TaScan MCP server?

TaScan is an MCP server listed in the public MCP registry as io.github.snowbikemike/tascan-mcp. 36 MCP tools for projects, tasks, workers, QR/NFC tags, and AI remediation. Task. Scan. Done. This page covers its hosted endpoint (https://app.tascan.io/mcp).

### Is the TaScan MCP server safe to use?

TaScan scores 90 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the TaScan MCP server expose?

TaScan exposes 79 tools: tascan_list_projects, tascan_create_project, tascan_get_project, tascan_update_project, tascan_delete_project, and 74 more. Their descriptions and schemas cost roughly 12,174 tokens of context every time the server is loaded.

### Does the TaScan MCP server require authentication?

Yes. TaScan asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the TaScan MCP server still maintained?

TaScan is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://app.tascan.io/mcp
- Repository: https://github.com/snowbikemike/tascan-mcp
- Website: https://tascan.io/
- Changelog RSS feed: https://verifymcp.io/servers/snowbikemike-tascan-mcp/app.xml
- Changelog JSON feed: https://verifymcp.io/servers/snowbikemike-tascan-mcp/app.json
- HTML version of this page: https://verifymcp.io/servers/snowbikemike-tascan-mcp/app