endiagram-mcp
Server Details
EN Diagram — structural verification for concurrent systems. Pure math, no AI.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- dushyant30suthar/endiagram-mcp
- GitHub Stars
- 7
- Server Listing
- endiagram
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.7/5 across 7 of 7 tools scored. Lowest: 1.8/5.
Each tool targets a distinct analysis operation: compose for merging/extracting, equivalent for comparison, invariant for property checking, live for deadlock/boundedness, reachable for reachability, render for visualization, and structure for overall shape. No overlapping purposes.
All tool names are single-word verbs in lowercase, following a consistent imperative style (compose, equivalent, invariant, live, reachable, render, structure). No mixing of conventions.
With 7 tools, the server covers the essential analysis operations for system diagrams without being overly large or minimal. Each tool earns its place.
The tool surface covers structural analysis (structure), behavioral properties (invariant, live, reachable), comparison (equivalent), composition (compose), and visualization (render). No obvious gaps for the stated analysis purpose.
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?
No annotations are provided, so the description carries full burden. It discloses the two modes, how merging works (string-equality of shared names), and that extract creates a standalone EN with boundary elements. It does not explicitly state read-only or output format, but behavior is well-described.
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 efficient, starting with an engaging question and then explaining both modes. Each sentence serves a purpose. Slightly more structured formatting (e.g., bullet points) could improve clarity, but it remains 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?
With no output schema, the description hints at return types ('combined graph', 'standalone EN'). It covers prerequisites and modes well. Missing explicit mention of output format or that parameters are mode-specific, but overall complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description significantly adds value by tying parameters to modes, explaining the links format, and sourcing subsystem names from structure output. This goes well beyond the schema 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 identifies two modes (merge and extract), specifies the verb ('combine'/'extract') and resource ('EN'), and distinguishes itself from sibling tools like 'structure'.
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 when to use each mode and provides a prerequisite for extract mode (call structure first). It does not explicitly mention when not to use the tool or list alternatives, but the context is clear.
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?
Given no annotations, the description effectively explains behavioral traits: isCospectral meaning, evolve mode as dry-run, and patch directive types. It doesn't mention permissions or rate limits but covers core behavior comprehensively.
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 front-loaded purpose, mode breakdown, and detailed patch syntax. While slightly lengthy, every sentence adds necessary context without redundancy.
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 4 parameters and no output schema, the description covers expected outputs (diff, edit distance, bridge nodes) and both usage modes. Missing error handling or edge cases, but complete enough for typical 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?
Schema coverage is 100%, and the description adds significant meaning beyond parameter names and types: it explains modes, how patch directives work, and the relationship between parameters (source_a+source_b vs source+patch). This enhances agent understanding of 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 systems for equivalence or differences, using verb 'are the same' and 'compare'. It distinguishes two modes (Compare and Evolve) and explains their purposes, differentiating it from sibling tools like compose or render.
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 clear guidance on when to use each mode: Compare mode for structural differences/edit distance/spectral equivalence, and Evolve mode for dry-run changes. It does not explicitly state when not to use the tool or alternatives, but the context is sufficiently clear.
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?
With no annotations, the description carries the full burden. It details automatic outputs (e.g., conservationLaws, sustainableCycles) and the behavior of on-demand rules, including handling of unrecognized rules. However, it does not explicitly state whether the tool is read-only or has side effects, creating minor ambiguity.
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 informative and organized, starting with a clear summary then detailing outputs and rules. While lengthy, every sentence adds value. It could be slightly more concise, but it avoids tautology and uses clear structure.
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 specify return format. It lists automatic output fields but does not describe the structure of the response (e.g., JSON object with specific keys). This omission leaves the agent uncertain about how to parse results.
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%, providing a baseline of 3. The description adds significant value, especially for the 'rules' parameter, by listing four supported sentence shapes with examples and explaining the response for unrecognized rules. The 'source' parameter description mirrors the schema but 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?
The description clearly states the tool's dual purpose: automatic invariant findings and on-demand custom rule checking. It lists specific outputs and distinguishes the on-demand rules as a way to check things topology alone can't see, which differentiates it from sibling tools like 'structure'.
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 some guidance: automatic outputs are always available, and rules are for custom claims. However, it lacks explicit comparison to siblings or when-not-to-use scenarios. No alternative tools are named, leaving the agent to infer use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
liveDInspect
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?
No annotations exist. The description mentions potential outputs ('uncoveredSiphons', 'unboundedCycles') but does not confirm them as return values or specify side effects (e.g., read-only nature). Behavioral traits are inadequately disclosed.
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 starts with rhetorical questions and spends space defining terms without clearly stating the tool's function. It is not concise; every sentence does not earn 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 no output schema, the description should clarify return format. It hints at outputs like 'uncoveredSiphons' and 'isStructurallyLive' but does not explicitly state what the tool returns. Incomplete for a one-parameter 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?
Schema covers the 'source' parameter 100% with description 'EN source code, or path to .en/.txt file'. The tool description adds no additional meaning, only deferring to 'server instructions'. It does not explain what EN language is, leaving the parameter ambiguous.
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 defines terms like 'isStructurallyLive' and 'uncoveredSiphons' but does not directly state that the tool analyzes Petri nets for liveness and boundedness. The purpose is implied through questions and definitions, but lacks a clear verb-resource statement distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like 'reachable' or 'structure'. The only usage hint is 'See the server instructions for EN language syntax', which is about input syntax, not tool selection.
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?
With no annotations provided, the description carries the full burden and excels. It discloses the algorithm (directed first, then undirected), explains what the path shows (each step with actor and location), clarifies locationCrossings as boundary transitions, and details defense_nodes checking for full coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no wasted words. It front-loads the core concept ('Can X reach Y?'), then systematically explains inputs and outputs. Every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (graph reachability with various features), the description covers input syntax, output details (path, locationCrossings, defense_nodes), and even mentions fullCoverage flag. It refers to external server instructions for EN syntax, which is a minor gap but acceptable for such a detailed tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value beyond the schema: it clarifies that 'from' and 'to' accept entity or action names (resolved), and explains the meaning of 'defense_nodes' coverage output. This extra context helps the agent use parameters correctly.
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 starts with 'Can X reach Y?' which clearly conveys the tool's purpose: checking reachability in a program graph. It mentions directed data flow with fallback to undirected, but does not explicitly differentiate from sibling tools like 'equivalent' or 'live'.
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?
It explains that 'from' and 'to' accept entity or action names resolved against the program, and describes additional outputs like 'locationCrossings' and 'defense_nodes' coverage. However, it does not provide guidance on when to choose this tool over alternatives like 'compose' or 'invariant'.
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?
No annotations exist, so the description carries the full transparency burden. It discloses that the rendered image is 'delivered to the user, not injected into the model's context,' clarifying output destination. It also references server instructions for syntax. However, it does not discuss side effects, permissions, or error handling, which are minor gaps for a render 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 three sentences, each earning its place: purpose, usage condition, and output behavior. It is front-loaded with the core function and concise without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema), the description covers key behavioral aspects: output format, delivery destination, and reference to external syntax instructions. It does not explain return values or error cases, but for a render tool this is acceptable. Slightly incomplete regarding integration with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds no new parameter-specific meaning beyond the schema, only referencing server instructions for syntax. Baseline score of 3 is appropriate as the description does not enhance understanding of parameter usage or constraints.
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 states 'SVG or PNG diagram' and 'Only call when user explicitly asks to visualize.' It clearly identifies the tool's output and usage trigger. However, it does not explicitly specify what type of diagram (e.g., from EN source code) or differentiate from sibling tools like 'compose' or 'structure', though the context of visualization implies a distinction.
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?
Provides a clear condition for use: 'Only call when user explicitly asks to visualize.' This guides the agent on when to invoke. However, it does not mention when not to use the tool (e.g., if the user asks for analysis) nor list alternative sibling tools for non-visualization tasks, which would improve decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
structureBInspect
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, the description must disclose behavior fully. It explains key behaviors: return overview by default, per-node centrality when 'node' is provided, and structural findings when 'detect_findings=true'. However, it omits side effects, authentication needs, or mutation status.
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 moderately concise but dense with terms. It front-loads with 'What is this system?' which is helpful, but the listing of many output concepts could be better structured (e.g., bullet points) for 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, the description should thoroughly explain the return structure. It lists many output elements but does not provide a clear format or schema. It also redirects to external documentation ('See server instructions') which reduces 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?
Schema descriptions cover 100% of parameters. The tool description adds value by explaining the 'node' and 'detect_findings' parameters in context ('Levers'), clarifying their effects. The 'source' parameter is covered adequately by 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 what the tool does: it returns system structure information (shape, stages, etc.). It distinguishes the tool's domain (structural analysis) from sibling tools, though it does not explicitly differentiate them.
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 over its siblings. The description does not include when/when-not or alternative tool references.
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!
Your Connectors
Sign in to create a connector for this server.