Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/io-github-ringer-warp/issues.md or /mcp/io-github-ringer-warp/issues.json, or Pod over MCP.

Reported issues for io.github.Ringer/warp

Pod holds 7 of 7 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to io.github.Ringer/warp.

Most discussed

Align port_set_group_details schema with WARP carrier-details contract

WARP contract

PUT /v1/porting/requests/{id}/groups/{spid}/details now validates the complete carrier-details payload before any TNIQ writes. The shipped warp-mcp@1.0.2 tool port_set_group_details declares only id and spid required and describes service_address as unconstrained free text.

The customer endpoint requires:

Read the thread · 2026-08-12 · open · outside contributor · 0 comments

Replace inert port_validate_request lifecycle step with port_revalidate_tns

WARP contract change

WARP's POST /v1/porting/requests/{id}/validate is now a deprecated compatibility acknowledgement. TN upload already queues validation, and proxying a second call to TNIQ's legacy project validator can race the first job and clear WARP's auto-assigned LRN (Ringer/ringer-tniq#476).

The shipped warp-mcp@1.0.2 still:

Read the thread · 2026-08-12 · open · outside contributor · 0 comments

msg_update_campaign is missing the "full replace, supply the complete object" warning that msg_update_brand has

Summary

Both msg_update_brand and msg_update_campaign are PUT (full-replace) operations sharing the same underlying pattern, but only one of them documents that clearly.

msg_update_brand's description:

"Full replace (PUT) of one of your 10DLC brands — supply the complete brand object, not just changed fields."

msg_update_campaign's description:

"Update (PUT) one of your 10DLC campaigns — e.g. fix sample messages or opt-in flow after a carrier rejection, then resubmit with msg_r

Read the thread · 2026-07-21 · open · external user · 0 comments

Missing tool for GET /v1/numbers/pricing — no way to check effective monthly rate before ordering

Summary

GET /v1/numbers/pricing exists in the customer-facing OpenAPI spec (tagged Customer/Numbers, same group as num_search/num_order) but has no corresponding warp-mcp tool. Confirmed the underlying API itself works fine — the gap is purely on the tool side.

Confirmed via direct API call

GET /v1/numbers/pricing
→ 200 {"did":{"sku_code":"DID-LOCAL-MONTHLY","monthly_rate":0.5},"tfn":{"sku_code":"DID-TOLLFREE-MONTHLY","monthly_rate":2}}

This returns the customer's own e

Read the thread · 2026-07-21 · open · external user · 0 comments

trunk_add_ip_acl sends wrong field name — "ip" instead of the API's required "ip_address"

Summary

trunk_add_ip_acl always fails with INVALID_PAYLOAD regardless of input, because the tool builds its request body with the wrong field name.

Root cause (confirmed in source)

src/tools/trunks.ts, trunk_add_ip_acl:

async ({ trunk_id, ip, netmask, description, enabled }) =>
  formatResponse(
    await client.post(`/v1/trunks/${trunk_id}/ips`, {
      ip,
      netmask,
      description,
      enabled,
    })
  )

The actual API schema (AddTrunkIPRequest in the O

Read the thread · 2026-07-17 · open · external user · 0 comments

Remove cdr_get_dashboard_stats — backing endpoint /v1/dashboard/stats deleted (now 404)

Summary

The api-gateway endpoint GET /v1/dashboard/stats has been removed (ringer-warp b6984957, deployed to prod). The MCP tool cdr_get_dashboard_stats calls that endpoint and now returns 404. Please remove/deprecate the tool.

Why the endpoint was removed

/v1/dashboard/stats returned platform-shaped rollup counts (total/active customers, active vendor count, customer-growth) that:

Read the thread · 2026-07-17 · open · outside contributor · 0 comments

team_/key_ tools require undeclared customer_id param — inconsistent with every other "list mine" tool

Summary

team_list_members, team_list_roles, key_list, and key_get_audit_all all throw a validation error demanding customer_id when called with no arguments — but nothing in the tool contract signals that this parameter is actually mandatory, and no other "list mine" tool in this server behaves this way.

Found during a live customer-behavior verification pass against a test WARP account (2026-07-15), run through the MCP tools themselves (not the raw REST API).

Repro

team_

[Read the thread](https://github.com/Ringer/warp-mcp/issues/1) · 2026-07-15 · open · external user · 0 comments

## Most recent

The remaining reports are on [the project's issue tracker](https://github.com/Ringer/warp-mcp/issues).