BeeL vs X402 Trust MCP
A side-by-side look at the BeeL and X402 Trust MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose BeeL for finance & fintech work as a local process; choose X402 Trust MCP for finance & fintech as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose BeeL when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
BEEL_API_KEY. - You want tools like
beel_activate_company, beel_cancel_representation, beel_change_managed_access_level.
Choose X402 Trust MCP when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You have the keys it needs:
X402_PRIVATE_KEY, X402_MAX_USD. - You want tools like
x402_ecosystem_stats, x402_trust_leaderboard, x402_trust_preview.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Finance & Fintech | Finance & Fintech |
| Quality signal | 63/100 · Good | 64/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Freemium |
| Required env vars | BEEL_API_KEY | X402_PRIVATE_KEYX402_MAX_USD |
| Verified owner | Community listing | Community listing |
| GitHub stars | 2 | 1 |
| Directory activity | 1 views 0 installs 0 upvotes | 4 views 0 installs 0 upvotes |
| Tools | 131 | 13 |
| Full listing | View BeeL | View X402 Trust MCP |
Tools & capabilities
BeeL tools 131
beel_activate_companySwitches an existing company on in the mode carried in the body. The mode is always explicit and never taken from the credential's environment, so a Test key can switch a NIF on in Live. ## Modes and billing - **`TEST`:** immediate and free. - **`PROD`:** immediate when the account already has a card on file or an enterprise contract, and the NIF is added to the existing subscription. With no card on file it answers `402 CHECKOUT_REQUIRED`, returning a `checkout_url` when `success_url` and `cancel_url` are supplied. It also requires being the billing subject of the account (`403 NOT_BILLING_OWNER` otherwise). ## Idempotency and pending switch-offs - **Repeating the call:** opens no second checkout and adds no second subscription item; it returns the existing activation with `already_active: true`. The same `Idempotency-Key` sent to this route and to the nested one it replaces is the same operation, so it is replayed and never charged twice. - **A pending switch-off is cancelled:** while it is pending the NIF is still on — it just carries an effective date — so switching it on again only removes that date, answers `scheduled_deactivation_cancelled: true`, and charges or credits nothing. Endpoint: POST /v1/companies/{company_id}/activationsbeel_cancel_representationCancels the active AEAT representation of a company. - **Effect:** until a new document is generated and signed, the company can no longer submit invoices to AEAT in production. Its activation and its ability to issue non-VeriFactu invoices are untouched. - **No active representation:** rejected with `400`. Cancelling is a state transition, not a delete-if-present. Endpoint: DELETE /v1/companies/{company_id}/representationbeel_change_managed_access_levelUpdates the `access_level` you keep over an account you provisioned. - **Raising it:** only possible while the account is unclaimed. Once its holder has taken ownership you may keep or lower your access, but only they can raise it. - **Billing:** the level never affects it — you pay for the account's subscription at any level. - **`OPERATE`:** issuing invoices on the holder's behalf additionally requires a signed fiscal representation from them. - **Entitlement:** requires `manage_accounts`. Endpoint: PATCH /v1/accounts/{account_id}/access-levelbeel_convert_proforma_to_invoiceConverts an accepted proforma of this company into a real invoice. The new invoice is created as a `STANDARD` draft linked back through `source_proforma_id`. - **What converts:** only proformas in status `ACTIVE`. One shown as `EXPIRED` is still `ACTIVE` underneath and converts too. - **The proforma:** preserved as the record of what the customer accepted — it keeps its `PRO-...` number and PDF and moves to the terminal status `CONVERTED`. - **`issue`:** with `true` the new invoice is numbered and issued in the same atomic call. If issuing fails nothing is created and the proforma stays `ACTIVE`. That includes `400 SERIES_NUMBER_COLLISION`: the number the series would assign is already used by another invoice of the same company, and the series needs review, so contact support. - **Errors:** `422 CONVERSION_REQUIRES_PROFORMA` when the document is not a proforma, `422 PROFORMA_NOT_CONVERTIBLE` when it is not `ACTIVE`, and `409 PROFORMA_ALREADY_CONVERTED` when it has already been converted — a second call never creates a second invoice. Endpoint: POST /v1/companies/{company_id}/invoices/{invoice_id}/convert-to-invoice ⚠️ Read before calling: - The status names, the proforma lifecycle, and which tool performs each operation. (resource: beel://guardrails/invoice-state-machine)beel_create_claim_tokenIssues a single-use `claim_token`, and the `claim_url` built from it, so the account's holder can set a password and take ownership. - **`email`:** send it when the account has no holder yet — the person is created by this call. Omit the body to re-issue the token for the holder the account already has. An `email` that differs from the existing holder's is rejected rather than replacing them. - **Lifetime:** tokens last 30 days, and only the last one issued is live. Issuing again invalidates the previous token, so the old link stops working the moment you ask for a new one. - **Not an invitation:** this hands the account itself over to its holder. To add a further person to an account that already has one, invite them with `POST /v1/accounts/{account_id}/invitations`. - **Entitlement:** requires `manage_accounts`. Endpoint: POST /v1/accounts/{account_id}/claim-tokensbeel_create_invitationCreates a single-use invitation for a person to join the account with the given `account_role`. - **`token`:** the acceptance secret, returned once and never readable again, so deliver it to the invitee. `invitation_url` is the ready-to-use link built from that same token. - **`grants`:** the companies a `MEMBER` starts with. Omit it, or send `[]`, to invite them with no company access yet; an explicit `null` is rejected with `422`. Grants are only valid for `MEMBER`, since `OWNER` and `ADMIN` reach every company implicitly. - **`account_role`:** `OWNER` cannot be invited. An account has exactly one owner, handed over only through `PUT /v1/accounts/{account_id}/owner`. - **`send_email`:** defaults to `false`, so BeeL sends no email and you deliver the token or `invitation_url` yourself. Set it to `true` to have the invitation emailed to `invited_email` as well. Endpoint: POST /v1/accounts/{account_id}/invitationsbeel_create_webhook_subscriptionRegisters an HTTPS endpoint to receive notifications for the event types listed in `events`. - **`secret`:** returned **only** in this response and never again. Store it before discarding the body; deliveries are signed with it and carry the signature in the `BeeL-Signature` header. - **`test_delivery`:** a one-off signed delivery sent to your URL as part of creating the subscription, so you learn whether your endpoint answers without a second call. It is best effort: the subscription exists and is active whatever it says, and the field is `null` when the test could not be run at all. - **`account_relationship`:** which accounts the subscription receives events from — `own` (the default), `managed`, or `all`. - **Limits:** an account holds at most **10 active subscriptions**; creating an eleventh is rejected with `400` `WEBHOOK_ACTIVE_SUBSCRIPTION_LIMIT_REACHED`. Registering the same URL twice creates two subscriptions, and the endpoint then receives each event twice. Endpoint: POST /v1/accounts/{account_id}/webhooksbeel_create_companyCreates a company under the account the request resolves to. The NIF is registered in the name of that account's holder, never in the name of the caller. - **`activate`:** unless it is `false`, the company is switched on in `aeat_environment` and its three default invoice series (ordinary, simplified, corrective) are seeded there. This endpoint never switches an existing company on: that is `POST /v1/companies/{company_id}/activations`. - **`numbering`:** decides the code, format, counter reset and starting number those series are born with. Only accepted when the request activates the company. - **Billing:** no charge is ever started here. Creating a production NIF requires being the billing subject of the account (`403` otherwise), and an account without billing is rejected with `402`; no checkout is opened in either case. - **Duplicates:** a NIF that already exists in the account is rejected with `409`, and the response carries the existing `error.details.company_id`. - **Addresses:** a Spanish postal code (`country_code` omitted or `ES`) must have 5 digits, in `address` and in `legal_representative.address`; otherwise `422 POSTAL_CODE_INVALID_ES` and nothing is created. Other countries' postal codes are free-form. Endpoint: POST /v1/accounts/{account_id}/companies ⚠️ Read before calling: - Which company an operation acts on, and how that is selected. (resource: beel://guardrails/multi-nif) - Why a name that does not match the census makes an invoice unsubmittable. (resource: beel://guardrails/nif-validation) - How a series formats numbers, and which series configurations are rejected. (resource: beel://guardrails/series-and-numbering)beel_create_corrective_invoiceIssues a corrective invoice that amends the invoice in the path. It is a new fiscal document with its own number, not an edit of the original. - **`rectification_type`:** `TOTAL` leaves the original `VOIDED` and rectifies what is still invoiced on it: every line of the original and of its live correctives (voided ones do not count), negated. It takes no `lines` — sending them fails with `422 RECTIFICATIVA_TOTAL_CON_LINEAS`. `PARTIAL` leaves the original `RECTIFIED` and requires the adjustment `lines`. - **Never more than was invoiced:** a `PARTIAL` may raise any amount, but may not take the taxable base of any rate (tax, rate and equivalence surcharge; `SUPLIDO` lines by their amount) below zero once the previous correctives are counted. That fails with `422 CORRECTIVE_EXCEEDS_INVOICED_AMOUNT`, and `error.details` (`CorrectiveInvoiceErrorDetails`) carries `tax_group` (for example `IVA 21%`) and `max_reduction`, how much of that rate is left to rectify. A `TOTAL` on an invoice that previous correctives already brought to zero fails with `422 CORRECTIVE_NOTHING_LEFT_TO_RECTIFY`. - **Not for the withholding alone:** a `PARTIAL` whose lines leave the taxable base of every rate unchanged and only change the withholding fails with `422 CORRECTIVE_WITHHOLDING_ONLY`. A withholding is not a cause for a corrective: void the invoice and issue a new one without it. - **The original's PDF:** unchanged by either type. The corrective has its own PDF; the original keeps the one that was delivered, and its new status is in `status`. - **Total of 0:** a corrective whose `total_to_pay` is 0 has nothing to refund or collect, so it is issued as `PAID`, with `payment_date` equal to `issue_date`. - **What can be rectified:** an ordinary or simplified invoice in `ISSUED`, `SENT`, `PAID`, `OVERDUE` or `RECTIFIED`. Rectifying a corrective fails with `422 CORRECTIVE_NOT_RECTIFIABLE` — to fix an erroneous corrective, issue another one against the original invoice. - **Repeat rectifications:** several `PARTIAL` correctives are allowed, but a `VOIDED` invoice is no longer rectifiable, so a second `TOTAL` against the same invoice fails with `422 INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS`. - **Correcting the recipient's data:** when the invoice recorded its recipient with a wrong name, tax ID or address, send the corrected `recipient` with `rectification_type` `PARTIAL`, `rectification_code` `R4` and no `lines`. The corrective carries the corrected recipient and does not change the amounts: its lines negate what is still invoiced and repeat it, so every rate nets to zero. A different person is not a data correction (`422 CORRECTIVE_RECIPIENT_IS_ANOTHER_PERSON`): correct the invoice in full and issue a new one to the right customer. - **Original rejected by the AEAT:** when VeriFactu rejected the original's record and it has not been resubmitted, the original is not in the AEAT's books: fix and resubmit it first. Until then the request fails with `422 CORRECTIVE_ORIGINAL_RECORD_REJECTED`. - **Deadline:** four years from when the tax accrued (the original's operation date) or, for a cause of article 80 of the VAT Act, from the `circumstance_date` you declare. Past it the request fails with `422 CORRECTIVE_OUT_OF_TIME`, with `deadline` and `counted_from` in `error.details` (`CorrectiveInvoiceErrorDetails`). - **What the reason code requires** (Ley 37/1992, art. 80): `R2` (insolvency) and `R3` (bad debt) need a recipient established in Spain, the Canary Islands, Ceuta or Melilla —an `R2` also accepts a recipient in another EU member state, for insolvency proceedings there— and fail otherwise with `422 CORRECTIVE_RECIPIENT_NOT_ESTABLISHED`. An `R3` needs at least six months since the original's operation date (`422 CORRECTIVE_BAD_DEBT_TOO_EARLY`, with `earliest_date`; one year when the previous year's turnover exceeded 6,010,121.04 €, which is the issuer's to apply), and on an operation with a base of 50 € or less it needs `recipient_is_business` (`422 CORRECTIVE_BAD_DEBT_BASE_TOO_LOW`). The other conditions of each code (claims, guarantees, related parties, filing with the AEAT) are the issuer's to meet. - **Fiscal inheritance on a `PARTIAL`:** a line that omits `irpf_rate` or `equivalence_surcharge_rate` takes it from the **original invoice** — the document being amended — and never from the company's current tax profile, so a profile that changed after the original was issued does not leak into the credit note. An explicit value always wins, `0` included. The surcharge inherits the *regime* (on/off), not the rate: the rate is re-derived from each corrective line's own VAT (21→5.2, 10→1.4, 5→0.62, 4→0.5), and an original outside the regime pins the line to `0`. `SUPLIDO` lines are out of it on both sides. When the original is not unambiguous BeeL does not pick for you: different IRPF rates per line fail with `422 CORRECTIVE_ORIGINAL_MIXED_IRPF`, and a surcharge applied on some lines but not others fails with `422 CORRECTIVE_ORIGINAL_MIXED_SURCHARGE`. Declare the figure on every line to get past either — both only fire when some line actually needs to inherit. - **`series_id`:** when omitted, the document is numbered in the company's default corrective series, never in the series of the original: corrective invoices go in a series of their own (RD 1619/2012, art. 6.1.a). If the company has none, it is created on first use (code `R`, or the next free one that cannot repeat another series' numbers). An explicit `series_id` must be a corrective series. - **Numbering conflict:** if the number the series would assign is already used by another invoice of the same company, in this series or in another one, the request fails with `400 SERIES_NUMBER_COLLISION` without issuing anything or consuming a number. The series needs review, so contact support. Endpoint: POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective ⚠️ Read before calling: - Fiscal rules, domains corrective, void: beel_rules_list with domain, or resource beel://guardrails/<domain>. - How a line states its price, and which field combinations are rejected. (resource: beel://guardrails/invoice-lines) - The status names, the proforma lifecycle, and which tool performs each operation. (resource: beel://guardrails/invoice-state-machine) - How a series formats numbers, and which series configurations are rejected. (resource: beel://guardrails/series-and-numbering)beel_create_customerCreates a new customer under this company. - **`Idempotency-Key`:** it identifies the same operation on the deprecated flat route, so a retry that switches route replays instead of creating twice. Endpoint: POST /v1/companies/{company_id}/customers ⚠️ Read before calling: - Why a name that does not match the census makes an invoice unsubmittable. (resource: beel://guardrails/nif-validation)beel_create_customers_bulkCreates up to 500 customers of this company in a single call. - **Atomic:** if any customer fails validation the whole batch is rejected with `422` `BULK_VALIDATION_ERROR` and nothing is persisted. This is not a partial operation. - **`dry_run`:** with `dry_run=true` the batch is only validated — tax identifiers against the AEAT register, duplicates inside the batch and against the existing customers, field formats — nothing is written and the answer is `200`. With `dry_run=false`, the default, validation is followed by creation and the answer is `201`. - **Report:** both modes return the same per-record report, so a dry run and a real run are read the same way. Endpoint: POST /v1/companies/{company_id}/customers/bulk ⚠️ Read before calling: - Why a name that does not match the census makes an invoice unsubmittable. (resource: beel://guardrails/nif-validation)beel_create_invoiceCreates an invoice for this company. The issuer data comes from the company in the path, and the document is created as a draft unless you ask for it to be issued. - **Issuing:** `options.issue_directly` numbers and issues the invoice in the same call. Submission to the AEAT is asynchronous, so `verifactu.submission_status` comes back as `PENDING`: a 2xx means the invoice was accepted for submission, not that the AEAT has registered it. If the number the series would assign is already used by another invoice of the same company, in this series or in another one, it fails with `400 SERIES_NUMBER_COLLISION` without issuing anything or consuming a number: the series needs review, so contact support. - **Document type:** `type` chooses the document. A `PROFORMA` is non-fiscal — it is born `ACTIVE`, numbered `PRO-...` from its own non-fiscal series, and ignores `issue_directly`. - **Related:** to copy an existing invoice into a new draft, use `POST …/invoices/derivations`, which carries neither `type`, nor `recipient`, nor `lines`. Endpoint: POST /v1/companies/{company_id}/invoices ⚠️ Read before calling: - Fiscal rules, domains simplified, contents, taxes, surcharge: beel_rules_list with domain, or resource beel://guardrails/<domain>. - How a line states its price, and which field combinations are rejected. (resource: beel://guardrails/invoice-lines) - Why a name that does not match the census makes an invoice unsubmittable. (resource: beel://guardrails/nif-validation) - How to tell, before issuing, whether a NIF can issue, and what each blocker means. (resource: beel://guardrails/verifactu-gates) - How a series formats numbers, and which series configurations are rejected. (resource: beel://guardrails/series-and-numbering)- +119 more on the listing page
X402 Trust MCP tools 13
x402_ecosystem_statsFree aggregate snapshot of the entire x402 ecosystem (Base + Solana): how many endpoints are listed/active/delisted, what fraction are reachable and spec-compliant, and real on-chain USDC settlement volume / receivers / payers over the last 30 days. Use this to gauge market health before transacting.x402_trust_leaderboardFree top-25 most trustworthy x402 hosts (providers), ranked by a deterministic trust score. Each host's score is the probe-weighted mean of its listed endpoints' scores, so providers are judged by their whole measured surface instead of one provider flooding the board with path variants. The per-endpoint score blends uptime, envelope compliance, latency, age, on-chain settlement activity and price stability. Latency is measured from a single EU vantage point and includes network distance to the endpoint (so it is only lightly weighted). Use this to discover reliable paid endpoints.x402_trust_previewFREE showcase of what x402_trust_score returns. You do NOT choose the endpoint: this returns the COMPLETE paid-grade trust report (every field — exact score, scoreRange, full component breakdown, advertised price, on-chain settlement figures, all flags) for THREE endpoints picked from the current population — the best-scored, the median, and the worst-scored ('samples' each carry 'role', 'populationRank', and the full 'report'). Use it to see exactly what the paid output looks like across the entire quality range BEFORE paying. It cannot score an endpoint you choose — to evaluate YOUR OWN endpoint, call x402_trust_score (paid). Takes no arguments.x402_trust_scoreTrust score (0-100, grade A-F, or '?' when unmeasured) for a SPECIFIC x402 endpoint -- cataloged or not (uncataloged endpoints are live-probed on first query, auto-adopted, score carries a low-confidence first-contact flag). PLUS a machine-readable verdict ('recommendation': proceed|caution|avoid|parameterize|unverified|not-payable|free), the advertised price ('advertised.amountUsd'), a confidence-adjusted band ('scoreRange'), and structured flags ('flagsDetailed' with code/severity/message; any severity 'error' means avoid). The 'parameterize' verdict (with 'templated':true) means the resource URL still contains an unresolved template placeholder (e.g. {slug}, :slug or %7B…%7D) but we DO have a real signal (scored probes or a discovery fallback): substitute a valid value first, then the health metrics apply to the resolved URL. The 'unverified' verdict (grade '?') means we have NO measurement at all (every probe excluded and no discovery payment requirements to fall back on): it is unknown, not bad, so verify the endpoint yourself before paying. The 'not-payable' verdict (grade '?') means the URL answers a 402 with an EMPTY accepts[] (an auth/API-key gate such as sign-in-with-x), or answers a bare 401/403 with no payment envelope, so it is not an x402-payable resource at all and there is nothing to settle. The 'free' verdict (grade '?') means the endpoint answers plain requests with data (HTTP 200, no payment envelope) and has never presented a payment challenge: a free resource with no payment flow to grade, unmeasured by design, not a negative verdict. For templated per-item endpoints that ARE payable, a varying payTo/price is EXPECTED (one wallet/price per item): the report surfaces 'stats.payToVaries'+'payToDistinct30d' and 'advertised.amountRange30d' as a 'payto-varies'/'price-varies' note rather than a 'payto-changed-recently' hijack error; always pay the payTo in the live 402 quote, not a cached listing. 'stats.scoredProbes30d' vs 'stats.excluded30d' show how many probes actually back the score. When the endpoint's host completed provider verification (domain control proven with a public key in /.well-known/x402-trust.txt plus a confirmed contact email), the report carries 'providerVerified': true, 'providerName' (the provider's own organization name) and 'providerContact' (the confirmed contact address); verified endpoints also carry the 'provider-verified' info flag; verification never changes the score. Includes the full component breakdown, the provider-advertised 'serviceName' and 'description' (unverified provider claims, shown next to our independent metrics), and 30-day on-chain stats. Note: 'stats.avgLatencyMs' is measured from a single EU vantage point and includes network distance to the endpoint (see 'stats.latencyVantage'), so a geographically distant endpoint reads slower even when its server is fast. One call answers WHETHER and at WHAT PRICE to use an endpoint. Call this BEFORE paying an unknown x402 endpoint to avoid dead, fraudulent, or recently-hijacked services. Each paid call also refreshes the endpoint's free public snapshot (page, badge, card) immediately. Pay-per-call over x402; auto-pays if a wallet is configured, otherwise returns the price quote.x402_endpoint_historyRaw observation time-series for a SPECIFIC x402 endpoint: listing/delisting/relisting events, advertised price changes, payTo changes, and probe results over the requested window (1-90 days). Each probe carries 'ts', 'ok', 'latencyMs', 'amount' plus its outcome 'status' (success, dns_error, timeout, http_error, ...), 'httpStatus', an 'error' detail and an 'excluded' flag; excluded probes carry no endpoint signal (rate limits, unresolved URL templates, resolver outages on our side) and never count as downtime. A 'probeSummary' aggregates the window: counts by status, longest failure streak, per-day failure breakdown. Per-probe 'latencyMs' is measured from a single EU vantage point and includes network distance to the endpoint. Pay-per-call over x402; auto-pays if a wallet is configured, otherwise returns the price quote.x402_find_alternativesGiven an x402 endpoint URL, returns the top semantically-similar endpoints (matched on advertised purpose via description embeddings) that currently OUT-SCORE it on the deterministic trust score. Use this to route away from a mediocre/dead/expensive endpoint toward a more reliable, better-settled one serving the SAME function — e.g. before paying, check if a higher-graded equivalent exists. Each alternative carries its trust 'score', 'grade', 'recommendation', cosine 'similarity' (0-1), 'amountUsd' price, 'priceCeiling' (true when amountUsd is an x402 'upto' authorization ceiling, not a fixed per-call price), and a free 'endpointPage' URL. It also carries 'hasDescription': false means the endpoint advertises no description, so its similarity was computed from service name + URL path tokens only, a weaker signal worth more skepticism than a description-based match. Same-host siblings and 'avoid'-flagged endpoints are excluded. An empty 'alternatives' array is a valid answer meaning nothing beats the subject. Similarity is independent of latency/geography. Pay-per-call over x402 (~$0.005); auto-pays if a wallet is configured, otherwise returns the price quote.x402_semantic_searchFree-text SEMANTIC SEARCH across the entire monitored x402 endpoint catalog. Given a plain-language query (e.g. "weather forecast", "image generation", "EVM gas price oracle"), returns the up to 25 endpoints whose advertised purpose is semantically closest. Ranking is deterministic and fully specified: cosine similarity bucketed to whole percentage points first (80.3% and 80.5% are the same bucket, so sub-percent noise never outranks a better endpoint), then trust score (0-100), then described-before-undescribed, then endpoint id as a stable final tiebreak. Matches below a 0.5 cosine-similarity floor are dropped entirely, so a query can return fewer than the requested limit (or none). Endpoints that advertise no description are still matched: they are embedded from their service name and URL path tokens instead of a written description (host name as a last resort). The EXACT effect of a missing description: no fixed point deduction, and no direct similarity malus either; the only deterministic penalty is the described-before-undescribed tiebreak (at equal similarity bucket AND equal trust score, a described endpoint ranks first). Beyond that the effect is purely indirect: the shorter fallback text typically yields lower cosine similarity than a prose description, so undescribed endpoints tend to land in lower similarity buckets, by a query-dependent (never fixed) amount. Use this for DISCOVERY: find candidate endpoints for a capability before checking any of them in depth. Each match carries 'id', 'resource' URL, trust 'score' (0-100), 'grade' (A-F), raw cosine 'similarity' (0-1; ranking buckets it to whole percents), 'amountUsd' price (null when not advertised), 'priceCeiling' (true when amountUsd is an x402 'upto' authorization ceiling, not a fixed per-call price), 'description' when advertised, and a free 'endpointPage' URL. 'score'/'grade' are null for endpoints not yet scored. Deliberately NO verdict/recommendation or flag detail: the per-endpoint trust report (x402_trust_score) carries those. Pay-per-call over x402 (~$0.001); auto-pays if a wallet is configured, otherwise returns the price quote.x402_trust_bulkScore up to 500 x402 endpoints in a SINGLE paid call. Returns the authoritative full-density trust score (0-100, grade A-F or '?' when unmeasured, recommendation proceed|caution|avoid|parameterize|unverified|not-payable|free), confidence, `probed_at`, `computed_at`, and a `recomputed` flag for each requested resource. Cache rows older than ~15 minutes are recomputed on-demand from the latest stored probes and settlements (no live network re-probe), so bulk scores typically reflect reality within minutes. Each recomputed row also refreshes that endpoint's free public snapshot (page, badge, card) immediately. Per-request recompute limits apply: at most 50 endpoints / 8 seconds are recomputed; the response includes `recompute_limit_hit` and `recompute_limit` so you know if the cap was reached. The smallest tier that fits your request is selected automatically (10/50/100/200/500 endpoints; ~$0.045/$0.20/$0.325/$0.40/$0.50). Resources not in our observation set return `found:false`; you still pay for the batch. For a fresh live probe, use `x402_trust_score`. Pay-per-call over x402; auto-pays if a wallet is configured, otherwise returns the price quote.x402_watch_createStart monitoring ONE x402 endpoint for 30 days. Get alerted on changes that break autonomous payment: payTo changes (possible takeover/rug — but for a templated per-item endpoint a payTo move is expected variance and is delivered as severity 'warn', not 'critical'), price changes, asset/network changes, 402-spec regressions, delisting, and liveness down/recovered. A self-healing endpoint that repeatedly blips is auto-detected as `liveness_flapping` and its individual down/up alerts are coalesced into a single flapping notice (plus one 'stopped flapping' notice when it stabilizes) so you are not spammed. Returns a one-time bearer secret + poll URL + renew URL + edit URL + cancel URL + machine-readable `next_steps`. Use x402_watch_events to poll the append-only log, or configure push delivery to one or more signed HTTPS webhooks and/or Slack/Discord incoming webhooks (max 5 each). `webhook_url`/`slack_url` accept a single URL string or an array of URLs. All URLs are connection-tested BEFORE payment — unreachable URLs are rejected with no charge (retry with a corrected URL). On success the response reports per-URL delivery in `delivery.connection_test`. Webhook signature: `x-signature` = 'sha256=' + HMAC-SHA256(body) keyed by hex(sha256(secret)), NOT the raw secret. Pay-per-call over x402 (~$0.20); auto-pays if a wallet is configured, otherwise returns the price quote.x402_watch_eventsRead the append-only event log for an active x402 watch. Returns two streams: `events` (endpoint changes — payTo/price/asset/spec/delisting/liveness) and `watch_events` (lifecycle feedback — created/edited/cancelled/renewed/expiring/expired). Nothing between two polls is lost. Provide the watch_id and the one-time secret from x402_watch_create. Advance `since` with the returned `next_cursor` (endpoint events) and `watch_since` with `watch_events_cursor` (lifecycle events). Cursors/ids are GLOBAL sequences shared across watches (a watch's first event id may be >1); always page by the returned cursor rather than assuming they start at 1. Cancelled watches remain READABLE until expires_at (no new events accrue). If the watch has push delivery, still poll to reconcile missed webhooks.x402_watch_editEdit an active watch: change webhook/Slack URLs, liveness sensitivity, or subscribed events. Bearer-authed with the secret from x402_watch_create. Newly-added URLs are connection-tested before the change is persisted; if any new URL fails, the existing config is unchanged. Delivery fields are full-replace per channel (omit to leave that channel unchanged). Returns the updated watch view.x402_watch_cancelSoft-cancel a watch immediately: no new events accrue, but the event log stays READABLE via x402_watch_events until the original expires_at (cancel is not a delete). Probing drops back to normal cadence as soon as no active watches cover the endpoint. Bearer-authed with the secret from x402_watch_create. Free and idempotent.- +1 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
BeeL
{
"mcpServers": {
"beel": {
"command": "npx",
"args": [
"-y",
"@beel_es/mcp"
],
"env": {
"BEEL_API_KEY": "YOUR_BEEL_API_KEY_HERE"
}
}
}
}
X402 Trust MCP
{
"mcpServers": {
"x402-trust-mcp": {
"command": "npx",
"args": [
"-y",
"x402-trust-mcp"
],
"env": {
"X402_PRIVATE_KEY": "YOUR_X402_PRIVATE_KEY_HERE",
"X402_MAX_USD": "YOUR_X402_MAX_USD_HERE"
}
}
}
}
Frequently asked questions
BeeL is categorized under Finance & Fintech and uses a local stdio subprocess. X402 Trust MCP belongs to Finance & Fintech and uses a local stdio subprocess. Pick BeeL for finance & fintech work and X402 Trust MCP for finance & fintech.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
BeeL has no declared pricing — check the project's own site. X402 Trust MCP is listed as freemium — a free tier with paid plans. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add beel and x402-trust-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, BeeL has a quality signal of 63/100 (Good) with 1 views, 0 installs and 2 GitHub stars. X402 Trust MCP has 64/100 (Good) with 4 views, 0 installs and 1 GitHub stars.