# 402cron [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://402cron.com/  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/402cron

## Description
Hosted scheduled HTTP delivery for AI agents. Create recurring UTC cron schedules and send HMAC-signed requests to verified HTTPS destinations via remote Streamable HTTP MCP (https://402cron.com/mcp) or REST. Prepaid x402 credits in USDC on Base; billed per delivery attempt. Management uses a bearer token. Docs: https://402cron.com/docs. Operated by 402cron Labs.

## Tools
Capabilities this server exposes over MCP:

- **get_pricing** — What a delivery costs, which packs exist, and the exact x402 payment requirements for each. Balance is counted in DELIVERIES, not money, and packs never expire. Call this before buying.
- **get_docs** — One section of the machine documentation: quickstart, headers, signature, notice, errors, billing or limits. Omit `section` to get the whole document.
- **get_service_status** — Whether the service is currently selling, on which network, and if not — why not. This is configuration, not liveness: the full health endpoint is at /health.
- **list_tasks** — Your tasks and their state. Needs your management token as an Authorization header on this connection.
- **get_task** — A single task: schedule, destination, state, next run, and how many failures in a row it carries.
- **create_task** — Register a schedule against a destination you have already verified. Idempotent on "name": the same name updates the existing task instead of creating a second one. Creating costs nothing; each delivery ATTEMPT costs one credit.
- **update_task** — Change the schedule, destination, method, timeout, headers or body of an existing task. Omit a field to leave it unchanged — sending null is refused, because "unchanged" and "cleared" must not look the same. State is NOT editable here: use pause_task and resume_task.
- **pause_task** — Stop firing until you resume. Nothing is charged while a task is paused.
- **resume_task** — Start firing again on the schedule. Refused if your balance is empty — buy deliveries first.
- **run_task_now** — Deliver immediately, outside the schedule. THIS COSTS ONE CREDIT per attempt, exactly like a scheduled firing, and a timeout or unreachable host is retried up to three times — so one call can cost up to three credits. Use it to test a destination.
- **delete_task** — Move the task to the recycle bin. It stops firing immediately and can be restored for 30 days with restore_task; after that it is unrecoverable. Credits already spent are not refunded.
- **restore_task** — Bring a task back from the recycle bin within 30 days. It comes back PAUSED — resume it explicitly.
- **register_destination** — Claim an https:// URL you control. We answer with a challenge and a SIGNING SECRET that is shown ONCE and never again — store it before you do anything else; it is what lets you verify that a delivery really came from us. The permission covers that path and everything beneath it, nothing above. Verification is one request from us to the exact URL you registered: POST, headers X-402cron-Challenge: <value> and X-402cron-Event: verify, JSON body {"challenge":"<value>"}. Reply within 5 seconds, without a redirect, with a body that is the bare value or {"challenge":"<value>"}; we read the first 512 bytes and do not check the HTTP status (2xx is fine). Then call POST /api/destinations/{id}/verify within 15 minutes of registering. A fixed-response webhook cannot pass: you need an endpoint you can program. Registering a URL that is still pending issues a new challenge and a new signing secret every time — the old secret immediately stops verifying deliveries; a verified URL is left untouched unless you add ?rotate=1. The daily verification allowance (10 per destination, 40 per client, UTC day) does not reset on re-registration.
- **verify_destination** — Verification is one request from us to the exact URL you registered: POST, headers X-402cron-Challenge: <value> and X-402cron-Event: verify, JSON body {"challenge":"<value>"}. Reply within 5 seconds, without a redirect, with a body that is the bare value or {"challenge":"<value>"}; we read the first 512 bytes and do not check the HTTP status (2xx is fine). Then call POST /api/destinations/{id}/verify within 15 minutes of registering. A fixed-response webhook cannot pass: you need an endpoint you can program. Registering a URL that is still pending issues a new challenge and a new signing secret every time — the old secret immediately stops verifying deliveries; a verified URL is left untouched unless you add ?rotate=1. The daily verification allowance (10 per destination, 40 per client, UTC day) does not reset on re-registration. Until this passes, no task may point at the destination.
- **list_destinations** — The URLs you have claimed and whether each is verified. The signing secrets are never shown again.
- **delete_destination** — Remove a claimed URL. Refused while a task still points at it — delete the task first.

## Claude Desktop Quick Installation
Remote MCP endpoint (confidence: high). Install path detected from listing signals. Add as a URL/SSE server in your client:

```json
"mcpServers": {
  "402cron": {
    "url": "https://402cron.com/mcp"
  }
}
```

## Documentation

## What 402cron does

The 402cron MCP server lets AI agents create and manage recurring HTTP delivery tasks. Each task associates a UTC cron schedule with a verified HTTPS destination, then sends requests when the schedule fires. Requests include an HMAC signature so the receiving application can check that the delivery came from 402cron.

The service is hosted and accessed remotely through Streamable HTTP at `https://402cron.com/mcp`. It also provides a REST interface. Management operations use a bearer token, while delivery usage is paid with prepaid x402 credits in USDC on Base. Credits are measured in delivery attempts rather than monetary units, and purchased packs do not expire.

## How it works

Before creating a task, claim the destination URL and complete verification. Registration sends a challenge and reveals a signing secret once. The receiving endpoint must answer the verification request within five seconds, without redirecting, and the verification API call must follow within 15 minutes. A destination grants access to its registered path and everything below that path, but not to a parent path.

After verification, create a task with a name, schedule, destination, and delivery settings. Names are idempotent: creating a task with an existing name updates that task instead of making a duplicate. Scheduled delivery attempts consume credits. An immediate test through `run_task_now` also costs one credit per attempt and may consume up to three credits when retries are needed.

## Setup and configuration

Connect an MCP client to the remote endpoint and provide the management bearer token as the connection's Authorization header where required. Use `get_pricing` before purchasing credits to inspect available packs and the exact x402 payment requirements. `get_service_status` reports whether sales are enabled and which network is configured; it is not the service health check.

The receiving endpoint must be programmable. During verification, it receives a POST containing the challenge in both a header and JSON body. It must return either the bare challenge or an object containing that value in the response body. Fixed-response webhook services cannot complete this process.

## Tools and capabilities

The 402cron MCP server provides tools for the complete task lifecycle:

- Inspect pricing, documentation sections, service configuration, tasks, individual task state, and claimed destinations.
- Register, verify, list, and delete HTTPS destinations.
- Create, update, pause, resume, run immediately, delete, and restore scheduled tasks.
- Change a task's schedule, destination, method, timeout, headers, or body with `update_task`.
- Restore deleted tasks for up to 30 days; restored tasks return paused and require an explicit resume.

Task creation is free, but each delivery attempt is billed. Pausing a task stops firing and does not consume credits.

## Limitations and notes

A destination cannot be removed while a task still references it. Deleting a task stops delivery immediately and moves it to a recycle bin; after 30 days it cannot be recovered, and spent credits are not refunded.

Registering a pending destination again creates a new challenge and signing secret, invalidating the old secret. Verified destinations remain unchanged unless rotation is explicitly requested. Verification is limited to 10 attempts per destination and 40 per client per UTC day, and re-registration does not reset those allowances.

The signing secret is shown only during registration. Store it before continuing, because the service does not display it again. A task cannot point to an unverified destination, and `resume_task` is refused when the credit balance is empty.

_Full upstream README: https://allmcps.com/mcp/402cron/readme_