Your support agent is now an MCP server (and why that matters)

We shipped something this week that sounds like a footnote and isn't: your Asks support agent is now a remote MCP server. Any AI client that speaks the Model Context Protocol — Claude, Cursor, ChatGPT's connectors, your own scripts — can now call your support brain as a tool, with one endpoint and an API key.

Concretely: a developer using your API can ask their coding assistant a question about your product, and the assistant queries your grounded support agent directly — no browser tab, no widget, no copy-pasting docs. Your support knowledge stops being a destination and becomes infrastructure.

This is a dev-flavored post about why we built it and how it works. If you want the business-side view of support automation first, start with the customer service automation overview and come back.

MCP in sixty seconds

The Model Context Protocol is an open standard for connecting AI clients to external tools and data. Anthropic released it in late 2024; since then it's been adopted well beyond Claude — Cursor, ChatGPT, and a long tail of agent frameworks all speak it. The standard analogy is "USB-C for AI"; I'll spare you the extended version.

The mechanics are simple: JSON-RPC. A client calls initialize to handshake, tools/list to discover what the server offers, and tools/call to invoke a tool with arguments. The server returns results the model can read. That's essentially the whole protocol for our purposes — the point isn't sophistication, it's that everyone agreed on it, which is the rare and valuable part.

Until now, MCP servers have mostly wrapped databases, file systems, and SaaS APIs. We think support agents belong on that list.

What we shipped

Your Asks workspace agent — the one trained on your website, docs, and policies, with hybrid retrieval and a groundedness gate — is now callable at:

POST https://api.asks.app/v1/mcp
Authorization: Bearer ask_live_...

It implements the minimal MCP server surface (initialize, tools/list, tools/call, ping) over plain HTTP, and exposes up to two tools:

• send_message — ask the agent a question, get back the same grounded, citation-backed answer a customer would get in the widget. You can rename this tool per workspace (e.g. ask_acme_support) and write its description yourself, which matters more than it sounds: the tool name and description are what other models read when deciding whether to call you.
• search_knowledge (optional, off by default) — raw retrieval over your knowledge base, for clients that want source passages rather than a synthesized answer.

Authentication is an ask_-prefixed API key, and the workspace is derived only from the key — the tool schemas have no tenant field, so there's no way for a confused client to query someone else's workspace. Point Claude Code at it and it looks like this:

{
  "mcpServers": {
    "acme-support": {
      "type": "http",
      "url": "https://api.asks.app/v1/mcp",
      "headers": { "Authorization": "Bearer ask_live_..." }
    }
  }
}

Same shape in Cursor, Claude Desktop, or anything else with remote MCP support.

Why this direction matters

The honest version of the pitch has three parts.

Your support knowledge becomes infrastructure. If you've done the work — curated your docs, taught the agent your policies, closed the knowledge gaps — you've built something genuinely valuable: a machine that gives correct, grounded answers about your business. Locking that machine inside a chat bubble on one website is a waste. As an MCP server, the same brain answers in your customers' IDEs, your team's internal Claude workspace, your partner integrations — anywhere an AI client runs.

Support happens where the user already is. The support interaction of the last decade was "go to the website, find the widget, type." The one emerging now is "ask your assistant, and your assistant asks around." A developer hitting a confusing 422 from your API doesn't want to context-switch to your help center; their coding agent can call ask_acme_support mid-session and keep working. When your users' AI can query your support agent directly, the distance between "confused" and "answered" drops to one tool call.

Agents calling agents is coming either way. More of your customers arrive with an AI intermediary every month. You can either be machine-readable when their agents come asking, or be the business whose answers get hallucinated from a stale training-set crawl of your marketing site. An MCP endpoint is how you opt into being the source of truth. (Why grounding beats letting models guess is a whole post of its own — here it is.)

It goes both ways

The exposed server is half the story. Asks agents can also consume external MCP servers as tools — plug in an MCP server for your internal order system, your booking platform, your feature-flag service, and the support agent can call it mid-conversation to answer questions your docs alone can't. Plans include 1, 3, or 10 connected servers, alongside custom HTTP actions for APIs that don't speak MCP.

So the full picture is bidirectional: your agent calls out to your systems to resolve customer questions, and outside AI calls in to your agent to get answers. Same protocol both directions. That symmetry is the part I find genuinely elegant — the support agent stops being an app and starts being a node.

Setting it up

The sketch, end to end:

1. Enable it in the dashboard under AI Agent → MCP server: flip it on, name your tool, write a one-line description ("Ask Acme's support agent about the product, API, billing, and policies"), and decide whether to also expose search_knowledge.
2. Create an API key with the agent:chat scope. Keys are created and revoked independently of the MCP config.
3. Add the endpoint to your client — the JSON above for Claude Code, or the equivalent connector config elsewhere.
4. Verify — run tools/list from your client; you should see your tool. Ask it something you know is in your docs, and check the answer carries citations.

Full details are in the docs.

Security notes

Exposing an agent to the internet deserves paranoia, so here's ours:

• Tenant isolation by key, not by argument. The workspace comes exclusively from the API key. There is no workspace_id parameter for a prompt-injected client to fiddle with.
• Scoped keys. The handshake (initialize, tools/list, ping) needs no scope, so client setup never fails mysteriously — but tools/call, the part that does work and spends credits, requires the agent:chat scope. Revoke the key, the endpoint goes dark.
• A deliberate allowlist. The server exposes exactly what you enable: the answer tool, and optionally raw knowledge search. There is no MCP path to your inbox, your customer records, or your settings. External callers get answers, not access.
• Same grounding as everywhere else. MCP answers run through the identical pipeline as widget answers — retrieval over your content, groundedness checks, citations. The endpoint doesn't get a less-careful version of the agent.
• Predictable cost. MCP calls draw from the same monthly AI credits as every other channel — no separate metering, no per-call fees to be surprised by.

The honest caveats

This is early, and I'd rather say so than let you find out. The exposed MCP server is Premium-tier only ($349/month) — it's infrastructure for teams whose support knowledge is genuinely load-bearing, not a starter feature. The surface is deliberately minimal: two tools, no MCP resources or prompts yet. And the ecosystem itself is young — remote MCP support varies by client and, in ChatGPT's case, by plan, so check your client's connector docs before promising this to your team.

But the direction feels right to me in a way few features do. Every business is about to have a grown AI answering machine; very few have thought about who — or what — gets to call it. We're betting the answer is "any AI your customers already trust," speaking a protocol nobody owns.

If you're on Premium, it's live in your dashboard today. If you build something odd with it, I want to hear about it.

Frequently asked questions

What is an MCP server?

An MCP (Model Context Protocol) server is a service that exposes tools and data to AI clients over an open, JSON-RPC-based standard. Clients like Claude, Cursor, and ChatGPT discover the server's tools via tools/list and invoke them via tools/call, letting the AI use external systems — including, now, a company's support agent — as part of answering.

Which AI clients can connect to the Asks MCP server?

Any client with remote MCP support: Claude Code, Claude Desktop, Cursor, ChatGPT's connectors (plan-dependent), and custom agents built on MCP SDKs. The server speaks plain HTTP JSON-RPC at POST api.asks.app/v1/mcp with a Bearer API key, so anything that can send an authenticated POST can integrate.

Is the MCP server available on all Asks plans?

The exposed MCP server — your agent callable by outside AI — is Premium-only. The inbound direction, where your Asks agent consumes external MCP servers as tools, is available on every plan with caps of 1, 3, or 10 connected servers by tier.

Does calling the agent over MCP cost extra?

No per-call fees. MCP responses consume the same monthly AI credits included in your plan as answers on any other channel, so the cost is flat and predictable rather than metered per resolution.

Is it safe to expose my support agent as an MCP server?

The attack surface is deliberately small: callers authenticate with revocable scoped keys, the workspace is bound to the key (not a request parameter), and the server exposes only the tools you enable — grounded answers and, optionally, knowledge search. External callers can ask questions; they cannot read conversations, customer data, or settings.