Svix MCP by usefulapi

它能帮你做什么

我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。

• 连接方式: 在云端运行
• 传输方式: Streamable HTTP
• 分类: 其他

安装

选择你使用的 AI 应用，然后复制设置。

你需要

• 在云端运行无需安装任何东西，通过互联网连接

你用的是哪个应用？

https://svix.usefulapi.io/mcp

claude mcp add --transport http svix https://svix.usefulapi.io/mcp

{
  "mcpServers": {
    "svix": {
      "url": "https://svix.usefulapi.io/mcp"
    }
  }
}

{
  "servers": {
    "svix": {
      "type": "http",
      "url": "https://svix.usefulapi.io/mcp"
    }
  }
}

https://svix.usefulapi.io/mcp

你的选择通过 Cookie 保存在这台设备上，无需账户。

这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同，请以 README 为准。

它能做什么

工具名称和描述与服务器在 2026年11月6日 报告的完全一致。这些内容由作者撰写，不是我们写的；我们以纯文本形式显示。

• svix_list_applications

  List the applications (your tenants/customers) in the Svix environment. Svix REST: GET /api/v1/app.

• svix_get_application

  Fetch a single application by its Svix id or your own uid. Svix REST: GET /api/v1/app/{app_id}.

• svix_list_endpoints

  List the webhook endpoints registered for one application. Svix REST: GET /api/v1/app/{app_id}/endpoint.

• svix_get_endpoint

  Fetch a single webhook endpoint, including its URL, subscribed event types and channels. Svix REST: GET /api/v1/app/{app_id}/endpoint/{endpoint_id}.

• svix_get_endpoint_stats

  Read delivery statistics for one endpoint — counts of success, pending, sending and fail. The fastest way to see whether an endpoint is healthy. Svix REST: GET /api/v1/app/{app_id}/endpoint/{endpoint_id}/stats.

• svix_list_messages

  List the webhook messages sent for one application, newest first. Filter by event type, channel, tag or time window. Svix REST: GET /api/v1/app/{app_id}/msg.

• svix_get_message

  Fetch a single message, including its event type and payload. Svix REST: GET /api/v1/app/{app_id}/msg/{msg_id}.

• svix_list_attempts_by_message

  List every delivery attempt Svix made for one message, across endpoints — status, response code and body. This is the tool for answering 'why did this webhook not arrive?'. Svix REST: GET /api/v1/app/{app_id}/attempt/msg/{msg_id}.

• svix_list_attempts_by_endpoint

  List delivery attempts against one endpoint, newest first. Filter by status to find the failures. Svix REST: GET /api/v1/app/{app_id}/attempt/endpoint/{endpoint_id}.

• svix_list_endpoint_messages

  List the messages destined for one endpoint, with each message's delivery status. Svix REST: GET /api/v1/app/{app_id}/endpoint/{endpoint_id}/msg.

• svix_list_event_types

  List the event types defined in the environment — the catalogue endpoints can subscribe to. Svix REST: GET /api/v1/event-type.

• svix_get_event_type

  Fetch a single event type by name, including its description and JSON schema. Svix REST: GET /api/v1/event-type/{event_type_name}.

• svix_list_background_tasks

  List Svix background tasks (bulk replays, expunges, imports) with their status. Use it to follow up a recover or replay. Svix REST: GET /api/v1/background-task.

• svix_health

  Check that the Svix API is reachable and the API key works. Returns 200 with an empty body when healthy. Svix REST: GET /api/v1/health.

• svix_create_application

  Create a new application (one tenant/customer of yours) in the Svix environment. Svix REST: POST /api/v1/app.

• svix_create_endpoint

  Register a webhook endpoint URL for one application, optionally scoped to specific event types and channels. Svix REST: POST /api/v1/app/{app_id}/endpoint.

• svix_send_message

  Send a webhook message to every endpoint of an application subscribed to the event type. This delivers real traffic to your customers' URLs. Svix REST: POST /api/v1/app/{app_id}/msg.

• svix_resend_message

  Queue one message for redelivery to one endpoint. The usual fix after a customer's endpoint was down. Svix REST: POST /api/v1/app/{app_id}/msg/{msg_id}/endpoint/{endpoint_id}/resend.

• svix_recover_endpoint

  Replay every failed message for one endpoint since a timestamp. Runs as a background task — follow it with svix_list_background_tasks. Svix REST: POST /api/v1/app/{app_id}/endpoint/{endpoint_id}/recover.

基础检查i

我们检查的是任何人都能看到的信息；我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日

• ✓ 通过

  作者与仓库一致

  注册名称已通过域名 usefulapi.io 验证（注册中心会核实域名所有权）

• … 尚未检查

  仍在维护

  我们还没有从 GitHub 读取这个仓库

• … 尚未检查

  有许可证

  我们还没有从 GitHub 读取这个仓库

• ✓ 通过

  端点有响应

  在 9 毫秒内响应（HTTP 200）

• – 不适用

  使用 OAuth 登录

  无需登录

• ✓ 通过

  工具描述中没有隐藏指令

  已读取 19 个工具描述，未发现针对 AI 的隐藏指令

与“其他”中的其他服务器比较i

• 星标数多于此分类中其他 32464 个服务器的 0%
• 发布到注册中心的时间比此分类中其他 32464 个服务器的 96% 更新
• 基础检查结果等于或优于此分类中其他 32464 个服务器的 100%

与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时，星标数才计入。

替代选择

同一分类中其他作者的服务器，按星标数排序。

如何看卡片：★ GitHub 星标i三大支柱：评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i

作者的 README

{