Bidda Compliance is a remote MCP server that gives an AI agent 25 tools, among them browse_topics, check_action_compliance, compare_jurisdictions. It answers at https://bidda.com/mcp over streamable HTTP, and it listed its tools to an anonymous client, so no sign-in was needed for that. Our probes reached it 10 of 10 times since 4 September 2026; the last check, on 18 October 2026, succeeded.
9,762 source-verified compliance nodes (EU AI Act, GDPR, HIPAA, DORA, NIST, MITRE). 14 MCP tools.
Description as the publisher wrote it.
| Tool | What it does |
|---|---|
browse_topics | 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 Inputs: topic |
check_action_compliance | 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 Inputs: action, jurisdiction, limit |
compare_jurisdictions | 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 an Inputs: topic, api_key |
consult_node | 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 cur Inputs: run_id, node_id, user_input, input_hash, decision, action |
create_attestation | 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 ke Inputs: agent, nodes, action, workflow_steps_followed, api_key |
create_control_attestation | 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 mapp Inputs: control, statement, nodes, framework, effective_date, control_status |
drift_check | 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 (cont Inputs: anchors, api_key |
gap_check | 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 withd Inputs: nodes, depth, api_key |
get_audit_pack | 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 th Inputs: run_id, api_key |
get_crosswalk | 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; f Inputs: node_id |
get_dependency_chain | 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 us Inputs: node_id, max_depth |
get_jurisdiction_bundle | 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 Inputs: jurisdiction, limit |
get_latest_changes | 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 comp Inputs: days, pillar |
get_mitre_mapping | 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, IS Inputs: technique_id |
get_node | 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 Inputs: id |
get_run | 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. Inputs: run_id, api_key |
list_pillars | 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, includ |
obligation_deltas | 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 chang Inputs: since, pillar, nodes, limit, api_key |
open_run | 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 sig Inputs: agent, label, api_key |
oscal_assessment_results | 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 + integr Inputs: run_id, api_key |
point_in_time | 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 subsc Inputs: node_id, as_of, api_key |
record_run_entry | 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 subsc Inputs: run_id, nodes, decision, action, note, input_hash |
seal_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. Inputs: run_id, api_key |
search_nodes | 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 Inputs: query, pillar, limit |
watch_changes | 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. Inputs: nodes, pillars, channels, webhook_url, label, api_key |
Every block below points at https://bidda.com/mcp. Pick your client and copy.
claude mcp add --transport http bidda-compliance https://bidda.com/mcp
{
"mcpServers": {
"bidda-compliance": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://bidda.com/mcp"]
}
}
}{
"mcpServers": {
"bidda-compliance": {
"url": "https://bidda.com/mcp"
}
}
}{
"servers": {
"bidda-compliance": {
"type": "http",
"url": "https://bidda.com/mcp"
}
}
}{
"context_servers": {
"bidda-compliance": {
"url": "https://bidda.com/mcp"
}
}
}{
"mcpServers": {
"bidda-compliance": {
"serverUrl": "https://bidda.com/mcp"
}
}
}{
"mcpServers": {
"bidda-compliance": {
"url": "https://bidda.com/mcp"
}
}
}name: Bidda Compliance
version: 0.0.1
schema: v1
mcpServers:
- name: Bidda Compliance
type: streamable-http
url: https://bidda.com/mcp{
"mcpServers": {
"bidda-compliance": {
"httpUrl": "https://bidda.com/mcp"
}
}
}{
"mcpServers": {
"bidda-compliance": {
"type": "http",
"url": "https://bidda.com/mcp"
}
}
}{
"mcpServers": {
"bidda-compliance": {
"url": "https://bidda.com/mcp"
}
}
}goose://extension?url=https%3A%2F%2Fbidda.com%2Fmcp&type=streamable_http&id=bidda-compliance&name=Bidda%20Compliance
It answered our last check on 18 October 2026 in 624 ms. Over 10 checks since 4 September 2026 it answered 10. Status here comes from Neuronto's own probes, not from the publisher.
Yes. It is published by bidda.com and served from bidda.com, the vendor's own domain: https://bidda.com/mcp.
25, as returned by the server's own tools/list on 10 September 2026: browse_topics, check_action_compliance, compare_jurisdictions, consult_node, create_attestation, create_control_attestation, drift_check, gap_check, and 17 more.
It answered our last check on 18 October 2026 in 624 ms. Over 10 checks since 4 September 2026 it answered 10.
Put the server under mcpServers in ~/.cursor/mcp.json with the URL https://bidda.com/mcp. The exact JSON is above, with the same setup for Claude Code, Claude Desktop, VS Code, Windsurf, Zed, Gemini CLI and the rest.
It listed its tools to an anonymous client, so reading the tool list needs no key. Individual tools can still ask for credentials in their own inputs.
Publisher: com.bidda. Endpoint host: bidda.com. ARD identifier: urn:air:com.bidda:mcp:bidda-compliance.
First indexed 31 August 2026. The tools are exactly what the server returned; nothing on this page
is inferred from its name. Ranking in Neuronto search is never for sale.