Skip to content

com.bidda/bidda-compliance

by bidda.com · remote · no sign-in to list tools · v1.6.0 · published by com.bidda

10,065 source-verified compliance nodes, 39 pillars, 25 MCP tools (EU AI Act, GDPR, NIST, MITRE).

Changes · 13

25 tools: 13 change things and 12 only read.

Scanned Oct 21, 2026

1 check matched something in the tool definitions. No finding is not a safety guarantee. How the checks work.

claude mcp add --transport http bidda-compliance https://bidda.com/mcp

Findings

Matches of fixed checks, with the text they matched.

1 warn
  • The server marks "point_in_time" as not read-only (readOnlyHint: false), and its words say it reads.

    Matched text

    annotations: {"readOnlyHint":false,"destructiveHint":false,"idempotentHint":false,"openWorldHint":true}; The description's first verb is "get": a word for reading.

    What this check looks for

Tools

Open a tool for its reasons and full description. Descriptions are the publisher's own words, shown as they are.

25 tools

Changes things 13Claude Code: ask
  • check_action_compliancePre-flight regulatory check.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
    Description, as the server wrote it
    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 workflows.

    Annotations the server declares

    • title: Pre-flight compliance check
    • readOnlyHint: true
    • openWorldHint: true
  • consult_nodeThe 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 op…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    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 active Bidda subscription: pass api_key.

    Annotations the server declares

    • title: Consult a rule and record it
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: false
    • openWorldHint: true
  • create_attestationCreate a signed, time-stamped record of which Bidda rules a person or AI agent relied on for a decision.No findings

    Why it is in this group

    • The name "create_attestation" says "create": a word for a change.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Sign a decision record
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: false
    • openWorldHint: true
  • create_control_attestationSign a tamper-evident record of one of YOUR OWN controls or policies and the Bidda obligation nodes it maps to.No findings

    Why it is in this group

    • The name "create_control_attestation" says "create": a word for a change.
    • The input takes a statement or command to run (input.statement), which can change anything it can reach.
    Description, as the server wrote it
    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. Requires an active Bidda subscription: pass api_key.

    Annotations the server declares

    • title: Sign a control attestation
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: false
    • openWorldHint: true
  • drift_checkCheck whether the compliance rules an agent has cached in its own memory are still current.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
    Description, as the server wrote it
    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 scales with your plan. Pass api_key.

    Annotations the server declares

    • title: Check cached rules for drift
    • readOnlyHint: true
    • openWorldHint: true
  • gap_checkGiven 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 oblig…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Check coverage for prerequisite gaps
    • readOnlyHint: true
    • openWorldHint: true
  • obligation_deltasThe 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,…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Get obligation-level changes
    • readOnlyHint: true
    • openWorldHint: true
  • open_runOpen 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).No findings

    Why it is in this group

    • The name "open_run" says "open": a word for a change.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Open a run ledger
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: false
    • openWorldHint: true
  • oscal_assessment_resultsExport 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 c…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Export OSCAL assessment results
    • readOnlyHint: true
    • openWorldHint: true
  • point_in_timeGet a signed record of which committed version of a rule was authoritative at a specific past date, anchored to the public history chain.1 finding

    Why it is in this group

    • The description's first verb is "get": a word for reading.
    • The server marks it as not read-only (readOnlyHint: false).

    Findings

    • Warn

      The server marks "point_in_time" as not read-only (readOnlyHint: false), and its words say it reads.

      Matched text

      annotations: {"readOnlyHint":false,"destructiveHint":false,"idempotentHint":false,"openWorldHint":true}; The description's first verb is "get": a word for reading.

      What this check looks for
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Sign a point-in-time record
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: false
    • openWorldHint: true
  • record_run_entryAppend 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).No findings

    Why it is in this group

    • The name "record_run_entry" says "run": a word for a change.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Record a run entry
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: false
    • openWorldHint: true
  • seal_runSeal an open run into one signed Run Receipt covering every entry, with a public verify URL.No findings

    Why it is in this group

    • The name "seal_run" says "run": a word for a change.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Seal a run into a signed receipt
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: true
  • watch_changesSubscribe to regulatory change alerts: watch specific rules and/or whole pillars and get notified by email or webhook when their primary source changes.No findings

    Why it is in this group

    • The description's first verb is "subscribe": a word for a change.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Create a regulatory change alert
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: false
    • openWorldHint: true
Only reads 12Claude Code: allow
  • browse_topicsBrowse the registry by cross-cutting compliance TOPIC (for example data breach notification, AI transparency, AML and KYC).No findings

    Why it is in this group

    • The name "browse_topics" says "browse": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Browse rules by topic
    • readOnlyHint: true
    • openWorldHint: true
  • compare_jurisdictionsCompare how different jurisdictions address a compliance topic, side by side, including where their numeric thresholds differ (for example a breach-notification deadline of 72 hour…No findings

    Why it is in this group

    • The name "compare_jurisdictions" says "compare": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Compare jurisdictions
    • readOnlyHint: true
    • openWorldHint: true
  • get_audit_packExport 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 inte…No findings

    Why it is in this group

    • The name "get_audit_pack" says "get": a word for reading.
    Description, as the server wrote it
    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 your api_key.

    Annotations the server declares

    • title: Export a governance evidence pack
    • readOnlyHint: true
    • openWorldHint: true
  • get_crosswalkReturn the cross-framework mapping dimensions for a node: which other regulations, standards, or jurisdictions this rule maps to (e.g.No findings

    Why it is in this group

    • The name "get_crosswalk" says "get": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Get cross-framework mapping
    • readOnlyHint: true
    • openWorldHint: true
  • get_dependency_chainWalk the prerequisite chain for a compliance node.No findings

    Why it is in this group

    • The name "get_dependency_chain" says "get": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Get prerequisite chain
    • readOnlyHint: true
    • openWorldHint: true
  • get_jurisdiction_bundleReturn all compliance nodes that apply in a specific jurisdiction (EU, US, UK, Australia, Singapore, India, Canada, China, South Africa, Japan, Brazil and others).No findings

    Why it is in this group

    • The name "get_jurisdiction_bundle" says "get": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Get rules by jurisdiction
    • readOnlyHint: true
    • openWorldHint: true
  • get_latest_changesList the most recently updated compliance nodes: the regulatory change feed.No findings

    Why it is in this group

    • The name "get_latest_changes" says "get": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Get regulatory change feed
    • readOnlyHint: true
    • openWorldHint: true
  • get_mitre_mappingThe MITRE Rosetta Stone.No findings

    Why it is in this group

    • The name "get_mitre_mapping" says "get": a word for reading.
    Description, as the server wrote it
    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 (technique IDs) and how compliance teams think (control families). Free.

    Annotations the server declares

    • title: Map MITRE technique to controls
    • readOnlyHint: true
    • openWorldHint: true
  • get_nodeGet a specific compliance node by its ID.No findings

    Why it is in this group

    • The name "get_node" says "get": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Get compliance rule
    • readOnlyHint: true
    • openWorldHint: true
  • get_runFetch a run and its entries.No findings

    Why it is in this group

    • The name "get_run" says "get": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • title: Get a run and its entries
    • readOnlyHint: true
    • openWorldHint: true
  • list_pillarsList all compliance pillars in the Bidda Sovereign Intelligence registry with node counts.No findings

    Why it is in this group

    • The name "list_pillars" says "list": a word for reading.
    Description, as the server wrote it
    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 and more.

    Annotations the server declares

    • title: List compliance pillars
    • readOnlyHint: true
    • openWorldHint: true
  • search_nodesSearch Bidda compliance nodes by keyword.No findings

    Why it is in this group

    • The name "search_nodes" says "search": a word for reading.
    Description, as the server wrote it
    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".

    Annotations the server declares

    • title: Search compliance rules
    • readOnlyHint: true
    • openWorldHint: true

This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.

Install

Pinned to version 1.6.0. Values in angle brackets are yours to fill in.

claude mcp add --transport http bidda-compliance https://bidda.com/mcp

Run in a terminal.

Claude Code permissions

Allow the reads, ask before a change, deny the deletes. Paste into .claude/settings.json.

.claude/settings.json
{
  "permissions": {
    "allow": [
      "mcp__bidda-compliance__list_pillars",
      "mcp__bidda-compliance__search_nodes",
      "mcp__bidda-compliance__get_node",
      "mcp__bidda-compliance__get_dependency_chain",
      "mcp__bidda-compliance__get_crosswalk",
      "mcp__bidda-compliance__get_latest_changes",
      "mcp__bidda-compliance__get_jurisdiction_bundle",
      "mcp__bidda-compliance__get_mitre_mapping",
      "mcp__bidda-compliance__browse_topics",
      "mcp__bidda-compliance__compare_jurisdictions",
      "mcp__bidda-compliance__get_audit_pack",
      "mcp__bidda-compliance__get_run"
    ],
    "ask": [
      "mcp__bidda-compliance__check_action_compliance",
      "mcp__bidda-compliance__create_attestation",
      "mcp__bidda-compliance__point_in_time",
      "mcp__bidda-compliance__watch_changes",
      "mcp__bidda-compliance__open_run",
      "mcp__bidda-compliance__record_run_entry",
      "mcp__bidda-compliance__consult_node",
      "mcp__bidda-compliance__seal_run",
      "mcp__bidda-compliance__drift_check",
      "mcp__bidda-compliance__create_control_attestation",
      "mcp__bidda-compliance__gap_check",
      "mcp__bidda-compliance__obligation_deltas",
      "mcp__bidda-compliance__oscal_assessment_results"
    ],
    "deny": []
  }
}

Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. It assumes the server is installed as bidda-compliance. Review it before you use it.