dependencyoracle
Server Details
DependencyOracle - 10 ICT dependency tools: SBOM, supply chain, third-party graph.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ToolOracle/dependencyoracle
- 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.8/5 across 10 of 10 tools scored.
Each tool has a clearly distinct purpose: registration, inventory, dependency analysis, simulation, health check, and SPOF detection. No two tools overlap in functionality.
Most tools follow a descriptive noun or verb_noun pattern (e.g., register_asset, map_dependency). A few are noun phrases (blast_radius, health_check), but the pattern is generally consistent and readable.
With 10 tools, the server covers the core needs of ICT dependency management without being overly heavy or sparse. Each tool adds clear value.
The toolset covers registration, inventory, dependency mapping, various analyses (blast radius, criticality, SPOF), and simulation. Missing update/delete for assets is a minor gap but acceptable for an analysis-focused server.
Available Tools
10 toolsasset_inventoryCInspect
Full ICT asset inventory with classification and filters.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_type | No | ||
| criticality | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It does not state that the tool is read-only, has no side effects, or what permissions are required. Only implies a list operation without confirming safety or limitations.
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 (one sentence) and front-loaded. However, it is too brief: it sacrifices completeness for brevity, leaving out crucial details about usage, parameters, and return 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 no output schema, the description should explain what the tool returns (e.g., list of assets with classifications). It does not mention the optional nature of parameters or the format of the inventory. The sibling tools are analytical, so this is a data retrieval tool, but the description is incomplete for proper 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 description coverage is 0%, but the description only vaguely hints at 'classification and filters'. It does not explain what asset_type or criticality parameters do, their impact on results, or how to use them. The enum values are self-explanatory but the description adds no extra 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 'Full ICT asset inventory with classification and filters' clearly indicates a retrieval/list tool that returns all assets. It distinguishes from siblings like register_asset (creation) and criticality_score (scoring), though it could explicitly say 'list' or 'get'.
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 blast_radius, dependency_graph, or health_check. The description does not mention when not to use it or provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
blast_radiusBInspect
Calculate blast radius — what breaks if this entity fails.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the purpose but does not disclose whether the tool is read-only, what it returns, or any side effects. Important traits like idempotency or performance implications are missing.
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 10 words, front-loading the purpose with no extraneous information. Every word earns its place.
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 one parameter, no output schema, and no annotations, the description is insufficiently complete. It fails to explain the output format, preconditions, or how the result is structured, leaving an agent with significant uncertainty.
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%, so the description must compensate. It implies entity_id refers to 'this entity' but provides no detail on expected format, type, or constraints. The single parameter's semantics are minimally explained.
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 uses a specific verb ('Calculate') and resource ('blast radius') with a clarifying example ('what breaks if this entity fails'). It clearly distinguishes the tool's intent from siblings like dependency_graph or impact_simulation by focusing on failure of a single entity.
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 such as dependency_graph, impact_simulation, or spof_analysis. The description provides no context for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
criticality_scoreCInspect
Calculate criticality score based on dependencies, classification, redundancy.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
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, but it only states the calculation factors. It does not mention whether the tool is read-only, any side effects, authorization needs, or what happens with invalid inputs. Critical behavioral context is missing.
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. It is front-loaded with the verb 'Calculate'. However, it could benefit from additional structure such as listing inputs or outputs.
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 and lack of output schema, the description is incomplete. It fails to mention the return format, score range, or typical usage context. Sibling tools suggest this is an analysis tool, but the description lacks sufficient detail for full autonomous use.
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 0% description coverage for the single parameter entity_id. The description mentions three factors (dependencies, classification, redundancy) but does not explain how they relate to the parameter. The description adds minimal semantic value 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 calculates a criticality score using dependencies, classification, and redundancy. It is a specific verb+resource, but does not differentiate from sibling tools like blast_radius or impact_simulation, which perform similar analytical 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. There is no mention of prerequisites, exclusions, or comparative advantages over sibling tools such as dependency_graph or spof_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dependency_graphCInspect
Get dependency tree for an entity — upstream/downstream.
| Name | Required | Description | Default |
|---|---|---|---|
| direction | No | ||
| entity_id | Yes | ||
| max_depth | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details such as what the tree structure looks like, how depth works, or any performance implications. Since annotations are absent, the description carries the full burden but fails to disclose important behaviors.
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 at one sentence, but it sacrifices necessary detail. It is front-loaded with the action but lacks structure for a multi-parameter tool.
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 three parameters, no output schema, and no annotations, the description is notably incomplete. It does not cover expected return format, error handling, or parameter constraints, leaving the agent underinformed.
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 0% schema description coverage, the description adds no semantic value beyond the schema itself. The direction parameter is mentioned in passing but not explained, and entity_id and max_depth receive no clarification.
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 gets a dependency tree for an entity and mentions the direction options (upstream/downstream). However, it does not differentiate from the sibling tool 'map_dependency' which may serve a similar purpose.
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 like 'blast_radius' or 'impact_simulation'. There are no prerequisites or exclusions 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 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 should disclose behavioral traits. It implies a read-only operation but lacks details on side effects, return format, or authentication needs.
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 terse (two words) but under-specified. True conciseness would retain necessary detail without verbosity; here, crucial information is missing.
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 a simple health check tool, the description fails to explain what 'status' entails, the response structure, or error conditions, leaving the agent underinformed.
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 adds no parameter info, but baseline is 4 for zero-parameter tools.
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' clearly indicates the tool checks server health, but it restates the tool name without additional context or differentiation from sibling tools like 'asset_inventory' or 'criticality_score'.
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, nor are there any prerequisites or context signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
impact_simulationCInspect
Simulate outage — cascade impact of entity failure.
| Name | Required | Description | Default |
|---|---|---|---|
| failed_entity | Yes | Entity name or ID to simulate failure |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. The word 'simulate' hints at a non-destructive action, but it does not explicitly state whether the tool is read-only, requires special permissions, or modifies any state. The description fails to provide adequate transparency.
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 at 5 words, with no wasted words. It is front-loaded and immediately conveys the core action. However, the brevity may sacrifice some necessary detail, preventing a perfect 5.
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 no output schema, the description should explain what the tool returns (e.g., a list of affected entities, a severity score). It does not mention output format, behavior, or side effects. For a simulation tool that likely produces a report, 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 covers the single parameter 'failed_entity' with a description ('Entity name or ID to simulate failure'), achieving 100% coverage. The tool description adds context by mentioning 'cascade impact', which relates to the parameter. However, it does not significantly enhance understanding beyond the schema, earning a baseline score of 3.
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 simulates an outage and cascade impact of entity failure. It uses specific language ('simulate', 'cascade impact') that distinguishes it from siblings like 'blast_radius' or 'spof_analysis', though it could be more explicit about what the simulation produces.
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 like 'spof_analysis' or 'blast_radius'. There is no mention of prerequisites, context, or exclusion criteria, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
map_dependencyCInspect
Create a dependency link between two entities.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| to_id | Yes | Entity depended upon | |
| from_id | Yes | Entity that depends | |
| to_name | No | ||
| from_name | No | ||
| criticality | No | ||
| dependency_type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Create a dependency link', implying a write operation without disclosing side effects, idempotency, or permission requirements.
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, direct sentence that is easy to parse, but it lacks structure to address the tool's complexity.
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 7 parameters, no output schema, and no annotations, the description fails to provide sufficient information for proper invocation, such as handling of optional fields or return values.
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 low (29%) with only two parameter descriptions; the description adds no additional meaning for the seven parameters, leaving critical fields like 'notes', 'criticality', and 'dependency_type' unexplained.
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 ('Create') and the resource ('dependency link'), specifying it involves two entities, which distinguishes it from sibling tools like 'dependency_graph' or 'register_asset'.
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 (e.g., when to create a link vs. querying the graph). No context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_assetCInspect
Register an ICT asset (application, database, server, etc.) — Art. 8.
| Name | Required | Description | Default |
|---|---|---|---|
| sla | No | ||
| notes | No | ||
| owner | No | ||
| asset_id | No | ||
| location | No | ||
| provider | No | ||
| asset_name | Yes | ||
| asset_type | No | ||
| department | No | ||
| redundancy | No | ||
| criticality | No | ||
| description | No | ||
| backup_exists | 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 must fully disclose behavior. It only says 'register' (implying creation) but does not mention idempotency, update behavior on duplicate asset_name, authentication needs, or side effects. For a tool with 14 parameters, 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?
The description is a single short sentence, which is concise but too brief for a tool with 14 parameters. It could be structured more informatively without being verbose. Adequate but not optimal.
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 (14 parameters, no output schema, no annotations), the description is incomplete. It lacks details on return values, error conditions, validation rules, and parameter relationships. A more thorough description is needed.
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%, so the description must add meaning to parameters. It does not explain any parameter; it only lists generic examples in parentheses. Parameter names like 'sla' or 'redundancy' are not clarified. The description adds minimal value 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 action 'register', the resource 'ICT asset', and provides examples like application, database, server. It also references 'Art. 8', adding regulatory context, and distinguishes itself from sibling tools like asset_inventory (read-only) and register_function (function-level).
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 alternatives. The reference to 'Art. 8' hints at compliance, but there is no statement about prerequisites, exclusions, or when not to use this tool. Sibling tools are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_functionCInspect
Register an ICT-supported business function — Art. 8.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| owner | No | ||
| department | No | ||
| criticality | No | ||
| description | No | ||
| function_id | No | ||
| process_type | No | ||
| function_name | Yes | ||
| revenue_impact | No | ||
| users_affected | No | ||
| regulatory_relevance | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description beyond 'Register an ICT-supported business function', the agent has no information about side effects, permissions required, uniqueness constraints, or what happens on registration. The description carries the full burden but provides almost nothing.
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 (one sentence), but it lacks substance. Conciseness is not valuable when the information is insufficient. It is under-specified rather than efficiently structured.
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 (11 parameters, no schema descriptions, no output schema, no annotations), the description is severely incomplete. It does not explain return values, registration behavior, or any validation rules, leaving the agent with almost no useful 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 description coverage is 0% (no property descriptions), and the description adds no meaning for any of the 11 parameters. The agent has no clue what fields like 'revenue_impact' or 'users_affected' represent or how to fill them.
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 registers an ICT-supported business function, referencing Art. 8. The verb 'register' and resource 'business function' are specific, and the sibling tools are all analysis-oriented (e.g., asset_inventory, dependency_graph), so this tool is clearly distinct as a registration/creation tool.
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. There is no mention of prerequisites, ordering, or situations where other tools like update or analysis tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spof_analysisAInspect
Detect Single Points of Failure without redundancy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only indicates the purpose without disclosing behavior such as whether it is read-only, what outputs it produces, or any side effects. 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?
The description is a single sentence, very concise and front-loaded. However, it could include more behavioral context without becoming overly long.
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 no output schema, no annotations, and no parameters, the description is too minimal. It does not explain what the tool returns or how to interpret results, leaving the agent with incomplete information for a analysis 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 no parameters and 100% coverage, so the baseline is 4. The description adds no parameter information, which is acceptable since there are none to document.
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 detects single points of failure without redundancy, using a specific verb and resource, and distinguishes itself from sibling tools like blast_radius or dependency_graph by focusing on redundancy.
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 phrase 'without redundancy' implies when to use the tool, but there is no explicit guidance on when not to use it or alternatives. Usage context is implied rather than stated.
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!