endiagram
It has been replaced by endiagram-mcp
Server Details
12 deterministic graph-theory tools for structural analysis. Describe systems in EN syntax — get topology, bottlenecks, blast radius, critical paths. No AI inside the computation.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 7 of 7 tools scored. Lowest: 3.1/5.
Each tool has a clearly distinct purpose: compose merges/extracts systems, equivalent compares/replays changes, invariant finds automatic properties, live checks deadlock/boundedness, reachable tests connectivity, render visualizes, structure analyzes topology. No overlap.
All tool names are single, lowercase verbs (compose, equivalent, invariant, live, reachable, render, structure), forming a consistent and predictable pattern.
7 tools cover the major analysis dimensions of system modeling (composition, comparison, invariants, liveness, reachability, visualization, structure) without being overly numerous or sparse.
The tool set provides comprehensive analytical coverage: structural analysis, branching/composition, behavioral checks (invariants, liveness, reachability), change comparison, and visualization. No obvious gaps for its domain.
Available Tools
7 toolscomposeAInspect
How do parts combine, or how does a part stand alone? Merge mode (source_a + source_b + links): declare which entities in A are the same as entities in B; the combined graph is wired via string-equality of shared names. Extract mode (source + subsystem): pull a named subsystem out as standalone EN with boundary inputs/outputs, actors, and locations. Valid subsystem names come from structure's subsystems field — call structure on the source first to discover them. See the server instructions for EN language syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| links | No | Entity identifications, one per line. Format: `a.<entity name>=b.<entity name>` (A's entity is the same as B's entity). `#` starts a comment. Example: `a.user session=b.authenticated session`. | |
| source | No | EN source code for extract mode | |
| source_a | No | EN source code or path to .en/.txt file for the first system | |
| source_b | No | EN source code or path to .en/.txt file for the second system | |
| subsystem | No | Subsystem name to extract. Valid names come from structure's `subsystems` field — call structure on the source first to discover them. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full transparency burden. It details merge's string-equality wiring and extract's output (subsystem EN with boundaries, actors, locations). Lacks specifics on idempotency or side effects, but covers major 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 front-loaded with the two modes and is information-dense. While slightly verbose, each sentence serves a purpose, and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains outputs for both modes. It also notes a dependency on structure, providing necessary context for correct usage. Could mention parameter constraints (e.g., mutual exclusivity of merge vs extract params).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining how parameters map to modes (links for merge, source+subsystem for extract), providing context beyond individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's dual purpose: merge mode to combine graphs via shared names, and extract mode to isolate a subsystem. It distinguishes from siblings by referencing structure for subsystem discovery, providing a unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use merge vs extract, including prerequisite to call structure first for extracts. However, it does not list alternative tools for similar tasks (e.g., equivalent or invariant), leaving some ambiguity in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
equivalentAInspect
Are two systems the same, or what changes if I change this one? Compare mode (source_a + source_b): structural differences, edit distance, spectral equivalence. isCospectral=true means identical graph structure up to relabeling — topologically the same despite different names, actors, or locations. Evolve mode (source + patch): dry-run a change, shows diff plus new/lost bridge nodes. Patch has three directive types — plain EN statement adds an action; a line starting with - (and not containing do:) removes the named action; a statement whose action name matches an existing one replaces the original. See the server instructions for EN language syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| patch | No | EN patch for evolve mode. Three directive types: plain EN statement (`actor do: X needs: Y yields: Z at: W`) adds action X; a line starting with `-` (and not containing `do:`) removes the named action; a new statement with an existing action name replaces the original. Multiple directives allowed, one per line. | |
| source | No | EN source code for evolve mode | |
| source_a | No | EN source code or path to .en/.txt file for the first system | |
| source_b | No | EN source code or path to .en/.txt file for the second system |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the tool's behavior: it computes structural differences, edit distance, spectral equivalence in Compare mode, and dry-run diff with new/lost bridge nodes in Evolve mode. It also explains patch directive types. Since no annotations are provided, the description must carry the full burden, and it does so well, though it does not discuss side effects 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 structured into clear paragraphs for each mode and patch directives. The first sentence effectively introduces the tool's purpose. While it contains detail, it is not verbose for the complexity of the tool. A minor improvement could be tighter phrasing.
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 (two modes, patch syntax) and the absence of an output schema, the description covers the main functionality and parameter usage. However, it does not describe the output format or return type explicitly, which is a gap for an agent to understand what results to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of each parameter in context (e.g., source_a and source_b for Compare mode, source and patch for Evolve mode) and elaborating on patch directives beyond the schema's description. This helps an agent understand parameter usage.
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 compares two systems or dry-runs a patch, with two distinct modes (Compare and Evolve). The verb-resource pairing is explicit: 'compare' or 'evolve' systems. However, it does not distinguish itself from sibling tools like 'compose' or 'invariant', leaving the agent unsure when to prefer this 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. The description explains modes but does not state prerequisites, typical scenarios, or when not to use it. There is no mention of sibling tools or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invariantAInspect
What's always true — automatic findings and on-demand checks. Automatic outputs: conservationLaws (weighted entity sums constant across executions), sustainableCycles (T-invariants — action sequences returning to start state), depletableSets (entity groups whose simultaneous depletion is irreversible), behavioral.deficiency (0 means structure fully determines dynamics), behavioral.isReversible, behavioral.hasUniqueEquilibrium. On-demand via rules: encode domain-specific claims and verify them against the graph — this is how to check things the topology alone can't see (precedence, coverage, centrality bounds, resilience). See the rules parameter for supported sentence shapes.
| Name | Required | Description | Default |
|---|---|---|---|
| rules | No | Custom structural rules, one per line. Four supported sentence shapes (regex-matched): (1) `no bridge that is also hub` — flags nodes that are both a bridge and a hub. (2) `every path from X to Y passes through at least one of [A, B, C]` — encodes precedence/coverage; use to check `A must happen before Y produces Z` by rewriting as `every path from Z's input to Z passes through [A]`. (3) `no node with centrality above 0.5` — flags over-central nodes (replace 0.5 with any threshold). (4) `removing any single node disconnects at most N others` — connectivity robustness check. Unrecognized rules return satisfied:false with an explanation listing these shapes. | |
| source | Yes | EN source code, or path to .en/.txt file |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully carries the burden. It details automatic outputs and rule behavior, including unrecognized rule handling. It does not mention computational cost or side effects, but for a static analysis tool, the disclosure is adequate.
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 well-structured with automatic findings followed by on-demand checks. It is front-loaded with the core idea. While not extremely concise, every sentence 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?
With two parameters and no output schema, the description covers both parameters thoroughly and explains return values for automatic mode. It is complete enough for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description dramatically enhances understanding, especially for the 'rules' parameter by listing four supported sentence shapes with examples. This adds significant 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 communicates that the tool analyzes invariants, listing automatic findings and on-demand rules. It uses specific terms like 'conservationLaws' and 'sustainableCycles', but lacks a concise verb-resource summary that distinguishes it from siblings like 'structure' or 'reachable'.
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 explains on-demand rules for domain-specific claims, but does not explicitly state when not to use this tool or compare it to sibling tools. The context is clear, but exclusions and alternatives are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
liveBInspect
Can it deadlock? Can entities overflow? isStructurallyLive means every siphon contains a trap — no structural deadlock possible. uncoveredSiphons are entity groups that can drain permanently, with the actors and locations affected. isStructurallyBounded means no entity can accumulate without limit. unboundedCycles are action sequences that could cause overflow. See the server instructions for EN language syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | EN source code, or path to .en/.txt file |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the analysis outputs like uncovered siphons and unbounded cycles, suggesting a read-only static analysis. However, it does not explicitly state that the tool does not modify state or require special permissions.
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 not concise; it includes explanatory definitions of terms like 'isStructurallyLive' which could be separated. It lacks front-loading of the tool's primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not clearly state what the tool returns (e.g., data structure, text). While it mentions uncovered siphons and unbounded cycles, the format or structure of the result is ambiguous.
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 sole parameter 'source' is already fully described in the schema (100% coverage). The description adds no new semantic details beyond what the schema provides, so the baseline of 3 applies.
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 checks for structural liveness and boundedness in EN source code, mentioning specific concepts like siphons and cycles. It distinguishes from sibling tools like 'invariant' and 'reachable' by focusing on liveness analysis. However, the name 'live' is somewhat vague.
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 checking deadlock and overflow properties but does not explicitly state when to use this tool versus alternatives. It references server instructions for syntax, but lacks guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reachableAInspect
Can X reach Y? Follows directed data flow first; falls back to undirected. from and to accept entity names or action names (resolved against the program). Path shows each step with actor and location. locationCrossings counts boundary transitions. defense_nodes checks if guards cover all paths; coverage.fullCoverage=false means unguarded routes exist. See the server instructions for EN language syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target node name | |
| from | Yes | Starting node name | |
| source | Yes | EN source code | |
| defense_nodes | No | Comma-separated guard nodes to check coverage |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits: the fallback mechanism from directed to undirected, the path output with actor and location, and the locationCrossings and defense_nodes behaviors. Without annotations, this provides good transparency about what the tool does and returns.
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 and front-loaded with the core question 'Can X reach Y?'. It efficiently explains key details without redundancy. Every sentence adds value, though it could be slightly tighter.
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 covers important output aspects: path display, locationCrossings, and coverage.fullCoverage. It references external instructions for syntax. It is sufficiently complete for the tool's complexity, though missing some edge cases like error handling.
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 adds meaning beyond the input schema by explaining that 'from' and 'to' accept entity or action names resolved against the program, and clarifying the 'defense_nodes' parameter's effect on coverage output (fullCoverage flag). Schema coverage is 100%, so the baseline is 3, but the additional context justifies a 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 clearly states the tool's purpose: checking reachability ('Can X reach Y?') with directed data flow first, falling back to undirected. It distinguishes from sibling tools like 'equivalent' or 'render', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the behavior (directed first, then undirected) and mentions the 'defense_nodes' parameter for coverage checking. It does not explicitly state when not to use this tool, but the context of sibling tools implies distinct use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
renderAInspect
SVG or PNG diagram. Only call when user explicitly asks to visualize. The rendered image is delivered to the user, not injected into the model's context. See the server instructions for EN language syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Output format: png (default) or svg. PNG is rasterized server-side via Batik. | |
| view | No | Group by: actors (partition by actor) or locations (partition by location). Default auto-detects topology. | |
| color | No | Seed color hex (#RRGGBB) to generate a custom theme. Overrides theme parameter. One color generates the entire palette. | |
| theme | No | Color theme. Curated presets (each with light + dark variants; pair with `isDark`): `Editorial` (stone paper + rust focal, adapted from cathrynlavery/diagram-design), `Primer` (GitHub design system — blue accent, data-vis roles), `Carbon` (IBM Carbon — sharp 0px corners, corporate blue). Or seed-derived palettes generated on the fly from `color`. Pass 'dark'/'light' for the default variant. Overridden by `color` if provided. | |
| isDark | No | true or false. Selects the dark or light variant of a named preset. If omitted, defaults to dark unless theme=light. | |
| output | No | File path to save the rendered image | |
| source | Yes | EN source code, or path to .en/.txt file | |
| quality | No | Output quality: small, mid, or max | |
| direction | No | Layout direction: LR (left-to-right) or TB (top-to-bottom). Default auto-detects from condensation DAG aspect ratio. | |
| structure_layers | No | Bitmask for structure overlays. Bits: 1=subsystems, 2=pipelines, 4=cycles, 8=forks, 16=joins, 32=hubs, 64=deadlock, 128=overflow. Default 255 (all on). Pass 0 to hide all. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It discloses that the rendered image is delivered to the user and not injected into the model's context, which is critical for the agent's understanding. It does not mention auth needs or side effects, but the stated behavior is clear and sufficient for this non-destructive 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?
Three sentences, each serving a distinct purpose: what it does, when to use, and a behavioral note plus reference. Front-loaded and no extraneous words. Excellent 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 complexity of 10 parameters but full schema coverage, the description provides necessary context about output delivery and usage condition. It lacks details on return value format, but the statement 'delivered to the user' implies no return to the agent, which is adequate for a render tool. The reference to server instructions compensates for syntax 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?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds little beyond the schema, only reinforcing the output format (SVG/PNG). No additional semantic value beyond what is already in 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 renders SVG or PNG diagrams. The condition 'Only call when user explicitly asks to visualize' sharpens the purpose. Sibling tools like 'compose' and 'invariant' are distinct operations, so confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use only when the user asks to visualize, which is a clear trigger. It does not explicitly list alternatives or when not to use, but the sibling names and the specific condition provide sufficient guidelines. The reference to server instructions adds context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
structureAInspect
What is this system? Returns shape (Pipeline, Fork-Join, DAG, Star, Cycle, Tree, Complete, etc.), stages with roles, bridge nodes, cycles, parallelism, critical path, dominator tree, min-cuts, subsystems, interface nodes, actors (who does what, workload entropy), locations (where work happens, boundary crossings). Levers: node=X returns per-node centrality (betweenness, closeness, eigenvector) for a specific node. detect_findings=true flags named structural risks — unguarded-sink (sinks reachable via only pipeline actions, no JOIN/HUB gating), single-cut-path (source-sink pairs with only one vertex-disjoint path), multi-cut-path (paths with redundant defense, min-cut > 1). See server instructions for EN language syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| node | No | Node name. When provided, returns per-node centrality (betweenness, closeness, eigenvector) for this specific node instead of the overview. | |
| source | Yes | EN source code, or path to .en/.txt file | |
| detect_findings | No | Set to 'true' to flag named structural findings. Possible values: unguarded-sink, single-cut-path, multi-cut-path. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the tool's analytical nature and return values thoroughly. It does not mention side effects or safety, but as a read-only structure analysis, this is acceptable.
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 somewhat long and lists many outputs in a dense paragraph. While informative, it could be more structured (e.g., bullet points) to improve readability.
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 fully explains what the tool returns, including shapes, risks, and parameter effects. It also references server instructions for syntax, covering all important aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra context for detect_findings by explaining the meaning of each finding type, which provides 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 that the tool returns the structural shape and various properties of a system. It lists specific outputs (e.g., shape, stages, cycles) and distinguishes itself from siblings like compose or render by focusing on structural 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?
The description implicitly guides usage through parameter details (node and detect_findings) but does not explicitly compare with sibling tools. However, the purpose is distinct enough that no further guidance is necessary.
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!