Who answers a user who is stuck inside Claude?

A person on the vendor's team, from a normal inbox. The agent first tries support_ask, which answers from rules the vendor wrote in code. If the rules do not cover it, support_open_ticket hands it to the team.

Where does the ticket land?

In the vendor's canhelpto workspace inbox, next to tickets from the web widget, email and WhatsApp. The vendor's team can also work that inbox from Claude through the canhelpto MCP server.

How does the user get the answer?

By email, and in the conversation: the agent calls support_ticket_status and reads the team's public reply. Internal notes are never returned.

What does the team see about the failed call?

The account, the client user-agent, the connector catalogue version and the last tool calls with their errors. The connector server records these; the user does not have to describe them.

Support for a Claude connector

A vendor with a Claude connector needs three things for support: a tool the agent can call when something fails, a ticket that lands in a human inbox with the failed call already attached, and a reply that comes back to the user in the same conversation. Without them, a user whose tool call fails has nobody to ask. They leave, and you never see the error.

Who answers

Two layers. First, the agent calls support_ask. It answers from rules you wrote in code (credits, connection, permissions, rate limits) and makes no model call. If no rule matches, it says so and points at the ticket. It never invents an answer. Second, support_open_ticket sends the question to a person on your team.

Where tickets land

In your canhelpto workspace inbox, with the tickets from your web widget, email and WhatsApp. The ticket holds the user's words first. Under them is the context your server attached: account, client, catalogue version and the last calls with their errors. Your team can read and answer the inbox from Claude too, through https://canhelpto.com/api/mcp.

The failed call

Your connector server sees every tool call and its error. Keep the last dozen per account in memory and attach them when a ticket opens. The user then writes one sentence and your team sees the exact failure. This is the part a normal help desk cannot do, because it sits outside your server.

// One call from inside your connector. The server adds the failed call; the user does not.
await fetch("https://canhelpto.com/api/v1/tickets", {
  method: "POST",
  headers: { "X-API-Key": process.env.CANHELPTO_API_KEY!, "X-Service-Mode": "true", "Content-Type": "application/json" },
  body: JSON.stringify({
    summary: "approve_drafts fails with FORBIDDEN",
    message: "Claude cannot approve my drafts.\n\nLast calls:\n- 16:05:00 approve_drafts · 120 ms · FORBIDDEN",
    customerName: "Ana Pop",            // example customer
    customerEmail: "[email protected]",
    tags: ["mcp", "claude-connector"],
    page: "mcp://your-server",
    metadata: { mcp: { account: { userId: "7f3e…" }, recentCalls: [] } },
  }),
});

The answer comes back

The team replies from the inbox. The reply goes out by email. The agent can also read it with support_ticket_status, which checks that the ticket belongs to the caller and leaves internal notes out.

Questions

Who answers a user who is stuck inside Claude?: A person on the vendor's team, from a normal inbox. The agent first tries support_ask, which answers from rules the vendor wrote in code. If the rules do not cover it, support_open_ticket hands it to the team.
Where does the ticket land?: In the vendor's canhelpto workspace inbox, next to tickets from the web widget, email and WhatsApp. The vendor's team can also work that inbox from Claude through the canhelpto MCP server.
How does the user get the answer?: By email, and in the conversation: the agent calls support_ticket_status and reads the team's public reply. Internal notes are never returned.
What does the team see about the failed call?: The account, the client user-agent, the connector catalogue version and the last tool calls with their errors. The connector server records these; the user does not have to describe them.

Next: the full contract and the TypeScript wrapper are in Docs for agents. Plans are on Pricing.