10,065 source-verified compliance nodes, 39 pillars, 25 MCP tools (EU AI Act, GDPR, NIST, MITRE).
Scored across 25 tools
Most tools have clearly distinct purposes, especially the run-ledger and retrieval tools. A few pairs could cause hesitation, such as get_latest_changes vs obligation_deltas vs watch_changes, and get_node vs consult_node, but the descriptions do enough to separate them.
The majority follow a verb_noun pattern like get_node, open_run, and seal_run, but there are notable exceptions such as obligation_deltas, oscal_assessment_results, and point_in_time. The naming is readable but not consistently patterned.
At 25 tools, the set sits at the heavy end of the scalecard and feels dense for a single server. The breadth is arguably justified by the broad compliance domain, but several tools could be consolidated without losing capability.
The toolkit covers registry discovery, node retrieval, dependency analysis, crosswalk mapping, jurisdiction bundles, change monitoring, pre-flight checks, gap analysis, run ledgers, attestations, and OSCAL export. Minor gaps exist, such as no way to list runs or manage watch subscriptions, but the core workflows are well covered.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional topic name to filter or drill into. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds meaningful behavioral context: the tool returns counts across pillars and jurisdictions, topics are layered on top of pillars, and it is free with no key required. This gives the agent a clear picture of what to expect without needing extra calls.
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?
Four succinct sentences, each contributing unique information: purpose, return value, relationship to pillars, and usage/auth. Front-loaded with the core action, no redundancy or filler.
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 read-only tool with one optional parameter and no output schema, the description fully covers selection (what it does), invocation (how to drill down), and behavior (return summary and auth requirements). No significant gaps remain.
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 already fully documents the single optional parameter. The description adds value by giving example topic values and explaining the difference between omitting (browse all topics) and providing (drill into one) the topic string, enhancing the agent's understanding of invocation.
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 'Browse the registry by cross-cutting compliance TOPIC' with concrete examples (data breach notification, AI transparency, AML and KYC). It explicitly distinguishes topics from the 39 pillars, preventing confusion with sibling tools like list_pillars.
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?
Provides clear context for when to use (when exploring cross-cutting topics and their counts), and gives direct instruction 'Pass a topic string to drill into one.' It does not explicitly name alternatives or say 'use this instead of list_pillars', but the pillar relationship implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max matches to return. Default 10. Max 25. | |
| action | Yes | Natural-language description of the intended action. | |
| jurisdiction | No | Optional jurisdiction filter (eu, us, uk, etc.). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds value by detailing the output (ranked list of regulations, risk indicator) and the 'may apply' nuance, indicating a non-exhaustive heuristic. This aligns with annotations and adds transparency.
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 the core purpose, then examples, then positioning. No redundant 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?
The tool has 3 params, no output schema. The description provides sufficient context about inputs (natural language action), outputs (ranked list + risk indicator), and usage domain. It could detail the output structure more, but for a read-only compliance check, this is adequate.
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 100% of parameters with descriptions. The description enhances the 'action' parameter with concrete examples (EU biometric data, health records transfer, trading model) that teach the agent how to phrase queries. Limit and jurisdiction are already well-documented in 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 tool's function: a pre-flight regulatory check that takes natural-language action descriptions and returns ranked regulations with a risk indicator. It distinguishes itself from siblings by being 'the primary tool for runtime compliance gating'.
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 explicitly frames when to use: before performing an action, as a pre-flight check, and positions itself as the primary tool for runtime compliance gating in autonomous workflows. It doesn't explicitly name alternatives or when-not-to-use cases, but the context is strong.
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 and does not rank which jurisdiction is stricter. Requires an active Bidda subscription: pass your key as api_key.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic to compare, for example "data breach notification". | |
| api_key | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not required to restate safety. It adds valuable behavior: it 'surfaces the real rules and numbers' rather than opinions, explicitly does not rank, and discloses the subscription requirement ('Requires an active Bidda subscription') and how to pass the key (api_key). This goes beyond the schema by framing the tool's output philosophy and access prerequisite, though it does not detail error handling or return format.
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 60 words across three sentences, each earning its place: the first defines the core purpose and an illustrative example, the second clarifies the non-ranking behavior and focus on real data, and the third covers authentication requirements. It is front-loaded with the most important information and contains no redundant filler.
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 tool with only two params and no output schema, the description gives adequate context for correct invocation: what topic to provide, what the tool does, what it does not do, and the required authentication. The main gap is the lack of any description of the response format; while 'surfaces the real rules and numbers' hints at the content, an agent might benefit from knowing whether results are returned as a table, list, or structured document. With no output schema, a short note on return structure would complete the picture. Still, this is a minor omission given the strong clarifying statements elsewhere.
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% and both parameters are described: topic includes an example, and api_key has a thorough explanation of header vs argument precedence and free trial inclusion. The description does not add significant new parameter-level meaning beyond what the schema already provides; it only corroborates the api_key need. Baseline 3 is appropriate because the schema fully documents 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 opens with a clear verb and resource: 'Compare how different jurisdictions address a compliance topic, side by side.' It specifies the scope (jurisdictions, compliance topics) and the distinctive behavior of surfacing numeric thresholds (e.g., 72 hours vs 30 days). This distinguishes it from sibling tools like get_jurisdiction_bundle or check_action_compliance, and it states explicitly that it does not rank jurisdictions, removing ambiguity about its output philosophy.
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 clearly defines when to use the tool: when a side-by-side comparison of jurisdictions' rules on a compliance topic is needed. It also implies a contrast with ranking tools by stating 'does not rank which jurisdiction is stricter.' However, it does not explicitly name alternative tools for different use cases (e.g., single-jurisdiction lookup or compliance checking), nor does it state conditions when not to use this tool. It gives clear context but lacks explicit exclusionary guidance.
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 + 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.
| 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 | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. 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?
The description adds meaningful behavioral context beyond the annotations: it consumes one call on the key, records an entry, pins the node to its version and integrity hash, and requires an active Bidda subscription. This gives the agent a clear picture of side effects and proof semantics without contradicting the annotations.
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 compact, front-loaded with the main purpose, and every sentence earns its place: it explains the combined operation, the integrity-pinning behavior, when to use it instead of get_node, and the auth requirement. No unnecessary filler is present.
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 core operation, side effects, prerequisites, and usage context, which is strong given the tool's complexity. The only minor gap is that with no output schema, an explicit statement of the return shape would have been slightly more complete, but the description already implies the node is fetched and the entry recorded.
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%, and each parameter already has a detailed description, so the baseline is 3. The tool description reinforces the role of run_id and node_id and mentions api_key, but it does not add substantive parameter-level meaning beyond what the schema already provides.
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 a specific composite action: fetch the full vault node and record a verified node_consulted entry in one call. It also distinguishes itself from get_node by explicitly naming the sibling and the condition for choosing this tool, so an agent can tell them apart immediately.
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 'Use this instead of get_node when you are inside a run,' which is a direct when-to-use instruction with a named alternative. It also states the prerequisite of an active Bidda subscription and that recording happens on an open run, giving the agent the conditions needed to invoke it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | The system or AI agent that made the decision. | |
| nodes | Yes | node_ids that were checked (max 50). | |
| action | No | Optional: what the agent did. | |
| api_key | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts. | |
| workflow_steps_followed | No | Optional: steps the agent followed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=false and destructiveHint=false, so the write nature is covered. The description adds meaningful context: the subscription requirement, the public verify URL, and the implication of immutability ('confirm the record has not been changed'). This goes beyond the annotations without contradicting them.
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 compact—four short sentences, each with a distinct purpose: what it creates, what it returns, typical use, and a prerequisite. It is front-loaded with the core action and avoids filler. Slightly longer than two sentences but still 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?
For a tool with 5 parameters, no output schema, and moderate complexity, the description covers the core outcome (returned record ID and verify URL), the prerequisite (subscription), and the general use case. It omits edge cases, error behavior, and the sibling differentiation, but those are not critical for basic invocation. It is sufficiently complete for an agent to call it 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?
Schema coverage is 100%, so the baseline is 3. The description does not add any detail about agent or nodes beyond what the schema provides. It only mentions api_key in the context of subscription, which is already elaborated in the schema parameter description (including header precedence). Thus, it adds minimal extra semantic value.
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 states a clear verb-resource pair: 'create a signed, time-stamped record of which Bidda rules...'. It also explains what is returned (record ID and verify URL). However, it does not explicitly distinguish this from the sibling create_control_attestation, leaving the agent to infer the difference from the name alone.
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 gives a clear use case ('useful for agents that must keep an audit trail') and mentions a prerequisite (Bidda subscription). But it offers no explicit comparison to alternatives, nor any 'when not to use' guidance. The sibling create_control_attestation is never referenced, so selection between them is left implicit.
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 + 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.
| Name | Required | Description | Default |
|---|---|---|---|
| nodes | Yes | Obligation node_ids the control maps to (max 50). | |
| api_key | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. 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/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 | 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?
Annotations already declare write, non-idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it pins obligations to their version and integrity hash at signing time, and clarifies the subscription requirement and header precedence for api_key. This enriches the agent's understanding of side effects and dependencies.
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 compact paragraphs that front-load the purpose and distinguish the tool from run receipts. It includes the key behavioral note (pinning) and a practical usage hint (api_key header). It is efficient, with minimal fluff, though a slight trim could make it even tighter.
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 9 parameters and no output schema, the description covers the core purpose, the mapping behavior, the evidence type, and a prerequisite. It does not detail return values (no output schema expected) but provides enough for an agent to decide when to call and what to provide. Minor gaps such as error handling are not essential here.
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 schema already documents every parameter, including api_key header precedence. The description does not add new semantic details about parameters beyond what the schema provides; it only reiterates the subscription requirement. Baseline 3 is appropriate when the schema fully covers parameter meaning.
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 begins with a specific verb 'Sign' and a clear resource: 'tamper-evident record of one of YOUR OWN controls or policies and the Bidda obligation nodes it maps to.' It also contrasts with 'run receipts' to clarify the design-side evidence role, effectively differentiating from other attestation-like 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?
It states when to use this tool: 'design-side evidence' vs 'running-side evidence' from run receipts, giving a clear context. It also states a prerequisite ('Requires an active Bidda subscription: pass api_key'). It does not explicitly name an alternative sibling tool, but the run-receipt contrast conveys appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| anchors | Yes | The cached rules to check. | |
| api_key | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, which the description does not contradict; it adds behavioral context by explaining what 'drift' and 'withdrawn' mean and that the response is per-rule status. It also notes batch-size scaling with plan tier, going beyond the annotations without conflicting with them.
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 well-structured with a clear frontal statement of purpose, followed by input/output detail and behavioral context. The final sentences about tier inclusion and 'Pass api_key' are slightly redundant given the schema, but they do not bloat the text significantly. Overall, every sentence contributes to understanding.
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 tool with two parameters and no output schema, the description covers what the agent receives (per-rule status) and how to act on it. It does not specify an exact response format, but that is not essential for call selection. The description is sufficient for correct invocation and interpretation without additional documentation.
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, but the description adds semantic value: it explains the purpose of the hash (integrity check against last grounding), the node_id context (rules), and clarifies that api_key is optional and that the header takes precedence. This provides meaning beyond the schema's descriptions.
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 opens with a specific verb ('Check') and a precise resource ('compliance rules an agent has cached'), clearly distinguishing it from sibling tools like get_latest_changes or watch_changes. It also enumerates the three possible outcomes (fresh, drifted, withdrawn), making the tool's function 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?
The description explains when to use the tool ('before acting on stale law') and how to prepare inputs (submit node_id and stored hash). It does not explicitly name alternative tools or state when not to use it, but the context is clear and there are no misleading exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Optional: how many dependency hops to walk (1-3, default 1). | |
| nodes | Yes | The node_ids you cover (max 200). | |
| api_key | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the subscription requirement, the dependency-graph mechanism, and explicitly notes it does not rank compliance. It does not contradict annotations and supplies context beyond the structured metadata.
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 paragraph with two efficient sentences. The core function is front-loaded, and the 'coverage aid' phrasing with a dash adds a bit of fluff but does not waste space. It is concise and readable.
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 does explain the high-level output (gaps and withdrawn rules). It states the auth requirement and what the tool does not do. For a read-only tool with well-documented params, this is sufficiently complete, though return structure detail is absent.
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%, with each parameter (depth, nodes, api_key) already explained. The description adds no deeper meaning about parameter syntax or relationships; it only mentions passing api_key, which the schema already covers. 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 uses a specific verb ('return') with a clear resource (prerequisite rules from the dependency graph) and explicitly defines the two outputs: missed prerequisite gaps and withdrawn covered rules. It also distinguishes itself from ranking/determining compliance, separating it from other review 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?
It frames the tool as 'a coverage aid for a qualified reviewer' and states it does not rank or determine compliance, giving some context. However, it does not name specific sibling tools or provide explicit when-to-use versus when-not-to-use guidance, leaving inference to the agent.
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/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.
| 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?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds behavioral nuance: open runs produce a 'draft pack' and require api_key, and the pack includes hash-chain integrity checks. No contradictions with annotations.
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 states purpose and contents, second clarifies sealed/open behavior. All content earns its place, no filler.
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 sufficiently enumerates the pack's components and the sealed/open condition, though it doesn't specify the output format (e.g., zip/PDF/JSON). Sibling context suggests this is a specialized export 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 coverage is 100%, with both run_id and api_key described; the description's sealed/open context duplicates the schema's api_key note, adding no new parameter semantics.
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 uses the specific verb 'Export' with resource 'run', and enumerates the pack's contents (signed receipt, entries, node roll-up, hash-chain/Merkle check, coversheet), clearly distinguishing it from sibling get_run by its governance-evidence-pack scope.
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 specifies the conditional context: sealed runs are readable by id, open runs require api_key. This gives clear operational guidance, though it doesn't explicitly name alternatives like get_run for simpler retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | Node ID to inspect crosswalks for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context by noting that discovery returns available dimensions while full mapping values are vault-gated, which tells the agent about a two-tier access model not captured in annotations.
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 front-loaded action, includes a clarifying example, and ends with a concise note on access levels. Every sentence earns its place with no 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 the simple schema (one parameter) and lack of output schema, the description adequately covers the return value ('mapping dimensions') with an example and notes the vault-gating nuance. It is complete enough for a look-up tool, though a brief mention of output format would have made it fully concrete.
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 already provides 100% coverage with a clear description of node_id ('Node ID to inspect crosswalks for'). The description's mention of 'for a node' adds no significant semantic detail beyond the schema, so the baseline score of 3 applies.
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 uses a specific verb+resource ('Return the cross-framework mapping dimensions for a node') and includes a concrete example chain. It distinguishes itself from siblings like get_mitre_mapping by focusing on cross-framework mappings across regulations, standards, and jurisdictions.
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 its use case when cross-framework mappings are needed, but it does not explicitly state when to use this tool versus alternatives. It lacks exclusions or direct comparisons with sibling tools such as get_mitre_mapping or compare_jurisdictions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | Root node ID to expand from. | |
| max_depth | No | How many hops to walk (1-4). Default 2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint and openWorldHint, so the bar is lower. The description adds useful behavioral context: default depth 2, max 4, and typical output size (3-8 nodes). It doesn't mention pagination or return format, but with open-world hint and simple params, this is adequate.
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?
Three sentences, front-loaded with purpose, no wasted words. Each sentence provides distinct value: what it does, why to use it, and operational limits.
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 two-parameter tool with good annotations and no output schema, the description is complete: it states behavior, use case, depth behavior, and typical scale. No critical gaps remain.
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 baseline is 3. The description reinforces max_depth defaults but adds little beyond the schema's own descriptions. The schema already explains node_id and max_depth fully.
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: 'Walk the prerequisite chain for a compliance node' and 'returns its full dependency tree.' This specific verb+resource combination distinguishes it from siblings like get_node or browse_topics.
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 context: 'Use this to plan a complete compliance posture' and explains the typical need ('unlocking one node usually requires understanding 3-8 upstream nodes'). It doesn't explicitly mention alternatives or when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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, india, canada, china, south-africa, japan, brazil. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'Return all compliance nodes', but the input schema includes a 'limit' parameter with a default of 25 and maximum of 100, meaning the tool does not actually return all nodes by default. This is a significant behavioral misrepresentation. Annotations cover read-only and open-world aspects, but the description itself is misleading about the result set size.
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 long, front-loaded with the action, and every word adds value. It is concise and well-structured without any fluff.
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?
Despite having good annotations and full schema coverage, the description is incomplete and misleading due to the 'all' claim conflicting with the limit parameter. It does not clarify that results may be truncated or how pagination works, which is essential for a tool that purports to return an entire regulatory surface.
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 adds little beyond what the schema already provides for the jurisdiction parameter, and it completely ignores the 'limit' parameter, which is key to understanding the actual behavior. However, it does not need to repeat schema details, so a 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 returns all compliance nodes for a jurisdiction, uses a specific verb ('Return') and resource ('compliance nodes'), and lists many jurisdictions. It also distinguishes itself from siblings like compare_jurisdictions, which focuses on comparing rather than returning a bundle.
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 a clear use case: 'Use when an agent enters a new market and needs the full regulatory surface for that geography.' This gives context but does not mention exclusions or alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look back N days. Default 30. Max 180. | |
| pillar | No | Optional pillar filter, e.g. "AI Governance" or "Cybersecurity". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, openWorld), the description clarifies what counts as a change and advises on scheduling. It does not disclose return format or pagination, but given annotation coverage, this is sufficient for a 4.
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?
Four sentences, each contributing: action/resource, use cases, filtering, and scheduling. No filler. Front-loaded with the verb and object.
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 read-only feed with optional filters, the description covers the core usage and context. It lacks explicit output details, but the absence of an output schema and the tool's straightforward nature make this acceptable. Slight ambiguity about what 'updated' entails prevents a 5.
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 already fully documents the two parameters. The description reinforces pillar's purpose ('focus on a domain') but adds no new semantics. Baseline 3 applies.
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 action ('List') and resource ('compliance nodes'), positioning it as the 'regulatory change feed.' It implies a distinction from siblings like search_nodes or watch_changes, but does not explicitly name alternatives, so it falls short of a 5.
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 explicit use cases: monitoring amendments, new guidance, or new rules, and recommends a scheduling pattern. It does not mention exclusions or alternative tools, so a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| technique_id | Yes | MITRE technique ID. ATT&CK Enterprise (T1566, T1486, T1078, T1003.001, T1547.001); ATT&CK Mobile (T1474, T1521, T1471, T1430, T1417); ATT&CK ICS (T0883, T0809, T0879, T0886, T0814); D3FEND (D3-FIM, D3-MFA, D3-NTA, D3-NI, D3-AI, D3-CH); CAPEC (CAPEC-66, CAPEC-63, CAPEC-98, CAPEC-94, CAPEC-49); or ATLAS (AML.T0020). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that it returns a Bidda node plus obligations and mentions 'Free', but does not detail rate limits, authentication, or response structure beyond that.
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-loaded with a memorable metaphor and then detailed specifics. It is slightly verbose with 'The MITRE Rosetta Stone' and 'Free', but each part adds flavor or info. No wasted sentences.
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 (multiple frameworks and compliance standards) and no output schema, the description should explain more about the response format. It lists the standards but not the structure, which is a notable gap for an AI 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?
The schema description covers 100% of the parameter with extensive valid ID examples. The tool description adds framework context but introduces a slight inconsistency by listing 5 frameworks while schema includes CAPEC as an additional valid input type. Overall, the schema does the heavy lifting.
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 maps a MITRE technique ID to a Bidda node and associated compliance obligations across multiple frameworks. It distinguishes itself from siblings by its specific 'Rosetta Stone' role, bridging SOC and compliance terminology.
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?
Usage is implied clearly: when you have a MITRE technique ID and need mapping to compliance controls. It does not explicitly name alternatives or say when not to use, but the context is strong enough to guide selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Node ID, e.g. "basel-iii-capital", "gdpr-article-5-principles", "fatf-40-recommendations-2023-consolidated", "us-hipaa-privacy-rule" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the safe-read nature is already known. The description adds value by disclosing the exact summary fields returned (title, pillar, version, last updated, BLUF) and pointing out that the full node (with workflow, schema, citations) is not provided. No contradiction with annotations.
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-loaded with the primary action, and contains no redundant information. Every clause contributes meaning, making it highly 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 tool's simplicity (one parameter, read-only) and no output schema, the description sufficiently explains what the return value contains and what it does not. It sets expectations about the summary and directs users to an external source for the full node, covering all necessary contextual aspects.
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 required 'id' parameter with examples and a clear description. The description adds no extra semantic meaning beyond restating 'by its ID'. With 100% schema coverage, the baseline 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 clearly states the tool's function: 'Get a specific compliance node by its ID.' It specifies the verb (get), the resource (compliance node), and the scope (specific, by ID). It also lists the returned summary fields, distinguishing it from sibling tools like get_dependency_chain or search_nodes.
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 context: use this tool when you have a node ID and need a summary. It explicitly states what the tool returns and notes that the full node is available elsewhere, implying a when-not scenario. However, it does not name alternative sibling tools for cases like finding a node without an ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run_id to fetch. | |
| api_key | No | Optional: your Bidda key, required to read your own still-open run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behavioral details: the owner can read open or sealed runs with an api_key, sealed runs are publicly readable, and the response reports signature validity. This adds meaningful context about access control and output behavior that annotations alone do not provide.
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-loaded with the main action, then adding access and output specifics. Every word contributes to understanding the tool, with no repetition of schema details or fluff.
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, the annotations, and the 100% schema coverage, the description is quite complete. It explains what is returned (run, entries, signature validity) and the access conditions. However, it does not detail the exact return structure or pagination, but this is not critical for a straightforward fetch tool with no output schema.
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 already covers both parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by linking api_key to the owner role and noting that sealed runs are publicly readable without it, thereby clarifying when the optional parameter is necessary.
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 opens with 'Fetch a run and its entries,' using a specific verb and resource that clearly distinguishes it from sibling tools like open_run, seal_run, and record_run_entry. It also clarifies the object being fetched (a run and its entries), which fully identifies the tool's 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 provides clear usage context: it explains when an api_key is required (owner reading an open run), and that a sealed run is publicly readable by id. It does not explicitly name alternatives, but the context makes it obvious this is the tool for fetching run data, and the access rules are specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld. The description adds helpful context about the data size and categories (e.g., 10,099 nodes, 39 pillars, MITRE frameworks), which sets expectations without contradicting annotations.
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 and packed with useful specifics (counts, categories, examples). It is not overly verbose but slightly dense; however, it remains concise and well-structured.
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, it does not need to explain return values. It adequately describes what the tool lists and gives enough context about the registry's scope, making it complete for a list operation.
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?
There are no parameters, so schema coverage is 100% and no parameter explanation is needed. The description does not need to add anything about parameters; the baseline score 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?
Clearly states the action (list), resource (compliance pillars), and scope (Bidda Sovereign Intelligence registry) with node counts. It also differentiates from search tools by explicitly recommending this as the first step for discovery.
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?
Explicitly guides when to use: 'Use this first to discover available compliance domains before searching.' This implies that other search-oriented tools should be used after this listing, providing clear usage direction.
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. Use it to answer 'what obligations changed since I last reviewed?'. Requires an active Bidda subscription: pass api_key.
| 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 | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description does not contradict them. The description adds genuine behavioral context beyond the annotations: the subscription/auth requirement ('Requires an active Bidda subscription: pass api_key') and the edge-case semantics of what counts as a delta ('or whose node was withdrawn'). It omits rate limits and response format, but those are secondary for a read-only feed.
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?
Three sentences with zero waste: definition, canonical use case, and operational requirement. The core resource semantics are front-loaded before the usage hint, making the tool's identity clear in the first line.
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?
No output schema exists, so the description carries the burden of conveying what comes back; the first sentence does sketch the output content (source refs mapped to affected obligation nodes). Gaps remain: result ordering, how limit interacts with pagination, and the field structure of a delta item. For a simple read-only feed with fully documented parameters this is nearly complete.
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 value on top by grouping three params into their functional role ('filterable by time, pillar, or specific nodes'). It also flags api_key as effectively required ('Requires an active Bidda subscription: pass api_key') even though the schema declares it optional, which is a useful cross-reference with the header-precedence note.
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?
Names a specific resource ('the obligation-level change feed'), a concrete transformation ('primary sources whose content changed... mapped to the Bidda obligation nodes they affect'), and explicit filter scope ('time, pillar, or specific nodes'). The 'obligation-level' qualifier differentiates it from sibling change feeds like get_latest_changes and watch_changes.
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?
Provides an explicit usage directive: 'Use it to answer "what obligations changed since I last reviewed?"', which clearly frames when this tool is the right choice. However, it never names sibling alternatives (e.g., get_latest_changes or watch_changes) or states when NOT to use it, so contrastive guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | The system or agent running the task or conversation. | |
| label | No | Optional human label, for example the chat or ticket id. | |
| api_key | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read/write and idempotency, and the description adds behavioral context beyond that: the ledger is signed and tamper-evident, returns a run_id, and requires an active Bidda subscription via api_key. This is consistent with the annotations, which mark the operation as non-read-only and non-destructive.
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 compact and front-loaded with the tool's core function, then return value, workflow, and requirement. Every sentence carries useful information without fluff.
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 create-style tool with three params, the description explains the purpose, return value, workflow continuation (record_run_entry, seal_run), and auth requirement. No output schema exists, so noting run_id is sufficient; nothing critical is missing.
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 covers all three parameters with descriptions (100% coverage), including header precedence for api_key. The description adds only a redundant subscription requirement reference, so it doesn't significantly expand on 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?
States a specific verb and resource ('Open a run ledger') and explains the return value (run_id). It clearly differentiates from siblings by outlining the workflow with record_run_entry and seal_run, so an agent can tell it starts a new ledger rather than reading or appending.
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 context: use this to start a run ledger for a task/conversation, then use record_run_entry per turn and seal_run to finish. It does not explicitly name alternatives like get_run or state when not to use it, but the workflow makes the intended usage evident.
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 + 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?
Annotations already declare readOnlyHint and openWorldHint. The description adds value beyond these by disclosing that api_key is required for still-open runs, and by outlining the document composition (reviewed-controls, observations, props). No contradictions.
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 sentence with a colon-separated list. All content is relevant, though the parentheticals and clause 'the machine-readable format...' add length. Still, it is well-structured and front-loaded with the core purpose.
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 compensates by listing the key sections of the exported document. It also covers access requirements (api_key for open runs). This is sufficient for an export tool of moderate 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?
Schema coverage is 100%, with both run_id and api_key already described in the schema. The description essentially restates these (sealed vs. open run) without adding new parameter-level detail, so it neither compensates nor detracts; 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 verb ('Export'), the resource ('a governed run's evidence'), and the format ('NIST OSCAL assessment-results document'). It distinguishes this tool from siblings by specifying the machine-readable compliance format, making it 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?
The description provides clear context: this is for producing OSCAL assessment-results for GRC/audit tooling. It also gives a practical condition (sealed vs. open runs) that affects api_key usage. However, it does not explicitly name alternative tools or when not to use it.
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 an active Bidda subscription: pass api_key.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ISO date or time, or epoch milliseconds. Defaults to now. | |
| api_key | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts. | |
| node_id | Yes | The rule (node_id). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the annotations: the call requires a Bidda subscription, the record is signed, and it is anchored to the public history chain. It is slightly ambiguous whether this is purely a read of an existing record or creates a new signed record, especially given readOnlyHint=false and the title 'Sign a point-in-time record', but the description is reasonably transparent overall.
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 three sentences with no filler: core purpose, use case, and prerequisite. The most important semantics are 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?
There is no output schema, but the description explains the high-level output: a signed record of which committed version was authoritative. It omits exact response fields and failure behavior, but for a three-parameter tool with complete schema coverage and clear auth guidance, this is sufficient for correct invocation.
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 all three parameters. The description reinforces that api_key is needed and that as_of relates to a past date, but it does not add meaningful detail beyond what the input schema already provides.
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 names a specific operation ('Get a signed record') and a precise resource: the committed version of a rule authoritative at a past date, anchored to the public history chain. The use case ('show what a rule said at the moment it acted') clearly distinguishes it from current-state or change-log siblings like get_node and get_latest_changes.
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 gives a concrete scenario ('when an agent must show what a rule said at the moment it acted') and states the prerequisite of an active Bidda subscription with an api_key. It does not name alternative tools or say when not to use it, but the intended context is clear enough.
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 an active Bidda subscription: pass api_key.
| 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 (e.g. gpt-4o-2024-08-06). | |
| 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 | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts. | |
| decision | No | Optional: what the agent decided or did this turn. | |
| entry_type | No | Optional: node_consulted | action_checked | decision | 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 for per-subject traceability. Hash only, never plaintext. | |
| verify_nodes | No | Optional: pin each node in "nodes" to its current version + integrity hash (proof, not just a claim). No extra call charge. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: each entry is hash-chained (important for integrity), requires an active subscription, and explains the api_key header vs argument precedence. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).
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 that front-load the primary action and content, then include critical behavioral details (hash-chaining, auth) without fluff. Every word 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?
For a 12-parameter tool with no output schema, the description covers the essential purpose, key constraints (open run, auth), and the distinction between textual and hashed input. No critical information for correct use is missing.
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 description adds value beyond the schema by clarifying that the end user's input can be sent as text via note or privately via input_hash, and by explaining that verify_nodes provides proof by pinning nodes to versions. These enrich meaning without repeating schema descriptions.
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 (Append one entry) and the resource (an open run), plus the content (rules consulted, decision, end user input). It is specific and distinct from sibling tools like open_run, get_run, and seal_run, which have different purposes.
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 when to use it (recording a run entry) and mentions prerequisite (active Bidda subscription, api_key). It does not explicitly contrast with sibling tools, but the purpose is clear enough that an agent can infer when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run_id to seal. | |
| api_key | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as non-read-only, idempotent, and non-destructive; the description adds useful context by describing the signed receipt, the public verification URL, and the subscription requirement. No contradiction with annotations.
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 front-load the core action and output, then add idempotency and auth requirements. Every sentence carries meaningful information with no filler.
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 two-parameter tool with no output schema, the description provides the essential return concept (a signed receipt with public verify URL), idempotency, and auth prerequisite. It does not describe the receipt structure in detail, but that is unlikely to block correct invocation.
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 already documents both parameters fully (100% coverage), including the header-precedence behavior for api_key, so the description does not need to add much. Its mention of needing a subscription loosely reinforces api_key's purpose but adds little beyond 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?
States a specific verb ('Seal'), the target resource ('an open run'), the output ('one signed Run Receipt covering every entry, with a public verify URL'), and the idempotent behavior. This clearly differentiates it from sibling tools like open_run or record_run_entry without needing to inspect schemas.
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 clearly indicates this is for an open run that should be closed into a receipt, and idempotency covers repeated calls. It names the subscription requirement, but it does not explicitly name alternative tools or say when not to use it, so it stops just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 25) | |
| query | Yes | Search terms, e.g. "Basel III capital requirements", "GDPR data breach notification 72 hours", "FATF travel rule" | |
| pillar | No | Optional: filter by pillar name, e.g. "Banking & Global Finance", "Cybersecurity", "AI Governance & Law", "Medical & Healthcare" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, so the bar for additional disclosure is lower. The description adds valuable context: it explains the output format (summaries with a one-sentence BLUF) and makes a truthfulness claim ('Every node traces to a primary legal source (no hallucination)'). This goes beyond the annotations without contradicting them.
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 three tight sentences: purpose, output benefit, and illustrative examples. No filler or redundancy. The purpose is front-loaded, and every sentence earns its place by clarifying the tool's function and value.
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 absence of an output schema, the description explains what the tool returns (matching node summaries with BLUF) and its provenance guarantee. It does not mention pagination or sorting, but the schema documents the limit parameter. Overall, it is sufficiently complete for a straightforward search tool with good annotations and schema coverage.
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?
Input schema covers 100% of parameters, each with descriptions and examples. The description does not add parameter-level meaning beyond the schema; it only provides general use examples. This meets the baseline of 3 but does not exceed it.
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 a specific verb+resource: 'Search Bidda compliance nodes by keyword.' It clearly distinguishes the tool from siblings like browse_topics or get_node by focusing on keyword search and returning 'node summaries' with a one-sentence BLUF. The examples further clarify the intended use.
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 when to use the tool (when you have a keyword like 'Basel III capital') but does not explicitly provide exclusions or alternatives. It says 'Search... by keyword' and gives examples, but does not contrast with sibling tools like browse_topics or consult_node. Usage guidance is present but implicit.
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 an active Bidda subscription: pass api_key.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Optional name for the alert. | |
| nodes | No | node_ids to watch. | |
| api_key | No | Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. 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?
Annotations indicate readOnlyHint=false and idempotentHint=false, so the description correctly does not contradict that this is a non-idempotent write operation. It adds context about the Bidda subscription requirement and delivery channels, but does not explain side effects like duplicate alert creation, result format, or whether the subscription is persistent. The description adds some value beyond annotations but is not rich in behavioral disclosure.
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, well-structured sentence that front-loads the purpose ('Subscribe to regulatory change alerts') and uses a colon to introduce the requirement. It covers key aspects without fluff, making it easily scannable 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?
The description explains the trigger (primary source changes), the watch targets (rules/pillars), delivery channels, and the subscription requirement, which covers most operational aspects. However, there is no mention of the tool's return value or output structure, and since there is no output schema, an agent would not know what to expect. For a tool with six parameters and no output schema, this is a notable gap, but it is otherwise adequate.
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 all six parameters are already documented. The tool description reiterates the nodes/pillars distinction and email/webhook options, but adds minimal new meaning beyond the schema. Since the schema carries the parameter details, the description meets the baseline of 3 but does not exceed it.
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' and the resource 'regulatory change alerts', specifying that it watches specific rules or whole pillars and notifies via email or webhook. It also includes the prerequisite of an active Bidda subscription, which distinguishes it from sibling tools like get_latest_changes that likely fetch changes rather than create subscriptions. This makes the tool's 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?
The description provides clear context on when to use the tool: to subscribe to changes, and it notes the subscription requirement. However, it does not explicitly name any alternative tools or state when not to use it, such as directing agents to get_latest_changes for immediate retrieval. The context is present but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_jurisdictions2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key (sent as x-bidda-api-key). A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "topic",
- "api_key"
-]New value: +[
+ "topic"
+]consult_node2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "run_id",
- "node_id",
- "api_key"
-]New value: +[
+ "run_id",
+ "node_id"
+]create_attestation2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "agent",
- "nodes",
- "api_key"
-]New value: +[
+ "agent",
+ "nodes"
+]create_control_attestation2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "control",
- "statement",
- "nodes",
- "api_key"
-]New value: +[
+ "control",
+ "statement",
+ "nodes"
+]drift_check2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "anchors",
- "api_key"
-]New value: +[
+ "anchors"
+]gap_check2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "nodes",
- "api_key"
-]New value: +[
+ "nodes"
+]obligation_deltas2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "api_key"
-]New value: +[]open_run2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "agent",
- "api_key"
-]New value: +[
+ "agent"
+]point_in_time2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "node_id",
- "api_key"
-]New value: +[
+ "node_id"
+]record_run_entry2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "run_id",
- "api_key"
-]New value: +[
+ "run_id"
+]seal_run2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "run_id",
- "api_key"
-]New value: +[
+ "run_id"
+]watch_changes2 fields changedInput schema / properties / api_key / descriptionPrevious value: -"Your Bidda subscription API key. A free trial counts."New value: +"Optional. Your Bidda subscription key. Prefer sending it as the x-bidda-api-key header (or Authorization: Bearer), which is what the auth settings in your MCP client configure; the header takes precedence over this argument. A free trial counts."Input schema / requiredPrevious value: -[
- "api_key"
-]New value: +[]consult_nodecreate_control_attestationgap_checkget_audit_packobligation_deltasoscal_assessment_resultsrecord_run_entry3 fields changedInput schema / properties / modelAdded value: +{
+ "description": "Optional: the model id/version that produced this decision (e.g. gpt-4o-2024-08-06).",
+ "type": "string"
+}Input schema / properties / subject_hashAdded value: +{
+ "description": "Optional: a sha256:... hash of an end-user identifier for per-subject traceability. Hash only, never plaintext.",
+ "type": "string"
+}Input schema / properties / verify_nodesAdded value: +{
+ "description": "Optional: pin each node in \"nodes\" to its current version + integrity hash (proof, not just a claim). No extra call charge.",
+ "type": "boolean"
+}drift_checkget_runopen_runrecord_run_entryseal_runbrowse_topicscompare_jurisdictionscreate_attestationpoint_in_timewatch_changescheck_action_complianceget_crosswalkget_dependency_chainget_jurisdiction_bundleget_latest_changesget_mitre_mappingget_nodelist_pillarssearch_nodesEU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
AI legal compliance: contract review, risk scoring, EU/CN AI act, watermark check. 8 MCP tools.
BC/DR & compliance tools: DORA, NIS2, NIST CSF, GDPR, SOC 2, CMMC, CAF, ISO 27001, FCA/PRA.
Add one secure layer between your agents and this server.