bidda-compliance
Server Details
9,500 verified compliance nodes (EU AI Act, GDPR, HIPAA, DORA, NIST, MITRE). Zero hallucination.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 9 of 9 tools scored.
Each tool targets a distinct function: pre-flight compliance checking, crosswalk mapping, dependency exploration, jurisdiction bundle retrieval, change monitoring, MITRE mapping, node lookup, pillar listing, and keyword search. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun snake_case pattern: check_action_compliance, get_crosswalk, get_dependency_chain, get_jurisdiction_bundle, get_latest_changes, get_mitre_mapping, get_node, list_pillars, search_nodes. The verbs are descriptive and the nouns clearly indicate the object.
9 tools is well-scoped for a compliance server. It covers discovery (list_pillars, search_nodes), detailed queries (get_node, get_crosswalk, get_dependency_chain, get_jurisdiction_bundle), change tracking (get_latest_changes), action compliance checking, and MITRE mapping. Each tool serves a clear purpose without redundancy.
The tool surface covers the full query lifecycle: discovering available pillars, searching by keyword, retrieving specific nodes, understanding dependencies and cross-references, checking regulatory applicability by jurisdiction or specific action, and monitoring changes. Missing write operations are appropriate since the full node data is hosted externally.
Available Tools
9 toolscheck_action_complianceAInspect
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.). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the input (natural language action) and output (ranked regulations + risk indicator). However, it does not disclose side effects (none expected for a check), authentication requirements, or rate limits. The description is adequate but could be more explicit about non-destructive nature.
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 effectively convey purpose, input/output, and use-case. Examples are illustrative without being verbose. Every word earns its place, 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?
The description explains the core functionality: input (natural language), output (ranked regulations + risk indicator). With no output schema, it covers return values. It does not discuss error handling or edge cases, but for a compliance check tool, the description is sufficiently complete for an agent to use 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 baseline is 3. The description reiterates that 'action' is natural language and provides examples, adding some value. For 'limit' and 'jurisdiction', it does not add beyond schema descriptions, so overall it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Pre-flight regulatory check' with concrete examples of natural-language actions. It positions itself as 'primary tool for runtime compliance gating', distinguishing it from sibling tools which are more about crosswalks, dependencies, and searching.
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 itself as the primary tool for compliance checks during autonomous workflow execution. While it does not list specific alternatives or when-not-to-use, the context of sibling tools (e.g., get_crosswalk, search_nodes) implies differentiation, and the description gives clear use-case context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crosswalkAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that full mapping values are 'vault-gated' (access-controlled) and distinguishes between 'discovery' and 'full' results. However, it does not confirm read-only behavior, rate limits, or other operational traits.
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 with an illustrative example and a clear two-part output explanation. Every phrase adds value without 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?
For a single-parameter tool with no output schema, the description provides a good overview: purpose, example, and access restriction. It lacks explicit return format details but is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the node_id already described. The description does not add additional meaning beyond what the schema provides, staying at the baseline score.
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 'cross-framework mapping dimensions for a node' and provides a concrete example (GDPR to CCPA to POPIA). This distinguishes it from sibling tools like 'get_dependency_chain' or 'get_mitre_mapping' which serve 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 usage when needing to see cross-framework mappings but does not explicitly state when to use this tool over alternatives, nor does it provide exclusion criteria. It mentions 'vault-gated' but lacks clearer guidance on access prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dependency_chainAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the operation (walking prerequisite chain), defaults (depth 2, max 4), and typical behavior (3-8 upstream nodes). It implies a read-only operation, which is sufficient for this tool.
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 concise sentences: action, return value, and usage context with defaults. No redundant information; every sentence adds 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?
For a tool with only two simple parameters and no output schema, the description fully covers what the tool does, why to use it, and key behavioral details (like default depth and typical tree size). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description confirms defaults and adds context about typical usage, but does not significantly extend the schema descriptions (which already document node_id as root and max_depth with min/max/default).
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 'walk' and the resource 'prerequisite chain for a compliance node,' with additional context about returning a full dependency tree. It distinguishes itself from sibling tools like check_action_compliance and get_node by focusing on dependency traversal.
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 usage context: 'Use this to plan a complete compliance posture' and mentions typical upstream nodes. However, it does not specify when not to use it or alternatives, 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.
get_jurisdiction_bundleAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It honestly states the output is compliance nodes, but lacks details on pagination (limit parameter), ordering, or error handling. The schema covers limit, so behavioral disclosure is adequate but not rich.
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, no unnecessary words, front-loaded with purpose and use case. Highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the output (compliance nodes) and use case. It lacks explicit mention of return format or default limit, but the schema covers limit details. Complete enough for a simple retrieval 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% (both parameters have descriptions). The description adds minimal value beyond the schema, only reiterating the jurisdiction list. Baseline 3 is appropriate as the schema already 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?
Description clearly states the tool returns compliance nodes for a specific jurisdiction, with a specific verb 'return' and resource 'compliance nodes'. It distinguishes from siblings like check_action_compliance (specific action) and get_node (single node) by mentioning 'full regulatory surface for that geography'.
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 says 'Use when an agent enters a new market and needs the full regulatory surface for that geography', providing clear context. While it doesn't explicitly state when not to use it, the context implies it is for the full set, differentiating from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_latest_changesAInspect
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". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It mentions the tool lists recent changes and supports filtering by pillar, but it does not disclose potential limitations like pagination, rate limits, data freshness, or authentication requirements. The behavioral transparency is adequate but not detailed.
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 extremely concise: three sentences, no wasted words, and the key purpose is front-loaded. Every sentence serves a purpose, and the structure is clear 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 covers the purpose, typical use case (scheduled monitoring), and filtering. However, it lacks details about the return format (e.g., what fields each node includes) since there is no output schema. Given the tool's simplicity, the description is mostly complete but could briefly mention the output structure.
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?
With 100% schema description coverage, both parameters (days, pillar) are already documented in the schema. The description adds minimal extra context: 'Filter by pillar to focus on a domain.' This is helpful but does not significantly enhance understanding beyond the schema. Thus, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List the most recently updated compliance nodes — the regulatory change feed.' It uses a specific verb ('List') and resource ('compliance nodes'), and the context differentiates it from siblings like get_node (single node) or search_nodes (search), making the purpose unmistakable.
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 usage guidance: 'Use to monitor incoming amendments...' and 'Agents should call this on a schedule to keep compliance posture current.' This tells when to use the tool. However, it does not explicitly state when not to use it or mention alternatives among siblings, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mitre_mappingAInspect
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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It does not mention side effects, authentication needs, rate limits, or whether the operation is read-only. While the tool is likely safe, the lack of behavioral context is a significant gap.
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 informative and front-loaded with the key purpose. It uses a metaphor ('Rosetta Stone') and lists supported frameworks, but could be slightly more concise by trimming marketing language like 'Free.'
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 should describe the output structure more fully. It mentions returning the Bidda node and compliance obligations, but does not detail the format, fields, or whether multiple results are possible. This leaves some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is already well-documented with examples. The tool description adds context about frameworks and compliance obligations but does not enhance understanding of the parameter itself 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?
The description clearly states the tool's purpose: given a MITRE technique ID from multiple frameworks, it returns the Bidda node and mapped compliance obligations. The verb 'return' and specific resource ('Bidda node plus mapped compliance obligations') make it distinct from sibling tools like get_node or get_crosswalk.
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: as a bridge between SOC technique IDs and compliance control families. However, it does not explicitly state when not to use or provide alternatives among siblings (e.g., get_crosswalk, get_dependency_chain), which could refine the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_nodeAInspect
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" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the return fields and mentions a full node is available elsewhere, but does not disclose if the operation is read-only, idempotent, or requires authentication. The behavioral transparency is adequate for a simple 'get' operation but could be more explicit.
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 action and returns, and includes a clear pointer to additional information. No unnecessary 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?
Given the tool is simple (one parameter, no output schema), the description adequately explains what it does and what it returns. It could mention error handling (e.g., invalid ID) but is otherwise complete for a node retrieval tool with clear sibling differentiation.
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 coverage is 100% with a single parameter 'id' having examples. The description does not add meaning beyond the schema; it restates that the tool gets a node by ID. Baseline 3 is appropriate since schema already documents parameter semantics sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a compliance node by ID and lists the specific fields returned (title, compliance pillar, version, last updated, BLUF). It distinguishes from sibling tools like get_dependency_chain or get_crosswalk by focusing on a single node summary.
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 makes clear this tool is for fetching a node by ID, which is the primary use case. It does not explicitly mention when not to use it or suggest alternatives, but the context of sibling tools implies different purposes (e.g., get_dependency_chain for dependency info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_pillarsAInspect
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 9,635 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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions node counts and examples of pillars, but does not disclose potential side effects, authentication needs, or safety profile. As a list operation, it is likely read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: first sentence states core function, second adds usage guidance and descriptive context. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description compensates by mentioning node counts and listing example pillars. It gives enough context for an agent to understand what to expect, though a full return format 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 input schema has zero parameters, so schema coverage is 100%. Baseline is 4 for 0 parameters. The description adds no parameter info because none exist, but it adds value by describing the output.
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 'List all compliance pillars...with node counts', specifying the verb, resource, and additional output. It distinguishes from sibling tools like search_nodes and get_node by focusing on listing domains rather than individual 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 explicitly says 'Use this first to discover available compliance domains before searching', providing clear when-to-use guidance. It lacks explicit when-not or alternatives, but the context implies it as a precursor to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_nodesAInspect
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" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains that results include a one-sentence BLUF and that each node traces to a primary legal source (no hallucination), but does not disclose any destructive potential, rate limits, or pagination behavior. The disclosure is helpful but not comprehensive.
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 followed by examples, with no redundant or unnecessary wording. It is front-loaded with the core purpose and immediately adds value with the BLUF and source claims.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description adequately describes the return value (node summaries with BLUF and legal source) and provides example queries. It lacks details on the summary structure or handling of empty results, but is sufficient for an agent to understand what it will get back.
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% (all three parameters are described). The description adds example search terms for the 'query' parameter and mentions the optional 'pillar' filter, but does not provide additional meaning beyond what the schema already conveys. 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 'search' and the resource 'Bidda compliance nodes', and specifies that it returns node summaries with a BLUF and primary legal source. It distinguishes itself from siblings like get_node (which retrieves a single node by ID) and list_pillars (which lists pillars only).
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 examples of search queries but does not explicitly state when to use this tool versus alternatives like get_node or check_action_compliance. It lacks guidance on when not to use it or what situations call for a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!