Privacy

Free MCP entrance and the ChatGPT plugin (https://jithox.com/api/mcp/x/free)

This entrance answers five read-only checks without an account, card or token. We use what you send only to answer that check. Our own code keeps none of your input: it writes no tool input to a database, a file or the usage line in paragraph 4. Your input does pass through our host and, for some checks, goes to public registers (paragraph 2), and it can appear in our host's own request log (paragraph 5).

Recipients of your input: our host Vercel processes every request. For a Peppol lookup (lookup_peppol_participant, or preflight_payment with a Peppol identifier) the participant identifier goes to the Peppol Directory and to that participant's SMP. check_peppol_ready sends only a derived DNS lookup name. These are public registers with their own policies; we cannot delete anything there. Send only what the check needs.

To limit abuse, each caller may send up to 30 requests per minute. To count them we take your IP address and keep the first 16 characters of its SHA-256 hash, with a counter. This is a pseudonym, not anonymisation. The counter and hash apply to a window of 60 seconds. After that window the server deletes them as soon as it can run its clean-up: a timer set for the end of the window, or the next request to this entrance. If the server is busy at that moment, or our host has paused it, this happens later; our host does not publish a maximum for how long a paused server can last. If our host stops the server first, they disappear with its memory. Until they are deleted they exist only in that server's memory: our code writes them to no log and no database. If you exceed the limit, our hosting log records a security event with the route and the time, without the hash or your IP address.

Our hosting log at Vercel records one usage line for each request to this entrance that we read as starting a session, listing the checks or running a check, including requests we refuse or that fail after we have read them. Requests we refuse before reading them (over the rate limit in paragraph 3, too large, not valid JSON, or not a single valid JSON-RPC request) get no usage line; over the rate limit only the security event of paragraph 3 is written. The line holds the kind of request, the outcome, the client name and version as your client reports them, the browser family, the traffic type and the time. For a check that ran it also holds the tool name, a duration class and, if you got the address from one of our pages, a fixed word for that page. When a check request is refused and our recording of missed calls is on (paragraph 6), the line can also hold the name of the check (only if it is one of our five checks), a fixed error code, the names of the fields you used that belong to that check's published input, and the number of other fields. It never holds the names or values of those other fields. The client name and version are only filtered on form, so they can contain a name if your client sends one. The line contains no IP address and no input values. We use it to count how often the entrance is used and with which kind of client; we do not combine it into profiles.

Our host Vercel also logs every request itself: method, path, query parameters, status, user agent, time, region and outgoing requests. These logs can contain your IP address and, in an outgoing request, a Peppol identifier.

Retention: the rate-limit hash and counter apply to a 60-second window and are then deleted as described in paragraph 3 (later if the server is busy or paused). Security events, usage lines and hosting logs are kept by our host Vercel; for our plan, Vercel's documentation gives a retention of at most 30 days for these logs, and after that period we can no longer see or use them. How Vercel itself handles copies after that period is governed by Vercel's own terms. Our own code keeps none of your input. We do not forward these logs to any other party. This entrance sends no events to Vercel Web Analytics and writes nothing to our database. Our database does have a table of missed calls, mcp_missed_calls, which other Jithox entrances fill: /api/mcp (and the toolset addresses under it) for a priced check called with a token, and the agent-connection gateway. A row holds the entrance, the tool name, the names of the top-level fields that were sent (including names the caller chose; after a check of their form, without duplicates, sorted, at most twenty), an error code, the traffic type and the time. Our recording of missed calls, which also governs the refusal details in paragraph 4, has been switched off since 2026-10-11 11:43 UTC. The table still holds 110 rows recorded before then, the oldest from 2026-09-23 and the newest from 2026-10-02; 65 of them contain the names of the fields that were sent. We will delete these 110 rows no later than 2026-12-31.

Your controls: you decide what to send. For questions, access or deletion, write to info.jithox@gmail.com; a person reads every message and we answer within 30 days. We do not offer deletion of single lines from hosting logs; after the period above we can no longer see them.

What we store

• —The messages you paste or forward, and the invoices, drafts and questions prepared from them.
• —Your business details (name, VAT number, address, IBAN) that you enter once for your invoices.
• —Customer details you explicitly save — never saved without your confirmation.
• —Approvals and receipts: who approved what, when, and what the provider confirmed.
• —Sign-in identity via our sign-in provider (e-mail, name). Its own privacy policy applies on top of ours.
• —For priced MCP calls: usage and billing-reference metadata. Signed decision evidence, where available, is returned to the caller; not every call has a signed receipt.
• —For Invoice Status: the account-bound Moneybird permission (new writes through the checked writer are encrypted; we have not checked whether older stored permissions are encrypted) and fixed invocation and receipt-reference metadata. Jithox does not durably store the invoice query or result. Administration ids and names are cached in process: an entry is reused for 60 seconds and may remain until it is replaced or the process ends.

Retention and deletion: what is established

The numbers below are age cutoffs in deletion code, not proven maximum retention periods. The scheduled sweep requires working cron authentication and a separate database connection with deletion rights. We have not verified that this sweep runs in production. An empty or young table does not prove deletion.

• —First-party funnel rows: the sweep selects rows older than 30 days. We have not verified that this deletion runs in production, and it does not cover copies in logs or backups.
• —Client sighting rows: the sweep selects rows older than 90 days. We have not verified that this deletion runs in production, and it does not cover copies in logs or backups.
• —Missed-call rows: the sweep selects rows older than 90 days. We have not verified that this deletion runs in production, and it does not cover copies in logs or backups.
• —Access and error logs at our host Vercel: for our plan, Vercel's documentation gives a retention of 30 days for these logs, and after that period we can no longer see or use them. We do not forward these logs to any other party. Register-query logs, Vercel Analytics, growth/marketplace events, feedback and backups: we have no fixed retention period. You can ask us to delete data via info.jithox@gmail.com; we assess each request per data category. No automatic deletion of growth events or administrative records was found in the central sweep examined. That describes behaviour, not a retention period or legal basis.
• —Accounts, credentials, usage, payment metadata, invoices and approval/receipt records: we have no fixed retention period. Expired access or lack of automatic purge is not a period. Deletion requests are assessed per data category; any legal retention requirement and its duration need separate determination.
• —Tool results return to your MCP client. The eight check adapters do not write a general archive of full inputs/outputs; register-query logs and billing metadata are separate storage. check_payment_change and preflight_payment can return signed decision evidence with a salted input digest when a key is available. This is not a billing reference or VIES consultation number. How long your MCP client or its model provider keeps results is governed by their own terms.
• —Invoice, Peppol, VAT-list and payment-change web forms can keep input in your browser tab's sessionStorage. The funnel cookie expires after 24 hours; server correlation uses a daily date-salted hash only with a configured key. Moneybird administration data is reused for 60 seconds but may remain in process memory until replaced or the process ends. Cache expiry does not delete external copies.

Security and certifications

Jithox is an early-stage product. We do not claim SOC 2, ISO 27001, HIPAA or PCI certifications, and there has been no independent penetration test yet. Secrets stay server-side, workspaces are strictly separated, and every outbound action is approval-gated and receipted.