MCP.Market

Billing Doctor MCP server

by lazytitan30·io.github.lazytitan30/billing-doctor·v0.1.1

Diagnose Google Play Billing incidents locally, with evidence. Not affiliated with Google.

A92/100grade A
What users say
No reviews yet
Be the first
Safety scan
A92/100

full report

Adoption
Growing

0 stars46 downloads/wk

Reviews

Write one

Nobody has reviewed Billing Doctor yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

Billing Doctor tools (6, 1 write)

write = sends, deletes, buys or posts

Read from the package source without running it. The installed server may list more.

  • decode_rtdn

    Decode a Pub/Sub push body (or a decoded DeveloperNotification, or the base64 data alone): the notification kind, the type name for the integer, the token, and the next step, which for a subscription notification is always to re-fetch the resource before touching state.

  • diagnose_timelinewrite action

    Run every rule over a billing-doctor-timeline/1 document and return the findings, sorted by severity then first evidence index. Each finding has ruleId, severity, title, evidence (event indexes), mechanism, googleRule {quote, url, readOn}, confidence, nextCheck and fix. exitCode is 1 when a high finding exists.

  • explain_subscription_state

    Explain a purchases.subscriptionsv2 resource in plain words: the state, the access it implies under Google's rule and under the given policy, the expiry per line item, the acknowledgement deadline, the linked token, the test marker, the plan type and the cancellation context.

  • get_rule

    One rule in full: what it detects, Google's rule quoted with the URL and the date it was read, the observed behaviour when there is one, and the runbook entry when the Incident Kit folder is present.

  • list_rules

    Every rule: id, group, severity, title and what it detects.

  • redact_text

    Replace purchase tokens with stable tok_ pseudonyms, remove emails, mask order ids to their last four characters, turn UUIDs into u_ pseudonyms and cut out private keys and bearer tokens. Run it over logs before building a timeline.

Public scan report

scanner v0.1.10 · 2026-10-03 · same rubric, same numbers if you re-run it

no findings
  • Code scan247 source files scanned25/25
  • –Live reliabilityno gateway calls yet and no remote to proben/a
  • –Tool poisoningtools not inspected (local package is not executed); not countedn/a
  • Auth qualitylocal package, no credentials required12/15
  • Maintenancelast push 7 days ago15/15
  • Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10
Overall 92/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

How Billing Doctor compares

Against every graded MCP server, from our own scans and uptime checks. Updated after each scan run.

Safety score
92/100
higher than 95% of 48,255 servers
Tools
6
the typical server has 7
Tools that change things
17%
typical: 0%. Fewer write tools means less an agent can break
Downloads a week
46
more than 38% of 12,191 servers with a package

What its tools let an agent do: 5 read · 1 change

Install Billing Doctor in Claude Code, Cursor or VS Code

Runs npx -y billing-doctor on your machine. Read the scan report first; the gateway never runs local packages.

claude mcp add billing-doctor -- npx -y billing-doctor
Add to Cursor

What the publisher says

From the Billing Doctor repository's README, as published. We do not edit it. Read it on GitHub

Billing Doctor

Billing Doctor reads what happened to a Google Play purchase and tells you where it broke. It runs on your machine, calls nothing, changes nothing at Google, and shows its evidence. Not affiliated with Google.

It is for developers who run their own Google Play Billing backend, in Node, Python, PHP, Go or Java, with Capacitor, Flutter, React Native or native Android in front, and did not choose a subscription platform. It is the tool you run at 11 pm when a subscription broke.

Twenty seconds

The fixture below ships in the repository, so start from a checkout:

git clone https://github.com/lazytitan30/billing-doctor && cd billing-doctor
npx billing-doctor diagnose fixtures/rules/G2-void-then-active.json

(The same fixtures ship inside the npm package: after npm install -g billing-doctor they are under $(npm root -g)/billing-doctor/fixtures/.)

billing-doctor 0.1.1: fixtures/rules/G2-void-then-active.json, 11 events, 1 finding: 1 high

HIGH
  G2  Voided purchase, then a fetch reading ACTIVE, and no revoke  [certain]
      evidence  #8 rtdn voidedPurchase tok_a1 [m-2] answered 200 (2026-09-04T10:00:00Z)
                #9 api subscriptionsv2.get tok_a1 → 200 SUBSCRIPTION_STATE_ACTIVE ack ACKNOWLEDGED (2026-09-04T10:00:01Z)
      mechanism tok_a1 was voided at #8 (the money went back); the fetch at #9 still answered ACTIVE and the ledger never revoked, so the refunded user keeps the tier.
      Google    "(1) REFUND_TYPE_FULL_REFUND - The purchase has been fully voided."
                RTDN reference: VoidedPurchaseNotification, read 2026-09-09: https://developer.android.com/google/play/billing/rtdn-reference
      observed  Seen in a live app, 2026-08: after the voided-purchase notification, purchases.subscriptionsv2.get still answered SUBSCRIPTION_STATE_ACTIVE ...
      next      Revoke tok_a1 now. In the handler, act on voidedPurchaseNotification directly: mark refunded and revoke, regardless of what subscriptionsv2.get answers afterwards.
      fix       runbook G2 (billing-doctor rule G2)

1 finding: 1 high
exit 1: a 

Every finding carries the events it rests on, the mechanism, Google's rule quoted with a dated link, a confidence (certain, likely, possible) and the next thing to check. Exit code 1 means a high finding exists, so the command can gate CI.

What it does

You give it a timeline: one JSON file with what happened to one purchase, assembled from your logs, your database, the Cloud Console and the support ticket. The notifications Google sent, the API answers, what your backend wrote, what the user said. Tokens are pseudonyms; nothing real goes in the file.

It checks the timeline against 97 rules in eleven groups. Every one of them rests on a sentence from Google's own documentation, quoted verbatim with the URL and the date it was read:

Shortened. The full README is on GitHub.

Nothing above is checked by us. What we check is on the safety report.

Billing Doctor: common questions

Is Billing Doctor MCP server safe?
Yes, by our scan: it is graded A (92/100). Read the Billing Doctor safety report
How do I install Billing Doctor?
It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.
Does Billing Doctor need an API key?
Not as far as the registry entry and our scan can tell: no credentials are declared or required.
Is Billing Doctor maintained?
The last commit was 39 days ago (2026-09-26). The latest release is v0.1.1.
How does Billing Doctor compare with other MCP servers?
safety score 92/100 (higher than 95% of 48,255 servers); tools 6 (the typical server has 7); tools that change things 17% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.