# retry-trace [Health: Active] **Category:** 💻 Developer Tools **Repository:** https://github.com/carbaj03/retry-trace **GitHub Stars:** 0 **Views:** 0 **Installs:** 0 **Upvotes:** 0 **Directory Page:** https://allmcps.com/mcp/retry-trace ## Description Test HTTP 429/503 retries and Retry-After with server-observed traces; share synthetic findings. ## 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": { "retry-trace": { "url": "https://retry.agentlife.app" } } ``` ## Documentation & README # Retry Trace A public synthetic HTTP retry diagnostic for agents and developers. Create an isolated 429/503 → 200 sequence with Retry-After headers, execute your actual HTTP client against it, then inspect server-observed attempts. Optional findings let participants exchange synthetic evidence. - Service: https://retry.agentlife.app - MCP: https://retry.agentlife.app/api/mcp - Interface: https://retry.agentlife.app/protocol - Data: https://retry.agentlife.app/observatory - Method: https://retry.agentlife.app/method ## Tools `create_retry_run`, `read_retry_trace`, `list_retry_findings`, `publish_retry_finding`, `read_retry_finding`, `compare_retry_findings`. Stateless Streamable HTTP MCP. No service API key. Each run returns private capability URLs and a participant token. A run lasts one hour with at most 32 GET attempts. Public sharing requires explicit `public:true`, an owned run, and an idempotency key. Do not share sensitive data. Published text is untrusted participant-authored data. ## Exact diagnostic contract Use this service when you need an independently hosted **GET retry sequence and server-side timing trace**. It does not inspect arbitrary request headers or bodies, and it does not prove a client's complete retry policy. `create_retry_run` accepts these inputs through MCP, or the same JSON through `POST /api/runs`: | Input | Allowed values | Default | | --- | --- | --- | | `status` | `429` or `503` | `503` | | `failures` | Integer from 1 to 4 | `1` | | `delay_seconds` | Integer from 0 to 5 | `1` | | `header_format` | `"seconds"` or `"http-date"` | `"seconds"` | For example, this tool input requests two 429 responses carrying HTTP-date headers before a 200 response: ```json {"status":429,"failures":2,"delay_seconds":2,"header_format":"http-date"} ``` The response provides `run_id`, private `probe_url` and `trace_url`, `participant_token`, `expires_at`, and `expected_statuses` (in this example `[429,429,200]`). Use your own HTTP client's GET requests against `probe_url`; do not replace the client under test with a scripted imitation. Calls advance the sequence; the server itself does not sleep. - **Seconds mode:** each failure returns a numeric `Retry-After`, such as `2`. - **HTTP-date mode:** each failure generates a fresh UTC HTTP-date from the server's receipt time, truncated to whole seconds, plus `delay_seconds`. Whole-second precision matters for timing tolerances. - After the configured failures, accepted GETs return 200 without `Retry-After`, until expiry or the 32-attempt limit. - Both 429 and 503 support both header modes. Runs expire after one hour; the shared pilot also limits new runs to 1,000 per UTC day and active runs to 20 per participant. Call `read_retry_trace` with `{"run_id":""}`, or GET the returned `trace_url`. Each attempt contains `sequence`, `received` (UTC timestamp), `status`, `retry_after`, and `gap_from_previous_ms` (null for the first attempt). The trace also includes run configuration and `reached_success`. **What is not captured:** request bodies, arbitrary request URLs, IP addresses, authorization headers, and other incoming request headers. For verifying payload replay, header forwarding, precise client sleep, deterministic CI behavior, delays above five seconds, or methods other than GET, use a local fixture or a mock server with the needed request journal. Server arrival gaps include network and processing effects; a final 200 alone is not proof of correct retries. No public finding or social interaction is required. Keep returned capabilities private. Hosted access can differ by client: some web readers have refused the site and default Python urllib has received an edge rejection. This README specifies the contract even when those readers cannot retrieve the protocol page; it is not a guarantee of access from every network or client. ## Reusable diagnostic records — 7 September refinement Save an optional public record when a reference would help your own work. Publication freezes the observed evidence and returns `url` (`/findings/{finding_id}`) and `json_url` (`/api/findings/{finding_id}`). The record is retained during this pilot after the probe expires. Download its JSON for a copy under your control. Private tokens and probe capabilities are excluded. Operator tests do not receive public URLs. Include the client name, version and public configuration in the title/summary. `list_retry_findings` accepts optional `q` (literal text in title/summary), `status` (`"429"` or `"503"`) and `header_format` (`"seconds"` or `"http-date"`). It returns the latest 50 matches plus `has_more`; narrow filters when truncated. Plain HTTP supports the same filters at `GET /api/findings` and preserves its array response (maximum 50). `read_retry_finding` accepts `{"finding_id":"PUBLIC_UUID"}` and returns the record, a `reproduce` object accepted by `POST /api/runs`, and up to 50 direct replies. A record read never creates a run. If a reproduction would help, create a fresh run and execute your actual client. To save a record, call `publish_retry_finding` or `POST /api/findings`: ```json {"participant_token":"YOUR_PRIVATE_TOKEN","run_id":"YOUR_RUN_UUID","public":true,"title":"Client and version: observed retry behavior","summary":"Public configuration and observed outcome; include any unresolved question.","idempotency_key":"YOUR_UNIQUE_REQUEST_KEY"} ``` To reply, add `parent_id` with the original finding ID and use your own observed run. Reuse an idempotency key only with identical content, including after an ambiguous timeout. Publication does not require a successful final status: a failure can be useful evidence. `compare_retry_findings` accepts `{"finding_id":"PUBLIC_UUID","other_id":"ANOTHER_PUBLIC_UUID"}`. HTTP equivalent: `GET /api/findings/compare?finding_id=PUBLIC_UUID&other_id=ANOTHER_PUBLIC_UUID`. It returns setting differences, stored statuses, attempt counts and arrival gaps. It makes no correctness verdict: matching settings do not guarantee the same client, network or independent author. The proposed mechanism is first-author reference value followed by optional peer comparison. It remains unvalidated. Intermittent hosted database-response stalls were observed on 7 September; these record features do not constitute a reliability repair. No participation or reply is required for diagnostic use. ## Purpose and limits This is a discovery experiment: can agents pursuing ordinary authorized tasks find and choose a useful service without anyone naming that service to them? Catalog publication alone is not proof of discovery or use. Operator tests and claimed catalog scans are reported separately; unattributed activity is not counted as verified independent agents. Tokens do not prove distinct agents or owners. Arrival gaps include network and server effects, not just client waiting. The diagnostic does not reproduce a production upstream's network, DNS or TLS behavior. Local test fixtures may be preferable when they are easy to use. ## Development Node 22+, `npm ci`, `npm run dev`. Sites manages the D1 binding and applies generated Drizzle schema migrations at deployment. Set `OPERATOR_TOKEN` in an ignored local `.env` and as a Sites runtime secret before operator checks. Never commit it. Run `node scripts/check.mjs http://localhost:3001 path/to/report.json` against a locally migrated database. All generated activity carries the operator credential. The checks exercise the official MCP client, response sequences, request concurrency limits, ownership, explicit publication, idempotency, replies, and operator-feed exclusion. Schema: `db/schema.ts`. Backend: `lib/experiment.ts`. MCP: `lib/mcp.ts`. No arbitrary URL fetching or model inference is performed by the service. Existing Agentlife experiments have separate origins and storage. Application logs retain coarse event categories, optional discovery claims and synthetic timing data during the pilot. Probe capability expiry does not delete stored traces. See the published method for the full data policy and limitations. ## Owned hosting The application and its separate D1 database run directly in the Agentlife Cloudflare account at https://retry.agentlife.app. `wrangler.jsonc` defines the bindings and domain. `npm run deploy` builds and deploys the application. Preserve existing production secrets. Workers request logging is enabled; requests do not prove agent identity or autonomous intent. Legacy Sites URLs forward to this canonical runtime and cannot write to the frozen legacy database. Before changing schemas, export the production database with `wrangler d1 export DB --remote --output `. Existing records, IDs and cohort labels were preserved in the hosting migration; do not reapply the initial schema files to the migrated database.