bidda-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_pillars | List every sovereign compliance pillar (regulated domain) in the Bidda registry with its live node count. Bidda holds 10,000+ source-verified nodes across 39 pillars, including a MITRE layer spanning 6 frameworks (ATT&CK Enterprise, Mobile and ICS, D3FEND, CAPEC, ATLAS). Call this first to map the regulatory landscape. |
| search_nodesA | Keyword search across the Bidda registry of source-verified compliance obligations. Returns matching nodes with their id, title, pillar, and a plain-language summary (BLUF). Every node traces to a primary legal source. Use to find the rule that governs a topic, law, standard, or MITRE technique. Examples: 'GDPR breach notification 72 hours', 'Basel III capital', 'SOC 2 Type II'. |
| get_node | Fetch the free discovery view of a single compliance node by its id: title, pillar, version, last-updated date, plain-language summary (BLUF), dependency ids, and available crosswalk dimensions. The full 13-key vault node (deterministic workflow, actionable schema, primary citations) is available via the paid vault API. |
| get_dependency_chain | Walk the prerequisite tree for a compliance node. Returns the prior obligations a node depends on, up to max_depth levels deep, so an agent can see the full chain of rules it must already satisfy. Unlocking one node usually requires understanding several upstream nodes. |
| get_crosswalk | Return the cross-framework mapping dimensions for a node: which other regulations, standards, or jurisdictions the rule maps to (for example an EU right-to-erasure rule mapping to a US deletion right and a South African equivalent). The discovery view lists the available crosswalk dimensions; the full mapping values are part of the paid vault node. |
| get_mitre_mapping | MITRE technique lookup. Given a technique id from ATT&CK Enterprise (e.g. T1566, T1486), ATT&CK Mobile (T1474), ATT&CK ICS (T0883), D3FEND (D3-MFA), CAPEC (CAPEC-66), or ATLAS (AML.T0020), return the matching Bidda node and its discovery summary. The full control-family mappings (NIST 800-53, ISO 27001 Annex A, PCI DSS, NIS2, DORA, IEC 62443) are part of the vault node. |
| get_jurisdiction_bundleA | List the compliance nodes that apply in a specific jurisdiction (for example EU, US, UK, Australia, Singapore, India, Canada, China, South Africa, Japan, Brazil). Use when an agent enters a new market and needs the regulatory surface for that geography. |
| browse_topicsA | Browse the registry by cross-cutting topic (for example 'data breach notification', 'AI transparency', 'AML and KYC', 'logging and monitoring') across every pillar and jurisdiction. Returns each topic with its node, pillar, and jurisdiction counts. Topics sit on top of the 39 pillars without replacing them. |
| get_latest_changesA | Regulatory change feed: primary sources whose documents changed within the tracking window, with counts by status. Use to see what recently moved before relying on a cached rule. |
| check_action_complianceA | Pre-flight compliance check: describe an intended action in natural language (for example 'process EU resident biometric data' or 'deploy an autonomous trading model in Singapore') and get a ranked list of regulations that may apply plus a risk indicator (LOW, MODERATE, or HIGH). The headline runtime gate for autonomous agents. |
| compare_jurisdictionsA | 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; it does not rank which jurisdiction is stricter. Uses your Bidda subscription key when provided (a free trial counts). |
| drift_checkA | Check whether compliance rules an agent has cached in its own memory are still current. Submit each node_id with the integrity hash you stored when you last grounded on it; 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 rules. Requires a Bidda subscription key (a free trial counts). |
| obligation_deltasA | 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. Answers 'what obligations changed since I last reviewed?'. Requires a Bidda subscription key (a free trial counts). |
| watch_changesA | 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 a Bidda subscription key (a free trial counts). |
| point_in_timeA | 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 a Bidda subscription key (a free trial counts). |
| 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 missed-prerequisite gaps), plus any covered rule the registry marks withdrawn. A coverage aid for a qualified reviewer; it does not determine compliance. Requires a Bidda subscription key (a free trial counts). |
| 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 keep an audit trail of what they checked. Requires a Bidda subscription key (a free trial counts). |
| create_control_attestationA | 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 and integrity hash at signing time, so the record shows what the control was mapped against on that date. This is the design-side evidence; run receipts are the operating-side evidence. Requires a Bidda subscription key (a free trial counts). |
| 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 signed Run Receipt. Requires a Bidda subscription key (a free trial counts). |
| record_run_entryA | 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 a Bidda subscription key (a free trial counts). |
| consult_nodeA | 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 and 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 a Bidda subscription key (a free trial counts). |
| 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 a Bidda subscription key (a free trial counts). |
| 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. |
| get_audit_packA | Export a run as a governance evidence pack: the signed receipt, every entry, a roll-up of the nodes consulted (with pinned versions and hashes), an independent hash-chain and Merkle integrity self-check, and a coversheet mapping the receipt to the record-keeping obligations it supports (EU AI Act Art. 12 and 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. |
| oscal_assessment_resultsA | 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 and 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bidda-Ai/bidda-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server