mcpbeat Sign in

BDK Native MCP Server

not responding

BDK Native is listed as active in the registry but did not answer our last check. It exposes 12 tools.

Preview and configure BDK Native apps, check health, buy builds and request delivery.

Uptime history 69 hours of history · worst hour 0%
69 hours agonow
20.9%
Uptime 24h
19 of 91 checks
12
Tools
read from the server
451 ms
Response time
average over 24h
open, no key
Access
streamable-http

BDK Native does not always answer

Over the last week it answered 39.9% of our checks. We check every 15 minutes, so you hear about the next outage within the hour — not from your users.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 11 min ago.

run in your terminal
claude mcp add bdk-native --transport http https://mcp.thebdk.com/mcp
Settings → Connectors → Add custom connector, then paste this address
https://mcp.thebdk.com/mcp
~/.codex/config.toml
[mcp_servers.bdk-native]
url = "https://mcp.thebdk.com/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "bdk-native": {
      "url": "https://mcp.thebdk.com/mcp"
    }
  }
}
.vscode/mcp.json
{
  "servers": {
    "bdk-native": {
      "type": "http",
      "url": "https://mcp.thebdk.com/mcp"
    }
  }
}

Available tools 12

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

bdk
bdk_build
Request a build or rebuild only after explicit approval of that request and the saved settings. A first build requires confirm_build:true after the customer says yes. A ledger rebuild consumes one banked rebuild: pass build_kind:rebuild and confirm_consumes_rebuild:true. free_rebuild is legacy-only. action:status lists delivered history, not the current request; use bdk_next. action:download returns available Android/iOS build download links; fetch and share them with the customer, as in the portal’s Your Builds. Android archives contain an .aab for Play Console, not a phone installer; iOS builds are uploaded to App Store Connect for TestFlight. Never paste keystore passwords or secrets into chat. BDK builds and signs; the customer submits. Holds/checks can refuse a request. Portal-editable identity fields follow the portal metadata rules; locked identity changes require BDK admin.
bdk_check
Read health checks and health_checked_at, not build execution status. run:true schedules an asynchronous check. If scheduled, re-read without run after a minute. If not scheduled, say so and use the portal. A passing check is an observation, not compatibility or store approval.
bdk_checkout
Start or poll a project purchase only after purchase approval. First read bdk_next.commerce and confirm the customer’s platform via bdk_next confirm_product; a default Both is not consent. Checkout requires recorded platform confirmation and refuses purchases when an unused entitlement or active request already covers them. Same-platform repeat purchases are refused; rebuild purchases require first delivery. Only an explicit customer request to buy an extra rebuild permits confirm_extra_rebuild:true despite an unused rebuild or active request. Ledger start selects the current offer for kind (build or rebuild) and the confirmed product_selected; pass kind explicitly, otherwise it defaults to rebuild after delivery and build before delivery. Optional promotion_code comes from the customer. Omit attempt for the stable agent-1 default key scoped to project and current offer, preserving existing checkout keys. Reuse the same attempt for retries. Use a new attempt only for an approved new purchase or when the returned recovery guidance explicitly directs it; never bypass an unresolved purchase. This is a gateway preflight check, not a global purchase lock. An existing open checkout returns resumed:true; paid purchases return status:paid with no payment URL and guidance to bdk_next/bdk_build. An expired unpaid checkout gets at most one replacement start. Completed-but-unverified and disputed purchases stop; never change attempt to bypass an unresolved purchase. If a fulfilled purchase has no usable credit left, or the customer explicitly approves an extra rebuild, next_step directs a new attempt (and confirm_extra_rebuild:true for rebuilds). On an unreadable replay, retry the same start with the same attempt. Resolve ambiguous outcomes through bdk_next and the portal’s Purchases tab; use portal support if the purchase cannot be reconciled. Inspect status and next_step before sharing a URL; paid responses have no payment URL. When quote is present, tell the customer quote.total_minor (minor units of quote.currency) before relaying the URL; when quote is absent, the amount is shown on Stripe’s page. Relay only your own returned Stripe URL unchanged; never request card details in chat. Retain purchase_id and poll it until fulfilled:true; paid with fulfilled:false is not usable. Purchase approval does not authorize a build request. Legacy polling uses checkout_session_id.
bdk_configure
Fetch https://thebdk.com/agent/skill.md and apply only its documented writable fields after approval. Set tnc_accepted:true only after explicit acceptance of https://thebdk.com/terms for this project. launch_link changes installed apps: obtain approval for the exact URL. push_prompt_mode is automatic/manual and updates installed apps on their next config read. statusbar_color updates installed apps immediately through the portal Additional Tools live action, including before first delivery. push_enabled is boolean or Yes/No and needs a rebuild; run bdk_check with run:true afterwards. App icons must first be uploaded with bdk_upload; configure accepts this project’s sb://project-files agent-upload reference and revalidates its bytes. External icon URLs are refused. Keep secrets on the portal. Returns applied, refused and failed keys. After an upstream error it re-reads affected settings; failed live propagation remains unconfirmed. Preserve applied results on partial failure. Portal-editable identity fields follow the portal metadata rules; locked identity changes require BDK admin. Listing fields describe existing listing status, not listing copy.
bdk_create_project
Create a project after approval of the reference label and published app URL. project_name is a reference label, not the home-screen app name; that starts as the website hostname until configured. Duplicates by reference label or site host return candidates: ask the customer to choose create_new or use_existing with project_code; never reuse automatically. For an owner preview, pass from_preview_id to read editable prefill, then submit its observed_website_link. A same_site_project conflict requires explicit link_existing:true with project_code or false to create separately. Offer preview before checkout.
bdk_estimate
With project_code, verify access and read ledger offers; report lookup failure rather than substituting a standard quote. A legacy project without product returns legacy_project; with product, it returns standard prices. Without project_code, product also selects standard prices, not eligibility. offer.unit_amount is in minor units of currency. The tool never creates a payment URL. BDK builds and signs; the customer submits. Fetch purchase terms from https://thebdk.com/agent/pricing.md.
bdk_login
Start a device code for an additional HTTP client from an already authenticated MCP session. This MCP session cannot redeem that code through a tool. For initial or expired MCP authentication, use the host reconnect flow. For HTTP device flow, follow https://thebdk.com/agent/skill.md.
bdk_next
Read workflow state and next steps; call again after each action. confirm_product writes and records the customer-confirmed iOS / Android / Both choice: ask first. Checkout requires recorded confirmation matching the saved platform, even when the saved default already matches the customer's choice. If confirmation is missing or mismatched, send the answer as confirm_product, then re-read. A purchased platform can be locked: use the purchased platform or portal support; do not loop through bdk_configure. Milestones summarise project progress; unknown health or confirmation remains unknown. Preview refers to this project or its matching launch domain and is not proof of phone testing. allowed_tools is advisory. can_request_now does not guarantee the request will be accepted.
bdk_projects
List projects or read a status/progress/health snapshot, not full settings or credentials. Use bdk_next.commerce for ledger entitlement and current requests. Do not infer payment or delivery from legacy status, paid_for_service, requested_build, build_complete, rebuild_credits or free_rebuild_expires_at.
bdk_setup_preview
Creation requires intent:new; legacy app_link + preview_id updates that selected preview. list returns account preview names, published URLs, IDs and creation times. new calls the portal preview-manage create path (same-URL reuse and 20-preview cap); update requires the customer-selected preview_id and replaces that link. Published-link checks reject editor and builder-share links. At cap: Delete an existing preview to add another. Password protection and credentials, including clearing them, stay human-only on the portal. Pairing stays on the customer’s phone, never in chat. On iPhone only own previews open.
bdk_upload
Import a direct public HTTPS PNG, JPEG or WebP image up to 8 MB, without redirects; this does not assign a screen. Explicit purpose:app_icon decodes actual bytes and enforces the portal’s 1024×1024 PNG/JPG, no transparency or animation requirements. Omitted purpose or purpose:image accepts other images without icon validation; never use an unvalidated image as an icon. Use the portal for local files and screens. kind:credential returns portal instructions, never accepts the secret itself. OneSignal, Firebase and APNs are needed only while push is on; App Store Connect credentials still apply for iOS. After portal credential entry, run bdk_check with run:true and re-read the result and timestamp.
bdk_whoami
Read the signed-in user and their projects; call first. product_selected can be an unconfirmed default. Legacy status is not ledger entitlement; use bdk_next.commerce.

Endpoints

URLTransportStateLatencyChecked
https://mcp.thebdk.com/mcp streamable-http answering 56 ms 11 min ago

Alternatives to BDK Native

same job, measured the same way
Sendar
by sendar

Sendar application email: inspect setup, preview, send and check delivery.

answering
Tenkai
by tenkai

Deploy apps to servers you own: projects, deployments, logs, health and pull request previews.

answering
Bootstrapware RFQ
by bootstrapware

Configure buyer and supplier request-for-quote apps. No titles, quotes, prices, or file bytes.

answering
Agent Nexus
by agentnexus

Agent-native registry to discover APIs, MCP servers and CLIs, with live health checks.

6 tools answering
VibeFix
by vibe-fixer

Free check by an AI agent on your live app. On request: independent code review, fix, live re-check.

7 tools answering
Nteli Quoting
by nteli

AI-native product and pricing configuration (CPQ) for manufacturers, every rule checked.

answering
Capgo
by capgo

Ship and update Capacitor apps: live updates, channels, rollouts, devices, native builds, stats.

answering
AppBox
by appboxapp

Set up and check AppBox apps: setup status, builds, devices, guides, tester-only test pushes.

answering

BDK Native — questions

Answers built from our own checks of this server.

What can BDK Native do?
It exposes 12 tools, read directly from the server on our last check. Among them: bdk_build, bdk_check, bdk_checkout, bdk_configure, bdk_create_project, bdk_estimate and 6 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is BDK Native working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 19 of 91 checks got a reply (20.9%), average response time 451 ms. The bar chart above shows every period we have measured.
The registry lists BDK Native as active — why does it not respond?
The official MCP registry stores what the author submitted; it does not verify that the server still runs. We check the endpoint ourselves, and this one does not answer. Catalogues that copy the registry without checking will show it as working.
How do I connect BDK Native?
Copy the ready config from this page. We generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each in the form that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does BDK Native need an API key?
No. BDK Native completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 12 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is BDK Native?
It answers our handshake in 451 ms on average, which is faster than 27% of all working MCP servers we measure. The comparison comes from our own checks across the whole registry, every 15 minutes.