Privacy Policy | MCP Hunter

Last updated: 2026-08-25

This policy explains what MCP Hunter ("we", "us", "our") collects, why, and what you can do about it. It covers the service at https://mcp-hunter.com.

We handle personal data under the EU General Data Protection Regulation (GDPR). MCP Hunter is operated from the Netherlands.

1. Who we are

Service: MCP Hunter
Website: https://mcp-hunter.com
Contact: [email protected]
Security reports: [email protected]

If you have a concern about how we handle your data and we cannot resolve it directly, you can lodge a complaint with the data protection authority in your country of residence. In the Netherlands that is the Autoriteit Persoonsgegevens.

2. The service in plain language

MCP Hunter is a weekly launch board for products that ship an MCP server. Makers submit a product, the community votes, and each week produces one ranked board at a permanent URL.

Before a product is listed, we connect to the MCP endpoint the maker gave us, call tools/list, and record what came back. The listing is built from that answer.

We check once, at submission, and never again. Every verification claim on this site is past-tense and dated for that reason.

We do not rate security or safety. We have not audited any listed server's code, its data handling, or its permissions. A listing means a server answered us on a date. It does not mean the server is safe.

3. What we collect

3.1 If you only read the site

Nothing that identifies you.

We keep two counters for each listing: how many times its page was viewed, and how many times its product link was followed. They are counters and not records. A number per listing per day goes up, and nothing is stored beside it: no IP address, no user agent, no session, no identifier of any kind, so there is nothing there that could be traced back to you and nothing that could be joined to anything else. Views that announce themselves as crawlers are left out, which is the only thing we read a user agent for and it is not kept. The maker of that product can see their own counters and nobody else can, not even other makers.

The click counter uses your browser's own link reporting, which sends us a short note when you follow a product link. It stores nothing on your device and it carries nothing about you.

We also keep two counters for the site as a whole: how many pages were served, and how many separate readers that was on a given day. The first is a plain tally. The second has to tell one reader from another for the length of a day, and it does that without keeping anything about you. We generate a secret at the start of each day, combine it with the site's name, the address your request arrived from and your browser's user agent, and keep only the fingerprint that comes out of that mixture. Your address and your user agent are never written down. The secret is destroyed when the day ends, which means the same fingerprint can never be produced again and yesterday's cannot be matched against today's, so a reader who returns tomorrow is simply a new one. What survives the night is a number per day and nothing else.

Beyond those counters: there is no analytics product on this site, no tracking pixel, and no advertising network. We set one cookie, described in section 6.

Our server and our CDN keep short-lived request logs (IP address, timestamp, URL, user agent) as a normal part of serving and protecting the site.

3.2 If you sign in

Signing in is only needed to vote, comment, or submit. There are two methods, GitHub and Google, and you pick one. From the provider you choose we receive and store:

Your account identifier at that provider, used to recognise you on return visits
Your display name (or your username if no name is set)
Your avatar image URL
The date your GitHub account was created, when you sign in with GitHub. Google does not tell us this.
Your email address, if the provider gives us one and it is not already held by another account here. When it does not, we store an address of our own that cannot receive mail: GitHub's @users.noreply.github.com form, or @users.noreply.invalid. These name the account without inventing a real address, and we never send anything to them.

We never receive your GitHub password. We request no write access to your repositories.

The account creation date is stored because a brand-new account is a signal we use against vote manipulation.

3.3 If you submit a product

The product name, tagline, and the URLs you provide: the MCP endpoint, the product page, and optionally a repository and documentation link
A one-time verification token we generate to prove ownership
The result of our connection test: whether it connected, the tool count, the tool names and descriptions the server returned, response time, and any error
The product site's icon, fetched once from the domain you gave us and stored as an image
Review notes we write while deciding whether to list it

A test credential, if you give us one. Some MCP servers require a token to answer at all. That field is optional. If you use it, the value is encrypted at rest, sent only on that single check, and deleted once the check finishes, whether it passed or failed.

3.4 If you vote

We store which account voted for which product, the time, and the IP address the vote came from. The IP is kept to detect vote manipulation, which is the one thing that would make a ranked board worthless.

3.5 If you comment

We store what you wrote, which listing it was on, the time, and the IP address it came from, for the same reason we store it for votes: a public writing surface with no abuse signal at all is one nobody can keep clean. If you edit a comment we store the time of the edit, which is shown publicly next to it.

We also store your display name alongside the comment, so it still reads correctly if you later delete your account.

If a moderator hides a comment, we store the reason and who decided it. That record exists because we are obliged to tell you why, and you see it on your Account page.

3.6 If you report a comment

We store which comment, which account reported it, the category you picked, anything you typed, and what we decided. A report is not anonymous to us: we need to know who sent it to stop the report button being used as a weapon.

3.7 If you tell us your server is stdio-only

We store your account and the product URL you entered, so we can count how many makers a Streamable-HTTP-only rule turns away. Nothing else.

3.8 If you subscribe to the weekly digest

There are two ways onto the list and they are recorded the same way.

By making an account. Accounts created from 11 September 2026 onward are added when they are created, and the sign-in page says so before you click. Your provider has already verified that you hold the address, so there is no second confirmation step. Accounts that existed before that date were not added.
By typing your address at /newsletter. Anyone can type a stranger's address into a form, so this route sends one confirmation link and nothing else until somebody clicks it.

Either way we store your email address, when you were added, which route added you, the IP address it came from, and which issue you were last sent. The first four are the record that you were added legitimately, which we have to be able to show if our mail is ever reported as unwanted. The last one stops a re-run sending you the same issue twice.

Leaving the list does not touch your account, your listing or your votes, and deleting your account takes you off it.

4. Why we are allowed to hold it (legal bases)

Contract: account data, submission data, and votes. You asked us to list or rank something and we cannot do that without them. This covers the four emails in 7.1 as well: telling you the outcome of a review you asked for, and what happened to the launch you booked, is part of doing the thing you asked for, not marketing.
Legitimate interests: request logs, the vote IP address, and the GitHub account age, all for security, abuse prevention, and keeping the ranking honest. We think a board that can be trivially gamed serves nobody, and these are the least intrusive signals we found that work. The counters in 3.1 sit here too, both the per-listing ones and the site-wide pair: a maker who launches something is entitled to know whether anyone looked at it, and anyone buying a placement is entitled to know how many people would see it. Counting without keeping anything about the reader is the least we could collect and still answer either question. The site-wide visitor count reads your address and user agent in memory to build the fingerprint described in 3.1 and stores neither.
Consent: the weekly digest. It is the one thing here you can switch off and still use everything else, so it is the one thing that records how you were added (3.8) and stops the moment you say so, from a link in any issue. Nothing else relies on consent: the counters store nothing on your device and read nothing from it, so the cookie rules do not reach them. That is why the visitor count is built the way it is rather than with a cookie, which would have been simpler for us and would have required asking you.

5. What we publish

A listed product is public by design: its name, tagline, links, the dated connection-test result, its vote count, and its position on that week's board.

The maker's identity is not published. We do not show who submitted a product, and we do not show who voted for what.

Comments are published under your display name, which is the one place your identity appears on the board on purpose. The comment body, that name, and the date are public. The IP address behind it is not, and neither is any report anyone files about it.

Past weeks stay online permanently at /week/{year}/{week} and are never redirected. That is the point of the archive, so treat a submission as a public, permanent record.

6. Cookies

One cookie, set only to keep you signed in and to protect forms against cross-site request forgery. It is strictly necessary for the site to function, so it does not require a consent banner under the ePrivacy rules.

We set no analytics, advertising, or third-party tracking cookies. There is no consent banner because there is nothing to consent to. The counters described in 3.1 neither set nor read anything on your device, and that includes the site-wide visitor count: it is deliberately built out of a nightly secret and the request itself rather than out of something stored in your browser, so it does not change this.

7. Who else touches the data

We keep the list short on purpose.

Who	What they do	Where
Hetzner Online GmbH	Hosts the server the site runs on	Germany (EU)
Cloudflare, Inc.	DNS, CDN, the firewall in front of the site, and sending the email described below	Global edge, US company
GitHub, Inc.	Sign-in, when you choose it	US
Google Ireland Limited	Sign-in, when you choose it	Ireland (EU), US parent

We do not sell personal data, and we do not share it for anyone else's advertising.

Transfers outside the EU (Cloudflare, GitHub, and Google's US parent) rely on the European Commission's Standard Contractual Clauses and the EU-US Data Privacy Framework where applicable.

7.1 The email we send

We send exactly four emails, all about a submission you made, and only to a real address:

Your product was listed. Sent when a reviewer approves it, with a link to your listing.
Your product was not listed. Sent when a reviewer turns it down, and it carries the reason they wrote.
Your launch week has opened. Sent on the Monday a board you booked in advance goes live. You do not get this one if your product was listed into a week that had already started, because the listing email said so at the time.
You finished in the top 3. Sent once your week closes and the standings are final, telling you what that place earned and, if you have not proved the product is yours, what is needed to collect it.

Those four need no permission and carry no unsubscribe, because each one answers something you asked us to do: telling you what happened to your own submission is part of doing it. If your account holds one of the placeholder addresses described in 3.2, we send nothing at all, because those addresses cannot receive mail.

The weekly digest is the exception and it works the other way round. It is one email a week, on Monday, listing what launched on the board and where last week's finished. Making an account puts you on it and the sign-in page says so; anyone else can join by confirming their address at /newsletter. Every issue carries a one-click unsubscribe that takes effect immediately and needs no account and no reply from us, and a quiet week gets no issue at all. The list stays with us.

One more email exists and it does not go to you. When a submission reaches the review queue we write to ourselves, so that the review actually happens rather than waiting for someone to open the page. It names your product and your address, so the reviewer can reply to you directly.

8. How long we keep it

Listings: permanently. The weekly archive is a public record and is never redirected or deleted.
Account data: until you delete your account.
Votes: as long as the vote stands. Withdrawing a vote removes it.
Published comments: as long as the listing they are on, which is permanently. Editing one replaces what we hold; deleting one removes it from the page.
Hidden and deleted comments: kept while the account exists, and removed with it. A hidden one is kept so we can show you why it came down and reconsider if you contest it.
Comment reports: kept with the comment they are about, so a decision we made can be explained later.
Test credentials: deleted as soon as the check finishes. They are never retained.
Digest subscription: until you unsubscribe. We keep the row itself after that, holding the address and the fact that it opted out, so that a later signup cannot quietly put you back on and so we can show the request was honoured. Ask us and we will delete it outright.
Request logs: short-lived, typically days, and rotated automatically.

If you delete your account, we remove your personal data. A product already listed on a past week's board stays listed, because the archive is a public record of what launched that week. A comment that was published stays on the page for the same reason: other people read it there. Both stop being connected to your account, and your name comes off the comment.

9. Your rights

Under the GDPR you can ask us to give you a copy of your data, correct it, delete it, restrict or object to how we use it, or hand it over in a portable form.

You do not have to ask us for the common ones. Sign in and go to Account, where you can see exactly what we store about you, withdraw a submission, and delete your account yourself.

For anything else, email [email protected]. We reply within 30 days.

10. Security, stated honestly

The site runs over HTTPS. Test credentials are encrypted at rest and deleted after use. Administrative access to the server is restricted to a private network.

Connections to submitted MCP endpoints are made from a queued background job with a hard timeout, and private, loopback, and cloud metadata addresses are blocked, because a submitted URL is an untrusted address by definition.

No system is perfectly secure, and we are not going to claim otherwise. If you find a vulnerability, email [email protected].

11. Children

MCP Hunter is for people shipping software and is not directed at children under 16. We do not knowingly collect their data.

12. Changes

If we change this policy we update the date at the top. Material changes will be noted on the site.