registeroracle
Server Details
RegisterOracle - 10-tool DORA Art.28 register: ICT third-party, contracts, criticality.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ToolOracle/registeroracle
- 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 3.4/5 across 10 of 10 tools scored. Lowest: 2.6/5.
Each tool targets a distinct function: risk analysis, provider classification, export, gap identification, retrieval, server status, listing, registration, statistics, and validation. No overlap in purpose.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_providers, register_provider, concentration_risk). The naming is predictable and readable.
With 10 tools covering registration, validation, risk analysis, and reporting, the set is well-scoped for a DORA register management server. No unnecessary tools, and the count is appropriate for the domain.
The surface covers key operations: CRUD (list, get, register), validation, risk analysis, and export. A minor gap is the lack of an explicit delete provider tool, but register_provider supports updates, and the overall coverage is strong.
Available Tools
10 toolsconcentration_riskBInspect
Analyze ICT concentration risks across providers, countries, cloud types. DORA Art. 29 requires assessment of ICT concentration risk.
| 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 must fully disclose behavioral traits. It adds regulatory context but does not mention whether the tool is read-only, what data it accesses, or any limitations. This is insufficient for a tool with zero annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the key action, no filler. 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 tool has no output schema, so the description should explain what the analysis returns (e.g., report, score, table). It lacks this information, making it incomplete for an agent to understand the tool's 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?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter meaning, but it adds value by specifying the analysis scope. 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 analyzes ICT concentration risks across providers, countries, and cloud types, and cites a regulatory requirement (DORA Art. 29). However, it does not explicitly differentiate from sibling tools like gap_analysis, which could also involve risk assessment.
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 the tool is for analyzing concentration risk but does not specify when to use it 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.
ctpp_checkAInspect
Assess if a provider might qualify as Critical Third-Party Provider (CTPP) under DORA Art. 31-44. CTTPPs face direct ESA oversight.
| Name | Required | Description | Default |
|---|---|---|---|
| provider_id | Yes | Provider ID to assess |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively conveys a read-only assessment tool by 'Assess if a provider might qualify' and adds regulatory context (DORA, direct ESA oversight). Could mention side effects if any, but likely none.
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?
Single sentence efficiently packs purpose, regulatory context, and consequence. 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 single parameter, no annotations, and no output schema, description covers core purpose and context well. Lacks indication of return type, but overall sufficient.
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?
Only one parameter (provider_id) with schema coverage 100%. Description does not add extra meaning beyond schema, but baseline is adequate.
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 it assesses CTPP qualification under DORA, with specific regulatory articles and oversight context. Distinguishes from sibling tools like concentration_risk 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?
Describes when to use (assess potential CTPP status). Does not explicitly mention when not to use or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_itsBInspect
Export Register of Information in ITS-compliant format for supervisory reporting.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Export format |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, permissions, or side effects. It only states 'export', leaving ambiguity about mutation or cost.
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?
A single, front-loaded sentence with no unnecessary words. Every part 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 is complete for a simple tool with one parameter, but given no output schema or annotations, it could elaborate on what the exported data contains or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single parameter. The description adds the context 'ITS-compliant format' beyond the schema's 'Export format', but overall contributes minimal additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (export), the resource (Register of Information), and the specific format (ITS-compliant for supervisory reporting). It distinguishes from sibling tools like concentration_risk or gap_analysis.
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 guidelines on when to use this tool versus alternatives. Sibling tools have different purposes but the description does not provide any exclusion criteria or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gap_analysisBInspect
Identify gaps in the Register — missing fields, incomplete entries, missing exit plans, LEI coverage issues.
| 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 must disclose behavioral traits. It does not state whether the tool is read-only, modifies data, or has any side effects. The agent cannot infer if a mutation occurs.
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?
Single sentence, no fluff. Front-loads the main action ('Identify gaps in the Register') and lists specifics efficiently.
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 no parameters and no output schema, the description is passable but lacks information about what the result looks like (e.g., a report, list, or metrics).
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 exist, so schema description coverage is 100%. The description adds value by naming the gap categories analyzed, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: finding gaps in the Register, listing specific types like missing fields and incomplete entries. It is distinct from sibling tools like 'validate_roi', though it does not explicitly differentiate.
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 like 'concentration_risk' or 'ctpp_check'. Missing context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_providerAInspect
Get full details, risk flags, and ITS completeness of a specific provider.
| Name | Required | Description | Default |
|---|---|---|---|
| provider_id | Yes | Provider ID from list_providers |
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 indicates a read operation (Get), but does not disclose any behavioral traits like auth needs or rate limits, which would be expected.
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?
Single sentence with no unnecessary words, efficiently conveys purpose and key output elements.
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 lists what is returned (full details, risk flags, ITS completeness). It could be slightly more explicit about the output, but is largely sufficient.
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% (parameter 'provider_id' described as 'Provider ID from list_providers'), so baseline is 3. The description adds no further semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves full details, risk flags, and ITS completeness for a specific provider, using a specific verb-resource pair that distinguishes it from sibling tools like list_providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (use when you need full details on one provider and have its ID), but no explicit when-to-use or when-not-to-use guidance is provided, nor are alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkCInspect
Server and data status.
| 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 given, and the description fails to disclose any behavioral traits such as read-only nature, authentication needs, or side effects. The agent is left uninformed.
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 is not verbose. However, it is a noun phrase rather than a full sentence, slightly reducing clarity.
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 and zero parameters, the description should explain what 'status' entails or what the tool returns. It fails to provide that 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?
With zero parameters, the baseline score is 4. The description does not add parameter information, but schema coverage is 100% (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?
The description 'Server and data status' gives a general idea of checking health, but lacks specificity. It does not clearly distinguish from sibling tools like ctpp_check or gap_analysis.
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 context provided for appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_providersAInspect
List all ICT third-party providers in the Register of Information with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search by name/type/function | |
| country | No | ||
| criticality | No | ||
| service_type | 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 carry the full burden. It only states a non-destructive list operation with filters, but lacks details on authentication, rate limits, pagination, or what happens with empty results. The description is minimal for behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no redundant information. Every word earns its place, making it appropriately concise.
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 4 optional parameters, no annotations, and no output schema, the description is too brief. It fails to explain filtering behavior (e.g., combination logic) or response format, leaving gaps for an AI agent to correctly 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 input schema has 4 parameters with only 25% description coverage (search has a partial description). The tool description merely says 'optional filters' and does not explain the meaning or valid values for country, criticality, or service_type. This does not compensate for the low schema coverage.
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 verb 'list', the resource 'ICT third-party providers', and the source 'Register of Information', with mention of optional filters. This is a specific and distinct purpose compared to siblings like get_provider or register_provider.
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 the tool is for listing providers with optional filters, providing clear context for usage. However, it does not explicitly state when not to use it or compare to alternative tools like get_provider for single provider lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_providerCInspect
Add or update an ICT third-party provider in the DORA Register of Information (Art. 28). Tracks all ITS-required fields: LEI, service type, criticality, data location, exit plan, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| lei | No | Legal Entity Identifier (20-char) | |
| notes | No | ||
| country | No | Country of HQ (ISO 3166-1 alpha-2) | |
| cloud_type | No | ||
| criticality | No | ||
| provider_id | No | Unique ID (auto-generated if empty) | |
| audit_rights | No | ||
| contract_end | No | Contract end (YYYY-MM-DD) | |
| recovery_sla | No | ||
| service_type | No | ||
| data_location | No | Data storage/processing location | |
| provider_name | Yes | Name of ICT third-party provider | |
| certifications | No | ||
| contract_start | No | Contract start (YYYY-MM-DD) | |
| subcontracting | No | Uses sub-outsourcing? | |
| annual_cost_eur | No | Annual cost in EUR | |
| exit_plan_exists | No | Exit strategy documented? | |
| substitutability | No | ||
| function_supported | No | Business function supported | |
| notification_clause | No | ||
| last_risk_assessment | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions 'add or update' and 'auto-generated if empty' for provider_id, but omits details on mutation semantics (e.g., does update replace all fields or merge?), idempotency, error handling, or access requirements. For a complex tool, this is insufficient.
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 convey core purpose and scope without fluff. Could be slightly improved by bullet-listing key fields, but structure is adequate and front-loaded.
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 21 parameters, no output schema, and no annotations, the description lacks completeness. It does not describe return values, error conditions, or constraints beyond the input schema. For a complex regulatory tool, this is a significant gap.
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 52%, and the description lists only a few fields ('LEI, service type, criticality, data location, exit plan') without adding new semantic clarity beyond existing schema descriptions. Many parameters (e.g., certifications, audit_rights, notification_clause) remain unexplained in both schema and description, failing to compensate for the coverage gap.
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 verb ('add or update'), resource ('ICT third-party provider'), and regulatory context ('DORA Register of Information Art. 28'). It distinguishes itself from sibling tools like get_provider and list_providers by defining its create/update role.
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 siblings like get_provider or list_providers, nor on distinguishing between add and update scenarios. Usage context is implied by the verb but lacks direct comparisons or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_statsAInspect
Dashboard summary: provider counts, criticality distribution, ITS field completeness, exit plan and LEI coverage.
| 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 must fully disclose behavioral traits. It does not state that this is a read-only operation, whether it requires specific permissions, or any side effects. The description only lists output content, which is insufficient for an unannotated 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 a single sentence that conveys the tool's purpose without excess words. It is appropriately sized and front-loaded with the key action ('Dashboard summary') and details.
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, no output schema, and low complexity, the description adequately covers the purpose. However, it could mention that the tool is read-only or provide hints about the expected output format to enhance completeness.
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 there is no need for the description to add parameter details beyond the schema. Per instructions, 0 parameters baseline is 4, and the description does not include any misleading parameter information.
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 provides a dashboard summary with specific metrics: provider counts, criticality distribution, ITS field completeness, exit plan, and LEI coverage. It uses a specific verb ('Dashboard summary') and distinguishes from sibling tools (e.g., list_providers) by focusing on aggregated statistics rather than individual 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?
The description implies usage for dashboard or overview purposes but does not explicitly state when to use this tool versus alternatives like concentration_risk or gap_analysis. No when-not-to-use or exclusion criteria are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_roiAInspect
Validate entire Register of Information against DORA ITS requirements. Checks all mandatory fields, exit plans for critical providers, LEI coverage, etc.
| 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, so description must carry behavioral disclosure. It describes the operation but does not clarify if it is read-only, whether it triggers side effects, or its runtime behavior. This is insufficient for a tool with no 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?
Single sentence that is concise and front-loaded with key 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?
With zero parameters and no output schema, the description adequately explains what the tool does and its focus. However, it does not mention the output format or whether it modifies data, leaving some 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?
No parameters exist, so baseline is 4. The description adds value by explaining the scope of validation beyond the empty schema, listing specific checks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool validates the entire Register of Information against DORA ITS requirements, listing specific checks (mandatory fields, exit plans, LEI coverage). The verb 'validate' and resource are precise, and it distinguishes from sibling tools like gap_analysis.
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?
Implies usage for compliance validation but lacks explicit guidance on when to use this tool versus siblings like gap_analysis or ctpp_check. No exclusions or alternatives mentioned.
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!