This marketplace sits in the middle of a tool call, so that is the part worth writing down: what reaches the gateway when an agent calls a tool, what is written to a row, what is written nowhere, how long each record lives, and who else ever touches it. Cookies are near the bottom: there is one, it counts visits, and it does not exist until you say yes to it.
Each publisher is a separate controller for whatever their own server does with what an agent sends it. We are the controller for the account, the gateway record and the money.
A remote server runs on its publisher’s own infrastructure, reached through our gateway. Your client opens one connection to the gateway; the gateway checks the key, routes the call, returns the answer and meters it. Everything in that call passes through us — the tool name and every argument with it — because there is no way to route a call without reading its envelope.
What we keep of it is one row.
{
"at": "2026-07-29T14:20:06.481Z",
"account": "acct_8Q2F",
"seat": "seat_1104",
"install": "ins_7c31",
"server": "<server>",
"version": "2.4.1",
"tool": "<tool>",
"client": "claude-code",
"region": "eu-central",
"status": "ok",
"ms": 640,
"in": 412,
"out": 41903,
"units": 1,
"cost": 0.0024
}
That is the row. There is no field for the URL passed to fetch_page, and none for the 41,903 bytes that came back. Both were counted on the way through and forwarded. It is the same promise the ticket composer makes in your dashboard when it offers to attach diagnostics: call metadata only — which tool, when, and what it returned as a status. Never the arguments you sent or the content that came back.
We do not store what you passed to a tool. The server you called received it, because that is what a tool call is — fetch_page cannot fetch a page without the URL. What that server logs at its end is the publisher's, governed by their notice and not by this one, and it is the thing to read before installing anything that will be pointed at customer data. Every listing prints its tool surface and its complete egress allowlist for exactly this reason.
A failed call keeps its status and the publisher's error string, truncated at 200 characters and scrubbed of anything shaped like a token or a key. That string is written by the publisher's server, so it contains whatever they put in it. If you ever find an argument of yours echoed back inside one, report the listing: it is frozen while we read it.
A call that tries to reach a host outside the listing’s declared allowlist is refused at the gateway, and the refusal is written to your audit trail with the host it tried to reach. The host, not the request.
A local server never touches the gateway. We record that you installed it, and that you paid for it if it was not free. Its calls, its arguments and its results stay on your computer, and no figure anywhere on this site is drawn from them.
Related: what the scan checks · what a key can reach · what the 12% pays for
Two clocks. Operational records are kept for as long as they can answer a question you might reasonably ask — a bill you want to dispute, a failure you want to chase. Financial records are kept for as long as a tax authority can ask about them, which is longer and is not our decision.
Every figure on your usage page comes from a thirty-day window, which is why the whole site talks in thirty days, and on Free that is also how long the rows live. Pro is sold with 12 months of call log and keeps them that long. Either way what survives is the daily total below, which carries no tool name and no time finer than a date.
What survives the deletion above: calls, failures, p95, units and cost, one line per install per day. No tool name and no timestamp finer than a date.
Readable and exportable as CSV or JSON from the billing page, on every plan including Free.
We are the merchant of record, so we raise the invoice and remit the tax in 61 jurisdictions. Those authorities set this number, not us, and a deletion request cannot reach this copy. It holds the invoice, the amount, the tax and the billing name and address — never what you called or how often.
Neither is on a disk of ours, so neither has a clock here. What we store is an identifier and a status — the Stripe customer for a buyer, the connected account for a publisher — and the brand and last four digits of a card, so a billing page can name the thing it is about to charge. The number itself, the bank details, the identity documents and the tax form are Stripe's, and there is no copy of any of them for us to delete.
A balance is money we hold, so its ledger is an accounting record and keeps the same seven years an invoice does. Each row is a date, an amount, a direction and the Stripe reference the charge or the payout is known by — never what the money was later spent on, which is the invoice's business and lives in its own row.
One tag, read once, when an account is created, and kept for as long as that account exists — a reward paid over twelve months has to be attributable for twelve months, and a link that could be re-attributed later is a link somebody would re-attribute. It records the referring account and the date, and nothing about how the referred account was persuaded.
What a referrer is shown about you. The state of the referral, the month you joined and the settled amount their share is computed from — because a payment they are owed a fifth of has to be checkable. They are shown a masked address rather than your own, and never what you installed, which listings you use, your invoices or anything you wrote. If you would rather not be on that list at all, ask and the tag is removed: the reward stops, and nothing else about your account changes.
24 months on Pro. Free is not sold with one and keeps the same thirty operational days the call rows get; on Enterprise the term is written into the contract. It belongs to the organisation rather than to the person: a member cannot delete the record of their own approval, which is the entire point of keeping one.
A grade has to outlive the release it describes — somebody pinned to a two-year-old version still needs to read why it scored what it scored. These describe a publisher's code, not you.
The thread, the diagnostics you attached and the replies. Then the thread goes and a stub stays: ticket id, listing, category, opened, closed. Your dashboard and the publisher's inbox are two ends of one record, so both lose it on the same day.
The key stops working immediately. What we keep is when it was created, when it was last used and what it was scoped to — the reason anyone keeps this is the incident review that happens a year later.
Thirty days to change your mind. Then the account, its installs, its lists, its keys and its call metadata are deleted. The ledger copy of the invoices stays, for the reason six rows above.
Public writing with your name on it. Delete your own at any time. Closing the account does not delete them — a listing's rating cannot move for reasons no reader can see — but the name comes off and the organisation stands in its place.
A deletion request removes everything in this table except the ledger row, the reviews and the row Stripe holds rather than us, and it removes them from backups on the next restore cycle rather than by rewriting a backup in place. Backups are kept 35 days. A card is deleted from Stripe on the same request, which we pass on; the connected account is a publisher's own and is closed with Stripe.
Enough to run a business and to fix a bug, and no more. The line is drawn at identity: they get volumes, not people.
Installs and uninstalls, calls and failures, p95, revenue, and the split by client — Claude Code, Cursor, VS Code, a key of your own. Installs reach them as an opaque id such as ins_7c31, unique to that listing. The same buyer on two of their listings is two ids that cannot be joined, and neither of them is your account id.
They can subscribe to three events about buyers: install.created carries the client and nothing else, review.created carries the rating, and budget.capped says a cap was reached on their server — not whose, not what it was set to, and not what that account spends anywhere else.
You write a review. It publishes your name, your role, your organisation and a rounded call band — verified · 18.2k calls — because a review with no volume behind it is worth nothing to the next reader. Delete the review and all of that goes with it.
You open a ticket. The publisher sees your name, your organisation and what you wrote. The diagnostics are a checkbox: version, clients, thirty days of call counts and the failure codes. Untick it and the ticket still goes — their inbox shows a line saying you declined, because it is yours to decline.
Your email address. Your other installs. Your total spend, your cap, or how close to it you are. Your seat names or your team. Your invoices — we are the merchant of record, so your billing details are never theirs to hold. And from us, nothing about the content of any call: their own server received the arguments, and we do not add to what they already have.
The asymmetry is deliberate. They are selling and you are running their code against your data, so the burden of being legible is theirs. All of this is public on every listing and profile, without an account:
Not public: which individual at the publisher wrote a reply — a reply comes from the account, not the person — what they earn, where they bank, and who else buys from them. None of it is contact detail either. There is no way to email a publisher from this site outside a ticket raised against a listing you have installed, and that is a decision about spam rather than an oversight.
Most of this catalogue was not published here. It is assembled from public sources — the Model Context Protocol registry, npm, PyPI, container registries and the projects' own public repositories — and each entry carries the handle its author published the code under, because a listing without an author is a listing that takes credit for somebody else's work. If that is you, this section is the one that concerns you, and you can act on it without an account.
The handle you published under, the repository or package address, the name, description and version of the software, and the licence. Nothing else: no email, no avatar, no location, no follower graph, nothing scraped from a profile page and nothing bought from a data broker. We do not combine what is here with anything from another source to build a picture of a person.
Each entry names the public source it was taken from, which is also the disclosure the GDPR requires when data is not collected from the person it is about (Art. 14). The source is a link: you can read what we read.
Legitimate interests: running a catalogue of software that has been published for anyone to install, attributed to whoever published it. A handle attached to a public release is the least we can hold and still be honest about whose work it is. You can object, and see the next row for what happens when you do.
Write to support@mcprush.com from any address and say which entry. We delist it and delete the handle with it — no reason required, no form, no account, and we do not weigh our interest against yours first. If you would rather keep the entry and have it be yours, claim it from the button on the page instead: clause 5.4 of the terms sets out all three routes.
An unclaimed entry has no account, no inbox and no balance. We send nothing to its author, we sell nothing about them, we run no profiling or automated decision-making against them, and nothing about them is passed to an advertiser. Their name is on a page that says, in as many words, that they have not claimed it.
Three companiesFour companies, and the fourth only for people who agreed to it, and this is the whole of it — the list a DPA would refer to. It changes with 30 days' notice, announced here and by email to account owners, which is enough time to object before a change takes effect.
Charges cards, holds every card on file, and — through Stripe Connect — holds each publisher's connected account: their identity documents, their bank details and their tax form. On a Friday it receives the transfer we make into that account and pays it out to the bank behind it. It also carries a dispute to the card network, on the evidence we file.
Receives card details, typed into Stripe's own frame on our page and never into a field of ours; the billing name, address and country; the amount, the currency and an invoice reference. From a publisher: the identity document, the bank account and the tax form, none of which reach us. On a dispute, the call counts for the period being disputed, because that is the evidence.
Never which listings are on the invoice, which tools were called, or anything from a call.
Our hosting provider. It runs the machine this site, the gateway and the database live on, and holds the disks they are written to.
Receives nothing sent to it deliberately: it is the infrastructure the platform runs on, so everything the platform stores is on hardware they operate.
Never an account of their own inside the application. They are the landlord of the machine, not a reader of what is on it.
Answers the name, terminates the connection and passes the request to our server. Every page you read here and every API call your client makes arrives through it.
Receives what any network in the path receives: your IP address, the address you asked for, your browser's headers and the timing of the request.
Never a decrypted store of what you did afterwards. It carries the request; the record of what the request changed is ours.
There is no analytics property behind this site at the moment: no measurement id is set, so no analytics script is requested, no analytics cookie is written, and nothing is reported to anybody — whichever answer you give the cookie bar.
If that changes, the company receiving it is named in this list 30 days before it starts, on the same notice as any other change here, and it stays behind a question you can answer no to.
Google Analytics 4, on the public pages, and only after you press accept. It counts visits: which page was opened, which page it was opened from, roughly where in the world the request came from, and whether the visitor had been here before. Refuse it and nothing is requested from Google at all — the tag is injected on the grant rather than loaded and then muted.
Receives the page address, the referrer, the browser and device type, a coarse region from a truncated IP, and a random first-party id in the _ga cookie. Retention is set to the shortest GA4 allows, 14 months, and Google signals and ad personalisation are switched off in the property, so no hit reaches the advertising side of an account.
Never your account, your email, your invoices, anything from a tool call, or any page behind a login: the dashboard, the studio and the checkout do not report to it even with consent given.
Support is not on that list, and neither is mail. A ticket lives in your dashboard and in the publisher's inbox on this platform; no helpdesk vendor reads it. Transactional mail — receipts, invoices, release notices, ticket replies and password resets — is delivered by our own server to the address you gave, so there is no mail provider holding a copy of it; a relay put in front of that would be named here first. There is no session recording, no heatmaps, no advertising network, no customer data platform, no data broker, and no product analytics inside the dashboard. Nothing here is sold, nothing is enriched against a third-party profile, and none of it trains a model.
Stripe is the one that necessarily sees data outside the country you are in, because card networks are not regional, and it is covered by the standard contractual clauses with the EU–US Data Privacy Framework for anything that reaches the United States. Google Ireland is the contracting party for analytics, under the same clauses. The DPA is available on request on any plan, including Free — ask through contact.
No analytics cookie is written on this site at the moment, and there is nothing that could write one: no measurement id is configured, so no analytics script is loaded whatever you answer. The bar still asks, and your answer is still kept and still reversible from Cookies in the footer of every page, because the answer has to exist before there is anything for it to govern. The table of what analytics would write appears here on the day one is switched on, 30 days after it is announced.
There is exactly one cookie family on this site and it is analytics. It is not set when you arrive, it is not set if you press Only essential, and it is not set if you close the bar without answering. Nothing on this site is gated behind accepting it, and the answer is reversible from Cookies in the footer of every page — a refusal has to be as easy as a grant, and one press is what that means.
What analytics writes, if you agree to it:
| Cookie | What it holds | Lives |
|---|---|---|
| _ga | a random id for the browser, first-party, no account behind it | 13 months |
| _ga_<id> | the visit state Google Analytics 4 keeps per property | 13 months |
Both are first-party and neither is set on a page behind a login. Withdrawing consent deletes them in the browser you withdraw it in, and nothing is requested from Google until you answer yes.
And one more key, which is the answer itself:
| Key | What it holds | Written when |
|---|---|---|
| mm.consent | your answer about analytics, and its date — nothing else, and nothing that identifies you | you answer the bar · asked again after 12 months |
It is stored in localStorage rather than in a cookie, so a refusal is not itself a thing sent back to a server on every request. Clear your browser storage and the bar asks again, which is the only consequence.
Signing in adds one thing to that table and nothing else: a first-party session cookie, HttpOnly, SameSite=Lax, expiring with the session. It is strictly necessary — it is what keeps you signed in — so it is not part of the question the bar asks. Google Analytics is the only script here that belongs to somebody else, only on the public pages, and only on a yes.No analytics or advertising script runs here at all. One third party does see that you asked for a page: these pages load their typeface from Google Fonts, so Google's font server receives the request for it — no cookie, nothing about your account, and it is the whole of what leaves a page you are reading.
Access, correction, export, deletion, objection, and a complaint to a regulator if we handle any of those badly. Three of them you can do yourself, right now, without asking.
Usage and invoices as CSV or JSON from the billing page, on every plan including Free. No request and no queue.
Billing details, seat names and the address on your invoices are editable in the dashboard. A corrected address applies to the next invoice; issued ones are not rewritten, because an invoice that changes after it was issued is not an invoice.
Close the account in settings. Thirty days later everything in the retention table goes, except the ledger copy of your invoices, any review you left published, and the row Stripe holds rather than us.
Write to us. We answer inside 30 days and usually within three working days. If a request will take longer we say so before the 30 days are up, and say why.
Use the contact page and pick the account and privacy category — it routes to people who can act on the request rather than to a queue. Tell us the account email. We will not ask you for a document proving who you are unless answering would expose data about somebody else.
Two limits worth knowing before you ask. An organisation's audit trail belongs to the organisation: a member cannot erase the record of their own approvals, and a request to do so goes to the account owner rather than to us. And each publisher is a separate controller for whatever their own server does with what you sent it — we can tell you what we hold, and we cannot answer for them. Their notice is linked from their profile.
If you are in the EU or the UK, your supervisory authority is the one where you live and you are not obliged to come to us first. We would rather you did, because we can usually fix it the same week.
Material changes are announced 30 days before they take effect, here and by email to account owners, and every previous version stays readable for 24 months. The list in section 05 is the part of this page that moves: a company joining it is announced before it receives anything rather than after, which is enough time to close an account over it if that is your answer.
If the GDPR or the UK GDPR applies to you, this is the part that names the basis. Consent appears once, for analytics, and it is the only purpose you can withdraw without leaving the service — because every other one is either the contract itself or a law we cannot opt out of.
| What we do | Lawful basis | What it means in practice |
|---|---|---|
| Run the account, the gateway and the installs | Art. 6(1)(b) contract | Refusing means not having an account; there is nothing to withdraw |
| Charge, refund, pay out, and keep the ledger | Art. 6(1)(b) + (c) | Invoices and payout records are kept 7 years because tax law says so |
| Scan releases, rate-limit, and stop abuse | Art. 6(1)(f) legitimate interests | Keeping a marketplace of other people’s code safe to install; you can object |
| Transactional mail — receipts, alerts, resets | Art. 6(1)(b) contract | No marketing mail exists here, so there is no list to leave |
| Google Analytics on the public pages | Art. 6(1)(a) consent | Off until you accept; change it here at any time |
| Answer a regulator, a court or a card network | Art. 6(1)(c) legal obligation | Narrow, logged, and told to you unless we are ordered not to |
The records are held on our own server in Germany, and there is no second region they are copied to. The transfer that leaves it is Stripe, under the European Commission’s standard contractual clauses and the EU–US Data Privacy Framework for the part of it that reaches the United States. A transfer impact assessment for it is part of the DPA.
The UK addendum and the Swiss addendum are included in the same document, and it is available on request on every plan including Free.
No automated decision with legal effect. A scan grade is produced by a deterministic engine, but no account is closed, no payout is withheld and no listing is removed by that engine alone — a person decides, and the decision is written to the publisher naming the file or the call it turns on. That is Art. 22 satisfied by not relying on it.
No profiling and no special categories. We do not build audiences, score people, or ask for anything in Art. 9. If you send special-category data through a tool call it is not ours to hold: arguments are never written down.
A personal data breach is reported to the lead supervisory authority within 72 hours of us becoming aware of it, and to you without undue delay where it is likely to be a high risk to you — plainly, saying what was taken and what to do about it, on the status page as well as by email. A sub-processor of ours has 24 hours to tell us, by contract, so that the 72 is ours to keep rather than theirs to spend.
You can complain to your own supervisory authority without coming to us first — for most readers that is the data protection authority of the country you live in, and in the UK the Information Commissioner’s Office. We would rather you told us, because we can usually fix it the same week, but it is not a condition of anything.