chatdata

chatdata is a small local bridge to the hosted HasData ChatGPT MCP server. Give it a prompt, and ChatGPT answers it anonymously: the reply comes back as markdown text together with every web source ChatGPT consulted — each source's domain, page title, snippet, publication date and thumbnail — plus the links rendered inside the answer, the conversation title ChatGPT generated for the exchange, the model that answered, and a flag for whether a web search was used at all.

Each call is a fresh conversation with no memory of earlier ones. The language of the answer follows the prompt, so write the prompt in the language you want back, or ask for one explicitly. An optional timezone pins what words like "today" or "this week" mean for that call, which matters most for prompts about recent events — those are the prompts that make ChatGPT search the web and return sources.

The bridge stores nothing of its own. It serves the upstream server's tool list locally, exactly as captured from the live endpoint, and forwards each tool call upstream, returning the result untouched. The captured surface is a single read-only query: there is no write, messaging, or payment tool in it.

Tools

• hasdata_chatgpt_chat_getChatgptAnswer — send one prompt to ChatGPT and return its answer with its sources. Required: prompt (the question or instruction, up to 8000 characters). Optional: timezone (an IANA time zone name such as America/Chicago or Europe/Berlin, setting the frame of reference for the current date and time). Returns the answer as markdown, the web sources consulted, the links inside the answer, the generated conversation title, the answering model, and whether a web search was used.

Configuration

• HASDATA_CHATGPT_MCP_URL (optional) — override the upstream endpoint. Defaults to https://mcp.hasdata.com/mcp?apis=chatgpt. (The override hook is this rebuild's own labelled reconstruction.)
• HASDATA_API_KEY (optional) — when set, every upstream request carries an x-api-key: <key> header, for the caller's own HasData API key. When it is not set, no key header is sent. (The header name and the env name are pinned by the original's registry record; forwarding the key from this env var is a labelled reconstruction — the original surface was captured keyless.)

Forwarding mechanics

On the first tool call the client opens a streamable HTTP session with the upstream: a JSON-RPC initialize request (protocolVersion 2025-03-26, clientInfo name chatdata), then a notifications/initialized notification, then the tools/call request carrying the caller's arguments unchanged. When the upstream answers initialize with an Mcp-Session-Id header, that value rides on every later request of the session, which is reused for the life of the process. Replies may arrive as plain JSON or as server-sent events; both are read.

Successful upstream results pass through verbatim, including any isError flag the upstream sets. Failures — a JSON-RPC error, a non-2xx status, an unreadable response, or a request that cannot be completed — come back as an isError result whose text starts with chatdata error: (this rendering is this rebuild's own labelled reconstruction).

CLI

The tool is also a subcommand taking one JSON argument string:

npx @reneturcios/chatdata hasdata_chatgpt_chat_getChatgptAnswer '{"prompt":"What happened in tech today?","timezone":"America/Chicago"}'
npx @reneturcios/chatdata --version

Exit codes: 0 on success, 1 on an isError result, 2 on a usage error.

MCP server

npx -y @reneturcios/chatdata mcp

MCP client config:

{
  "mcpServers": {
    "chatdata": {
      "command": "npx",
      "args": ["-y", "@reneturcios/chatdata", "mcp"]
    }
  }
}

Docker

docker run -i ghcr.io/cloudcorprecords/chatdata
docker run --rm ghcr.io/cloudcorprecords/chatdata --version

The container's default comm

... View full README on GitHub