MCP servers explained: making your product AI-agent-friendly

Agents stopped reading your pages. They call your tools now.

An AI agent pointed at your product does not want your marketing site. It wants a typed function it can call, get a real answer from, and act on. That is what an MCP server is, and it is why a growing number of SaaS products now ship one next to their web app.

An MCP server is a live endpoint that exposes your product's actions as typed tools an AI agent can call directly. MCP stands for the Model Context Protocol. Instead of an agent scraping a rendered page and guessing at the layout, it authenticates, reads the tool list, and calls functions like create-site or publish-site with structured arguments. A SaaS exposes one so agents can read and change current data through a defined contract rather than a fragile HTML snapshot.

How an MCP server actually works

The server advertises a set of tools. Each tool has a name, a description, and a typed schema for its inputs. An MCP client (Claude Code, Cursor, and others) connects, fetches that list, and can then call any tool on the user's behalf. The agent never opens a browser. It reads the schema and sends a request.

PankoBlitz runs a remote MCP server over Streamable HTTP at https://api.pankoblitz.com/mcp. It exposes 9 tools, including create-site, publish-site, and set-subdomain. A client authenticates with a Bearer API key, then drives the whole product from the terminal.

Connecting takes one command:

claude mcp add --transport http pankoblitz https://api.pankoblitz.com/mcp

After that, a request like "spin up a launch page for my app and publish it" resolves to a concrete tool call. The agent calls create-site with your content, gets back a site id, then calls publish-site to push it live. Each step returns structured output the agent can check before moving on, so a failed publish is a real error the agent can retry, not a broken page it silently rendered.

Why a live surface beats a scraped page

Agents increasingly act through tools rather than reading a page a human designed. When an agent scrapes, it gets whatever markup the server returned at that moment, and it has to infer meaning from CSS classes and text position. When it calls a tool, it gets current data in a shape it was promised, and it can write back. A published page from three hours ago is a stale snapshot. A tool call is the live record.

This is a genuine shift in how software gets used. Some practitioners describe MCP as emerging infrastructure for AI-driven access to products, and the direction is consistent: the client that matters next may be an agent, not a human with a mouse.

What an MCP server does not do

Exposing an MCP server is about agent access and usability. It is not a Google ranking signal. Shipping one will not move your position in search results, and anyone selling it as an SEO tactic is guessing. The value is real but narrow: an agent can now drive your product without a human clicking through your UI.

It also does not remove the need for auth, rate limits, or careful scoping. A tool that changes data is an API surface, and it needs the same protection as any other endpoint. An API key with broad permissions handed to an agent is still an API key with broad permissions.

And it does not replace your web app. Humans still visit pages, still fill forms, still want a screenshot before they buy. The MCP server sits beside the product for the clients that prefer to call rather than click.

Try one tool call

Run the claude mcp add command above, then ask your agent to list the available PankoBlitz tools and create a draft site. You will see the actual create-site call and its structured response. For the full list of tools and their parameters, read the MCP tools reference. If you would rather script it yourself without an agent in the loop, the REST API guide covers auth, create, and publish over plain curl.