MCP & ChatGPT

Give ChatGPT, Claude or any MCP client a tool that answers from a website's own pages - by typing or by voice.

The Model Context Protocol is how an assistant calls tools that are not its own. Our MCP server exposes FireSiteChat as four of them, so the assistant can answer a question about your website from that website - instead of from whatever it remembers about the company.

Connect it

Server URL	`https://firesitechat.com/mcp`
Transport	Streamable HTTP (stateless - no session id)
Auth	`Authorization: Bearer` + your API key
Discovery	`GET /.well-known/mcp.json`

Create a key first at Profile & settings → API & MCP. It needs the answer scope to answer questions, and search to retrieve passages.

ChatGPT

Settings → Connectors → Create. Paste the URL above, choose API-key / bearer authentication, paste your key. Then ask it about your website.

Claude Code

claude mcp add --transport http firesitechat https://firesitechat.com/mcp \
  --header "Authorization: Bearer $FSC_KEY"

Anything else

Any client that speaks Streamable HTTP and can send a header will work. If yours can only be given a URL with no header field, see below.

The tools

Tool	Arguments	Returns
`ask_website`	`question`, `domain?`, `chat_id?`, `verify?`	Prose written to be read aloud, then exactly one `Sources:` line, listing every page the answer was built from
`search`	`query`, `domain?`	Matching passages with ids, titles and URLs
`fetch`	`id`	One page's full indexed text
`list_websites`	(none)	The websites this key can reach

domain is optional. If your key is restricted to one website, or your account has exactly one, the tools use it - which is what makes the plain search(query) and fetch(id) shape work unchanged. With several websites in play the tools ask which one rather than guessing, because guessing would answer about the wrong business.

Voice

A spoken question goes through the same ask_website tool, and what comes back is what gets read out. So the answer is written as prose, with the source URLs on their own labelled line at the end - an assistant can cite them without reading a URL aloud.

Ask "what are their opening hours?" and the answer comes from that site's pages. If the site does not cover it, the honest answer is that it does not - which is the point of pointing an assistant at a website in the first place.

You can see what it asked

Every ask_website call is saved to your chat history and appears in the dashboard sidebar marked 🤖, so a conversation your assistant had on your behalf is not invisible to you. That is deliberately not something the assistant can turn off.

What it costs

A tool call is a request from your account, billed to your account, under exactly the same credit allowances and limits as your own use of the app. There is no separate MCP plan. ask_website spends an answer's worth of credits; search spends one embedding call; fetch and list_websites spend nothing.

When something goes wrong

Failures come back as an ordinary tool result marked isError with a readable sentence, so the assistant can tell you what happened instead of failing silently. Common ones: the key lacks a scope, the account is out of credits, the website is not indexed yet, or several websites are available and the call did not say which.

If an answer arrives with no sources, nothing grounded it. That is the system telling you the truth about its own output - believe it over any citation line in the prose.

Clients that cannot send a header

Some hosted clients only accept a URL. A path-embedded key (POST /mcp/k/<key>) is available but ships off, and the reason is worth stating plainly: a key in a URL ends up in every access log between the client and us. Prefer the header wherever the client has one.

Guide · API · Get a key · Full API reference