Local MCP capabilities provider for Expo
Nothing to run from here
Bidda Compliance is installed from its publisher's own source and answers where it runs, so this marketplace is not in the path of a single call. There is no address here to send one to, and a panel that pretended otherwise would be showing you an answer we made up. Install it and call it from your own client — the Installation tab has the entry for each one.
25
tools declared
—
trust score
remote
at its publisher
—
calls last 7d
What it does
10,065 source-verified compliance nodes, 39 pillars, 25 MCP tools (EU AI Act, GDPR, NIST, MITRE).
Quickstart
# 1 — add it to Claude Code
claude mcp add --scope user --transport http bidda-compliance-mcp https://bidda.com/mcp
# 2 — ask your agent for something these tools do
# list_pillars, search_nodes, get_node and 22 more
Bidda Compliance costs nothing on mcprush: there is no plan to choose here, no cap to set and nothing mcprush can bill you for.
Publishernot claimed
BIAll 1 server
bidda1 server
1 category
Collected from a public index. Nobody has claimed this account, so nothing here was written by its author — claim it if it is yours.
Installation
Where are you running it?
Every route below installs the same thing and ends at the same approval screen. Nothing here runs on your machine and nothing runs on ours: this server answers at its publisher’s own address, and what you install is the connection straight to it.
Claude Codedeclared by this listing
This is a public server: it answers at its publisher’s own address and this marketplace is not in the path. Claude Code registers it in one command; --scope user makes it available in every project. The transport below is http, as the publisher's own manifest declares it.
claude mcp add --scope user --transport http bidda-compliance-mcp https://bidda.com/mcpReconnect, or start a new session, and the tools appear in the model’s tool list.
Free on mcprush, and it answers at its publisher’s own address: this marketplace is not in the path, so there is no key of ours to hold and no card to add.
What it writes
One config entry pointing straight at the publisher’s own address — this marketplace is not in the path, and nothing from this listing executes on your machine.
What you approve
25 tools, with what each one reads, writes and reaches shown before you agree — the same list on every route above. Read the tool surface.
Tool surface
What the model actually sees. Descriptions are diffed on every release — see version history.
List all compliance pillars in the Bidda Sovereign Intelligence registry with node counts. Use this first to discover available compliance domains before searching. Bidda has 10,099 cryptographically-verified nodes across 39 pillars, including a MITRE layer spanning 6 frameworks (ATT&CK Enterprise/Mobile/ICS, D3FEND, ATLAS, CAPEC) plus Banking, AI Governance, Cybersecurity, Healthcare, Legal, ESG
No parameter schema on file.
Search Bidda compliance nodes by keyword. Returns matching node summaries including a one-sentence BLUF (Bottom Line Up Front): the exact compliance obligation in plain language. Every node traces to a primary legal source (no hallucination). Examples: "Basel III capital", "GDPR data breach", "AML transaction monitoring", "SOC 2 Type II".
| Parameter | Type | Required | Notes |
|---|---|---|---|
| query | string | yes | Search terms, e.g. "Basel III capital requirements", "GDPR data breach notification 72 hours", "FATF travel rule" |
| pillar | string | no | Optional: filter by pillar name, e.g. "Banking & Global Finance", "Cybersecurity", "AI Governance & Law", "Medical & Healthcare" |
| limit | number | no | Max results (default 10, max 25) |
Get a specific compliance node by its ID. Returns the node summary: title, compliance pillar, version, last updated, and BLUF. The full node (machine-executable deterministic workflow, actionable schema, primary legal citations, dependency chain) is available at bidda.com.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | yes | Node ID, e.g. "basel-iii-capital", "gdpr-article-5-principles", "fatf-40-recommendations-2023-consolidated", "us-hipaa-privacy-rule" |
Walk the prerequisite chain for a compliance node. Given one node, returns its full dependency tree (the prior obligations an agent must satisfy before this one applies). Use this to plan a complete compliance posture: unlocking one node usually requires understanding 3-8 upstream nodes. Defaults to depth 2; max 4.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| node_id | string | yes | Root node ID to expand from. |
| max_depth | integer | no | How many hops to walk (1-4). Default 2. |
Return the cross-framework mapping dimensions for a node: which other regulations, standards, or jurisdictions this rule maps to (e.g. GDPR Article 17 → CCPA right-to-delete → POPIA Section 24). Discovery returns the available dimensions; full mapping values are vault-gated.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| node_id | string | yes | Node ID to inspect crosswalks for. |
List the most recently updated compliance nodes: the regulatory change feed. Use to monitor incoming amendments, new guidance, or freshly added rules. Filter by pillar to focus on a domain. Agents should call this on a schedule to keep compliance posture current.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| days | integer | no | Look back N days. Default 30. Max 180. |
| pillar | string | no | Optional pillar filter, e.g. "AI Governance" or "Cybersecurity". |
Return all compliance nodes that apply in a specific jurisdiction (EU, US, UK, Australia, Singapore, India, Canada, China, South Africa, Japan, Brazil and others). Use when an agent enters a new market and needs the full regulatory surface for that geography.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| jurisdiction | string | yes | Jurisdiction code or name: eu, us, uk, au, sg, india, canada, china, south-africa, japan, brazil. |
| limit | integer | no | Max nodes to return. Default 25. Max 100. |
The MITRE Rosetta Stone. Given a MITRE technique ID across 5 frameworks (ATT&CK Enterprise, ATT&CK Mobile, ATT&CK ICS, D3FEND, ATLAS), return the Bidda node for that technique plus its mapped compliance obligations: NIST 800-53 controls, ISO 27001 Annex A clauses, PCI DSS requirements, NIS2 articles, HIPAA Security Rule, DORA articles, NERC CIP, IEC 62443. The bridge between how SOC teams think (t
| Parameter | Type | Required | Notes |
|---|---|---|---|
| technique_id | string | yes | MITRE technique ID. ATT&CK Enterprise (T1566, T1486, T1078, T1003.001, T1547.001); ATT&CK Mobile (T1474, T1521, T1471, T1430, T1417); ATT&CK ICS (T0883, T0809, T0879, T0886, T0814); D3FEND (D3-FIM, D3 |
Pre-flight regulatory check. Agent describes an intended action in natural language ("process EU resident biometric data", "transfer health records to a third-party AI vendor", "deploy autonomous trading model in Singapore") and receives a ranked list of regulations that may apply, plus a risk indicator (LOW/MODERATE/HIGH). The primary tool for runtime compliance gating in autonomous agent workflo
| Parameter | Type | Required | Notes |
|---|---|---|---|
| action | string | yes | Natural-language description of the intended action. |
| jurisdiction | string | no | Optional jurisdiction filter (eu, us, uk, etc.). |
| limit | integer | no | Max matches to return. Default 10. Max 25. |
Browse the registry by cross-cutting compliance TOPIC (for example data breach notification, AI transparency, AML and KYC). Returns each topic with how many rules carry it and across how many pillars and jurisdictions. Topics sit on top of the 39 pillars without replacing them. Free, no key required. Pass a topic string to drill into one.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| topic | string | no | Optional topic name to filter or drill into. |
Compare how different jurisdictions address a compliance topic, side by side, including where their numeric thresholds differ (for example a breach-notification deadline of 72 hours versus 30 days). It surfaces the real rules and numbers and does not rank which jurisdiction is stricter. Requires an active Bidda subscription: pass your key as api_key.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| topic | string | yes | Topic to compare, for example "data breach notification". |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
Create a signed, time-stamped record of which Bidda rules a person or AI agent relied on for a decision. Returns a record ID and a public verify URL so anyone can later confirm the record has not been changed. Useful for agents that must keep an audit trail of what they checked. Requires an active Bidda subscription: pass api_key.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| agent | string | yes | The system or AI agent that made the decision. |
| nodes | array | yes | node_ids that were checked (max 50). |
| action | string | no | Optional: what the agent did. |
| workflow_steps_followed | array | no | Optional: steps the agent followed. |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
Get a signed record of which committed version of a rule was authoritative at a specific past date, anchored to the public history chain. Useful when an agent must show what a rule said at the moment it acted. Requires an active Bidda subscription: pass api_key.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| node_id | string | yes | The rule (node_id). |
| as_of | string | no | ISO date or time, or epoch milliseconds. Defaults to now. |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
Subscribe to regulatory change alerts: watch specific rules and/or whole pillars and get notified by email or webhook when their primary source changes. Requires an active Bidda subscription: pass api_key.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| nodes | array | no | node_ids to watch. |
| pillars | array | no | Pillar names to watch. |
| channels | object | no | Delivery channels, for example { "email": true, "webhook": false }. Defaults to email. |
| webhook_url | string | no | Required if the webhook channel is enabled. |
| label | string | no | Optional name for the alert. |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
Open a run ledger: a signed, tamper-evident log of what an agent does across a whole task or conversation (for example a support-bot chat). Returns a run_id. Record one entry per turn with record_run_entry, then seal_run to get a single signed Run Receipt. Requires an active Bidda subscription: pass api_key.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| agent | string | yes | The system or agent running the task or conversation. |
| label | string | no | Optional human label, for example the chat or ticket id. |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
Append one entry to an open run: which Bidda rules the agent consulted, what it decided, and the end user's input (as text via note, or privately as input_hash). Each entry is hash-chained to the previous one. Requires an active Bidda subscription: pass api_key.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| run_id | string | yes | The run_id returned by open_run. |
| nodes | array | no | Optional node_ids the agent consulted (max 50). |
| decision | string | no | Optional: what the agent decided or did this turn. |
| action | string | no | Optional: an action the agent took or checked. |
| note | string | no | Optional: the end user's message as text. |
| input_hash | string | no | Optional: a sha256:... hash of the user's message instead of the text. |
| output_hash | string | no | Optional: a sha256:... hash of the agent's output. |
| entry_type | string | no | Optional: node_consulted | action_checked | decision | note. Defaults to note. |
| verify_nodes | boolean | no | Optional: pin each node in "nodes" to its current version + integrity hash (proof, not just a claim). No extra call charge. |
| model | string | no | Optional: the model id/version that produced this decision (e.g. gpt-4o-2024-08-06). |
| subject_hash | string | no | Optional: a sha256:... hash of an end-user identifier for per-subject traceability. Hash only, never plaintext. |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
The one-call governed turn: fetch the full vault node (this consumes one call on your key, exactly like unlocking a node) AND record a verified node_consulted entry for it on an open run, in a single step. The entry pins the node to its current version + integrity hash, so the run receipt proves what the agent actually consulted. Use this instead of get_node when you are inside a run. Requires an
| Parameter | Type | Required | Notes |
|---|---|---|---|
| run_id | string | yes | The open run to record into (from open_run). |
| node_id | string | yes | The rule to fetch and record. |
| user_input | string | no | Optional: the end user's message as text. |
| input_hash | string | no | Optional: a sha256:... hash of the user's message instead of the text. |
| decision | string | no | Optional: what the agent decided using this node. |
| action | string | no | Optional: an action the agent took or checked. |
| model | string | no | Optional: the model id/version making the decision. |
| subject_hash | string | no | Optional: a sha256:... hash of an end-user identifier. Hash only. |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
Export a run as a governance evidence pack: the signed receipt, every entry, a roll-up of the nodes consulted (with pinned versions/hashes), an independent hash-chain + Merkle integrity self-check, and a coversheet mapping the receipt to the record-keeping obligations it supports (EU AI Act Art. 12/26, ISO/IEC 42001, NIST AI RMF). A sealed run is readable by id; a still-open run's draft pack needs
| Parameter | Type | Required | Notes |
|---|---|---|---|
| run_id | string | yes | The run to export. |
| api_key | string | no | Optional: your Bidda key, required for a still-open (unsealed) run. |
Seal an open run into one signed Run Receipt covering every entry, with a public verify URL. Idempotent: sealing an already-sealed run returns the same receipt. Requires an active Bidda subscription: pass api_key.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| run_id | string | yes | The run_id to seal. |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
Fetch a run and its entries. The owner can read an open or sealed run (pass api_key); a sealed run is also publicly readable by id and reports whether its signature is valid.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| run_id | string | yes | The run_id to fetch. |
| api_key | string | no | Optional: your Bidda key, required to read your own still-open run. |
Check whether the compliance rules an agent has cached in its own memory are still current. Submit the node_id and the integrity hash you stored when you last grounded on each rule; get back, per rule, whether it is fresh, has drifted (content changed), or was withdrawn (instrument repealed) - so the agent re-grounds before acting on stale law. Included with every API tier; the per-call batch size
| Parameter | Type | Required | Notes |
|---|---|---|---|
| anchors | array | yes | The cached rules to check. |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
Sign a tamper-evident record of one of YOUR OWN controls or policies and the Bidda obligation nodes it maps to. Each obligation is pinned to its current version + integrity hash at signing time, so the record shows what the control was mapped against on that date. This is the design-side evidence ('we operate this control, mapped to these obligations'); run receipts are the operating-side evidence
| Parameter | Type | Required | Notes |
|---|---|---|---|
| control | string | yes | The name of your control or policy. |
| statement | string | yes | What the control does or asserts (plain text). |
| nodes | array | yes | Obligation node_ids the control maps to (max 50). |
| framework | string | no | Optional: the framework you are mapping to (e.g. "EU AI Act"). |
| effective_date | string | no | Optional: YYYY-MM-DD the control took effect. |
| control_status | string | no | Optional: implemented | planned | in-progress. |
| control_owner | string | no | Optional: the role or team that owns the control. |
| evidence_ref | string | no | Optional: a reference/URL/hash to your own evidence (kept by you). |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
Given the compliance rules a team says it covers, return the prerequisite rules Bidda's dependency graph links to them that were NOT listed - the 'you missed the prerequisite obligation' gaps - plus any covered rule the registry marks withdrawn. A coverage aid for a qualified reviewer; it does not rank or determine compliance. Requires an active Bidda subscription: pass api_key.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| nodes | array | yes | The node_ids you cover (max 200). |
| depth | number | no | Optional: how many dependency hops to walk (1-3, default 1). |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
The obligation-level change feed: primary sources whose content changed (or whose node was withdrawn), mapped to the Bidda obligation nodes they affect, filterable by time, pillar, or specific nodes. Use it to answer 'what obligations changed since I last reviewed?'. Requires an active Bidda subscription: pass api_key.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| since | string | no | Optional: ISO timestamp; only deltas newer than this are returned. |
| pillar | string | no | Optional: restrict to one pillar. |
| nodes | array | no | Optional: restrict to deltas affecting these node_ids. |
| limit | number | no | Optional: max deltas to return (default 100, max 500). |
| api_key | string | no | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes preced |
Export a governed run's evidence as a NIST OSCAL assessment-results document (the machine-readable format GRC and audit tooling consumes): reviewed-controls (the obligation nodes consulted), observations (each pinned to its version + integrity hash), and props recording the independent integrity self-check. A sealed run is readable by id; a still-open run needs your api_key.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| run_id | string | yes | The run to export as OSCAL assessment-results. |
| api_key | string | no | Optional: your Bidda key, required for a still-open (unsealed) run. |
Free
$0 forever
- Every tool — any call limit is its publisher’s, not ours
- No card, and mcprush charges nothing for it
- Runs at its publisher’s own address — this marketplace is not in the path
- Nothing to cap, because mcprush bills nothing
What counts against your monthly calls
| Tool | Unit | Calls used | Out of the allowance |
|---|
Nothing here is billable: mcprush charges nothing to install Bidda Compliance or to call it, at any volume.
Call allowance · this installenforced at the gateway
Monthly allowance, in calls
—
—
Alert at 80% · then the tool returns a normal MCP error
Used this month: —
—Grade not published
No rule-by-rule report on file for this release
Two independent axes, because powerful and malicious are different questions. The grade is threat only. The capability level is blast radius, and it is never a penalty on the grade — it is priced as one subtract-only term in the score, where you can see it.
This listing is an address its publisher runs, and you connect to it directly — this marketplace is not in the path. The scanner reads packages and public source, and an address is neither. So there is no grade — not a withheld one, an unmeasured one.
Release history
This is an address its publisher runs: which release it serves is theirs to choose, so there is nothing here to pin. The history below is for reading; the current release on file is 1.6.0.
1.6.0
undated
latestNo release note was published with this version.
—
no reviews yet
Who can review
One review per account, from a signed-in account that does not publish this listing. Nothing else is asked — you can say what you think before you install it. Publishers can reply once per review, and a review can be edited or deleted by whoever wrote it.
Sign in to write one
Any signed-in account that does not publish Bidda Compliance can review it, once — before installing it or after. A review from an account that has installed it is marked as one.
No reviews yet
Nobody has reviewed this listing. The rating on the card is the mean of the reviews written here and nothing else, so there is no rating until somebody writes the first — which takes a signed-in account that does not publish it, and nothing else.