Bidda Sovereign Intelligence
Server Details
Search and retrieve cryptographically-verified compliance nodes. 3,000+ nodes across 31 pillars AI Governance, Banking & Global Finance, Cybersecurity, Medical & Healthcare, Legal & IP Sovereignty, ESG and more. Zero hallucination: every node traces to primary legal sources with avg 7 citations.
- 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.1/5 across 9 of 9 tools scored. Lowest: 3.4/5.
Every tool has a clearly distinct purpose: pre-flight checks, mappings, dependency chains, jurisdiction bundles, change feeds, MITRE mappings, node details, pillar listing, and search. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern with snake_case (e.g., check_action_compliance, get_crosswalk, list_pillars). The naming is predictable and uniform.
With 9 tools, the set is well-scoped for the compliance intelligence domain. Each tool covers a necessary aspect, avoiding both sparseness and overload.
The tool surface covers discovery (list_pillars, search_nodes), retrieval (get_node, get_jurisdiction_bundle, get_latest_changes), analysis (get_dependency_chain, get_crosswalk), runtime compliance (check_action_compliance), and cross-domain mapping (get_mitre_mapping). No obvious gaps.
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?
No annotations are provided, so the description must fully cover behavior. It discloses that the tool returns a ranked list of regulations with a risk indicator, but it does not mention side effects, authentication requirements, or rate limits. The description adds some transparency but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. Key details (purpose, input format, output characteristics) are front-loaded, 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?
Despite no output schema, the description effectively communicates the return format (ranked list of regulations, risk indicator). With three parameters and clear context, the description is complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all three parameters. The description adds value by explaining that the 'action' parameter should be a natural-language description, with specific examples (e.g., 'process EU resident biometric data'), which aids understanding 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 performs a 'pre-flight regulatory check' and provides examples of natural language actions it handles. It distinguishes itself by being 'the primary tool for runtime compliance gating in autonomous agent workflows,' which sets it apart from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is the primary tool for runtime compliance gating, implying when to use it. However, it does not mention when to avoid it or provide direct comparisons to siblings like get_crosswalk or search_nodes. The guidance is clear but lacks exclusions.
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?
With no annotations, the description discloses an important behavioral trait: full mapping values are vault-gated, while discovery returns available dimensions. This adds significant context beyond the schema, though it does not cover all possible behaviors (e.g., rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a clear purpose: first sentence defines the tool's function with an example, second sentence adds a critical behavioral note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description provides sufficient context about what the tool returns (dimensions) and the vault-gating distinction. However, it lacks details on the exact structure of the returned dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about the mapping dimensions but does not elaborate on the node_id parameter beyond what the schema offers.
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 action ('Return the cross-framework mapping dimensions for a node') and provides a concrete example (GDPR Article 17 → CCPA right-to-delete → POPIA Section 24), distinguishing it from sibling tools like get_dependency_chain or get_mitre_mapping.
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 for inspecting cross-framework mappings but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or 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, but the description discloses key behaviors: it walks the chain, returns a tree, defaults to depth 2, max depth 4. Lacks mention of side effects or auth, but is sufficiently informative for a read-like operation.
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 efficient sentences, front-loaded with the core verb and object, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but return value is described (full dependency tree). Siblings are listed but not compared. Overall complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, and the added context (full dependency tree, typical depth) enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it walks the prerequisite chain and returns the dependency tree, effectively distinguishing it from siblings like check_action_compliance or get_node by framing the purpose for compliance planning.
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 tells when to use the tool ('Use this to plan a complete compliance posture') and provides typical depth expectations (3-8 upstream nodes). Lacks explicit when-not or alternatives, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jurisdiction_bundleBInspect
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 provided, so the description must fully disclose behavior. It claims to 'Return all compliance nodes' but includes a limit parameter, creating ambiguity about completeness. It does not mention pagination, ordering, or what a 'compliance node' is, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The purpose and usage context are front-loaded. 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?
The description lacks explanation of 'compliance nodes' and the implications of the limit parameter (e.g., capping results). With no output schema, the description should clarify the expected output. This is insufficient for a tool intended for entering new markets.
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 parameters described. The description adds marginal value by listing jurisdiction examples (already in schema) but does not clarify the limit behavior or default beyond what schema states. 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 it returns compliance nodes for a specific jurisdiction, with examples. The verb 'Return' and resource 'compliance nodes' are specific, but it doesn't differentiate from siblings like search_nodes or get_node, which might also return nodes for a jurisdiction.
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.' This provides clear context, though it doesn't mention when not to use it or alternative tools like get_node for single node retrieval.
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 provided, so the description carries full burden. It explains the tool's purpose and filtering, but does not disclose important behavioral traits such as read-only nature, pagination, rate limits, or response structure. Lacks depth on behavior.
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 roughly two sentences, front-loading the main purpose. Each sentence adds value, though could be slightly more streamlined without losing meaning.
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 omits what the tool returns (e.g., node IDs, titles, dates). For a monitoring tool, the return format is important context. Also, without annotations, the description should provide more behavioral detail.
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 parameters described. The description adds value by framing 'filter by pillar to focus on a domain' and implying time range via 'recently updated'. This reinforces 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 clearly states the tool lists 'the most recently updated compliance nodes' and positions it as 'the regulatory change feed'. It uses specific verbs and distinguishes itself from siblings like check_action_compliance and 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?
Explicitly suggests using the tool to monitor amendments, guidance, and rules, and to filter by pillar. Also recommends scheduling. However, it does not explicitly contrast with search_nodes or other siblings for scenarios where a different tool might be better.
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?
With no annotations, the description carries full burden. It discloses the output (Bidda node and compliance obligations) and lists specific standards. It does not mention destructive actions or authentication needs, but the tool is clearly read-only and the description is transparent about its purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no unnecessary words. It is front-loaded with the catchy 'Rosetta Stone' analogy. Every sentence adds information, though it could be slightly more structured (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (node plus specific compliance frameworks). It covers the essential aspects for a single-parameter lookup tool, leaving no critical 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%, but the description adds value with examples (T1566, T1486, ATLAS) and clarifies the output (mapped compliance obligations). This goes beyond the schema's brief description, aiding correct 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 states the tool's function: given a MITRE or ATLAS technique ID, it returns the Bidda node and mapped compliance obligations. It uses specific verbs ('return') and resources ('node', 'compliance obligations'), and differentiates itself from siblings by focusing on cross-domain mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context ('bridge between SOC and compliance teams') and implies when to use it (when needing compliance mappings for a technique). However, it lacks explicit guidance on when not to use it or comparison with specific siblings, though siblings appear distinct.
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?
No annotations provided, so the description carries the full burden. It states the tool returns a summary and that the full node is available externally, which implies it is not a write operation. However, it lacks details on authentication, rate limits, or idempotency.
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 filler, front-loaded with the core action and results. Efficiently communicates purpose and extra information.
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 get by ID tool with one parameter and no output schema, the description adequately covers what the tool does and what it returns. It mentions where to find additional data, which is helpful context.
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 already describes the id parameter with examples. The description adds value by specifying that it retrieves a node by ID and listing the returned fields (summary contents), which goes beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get), the resource (compliance node by ID), and the content of the return (summary with title, pillar, version, etc.). It distinguishes from siblings by specifying single-node retrieval by ID.
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?
No explicit guidance on when to use this tool versus list_pillars or search_nodes. It does not mention alternatives or conditions for use.
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 5,419 cryptographically-verified nodes across 34 pillars + 203 MITRE nodes across 6 frameworks (ATT&CK Enterprise/Mobile/ICS, D3FEND, ATLAS, CAPEC) including 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 provided, but description implies a read-only list operation and adds details about node counts and pillar count. Does not explicitly state idempotence or side-effect absence, but sufficient for a simple listing 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?
Two sentences, front-loaded with purpose, no wasted words. Clearly structured and easy to parse.
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?
Covers purpose, usage context, and domain details (31 pillars, cryptography). Adequate for a parameterless listing 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?
No parameters in schema (baseline 4), but description adds meaningful context about registry and scale, going beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states "List all compliance pillars... with node counts." and specifies the Bidda Sovereign Intelligence registry. Distinguishes from siblings by positioning as a discovery step before 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?
Explicitly says "Use this first to discover available compliance domains before searching." Provides context on scale (3,000+ nodes, 31 pillars) to guide usage.
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?
Without annotations, the description carries the full burden. It explicitly states the output (summaries with BLUF) and assures factual grounding from legal sources, adding credibility beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus examples, front-loading the main action. Every word adds value, and the structure is clear.
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 or annotations, the description covers key aspects: search functionality, output content (BLUF), and source reliability. It briefly mentions optional filter (pillar) but does not detail return structure beyond summaries. Still sufficiently complete for a search 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%, so the description adds limited value for parameters. The examples for 'query' are helpful but not essential given the schema's descriptions already exist.
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 searches nodes by keyword and returns summaries with a BLUF. It provides examples and distinguishes itself from siblings (get_node, list_pillars) by focusing on search functionality.
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 but does not explicitly state when to use this tool versus alternatives. It implies usage for keyword searches but lacks direct guidance on exclusions or when to prefer sibling tools.
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!