resilienceoracle
Server Details
ResilienceOracle - 10 operational resilience tools: BIA, RTO/RPO, scenario testing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ToolOracle/resilienceoracle
- GitHub Stars
- 0
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 2.5/5 across 10 of 10 tools scored. Lowest: 1.5/5.
Each tool targets a distinct aspect of BCM/DRP: gap analysis, crisis plan validation, evidence collection, system health, recovery readiness, registration, RTO/RPO checking, scenario library, BIA setting, and test registration. No overlapping purposes.
All tool names use consistent lowercase_snake_case with clear verb_noun patterns (e.g., register_system, set_bia, crisis_plan_check). The naming is predictable and easy to parse.
With 10 tools, the server covers the core BCM/DRP lifecycle without being overly granular or sparse. Each tool serves a clear function, making the count well-scoped for the domain.
The tool set covers system registration, BIA, gap analysis, crisis plan checks, scenario library, test registration, evidence bundling, recovery status, and health checks. This covers key regulatory and operational needs, with no obvious missing operations for the stated purpose.
Available Tools
10 toolsbcm_gap_analysisBInspect
BCM plan completeness analysis across all systems.
| 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 must carry the full burden. It only says 'analysis', implying a read-only operation, but fails to disclose any behavioral traits such as side effects, authentication needs, or what happens during the analysis. This is insufficient for a tool with no annotation support.
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, efficient sentence with no wasted words. Every word contributes to stating the tool's 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?
Despite having no parameters, the tool lacks an output schema and the description does not hint at what the analysis returns. For a gap analysis tool, the output format or content is important for the agent to interpret results. Combined with no annotations, the description is incomplete.
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, and schema description coverage is 100%. The description does not need to add parameter semantics since none exist. Baseline for no parameters is 4.
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 'BCM plan completeness analysis across all systems', which clearly identifies the verb (analysis) and resource (BCM plan completeness). However, it does not differentiate from sibling tools like crisis_plan_check or recovery_status, which could have overlapping scopes.
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 guidance is provided on when to use this tool versus alternatives. The single sentence lacks context on prerequisites, scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crisis_plan_checkCInspect
Validate crisis communication plan elements (Art. 11(7)).
| Name | Required | Description | Default |
|---|---|---|---|
| media_handling | No | ||
| escalation_matrix | No | ||
| communication_plan | No | ||
| crisis_team_defined | No | ||
| crisis_drill_conducted | No | ||
| internal_communication | No | ||
| customer_notification_process | No | ||
| regulator_notification_process | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Validate' without explaining what validation entails, whether it modifies data, or what constitutes a valid plan. No side effects, authorization needs, or output format are mentioned.
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 short, but it sacrifices substance for brevity. It lacks front-loaded critical information beyond the basic 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?
The tool has 8 parameters and no output schema. The description provides no context on return values, validation logic, or how parameters interact. It is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the 8 boolean parameters. Although some names are self-explanatory, the description does not explain how they are used or what their roles are in validation.
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 'Validate' and the resource 'crisis communication plan elements' with a reference to 'Art. 11(7)'. This distinguishes it from sibling tools like 'bcm_gap_analysis' or 'health_check'.
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 guidance is provided on when to use this tool versus alternatives. It implies a regulatory validation use case but does not clarify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evidence_bundleBInspect
Collect BCM/DRP evidence for audit — systems, BIA, test records.
| Name | Required | Description | Default |
|---|---|---|---|
| system_id | No | Optional: scope to one system |
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 does not disclose whether the operation is read-only or destructive, authentication needs, rate limits, or side effects.
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, front-loaded sentence with no waste. It could be slightly more detailed without sacrificing conciseness.
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 annotations or output schema, the description lacks needed context on behavior, usage boundaries, and results. It is incomplete for reliable agent 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 coverage is 100% and the parameter description is clear. The description adds 'systems, BIA, test records' context but does not enrich beyond the schema's 'scope to one system'.
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 (Collect), resource (BCM/DRP evidence for audit), and scope (systems, BIA, test records), distinguishing it from sibling tools like bcm_gap_analysis or crisis_plan_check.
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 no explicit guidance on when to use this tool versus siblings. It implies audit evidence collection but does not provide criteria for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkDInspect
Server status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. 'Server status' gives no information about side effects, authorization needs, or what the tool actually does (e.g., pings a server, checks a database, returns metrics).
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 only two words, which is too brief and underspecifies the tool's purpose. It lacks informative structure and does not earn its place by adding 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 tool has no parameters and no output schema, the description should at least hint at what the tool returns or how it behaves. The current description is completely insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100%. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Server status' is vague and does not specify the exact nature of the health check (e.g., uptime, connectivity, resource usage). It fails to distinguish from sibling tools like 'crisis_plan_check' and 'recovery_status'.
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 guidance is provided on when to use this tool versus alternatives such as 'recovery_status' or 'scenario_library'. The description does not mention any prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recovery_statusBInspect
Recovery readiness dashboard — how many systems are DR-ready.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 of behavioral disclosure. It does not mention any behavioral traits such as read-only nature, authentication requirements, or rate limits. The description is minimal and does not supplement the lack of 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 very concise, a single sentence that directly conveys the purpose. It is front-loaded and contains no unnecessary words, though it could be more structured with a clearer breakdown.
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 parameters, no output schema, and a simple purpose, the description is minimally adequate. However, it lacks details about the output format or how the dashboard functions, which would help an agent understand the tool's complete behavior.
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 no parameters, and the description does not add parameter info, which is acceptable. Baseline for 0 parameters is 4, and the description is consistent with 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 it is a 'Recovery readiness dashboard' and specifies the metric 'how many systems are DR-ready'. It provides a specific verb-resource pair and distinguishes from sibling tools like health_check or rto_rpo_check, though it could be more explicit about the output format.
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 guidance is given on when to use this tool versus alternatives like bcm_gap_analysis or health_check. There is no mention of when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_systemCInspect
Register a business-critical ICT system for BCM tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| owner | No | ||
| provider | No | ||
| system_id | No | ||
| department | No | ||
| criticality | No | ||
| description | No | ||
| system_name | Yes | ||
| failover_site | No | ||
| backup_location | No | ||
| backup_frequency | No | ||
| data_classification | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the basic action ('Register'), without disclosing side effects (e.g., whether it creates a new record or updates an existing one), authentication requirements, or error conditions. This is insufficient for a registration 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 extremely concise (one sentence, 8 words), but this undermines completeness. For a tool with many parameters and no other help (annotations, output schema), this is under-specification, not effective conciseness.
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 high complexity (12 parameters, 0% schema coverage, no annotations or output schema), the description is completely inadequate. It covers only the most basic intent, leaving the agent to guess operational details.
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 0% with 12 parameters, and the description adds no parameter-level details. It does not explain what 'criticality', 'type', 'owner', etc., mean or how they should be used. The agent must guess parameter semantics from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Register') and resource ('business-critical ICT system'), with the purpose ('for BCM tracking'). It distinguishes from siblings like 'bcm_gap_analysis' which analyze rather than register. However, it is somewhat vague on what 'register' entails (e.g., create vs. update).
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 guidance on when to use this tool vs. alternatives (e.g., using 'test_register' or 'bcm_gap_analysis' for different tasks). There is no mention of prerequisites or conditions, limiting the agent's ability to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rto_rpo_checkCInspect
Validate RTO/RPO targets against actual backup/failover capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| system_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as whether it performs read-only validation or has side effects. It lacks transparency about safety or side effects.
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 concise sentence without unnecessary words. However, it could benefit from a bit more context, such as expected format of system_id.
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 single parameter, no output schema, and no annotations, the description fails to explain what the validation produces (e.g., boolean, report, warnings). It is incomplete for an agent to understand the full behavior.
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 only parameter 'system_id' is not explained in the description. With 0% schema description coverage, the description adds no meaning beyond the bare 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 validates RTO/RPO targets against actual capabilities, which is a specific verb and resource. It distinguishes from siblings like bcm_gap_analysis and recovery_status.
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 guidance on when to use this tool versus alternatives. No mention of prerequisites or context where this check is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scenario_libraryDInspect
DORA-relevant test scenario library (10 scenarios).
| Name | Required | Description | Default |
|---|---|---|---|
| severity | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description must disclose behavioral traits (e.g., read-only, authorization needs, side effects). It provides none, leaving the agent entirely unaware of the tool's 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 under-specified; it is short but omits critical information. Conciseness should not sacrifice completeness.
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 annotations, no output schema, and multiple sibling tools, the description fails to provide essential context: action, parameter usage, return format, or differentiation from other tools.
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 0%, and the description does not mention the 'severity' parameter or its enum values. The agent gains no additional understanding of how to use the parameter.
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 it is a 'DORA-relevant test scenario library (10 scenarios)' but does not specify the action (e.g., list, retrieve, search). This is ambiguous and does not help the agent understand what the tool does.
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 guidance on when to use this tool versus siblings like test_register, crisis_plan_check, or health_check. The description provides no context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_biaCInspect
Set Business Impact Analysis data — RTO, RPO, MTPD, financial impact.
| Name | Required | Description | Default |
|---|---|---|---|
| rpo_hours | No | ||
| rto_hours | No | ||
| system_id | Yes | ||
| mtpd_hours | No | ||
| dependencies | No | ||
| recovery_priority | No | ||
| regulatory_impact | No | ||
| customers_affected | No | ||
| reputational_impact | No | ||
| financial_impact_per_hour | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Set', implying mutation, but does not disclose whether it is idempotent, overwrites or merges existing data, or requires specific permissions. With no annotations, the description fails to provide essential behavioral context.
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 very concise, consisting of a single sentence. However, it is too brief to cover essential details, making it more under-specified than efficiently compact.
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 complexity (10 parameters, no annotations, no output schema), the description is severely incomplete. It does not explain system_id, return values, or the purpose of half the parameters, leaving the agent with insufficient 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?
The description mentions four parameters (RTO, RPO, MTPD, financial impact) but the schema contains ten, including dependencies, recovery_priority, and regulatory_impact. With 0% schema description coverage, the description does not adequately explain the meaning of most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets BIA data, mentioning key fields like RTO, RPO, MTPD, and financial impact. It differentiates from sibling tools that focus on analysis or checking, though it could be more precise about whether it creates or updates data.
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 guidance is provided on when to use this tool versus alternatives such as rto_rpo_check or register_system. The description lacks any when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
test_registerCInspect
Register a DR/BCM test execution with results and evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | ||
| scenario | Yes | ||
| system_id | No | ||
| test_date | No | ||
| test_type | No | ||
| evidence_ref | No | ||
| issues_found | No | ||
| participants | No | ||
| rpo_achieved_hours | No | ||
| rto_achieved_hours | No | ||
| remediation_actions | No |
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 behavioral traits like side effects, authorization needs, or error scenarios. The description only says 'Register', implying a write operation, but does not elaborate on confirmation, rollback, or any consequences. This is insufficient for a tool with many parameters.
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 sentence of 9 words, very concise and front-loaded with the action and resource. It contains no wasted words. However, given the tool's complexity (11 parameters), it may be overly terse.
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 11 parameters, no annotations, and no output schema, the description should provide more context about registration scope, constraints, or return behavior. The current description is too sparse to be considered 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 description coverage is 0%, meaning no parameter descriptions exist. The description only hints at 'results and evidence' (corresponding to 'result' and 'evidence_ref'), but does not explain the meaning or constraints of other parameters like 'scenario', 'test_date', 'participants', etc. The enum on 'result' is clear from the schema, but the description adds minimal 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 clearly states the verb 'Register' and the resource 'DR/BCM test execution', making the tool's purpose immediately understandable. It specifies that results and evidence are involved, which aligns with the 'result' and 'evidence_ref' parameters. However, it does not differentiate from sibling tools, but sibling names like 'bcm_gap_analysis' suggest distinct functions.
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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It only states the purpose, leaving the agent without contextual cues for appropriate invocation.
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!