# io.github.CCSTT-dev/callable (remote · getcallable.dev)

API for AI agents to delegate tasks to real humans.

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

## Components

- remote · `getcallable.dev`: 70/100 (this document), [markdown](https://verifymcp.io/servers/ccstt-dev-callable/api-mcp.md), [page](https://verifymcp.io/servers/ccstt-dev-callable/api-mcp)

## Channel facts

- Endpoint: `https://getcallable.dev/api/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**: 80/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - 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.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 66/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 644 tokens (~214/item across 3 items; 3 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**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 20/100
  - Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http ccstt-dev-callable https://getcallable.dev/api/mcp
```

### Codex

```toml
[mcp_servers.ccstt-dev-callable]
url = "https://getcallable.dev/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ccstt-dev-callable": {
      "type": "remote",
      "url": "https://getcallable.dev/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add ccstt-dev-callable --url https://getcallable.dev/api/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  ccstt-dev-callable:
    url: "https://getcallable.dev/api/mcp"
```

### Other

```json
{
  "mcpServers": {
    "ccstt-dev-callable": {
      "type": "http",
      "url": "https://getcallable.dev/api/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-02 (score 70, +1)

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

### 2026-07-31 (score 69, +4)

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

### 2026-07-30 (score 65, 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 65, +1)

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

### 2026-07-28 (score 64, +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 63, 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 63)

First indexed and scored.

## MCP tools (3)

### `submit_task` (~332 tokens)

Submit an account verification task to a real human operator. Use this when your agent is blocked on something only a real person can complete — a KYC check, a platform sign-in or 2FA prompt, a CAPTCHA, an identity confirmation, or any verification step that requires a human. The task is charged automatically via Stripe ($39). A vetted operator claims it, performs the verification on real hardware, and returns the result (with optional screenshot) to your callback_url or via get_task_status. Typical completion: 30 minutes.

Input parameters:

- `callback_url` (string): Webhook URL to receive a POST request with the task result when completed. Recommended for async agent workflows. If omitted, poll get_task_status instead.
- `deadline_minutes` (integer, required): Time in minutes the operator has to complete the verification after claiming it. Minimum 20. Recommended: 30.
- `instructions` (object, required): Structured input for account_verification. Required fields: platform (e.g. 'gmail', 'stripe'), url (where to perform the verification), credentials (login info or how to obtain the code), what_to_ver…
- `payment_credential` (object): Stripe Link Agent Wallet Single-use Payment Token (SPT) for fully autonomous agent payments with no human intervention required. Omit if the developer account has a saved card on file.
- `task_type` (string, required): account_verification — a real human verifies an account, KYC check, sign-in, or CAPTCHA on real hardware and returns structured proof ($39).

Output parameters:

- `estimated_completion` (string): Estimated completion time based on deadline_minutes
- `message` (string): Confirmation or error message
- `status` (string): Current task status
- `task_id` (string): Unique identifier for the submitted task

### `get_task_status` (~85 tokens)

Poll the status and retrieve the result of a previously submitted task. Returns the current status (pending, in_progress, pending_review, completed, disputed), the result payload, and any output URLs (video, screenshot). Use this in a polling loop after submit_task if no callback_url was provided.

Input parameters:

- `task_id` (string, required): The task ID returned when the task was submitted

Output parameters:

- `completed_at` (string): ISO timestamp of completion
- `operator` (string): Name of the operator who completed the task
- `output_url` (string): URL to download output file (video, screenshot, etc.)
- `result` (object): Task result payload when completed
- `status` (string)
- `task_id` (string)

### `review_task` (~179 tokens)

Optional. Approve or dispute a task that is in `pending_review` status. Use this after get_task_status reports the operator has completed the work. Approving releases the operator payout. Disputing requires a reason and a description of what is needed for acceptance; the operator is then allowed to resubmit. If you never call review_task, tasks are auto-approved after the review window expires.

Input parameters:

- `decision` (string, required): approve to accept the result and release payment; dispute to reject it and request a resubmission.
- `dispute_reason` (string): Required when decision = 'dispute'. What went wrong with the submission.
- `task_id` (string, required): The task ID returned by submit_task.
- `what_is_needed` (string): Required when decision = 'dispute'. What the operator must do for the submission to be accepted.

Output parameters:

- `status` (string)
- `success` (boolean)

## Diagnostics

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

## Score history

- 2026-08-03: 70
- 2026-08-02: 70
- 2026-08-01: 69
- 2026-07-31: 69
- 2026-07-30: 65
- 2026-07-29: 65
- 2026-07-28: 64
- 2026-07-27: 63
- 2026-07-26: 63

## Links

- Remote endpoint: https://getcallable.dev/api/mcp
- Repository: https://github.com/CCSTT-dev/callable-task-deck
- Changelog RSS feed: https://verifymcp.io/servers/ccstt-dev-callable/api-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/ccstt-dev-callable/api-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/ccstt-dev-callable/api-mcp