Bidda MCP server provides access to a large sovereign compliance intelligence registry (10,100+ nodes, 39 pillars) and governance tools for audit-ready, tamper-evident AI operations.
Search and retrieve source-verified regulatory nodes, with plain-language summaries, dependency chains, cross-framework crosswalks, and jurisdiction bundles.
Browse topics, get latest regulatory changes, check an action's compliance risk (LOW/MODERATE/HIGH), and map MITRE ATT&CK/ATLAS/CAPEC techniques to controls.
Compare jurisdictions, check cached rules for drift, review obligation deltas, and identify prerequisite compliance gaps.
Create signed attestations and control attestations with public verify URLs.
Open, record, and seal tamper-evident run ledgers proving which rules an agent consulted, and export audit packs or NIST OSCAL assessment results.
Watch rules/pillars for changes via email/webhook and get point-in-time signed records of what a rule said at a past date.
10,100+ source-verified regulatory compliance nodes across 39 sovereign pillars. Built to reduce hallucination by grounding every node in primary legal sources.
Actively maintained. Last reviewed 2026-08-12 - 10,108 nodes across 39 pillars, 25 MCP tools (server v1.6.0). Live counts always available via list_pillars() and GET https://bidda.com/mcp.
Bidda is a sovereign compliance intelligence registry. Every node traces to a primary legal source (avg 7 citations per node) and contains machine-executable deterministic logic, not summaries, not PDFs, not paraphrased commentary.
Pillars covered: EU AI Act · GDPR · NIST AI 600-1 · Basel III · HIPAA · DORA · FATF · SOC 2 · ISO 27001 · CCPA · PIPEDA · APRA CPS 234 · MiCA · POPIA · plus a MITRE layer across ATT&CK Enterprise/Mobile/ICS, D3FEND, ATLAS and CAPEC, and 150+ others across 39 compliance domains.
Related MCP server: AI Compliance Calendar MCP Server
POST https://bidda.com/mcp
GET https://bidda.com/mcp (server info, open this in a browser to inspect)Transport: Streamable HTTP (MCP 2025-03-26). No API key required for the discovery tier.
Tool | Description |
| List all 39 compliance pillars with live node counts |
| Search by keyword across 10,100+ nodes; returns title, ID, pillar, and BLUF (plain-language obligation) |
| Fetch a specific node by ID; returns summary plus link to machine-executable workflow |
| Walk the prerequisite chain for a node (1 to 4 hops). Plan a full compliance posture from one entry node. |
| Cross-framework mapping dimensions for a node (e.g. GDPR Art 17 to CCPA right-to-delete to POPIA Sec 24) |
| Regulatory change feed: most recently updated nodes, optional pillar filter |
| All nodes that apply in a specific jurisdiction (EU, US, UK, AU, SG, IN, CA, CN, ZA, JP, BR and others) |
| MITRE technique ID to Bidda node plus mapped NIST/ISO/PCI/HIPAA/NIS2/DORA controls. Across 6 frameworks. |
| Pre-flight runtime check. Describe an intended action in natural language; get ranked applicable regulations plus LOW/MODERATE/HIGH risk indicator. |
| Browse the registry by cross-cutting compliance topic (e.g. data breach notification, AI transparency) across every pillar and jurisdiction |
api_key; a free trial counts)Tool | Description |
| Compare how jurisdictions address a topic side by side, including where their numeric thresholds differ (e.g. a breach-notification deadline of 72 hours versus 30 days). Does not rank which is stricter. |
| Create a signed, time-stamped record of which rules a person or AI agent relied on for a decision, with a public verify URL |
| Signed record of which committed version of a rule was authoritative at a past date, anchored to the public history chain |
| Subscribe to email or webhook alerts when a watched rule or pillar's primary source changes |
| Open a run ledger for a whole task or conversation (for example a support-bot chat). Returns a run_id. |
| Append one tamper-evident entry to an open run: the rules consulted, the decision, and the user input as text or a private hash |
| Seal a run into one signed run receipt covering every entry, with a public verify URL anyone can check against Bidda's public key |
| Fetch a run and its entries; a sealed run is publicly readable and reports whether its signature is valid |
| Governed runs: fetch a full node and record a verified, hash-pinned entry in an open run in one call, so the sealed receipt proves exactly which version of the rule the agent read |
| Export a sealed run as one auditor-ready evidence pack: the signed receipt, the entry chain, and an independent integrity self-check |
| Check whether a cached compliance snapshot is still current: pass node ids (optionally with version or content hash) and get fresh, drifted, or withdrawn per node |
| Signed record mapping one of your internal controls to the Bidda obligations it addresses, with owner, framework, status, and a public verify URL. An audit trail, not a determination of compliance. |
| Walk the public dependency graph from the nodes you cover to surface prerequisite obligations you may be missing |
| Obligation-level feed of which primary sources changed or were withdrawn since a date, filterable by pillar or node |
| Export a sealed governed run as a NIST OSCAL assessment-results document for GRC tooling |
The discovery responses for every free tool are free. Full vault unlock (deterministic_workflow, actionable_schema, full primary_citations) costs $0.01 per node via Skyfire JWT or USDC on Base. The subscriber tools require an active Bidda subscription, which includes a free trial.
Point your MCP client at:
https://bidda.com/mcpThat is it: no install, no API key, no config file for the discovery tier. The full server-info manifest is available at GET https://bidda.com/mcp (open in a browser to inspect available tools).
This repo also ships a runnable local stdio MCP server (server.js) that declares the full 25-tool surface. The free discovery and intelligence tools run locally by calling the public Bidda REST API, with no API key. The subscriber and governance tools are declared with their full schemas and execute on the hosted endpoint at https://bidda.com/mcp with your Bidda key. Use it when you want the server running on your own machine or CI.
With Node (18+):
npm install
node server.jsWith Docker:
docker build -t bidda-mcp .
docker run -i --rm bidda-mcpClaude Desktop / Cursor config:
{
"mcpServers": {
"bidda": {
"command": "node",
"args": ["/absolute/path/to/bidda-mcp/server.js"]
}
}
}The local server declares all 25 tools. Ten run locally with no API key: list_pillars, search_nodes, get_node, get_dependency_chain, get_crosswalk, get_mitre_mapping, get_jurisdiction_bundle, browse_topics, get_latest_changes, and check_action_compliance. compare_jurisdictions uses your Bidda key when the comparison is gated. The remaining subscriber and governance tools (attestations, the run ledger, change alerts, drift checks, and OSCAL export) require a Bidda subscription key and execute on the hosted endpoint at https://bidda.com/mcp; a free trial counts.
list_pillars()
search_nodes("GDPR data breach notification 72 hours")
search_nodes("Basel III capital requirements", pillar="Banking & Global Finance")
get_node("eu-ai-act-article-13-transparency")
get_dependency_chain("nist-csf-2-0-govern", max_depth=3)
get_crosswalk("gdpr-article-17-right-to-erasure")
get_jurisdiction_bundle("singapore", limit=25)
get_mitre_mapping("T1566") # ATT&CK Enterprise (phishing)
get_mitre_mapping("AML.T0020") # ATLAS (AI-specific)
check_action_compliance("process EU resident biometric data", jurisdiction="eu")
browse_topics("data breach notification")
compare_jurisdictions("data breach notification", api_key="YOUR_BIDDA_KEY")
create_attestation(agent="loan-bot-v2", nodes=["gdpr-article-22-automated-decisions"], api_key="YOUR_BIDDA_KEY")
open_run(agent="acme-support-bot", label="chat 8f21", api_key="YOUR_BIDDA_KEY")
record_run_entry(run_id="run_...", nodes=["gdpr-article-17-right-to-erasure"], note="User: delete my data", api_key="YOUR_BIDDA_KEY")
seal_run(run_id="run_...", api_key="YOUR_BIDDA_KEY")list_pillars())Pillar | Approx. nodes |
Cybersecurity | ~1,900 |
Legal & IP Sovereignty | ~700 |
Banking & Global Finance | ~580 |
AI Governance & Law | ~570 |
Medical & Healthcare | ~325 |
Sustainability & ESG | ~285 |
Workplace | ~280 |
+ 32 more pillars | (call list_pillars) |
For exact live counts, call list_pillars(). The manifest at GET https://bidda.com/mcp returns the current totals dynamically.
Full coverage browser: bidda.com/intelligence
Nodes are produced by Bidda's internal deterministic pipeline: source parsers and verification scripts do the heavy lifting, AI assists only in a small, tightly-gated drafting step, and every node passes multiple independent verification gates before publication. The whole design exists to keep drift to a minimum.
Every node has:
Primary legal citations: real instruments, real URLs, real section numbers (avg 7 per node)
Deterministic workflow: machine-executable steps, not prose summaries
Integrity hash: a cryptographic fingerprint of the node content
Source integrity watcher: regular TLS and content fingerprint checks against live regulator URLs, results published at /api/v1/registry-health.json
Verbatim mandate on amendments: every regulatory amendment is quote-justified against the source text before it can change a node
No inference without a regulatory anchor. No blog posts. No secondary commentary. No Wikipedia. Bidda is an information tool, not legal advice; review each rule and its primary source before relying on it.
Bidda has signed the CISA Secure by Design Pledge, the seven public goals the U.S. Cybersecurity and Infrastructure Security Agency asks software manufacturers to commit to, and publishes its evidence against each goal. Additional Bidda and CISA mappings:
CISA CPG crosswalk: bidirectional mapping between Bidda compliance nodes and CISA's Cybersecurity Performance Goals: bidda.com/cisa/cpg-crosswalk
CISA Free Tools catalogue: no-cost capabilities Bidda offers federal, SLTT and critical-infrastructure defenders: bidda.com/cisa/free
GET https://bidda.com/api/v1/registry-health.jsonLive integrity-check results: source URL liveness, verification coverage percentage, regulatory change detection categories, with a public timestamp on the last sweep.
Website: bidda.com
Developer docs: bidda.com/developers
Full node registry: bidda.com/intelligence
CISA programs: bidda.com/cisa
Verify a node: bidda.com/verify
Methodology: bidda.com/methodology
Contact: info@bidda.com
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional substring to filter topic labels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses return structure and notes topics sit on top of pillars, but lacks details on side effects, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundancy. Examples are concise and helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple browse tool with one optional parameter and no output schema, the description is adequate. It explains what is returned and its relationship to pillars. Minor gap: no mention of default behavior when query is empty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about cross-cutting topics but does not enhance meaning of the 'query' parameter beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a verb ('browse') and resource ('registry by cross-cutting topic'), provides concrete examples, and explains return values (node, pillar, jurisdiction counts). It distinguishes from sibling tools that operate on nodes or jurisdictions directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when exploring topics across pillars, but offers no explicit guidance on when not to use it or how it compares to sibling tools like 'search_nodes' or 'consult_node'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max regulatory matches to return (default 10, max 25). | |
| action | Yes | The action or change to assess, in plain language. | |
| jurisdiction | No | Optional jurisdiction hint (e.g. 'eu', 'us', 'uk'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It indicates the tool returns a ranking and risk indicator (non-mutating checkout), but does not explicitly state whether it is read-only, has side effects, requires authentication, or has rate limits. The absence of such details leaves some behavioral ambiguity, though the 'pre-flight' metaphor suggests safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence front-loads the core purpose ('Pre-flight compliance check') and provides immediate clarity. The structure is efficient, using a colon to introduce details and examples. Every sentence serves a purpose: defining the tool, giving examples, and stating its role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters with full schema coverage and no output schema, the description covers the essential aspects: input format, output (ranked list + risk indicator), and use case. It could be more complete by mentioning whether the check is real-time or cached, or confirming that it is non-destructive. However, it is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing baseline semantics for all three parameters. The tool description adds significant value by explaining the 'action' parameter usage with concrete examples and clarifying that 'jurisdiction' is a hint. It also implies a default limit of 10 (from 'max 25' in schema) and describes the output format. This extra context elevates the parameter understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: a 'pre-flight compliance check' that takes an action description in natural language and returns a ranked list of regulations and a risk indicator. It uses specific verbs and nouns, and the examples ('process EU resident biometric data') make the purpose unmistakable. The phrase 'headline runtime gate for autonomous agents' further distinguishes it as a proactive compliance tool, though it does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context (when to assess an action before execution) and gives examples of input, which implies when to use. However, it does not mention when NOT to use this tool or suggest alternatives among the siblings (e.g., browse_topics, compare_jurisdictions). An agent would need to infer usage boundaries from the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic to compare, for example 'data breach notification'. | |
| api_key | No | Optional Bidda subscription key (sent as x-bidda-api-key). A free trial counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses it surfaces real rules and does not rank, but lacks details on data sources, update frequency, or potential side effects like rate limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence captures core function and key example; second adds important qualifier about ranking and api_key. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool does and its boundary (no ranking). Could optionally mention output format or supported jurisdictions, but not necessary for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 is fair. The description adds value by giving an example for 'topic' and explaining 'api_key' is optional, sent as header, and free trial counts. Goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool compares jurisdictions on a compliance topic side by side, including numeric thresholds. Distinguishes from siblings like 'check_action_compliance' or 'get_jurisdiction_bundle' by focusing on comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells when to use (compare jurisdictions) and explicitly states what it does not do (does not rank strictness). Mentions optional api_key usage. Could be improved by referencing sibling tools for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional: the model id/version making the decision. | |
| action | No | Optional: an action the agent took or checked. | |
| run_id | Yes | The open run to record into (from open_run). | |
| api_key | Yes | Your Bidda subscription API key. A free trial counts. | |
| node_id | Yes | The rule to fetch and record. | |
| decision | No | Optional: what the agent decided using this node. | |
| input_hash | No | Optional: a sha256:... hash of the user's message instead of the text. | |
| user_input | No | Optional: the end user's message as text. | |
| subject_hash | No | Optional: a sha256:... hash of an end-user identifier. Hash only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that it consumes one call on the key, records an entry, pins the node version, and requires an open run. It covers essential behaviors but could mention error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the key purpose. It uses four sentences without unnecessary detail, efficiently conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return values, but it does not. It also omits potential errors or states like what happens if the run is not open. This leaves a gap in completeness for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant per-parameter meaning beyond what the schema already provides, thus scoring at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a vault node and records a verified consult entry in a single step. It explicitly distinguishes this from get_node, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance: 'Use this instead of get_node when you are inside a run.' It also specifies the prerequisite of a Bidda subscription key, giving clear context when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| nodes | Yes | Obligation node_ids the control maps to (max 50). | |
| api_key | Yes | Your Bidda subscription API key. A free trial counts. | |
| control | Yes | The name of your control or policy. | |
| framework | No | Optional: the framework you are mapping to (e.g. 'EU AI Act'). | |
| statement | Yes | What the control does or asserts (plain text). | |
| evidence_ref | No | Optional: a reference, URL, or hash to your own evidence (kept by you). | |
| control_owner | No | Optional: the role or team that owns the control. | |
| control_status | No | Optional: implemented, planned, or in-progress. | |
| effective_date | No | Optional: YYYY-MM-DD the control took effect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that each obligation is pinned to its current version and integrity hash at signing time, and that the record is tamper-evident. However, it does not disclose potential side effects, storage behavior, or retrieval mechanisms beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a brief note, all front-loaded. First sentence gives the main action, second adds detail, third provides contrast. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain return values, success/failure indicators, or how to retrieve the created attestation. It also omits guidance on handling the max 50 nodes constraint. While the purpose is clear, missing return information reduces completeness for a tool with 9 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context for the overall purpose but does not significantly augment the parameter descriptions (e.g., it repeats the api_key requirement already in schema). No additional semantics are provided for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool signs a tamper-evident record of a control/policy and its mapped obligation nodes. It explicitly contrasts design-side evidence with operating-side evidence (run receipts), distinguishing it from sibling tools like record_run_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (for design-side evidence) and contrasts with run receipts, implying when not to use. It also mentions the requirement for a Bidda subscription key. However, it does not explicitly list alternative tools or conditions for avoidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| anchors | Yes | The cached rules to check. | |
| api_key | Yes | Your Bidda subscription API key. A free trial counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the possible return states (fresh, drifted, withdrawn) and behavior when the hash is omitted. It does not cover rate limits or authentication details beyond requiring an api_key, but the core behavioral traits are explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the purpose, then explains the usage and outcome efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (fresh, drifted, withdrawn). It covers prerequisites (api_key, cached hash), parameters, and the agent's follow-up action (re-ground). The context is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so baseline is 3. The description adds value by explaining the role of the hash (integrity hash for prior grounding) and the effect of omitting it (fetch current fingerprint), beyond the schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking whether cached compliance rules are current. It specifies the action (submit node_id with integrity hash) and the outcome (fresh, drifted, withdrawn), distinguishing it from sibling tools like check_action_compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (before acting on stale rules) and a prerequisite (Bidda subscription key). However, it does not explicitly exclude scenarios or compare to alternatives, though the language implies its specific use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run to export. | |
| api_key | No | Optional: your Bidda key, required for a still-open (unsealed) run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it explains the difference between sealed (readable by id) and open runs (needs api_key) and details the pack's contents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the purpose, but it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and lack of an output schema, the description thoroughly covers the tool's purpose, contents, and usage conditions, including regulatory references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters (100% coverage), and the description adds value by clarifying the conditional requirement for api_key when the run is unsealed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a run as a governance evidence pack and lists its specific components, distinguishing it from sibling tools like 'get_jurisdiction_bundle' or 'oscal_assessment_results'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (exporting a run as an evidence pack) and provides context for sealed vs. open runs, but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max nodes to return (default 25, max 100). | |
| jurisdiction | Yes | Jurisdiction code or name: eu, us, uk, au, sg, za, india, canada, china, japan, brazil, and others. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read-only operation by using 'List', but does not disclose side effects, authentication requirements, rate limits, or the format of returned nodes. More transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no wasted words. The first sentence states the core function immediately, and the second provides usage context. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is reasonably complete. It covers purpose and usage. However, it could elaborate on what a 'compliance node' is or the structure of the response, but the current level is adequate for an agent to understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds context by listing example jurisdictions and explaining the tool's purpose, which enhances understanding beyond the schema. However, it does not add specifics on parameter usage beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('compliance nodes') with a specific jurisdiction. It provides examples of jurisdictions, making the purpose clear. However, it does not explicitly differentiate from sibling tools like 'compare_jurisdictions' or 'browse_topics', so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear usage context: 'Use when an agent enters a new market and needs the regulatory surface for that geography.' It tells when to use the tool, but does not mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max change entries to return (default 25, max 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It explains the output (changed primary sources with counts) and implies a read-only operation, but does not detail the tracking window or status meanings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines the tool's purpose and output, second gives practical usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description provides sufficient context about what it returns and why to use it. Minor gaps like defining 'tracking window' are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'limit' parameter with min/max and default, so the description adds no additional meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a regulatory change feed for primary sources with counts by status. It distinguishes from siblings like 'browse_topics' or 'watch_changes' by focusing on recently changed documents and status counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage hint ('Use to see what recently moved before relying on a cached rule'), but does not explicitly state when not to use it or mention alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional: max deltas to return (default 100, max 500). | |
| nodes | No | Optional: restrict to deltas affecting these node_ids. | |
| since | No | Optional ISO timestamp; only deltas newer than this are returned. | |
| pillar | No | Optional: restrict to one pillar. | |
| api_key | Yes | Your Bidda subscription API key. A free trial counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It indicates the tool is a change feed (implying read-only), describes what it maps, and mentions filtering capabilities. However, it does not discuss pagination behavior, rate limits, or response structure, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the tool's core functionality, the second provides a concrete use case and a prerequisite. Every sentence adds value, no fluff, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description adequately explains the tool's purpose, filters, and the API key requirement. It lacks details on response format or behavior at limits, but the presence of sibling tools with similar purposes makes the differentiation clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 5 parameters with descriptions (100% coverage). The description adds contextual meaning by summarizing filter capabilities (time, pillar, nodes) and the requirement for an API key, but these largely mirror the schema descriptions without providing additional constraints or formatting details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the 'obligation-level change feed' that maps changed primary sources to affected obligation nodes. It also provides a concrete use-case question ('what obligations changed since I last review?'), which strongly differentiates it from sibling tools like 'get_latest_changes' or 'watch_changes' that might be more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool answers a specific question and highlights filterability by time, pillar, or nodes. However, it does not mention when not to use it or provide direct comparisons to sibling tools, such as when to prefer 'obligation_deltas' over 'watch_changes' or 'get_latest_changes'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run to export as OSCAL assessment-results. | |
| api_key | No | Optional: your Bidda key, required for a still-open (unsealed) run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully explains the export's content (reviewed-controls, observations, props) and notes the integrity self-check. It also clarifies the sealed/unsealed access behavior. However, it does not mention if any state is modified or if permissions are required beyond the api_key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first covers purpose and content, the second covers access conditions. No redundant or extraneous information, and the key details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the output format (OSCAL assessment-results with listed components) and handles the api_key condition. Since there is no output schema, the description adequately describes what the agent can expect. The tool's complexity is moderate, and all relevant aspects are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions with 100% coverage. The description adds value by explaining the purpose of api_key (required for unsealed runs), which the schema does not elaborate. However, the schema already describes the parameters adequately, so the addition is helpful but not essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action: exporting a governed run's evidence as a NIST OSCAL assessment-results document, listing the included components (reviewed-controls, observations, props). This clearly distinguishes it from sibling tools, which perform different functions like browsing topics or checking compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when the api_key parameter is needed (for still-open runs) and distinguishes sealed vs. open runs. However, it does not explicitly contrast this tool with siblings or state when to choose it over alternatives, though the unique OSCAL output implicitly sets it apart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ISO date or time, or epoch milliseconds. Defaults to now. | |
| api_key | Yes | Your Bidda subscription API key. A free trial counts. | |
| node_id | Yes | The rule (node_id). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It mentions the signed, anchored nature of the record and the API key requirement, but does not detail return structure, error conditions (e.g., missing node_id at the date), or rate limits. Some transparency provided, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one defining the action, the second providing use case and requirement. No unnecessary words; highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose, usage, and key requirement, it lacks details on the return format (signed record structure) and potential edge cases (e.g., no version at date). Given no output schema, more detail would improve completeness. Sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with descriptions (100% coverage). The tool description reinforces the api_key requirement and node_id as 'rule,' but adds no additional semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a signed historical record of which rule version was authoritative at a given past date. It distinguishes itself from sibling tools like 'consult_node' (current version) and 'get_latest_changes' (recent updates) by specifying past point-in-time retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Useful when an agent must show what a rule said at the moment it acted,' providing clear context for use. However, it does not name alternatives or state when not to use this tool, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional: the end user's message as text. | |
| model | No | Optional: the model id/version that produced this decision. | |
| nodes | No | Optional node_ids the agent consulted (max 50). | |
| action | No | Optional: an action the agent took or checked. | |
| run_id | Yes | The run_id returned by open_run. | |
| api_key | Yes | Your Bidda subscription API key. A free trial counts. | |
| decision | No | Optional: what the agent decided or did this turn. | |
| entry_type | No | Optional: node_consulted, action_checked, decision, or note. Defaults to note. | |
| input_hash | No | Optional: a sha256:... hash of the user's message instead of the text. | |
| output_hash | No | Optional: a sha256:... hash of the agent's output. | |
| subject_hash | No | Optional: a sha256:... hash of an end-user identifier. Hash only, never plaintext. | |
| verify_nodes | No | Optional: pin each node to its current version and integrity hash (proof, not just a claim). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only adds one behavioral detail: 'Each entry is hash-chained to the previous one.' This is useful but leaves out other traits like whether entries are immutable, permission requirements, or rate limits. The description carries the full burden and is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and key behavioral note (hash-chaining). It is concise but packs significant detail. Some restructuring could improve clarity (e.g., separating the entry content from the requirement), but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no output schema, no annotations), the description covers the core purpose and ensures the agent knows what an entry contains. However, it does not describe the return value (e.g., success indicator or entry ID), prerequisites beyond the API key, or what happens if the run is not open. These gaps could hinder a new agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is documented. The description adds meaningful context beyond the schema by explaining the distinction between note and input_hash for user input, and mentioning that entry_type defaults to note. This enriches understanding of how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'append' and the resource 'one entry to an open run', specifying the content (Bidda rules, decisions, user input). This distinguishes it from sibling tools like browse_topics or check_action_compliance, which are not recording actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the requirement for a Bidda subscription key, but does not explicitly state when to use this tool versus alternatives (e.g., consult_node, drift_check). Usage is implied by the recording nature, but no exclusions or comparative context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 50). | |
| query | Yes | Keywords, a regulation name, or a topic (e.g. 'GDPR breach notification'). | |
| pillar | No | Optional exact pillar/domain name to restrict results (see list_pillars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool returns nodes with id, title, pillar, and BLUF, and that every node traces to a primary legal source. However, it does not describe behavior such as result ordering, handling of no results, or whether search is fuzzy/exact. These gaps leave some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core function and return fields, the second provides usage guidance and examples. It is front-loaded, efficient, and every sentence contributes meaningfully. No redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters and no output schema, the description covers the essential aspects: functionality, return information, usage context, and examples. It lacks details on pagination or result limits (though limit param is documented), but overall it provides sufficient context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds value by showing example queries ('GDPR breach notification 72 hours') and hinting at pillar usage via 'list_pillars'. However, it does not significantly enhance understanding beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Keyword search across the Bidda registry of source-verified compliance obligations', clearly stating the verb ('search') and the resource (registry of obligations). It distinguishes from sibling tools like browse_topics or consult_node by being a general search tool, and the examples and usage guidance reinforce its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use to find the rule that governs a topic, law, standard, or MITRE technique' and provides concrete examples. While it doesn't explicitly say when not to use or list alternatives, the context of sibling tools and the clear search purpose imply the appropriate use cases. It would benefit from mentioning when to use browse_topics or consult_node instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Optional name for the alert. | |
| nodes | No | node_ids to watch. | |
| api_key | Yes | Your Bidda subscription API key. A free trial counts. | |
| pillars | No | Pillar names to watch. | |
| channels | No | Delivery channels, for example { "email": true, "webhook": false }. Defaults to email. | |
| webhook_url | No | Required if the webhook channel is enabled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the subscription nature and delivery methods (email/webhook), but lacks details on unsubscription, subscription lifecycle, limits, or what the tool returns (e.g., a subscription ID).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first captures action and method, second adds a critical prerequisite. No extra words, front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, nested objects, and no output schema, the description covers the what, how, and prerequisite. It misses the return value (e.g., subscription ID or confirmation), but overall is sufficient for an agent to understand the tool's role among 14 siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage), but the description adds value by explaining how parameters like 'nodes', 'pillars', 'channels', and 'webhook_url' relate to the overall purpose of watching rules and pillars and getting notified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Subscribe', the resource 'regulatory change alerts', and the outcome 'get notified by email or webhook'. It specifies what can be watched ('specific rules and/or whole pillars'), distinguishing it from sibling tools like 'get_latest_changes' (one-time query) and 'browse_topics' (browsing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the key prerequisite: 'Requires a Bidda subscription key (a free trial counts)'. It implies use for ongoing notifications rather than on-demand queries, but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct compliance function: browsing, compliance checking, jurisdiction comparison, node consultation, attestation, drift detection, export, etc. No two tools overlap in purpose; descriptions clearly differentiate them.
Most tools follow a verb_noun pattern (e.g., browse_topics, check_action_compliance). 'obligation_deltas' breaks this pattern (noun_noun), but the deviation is minor and the overall style remains consistent.
With 15 tools, the server covers a complex domain (regulatory compliance) without being overwhelming. Each tool has a clear purpose, and the number is appropriate for the scope.
The tool surface covers discovery, compliance checking, attestation, monitoring, and export. Minor gaps exist (e.g., no node update/delete), but core workflows like search, assessment, and audit are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
10,065 source-verified compliance nodes, 39 pillars, 25 MCP tools (EU AI Act, GDPR, NIST, MITRE).
Verified, tier-0 regulatory data for AI across 850+ official sources and 50+ jurisdictions.
EU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
Multi-jurisdictional AI compliance readiness scoring with sourced penalty math.
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
