Codex MCP guide

Test webhooks with Codex.

Register the remote Streamable HTTP endpoint in Codex, then use its tools to exercise and diagnose webhook flows from the repository you are changing.

Create → send → verify

Start with a sample webhook

Connect your assistant, send a sample event, and inspect what arrived. Free. No account or API key.

1. Connect your assistant

Run in your terminal

codex mcp add webhooktest --url https://webhooktest.net/mcp

Start a new Codex session and use /mcp to check that webhooktest is available.

Check that your assistant can discover the WebhookTest tools before continuing. Copying the configuration does not verify a connection.

2. Ask your assistant to run the test

Starter prompt

Use WebhookTest to create a temporary bucket named "My first AI webhook test". Show me its webhook_endpoint and dashboard_url, and keep the returned bucket ID for the next steps.

If you can execute HTTP requests, POST this JSON to that exact webhook_endpoint with Content-Type: application/json:
{"event":"hello.webhook","message":"My first AI webhook test"}

Otherwise, give me a copyable command for my operating system to send it, and pause until I confirm. WebhookTest's MCP tools inspect requests; they do not send the POST for you.

After sending, use wait_for_webhook or list_webhooks followed by get_webhook to retrieve the actual captured request. Verify that its method is POST and both JSON fields match. Show the captured values and dashboard link. Only report "Test passed" if the capture matches; a successful send or received:false is not proof. If nothing arrived, help me check the endpoint and send again.

No terminal access in your assistant? The prompt asks it for a command you can run yourself, then waits for your confirmation.

3. Verify the captured request

Example result — your assistant should produce this only after inspecting a matching capture.

✓ Endpoint created
✓ Webhook captured
✓ Method: POST
✓ event: hello.webhook
✓ message: My first AI webhook test

Test passed — the captured payload matches what was sent.

Next: point your own integration at the endpoint and ask your assistant to compare its payload with what you expected.

Setup and test workflow

01

Register the remote server

Run the Codex CLI command in the quick start above. The --url option selects Streamable HTTP; no bearer token is needed.

02

Verify the connection

Run codex mcp list, start a new Codex session, and confirm webhooktest tools are available. If a managed policy controls MCP servers, an administrator may need to allow the exact URL.

03

Ask for an end-to-end check

Have Codex create a bucket, update the local integration to use its endpoint, run the trigger, then wait for and inspect the capture. Keep unrelated production data out of the request.

04

Use confirmation for cleanup

When the test passes, ask Codex to clear captures or delete the bucket. The destructive tools require confirm:true and advertise destructive annotations to clients.

What the server exposes

Create and understand

`create_webhook_bucket` creates a temporary endpoint; `get_webhook_bucket` reads its name and response settings.

Observe deliveries

`wait_for_webhook` waits up to 25 seconds; `list_webhooks` paginates summaries; `get_webhook` returns one scoped capture.

Control and clean up

`configure_webhook_response` changes the reply. `clear_webhooks` and `delete_webhook_bucket` require explicit confirmation.

Privacy and limits

Retention policy update — effective October 8, 2026 at 22:00 UTC. Individual requests older than 15 days will be deleted, even in active buckets, including requests already stored. The existing 15-day bucket inactivity rule and per-bucket ceilings of 10,000 requests or 50 MiB remain unchanged. Cleanup is periodic, not deletion at an exact second. Retention details

Authorization, cookie, API-key, token, secret, password, and signature-like header or query values are redacted by default. Agents must explicitly request sensitive values. Bodies are limited to 64 KiB in tool output by default and can be raised only to 256 KiB. Use synthetic data: the endpoint is a debugging service, not a production processor.

Troubleshooting

  • Use the exact HTTPS URL and select remote or Streamable HTTP transport.
  • Restart or reload the client after changing MCP configuration.
  • Check that corporate policy allows the endpoint and outbound HTTPS.
  • A timeout with received:false is successful; verify the sender used the returned bucket URL.
  • HTTP 429 means the per-IP call, creation, bucket, or concurrent-wait limit was reached.

Client guides

MCP workflowClaudeCursorCodex