Bidda Sovereign Intelligence

drift_check

Read-only

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.

Input Schema

TableJSON Schema

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.

TDQS

A4.3/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Bidda Sovereign Intelligence tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools have clearly distinct purposes. The few overlapping pairs (get_node vs consult_node, get_latest_changes vs obligation_deltas) are explicitly differentiated in their descriptions, so an agent should be able to select correctly. No tools appear to do the same thing.

Naming Consistency3/5

The majority of tools follow a clear verb_noun pattern (get_node, create_attestation, seal_run). However, several tools deviate significantly: drift_check and gap_check put the noun first, obligation_deltas is a bare noun, and point_in_time and oscal_assessment_results are noun phrases without a verb. This inconsistency makes the set feel less predictable.

Tool Count3/5

At 25 tools, this is at the heavy end of the range. However, the tool set covers a very broad compliance intelligence domain, including discovery, compliance checks, run management, attestations, and change feeds. Each tool has a clear role, but the sheer number may overwhelm agents that need only a subset of functionality.

Completeness5/5

The tool surface is very comprehensive for a compliance intelligence platform. It covers discovery (browse, search, list, get), action compliance checking, jurisdiction comparison, dependency analysis, change tracking, run ledger management, attestation creation, and evidence export. There are no obvious dead ends or missing core operations for the stated domain.

Resources

Need Help?