Pigfox MCP endpoint

Call pigfox tools from an MCP client — Claude Desktop, an agent framework, or anything else that speaks the Model Context Protocol — with a bearer token, per-call metering, and a spend ceiling you cannot accidentally exceed.

Connect

The endpoint is https://pigfox.com/api/v1/mcp, served over Streamable HTTP. Create a token at your API tokens page (you will need to be signed in), then point your client at it:

{
  "mcpServers": {
    "pigfox": {
      "url": "https://pigfox.com/api/v1/mcp",
      "headers": {
        "Authorization": "Bearer pfx_YOUR_TOKEN_HERE"
      }
    }
  }
}

A request with no token, an unrecognized token, or a revoked token is refused before any tool runs and costs nothing.

Protocol version

This endpoint negotiates MCP protocol version 2025-11-25. That is what the server answers initialize with, measured against the running endpoint rather than read off a support table — the SDK lists newer revisions, but caps what it will negotiate here, so 2025-11-25 is what your client will actually get.

Endpoint versioning

Not to be confused with the protocol version above: that one is the MCP specification revision, this one is the URL. /api/v1/mcp is stable. A change that would break a working client — a removed tool, a renamed argument, a different response shape — ships as /api/v2/mcp alongside it, rather than altering what v1 means underneath you. Adding a tool is not a breaking change and will not move the version.

This endpoint previously answered on the same URL with no version segment in it. That older path now returns 404, and it is deliberately gone rather than redirected. A redirect converts a POST into a GET, so a client posting JSON-RPC at the old URL would not be forwarded: it would get an empty, confusing protocol error instead of a clear “no such endpoint”. A 404 is diagnosable in one request; a silently changed method is not. If a stored config still lacks the /v1/ segment, add it — nothing else about the request changes.

Tools

Four tools are exposed today. Each is the same engine as its page on this site, so a result here and a result there are the same result.

They are listed below in the order tools/list returns them, which the SDK sorts by name — so the table and your client agree. Note that this puts the one paid tool first; its description leads with the cost for that reason.

The rest of the pigfox tool catalog is not exposed over MCP yet. Most of those tools are reachable only through a form — a file upload, a multi-field questionnaire — and each needs a real adapter written and tested before it can be called by a machine. Four that work is the honest state of it; more will follow.

Driving it by hand

The config block above is the normal path — your client performs the handshake for you. This section is for verifying the endpoint yourself, or for writing a client. Four requests, all to the same URL.

1. Initialize. The response carries the negotiated version and, in its headers, an Mcp-Session-Id you must echo on every subsequent request. Both content types are required on the Accept header.

curl -isS https://pigfox.com/api/v1/mcp \
  -H "Authorization: Bearer pfx_YOUR_TOKEN_HERE" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
        "protocolVersion":"2025-11-25",
        "capabilities":{},
        "clientInfo":{"name":"curl","version":"1"}}}'

Read the Mcp-Session-Id response header and use it below as $SID.

2. Say you are initialized. A notification — no id, and the server answers 202 with no body.

curl -sS https://pigfox.com/api/v1/mcp \
  -H "Authorization: Bearer pfx_YOUR_TOKEN_HERE" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Mcp-Session-Id: $SID" \
  -d '{"jsonrpc":"2.0","method":"notifications/initialized"}'

3. List the tools. Free — tools/list is not a metered method.

curl -sS https://pigfox.com/api/v1/mcp \
  -H "Authorization: Bearer pfx_YOUR_TOKEN_HERE" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Mcp-Session-Id: $SID" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'

4. Call one. Use a free tool to check your wiring — homepage-density-optimizer costs a credit every time it runs, including when it runs by accident.

curl -sS https://pigfox.com/api/v1/mcp \
  -H "Authorization: Bearer pfx_YOUR_TOKEN_HERE" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Mcp-Session-Id: $SID" \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{
        "name":"security-headers-grader",
        "arguments":{"url":"https://example.com"}}}'

What a call costs

Credits are the same credits the rest of the site uses, drawn from the same balance. A free tool costs nothing. A paid tool costs one credit — the same price the web page charges for the same work, so there is nothing to arbitrage between the two doors. An active subscription covers MCP calls exactly as it covers the web tools: nothing is held and nothing is debited.

A tool that runs and reports a failure is still billed, because it ran. A call that is refused before dispatch — no credit, over a limit, unknown tool — is never billed.

Limits

These bound what one client can spend. They are deliberately denominated in credits rather than in requests, because the caller here is usually an agent: an agent that hits an error retries rather than stopping, and it is perfectly willing to wait between attempts, which is exactly the pattern a per-second rate limit cannot see.

What this does not do

Create a token See credit packs