TracePass
Server Details
Manage products, EU Digital Product Passports, operator parties, and GS1 EPCIS supply-chain events.
- 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/5 across 6 of 6 tools scored.
Each tool targets a distinct domain resource (passports, products, templates, EPCIS events, passport fields, passport parties) with unique purposes, leaving no ambiguity about which tool to use for a given task.
All tool names follow a uniform pattern: 'tracepass_' followed by a clear noun (e.g., tracepass_passports). This consistency makes it easy for an agent to predict tool names and navigate the server.
6 tools is a well-scoped number for a DPP management server. Each tool covers a logical domain (passports, products, templates, EPCIS, fields, parties) without excessive granularity or missing essential areas.
The tool set covers core CRUD for products and basic passport lifecycle (create, suspend, archive), but lacks passport update actions (e.g., approve, publish) and product deletion. These gaps may force agents to use workarounds or leave states unresolved.
Available Tools
6 toolstracepass_epcisTracePass EPCIS 2.0AInspect
GS1 EPCIS 2.0 supply-chain events. export is included on Starter plans and up; capture, capture_job, and query require the paid EPCIS add-on (those actions return a 403-style message without it).
Actions (pass via action, with args):
export — args: { id }. Export a passport's events as an EPCIS 2.0 JSON-LD document. Read-only.
export_by_serial — args: { serial, gtin? }. Same as export, addressed by your own serial. A serial is unique only WITHIN a GTIN — if it isn't unique in your account the call returns 409 ambiguous_serial; pass
gtin(or use export by id). Read-only.capture — args: { events }.
eventsis an EPCISDocument, a single event, or an array of events (JSON-LD). Returns a 202 with a captureJobId.capture_job — args: { jobId }. Poll an async capture job. Read-only.
query — args: { params? }.
paramsis a key/value map of standard EPCIS query parameters (EQ_bizStep, GE_eventTime, MATCH_epc, …). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; required fields depend on `action`. | |
| action | Yes | EPCIS 2.0: export a passport's events (export | export_by_serial), capture new events, poll a capture job, or query events. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The resource's TracePass id, when the response is a single entity. |
| page | No | Current page number (list actions). |
| error | No | Machine-readable error code, when the API rejected the request. |
| items | No | The page of results, when the action is a list. |
| limit | No | Page size (list actions). |
| total | No | Total matching records across all pages (list actions). |
| result | No | Wraps a non-object response body (e.g. a QR code string). |
| message | No | Human-readable error or status detail, when present. |
| totalPages | No | Total number of pages (list actions). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states that export, export_by_serial, capture_job, and query are read-only, while capture creates async jobs (returns 202). It also mentions error responses (403, 409). Annotations only provide idempotentHint false, which is consistent. No contradictions.
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 a brief introduction followed by bullet points for each action. It is efficient but not overly terse; every sentence adds value. Could be slightly more concise but overall balanced.
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 presence of an output schema, the description adequately covers main use cases and behaviors for each action. Error handling is partially covered (403, 409). It might lack details on pagination or limits for query, but the tool is sufficiently described.
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% with descriptions for all parameters. The description adds valuable context beyond the schema, such as the uniqueness constraint for serials and the structure of events for capture. Slightly more examples could push it to 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for 'GS1 EPCIS 2.0 supply-chain events', with specific actions (export, capture, query, etc.) that are well-defined. It also distinguishes from sibling tools like tracepass_passport_fields by focusing on EPCIS events exclusively.
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 excellent guidance on licensing requirements (Starter vs paid add-on) and explains when to use export vs export_by_serial, including handling ambiguous serials. However, it could be more explicit about when to choose this tool over its siblings, though the purpose is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tracepass_passport_fieldsTracePass passport fieldsAIdempotentInspect
Update field values on a Digital Product Passport. Every change is recorded in the passport's audit trail, tagged as an API-key update.
Actions (pass via action, with args):
update — args: { id, fieldKey, value }.
valuetype matches the field's dataType (string, number, boolean, array, object).update_by_serial — args: { serial, fieldKey, value, gtin? }. Same as update, addressed by your own serial. A serial is unique only WITHIN a GTIN — if it isn't unique in your account the call returns 409 ambiguous_serial; pass
gtin(or use update by id) to resolve exactly.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; required fields depend on `action`. | |
| action | Yes | Update one passport field, addressed by passport id (update) or by your serial (update_by_serial). |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The resource's TracePass id, when the response is a single entity. |
| page | No | Current page number (list actions). |
| error | No | Machine-readable error code, when the API rejected the request. |
| items | No | The page of results, when the action is a list. |
| limit | No | Page size (list actions). |
| total | No | Total matching records across all pages (list actions). |
| result | No | Wraps a non-object response body (e.g. a QR code string). |
| message | No | Human-readable error or status detail, when present. |
| totalPages | No | Total number of pages (list actions). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context: every change is recorded in the audit trail and tagged as an API-key update. Annotations only provide idempotentHint:true, which is consistent. No contradictions, and the description enriches understanding of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, then concisely details actions and args. Every sentence adds value 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?
The description covers all key aspects: purpose, actions, parameters, edge cases (serial ambiguity), and behavioral side effects (audit trail). With an output schema present, return values are addressed elsewhere. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant meaning: it explains the action-args structure, value type matching, serial ambiguity, and error condition (409). This goes well beyond the schema definitions.
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 'Update field values on a Digital Product Passport' and distinguishes two actions (update by id, update_by_serial). Sibling tools focus on other passport aspects (EPCIS, parties, etc.), so this tool's purpose is specific and differentiated.
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 action (id vs serial) and addresses the serial uniqueness issue with gtin. It does not explicitly state when not to use this tool or mention alternative tools, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tracepass_passport_partiesTracePass passport partiesAIdempotentInspect
Manage the economic-operator parties on a passport — manufacturer, importer, authorisedRepresentative, distributor, recycler, producerResponsibilityOrg. Each party carries a legal name and ideally a validated 13-digit GS1 GLN.
Actions (pass via action, with args):
set — args: { id, role, legalName, gln?, country?, legacyOperatorId? }. Sets or updates one role.
remove — args: { id, role }. Clears one role.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; required fields depend on `action`. | |
| action | Yes | Set (add/replace) or remove an economic-operator party on a passport by its role. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The resource's TracePass id, when the response is a single entity. |
| page | No | Current page number (list actions). |
| error | No | Machine-readable error code, when the API rejected the request. |
| items | No | The page of results, when the action is a list. |
| limit | No | Page size (list actions). |
| total | No | Total matching records across all pages (list actions). |
| result | No | Wraps a non-object response body (e.g. a QR code string). |
| message | No | Human-readable error or status detail, when present. |
| totalPages | No | Total number of pages (list actions). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the actions (set adds/replaces, remove clears) and mentions GLN validation. Annotations only provide idempotentHint; the description adds moderate behavioral context but could elaborate on consequences (e.g., overwriting existing parties).
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 two sentences and a bulleted action list. It front-loads the purpose and uses efficient structure, earning its place 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?
Despite complexity (nested objects, actions), the description covers usage and parameters well but omits any mention of return values or output format. Since an output schema exists but is not shown, this is a gap for a management 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%, so baseline is 3. The description adds value by clarifying required fields per action (e.g., legalName for set) and mentioning GLN format, which strengthens parameter meaning 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 manages economic-operator parties on a passport and lists the specific roles (manufacturer, importer, etc.). It distinguishes from sibling tools which handle other aspects (EPCIS, passport fields, etc.).
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 actions (set and remove) and their required arguments, guiding usage. It does not explicitly exclude alternative tools, but the context makes it clear when to use this tool for party management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tracepass_passportsTracePass passportsAInspect
Manage Digital Product Passports — create, read, and run lifecycle actions.
IMPORTANT: create consumes a DPP slot on the account's plan and IS BILLABLE. Creating a passport beyond the included quota incurs a per-passport overage charge; if over quota the tool returns a 402-style message — only re-run with args.confirmOverage=true after the user explicitly agrees to the charge. archive is IRREVERSIBLE (the public QR permanently 404s); prefer suspend when a change might be undone.
Actions (pass via action, with args):
list — args: { page?, limit? (≤100), productId?, status?, search? }. status ∈ draft|in_review|approved|published|suspended|expired|archived. Read-only.
get — args: { id, format? (summary|full), lang? }. Read-only.
get_by_serial — args: { serial, format?, lang?, gtin? }. Read-only. Addresses the passport by your own serial. A serial is unique only WITHIN a GTIN — if the same serial exists under two GTINs in your account the call returns 409 ambiguous_serial; pass
gtin(or use the by-id action) to resolve exactly.compliance — args: { id }. Read-only. Returns a three-tier compliance verdict (compliant | compliant_with_warnings | incomplete) with regulation-cited findings — use to gap-check a passport against the rules for its category, fix the cited fields/parties, then re-check.
create — args: { productId, gtin, serialNumber, confirmOverage? }. BILLABLE.
suspend — args: { id }. Reversible — public QR shows 'suspended'.
suspend_by_serial — args: { serial, gtin? }. Same as suspend, addressed by your serial. 409 ambiguous_serial if the serial isn't unique in your account — pass
gtin.archive — args: { id }. IRREVERSIBLE — confirm with the user first.
archive_by_serial — args: { serial, gtin? }. IRREVERSIBLE, addressed by your serial — confirm first. 409 ambiguous_serial if the serial isn't unique — pass
gtin.get_qr — args: { id, format? (svg|png) }. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; required fields depend on `action` (see each action above). | |
| action | Yes | Which passport operation to run. Reads: list | get | get_by_serial | compliance | get_qr. Lifecycle: create (BILLABLE) | suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The resource's TracePass id, when the response is a single entity. |
| page | No | Current page number (list actions). |
| error | No | Machine-readable error code, when the API rejected the request. |
| items | No | The page of results, when the action is a list. |
| limit | No | Page size (list actions). |
| total | No | Total matching records across all pages (list actions). |
| result | No | Wraps a non-object response body (e.g. a QR code string). |
| message | No | Human-readable error or status detail, when present. |
| totalPages | No | Total number of pages (list actions). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses billing, irreversibility, reversible suspension, error cases (402, 409), and read-only nature of some actions, providing crucial behavioral context beyond the sparse 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 well-organized and efficient, starting with essential caveats, then listing actions with clear argument specifications. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is highly complete, covering every action, its arguments, side effects (billing, reversibility), error conditions, and read-only markers. It leaves no ambiguity for the agent.
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?
Although the schema fully describes parameters, the description adds critical context for each action (read-only, billing, irreversibility) that is not present in the schema. This enhances parameter semantics beyond the baseline.
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 as managing digital product passports with specific read, write, and lifecycle actions. It distinguishes itself from sibling tools by focusing on passport operations.
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 usage guidelines for each action (e.g., prefer suspend over archive), but does not explicitly compare this tool to its siblings. It assumes the agent knows when to use passports vs other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tracepass_productsTracePass productsAInspect
Manage the TracePass product catalogue. A product is the catalogue layer — one product can have many passports (one per serialised unit). Products are not billable on their own.
Actions (pass via action, with args):
list — args: { page?, limit? (≤100), category?, status?, search? }. Read-only.
get — args: { id }. Read-only.
create — args: { name, model, category, description? }.
categoryis one of: battery, textile, electronics, construction, steel, chemicals, packaging, furniture, tyres, jewelry, toys, fmcg.update — args: { id, name?, model?, description? }; pass at least one field to change.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; required fields depend on `action` (see each action above). | |
| action | Yes | Which product operation to run: list | get | create | update. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The resource's TracePass id, when the response is a single entity. |
| page | No | Current page number (list actions). |
| error | No | Machine-readable error code, when the API rejected the request. |
| items | No | The page of results, when the action is a list. |
| limit | No | Page size (list actions). |
| total | No | Total matching records across all pages (list actions). |
| result | No | Wraps a non-object response body (e.g. a QR code string). |
| message | No | Human-readable error or status detail, when present. |
| totalPages | No | Total number of pages (list actions). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly labels list and get as read-only, and create/update as mutating, which adds behavioral context beyond the single idempotentHint: false annotation. It also details constraints like limit ≤100 and the category enum, providing full 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 well-structured, starting with overall purpose then detailing each action. It is reasonably concise but could be slightly tighter; for example, repeating 'args:' in each action bullet is redundant given the schema.
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 4 actions, nested args, and presence of an output schema, the description is fairly complete. It covers all actions and their parameters, though it does not describe return values (acceptable since output schema exists). The schema covers all parameters, so the description adds necessary action-level context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds extra context by specifying required fields per action (e.g., id required for get/update, name for create), which is not fully captured in the schema's property descriptions. This adds meaningful semantics.
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 manages the TracePass product catalogue, defines what a product is, and lists four actions (list, get, create, update) with their specific purposes. It distinguishes from sibling tools like tracepass_passports by focusing on the catalogue layer.
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 product catalogue operations but does not explicitly state when to use this tool versus alternatives like tracepass_passports. It mentions products are not billable, which hints at exclusion, but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tracepass_templatesTracePass DPP templates (regulatory schemas)ARead-onlyIdempotentInspect
Discover the regulatory field schema for each DPP category — what a COMPLIANT passport must contain, per the governing EU regulation. Read-only reference data. Use this to advise on requirements before creating products/passports, and to gap-check a draft against the rules.
Actions (pass via action, with args):
list — args: {}. Lists all 12 categories with their field count, required-field count, and governing regulation (name + number + effective/mandatory dates).
get — args: { category }. Full field schema for one category: every field's key, label, dataType, whether it is REQUIRED, its access level (public/restricted/authority), enum options, validation bounds, and — where known — the regulation article/annex that mandates it.
categoryis one of: battery, textile, electronics, construction, steel, chemicals, packaging, furniture, tyres, jewelry, toys, fmcg.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; `category` is required for get, ignored for list. | |
| action | Yes | List all DPP category templates, or get one template by category. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The resource's TracePass id, when the response is a single entity. |
| page | No | Current page number (list actions). |
| error | No | Machine-readable error code, when the API rejected the request. |
| items | No | The page of results, when the action is a list. |
| limit | No | Page size (list actions). |
| total | No | Total matching records across all pages (list actions). |
| result | No | Wraps a non-object response body (e.g. a QR code string). |
| message | No | Human-readable error or status detail, when present. |
| totalPages | No | Total number of pages (list actions). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. Description reinforces 'Read-only reference data.' No contradictions; adds behavioral detail about actions.
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?
Description is well-structured: first sentence states purpose, then usage guidance, then action definitions. Every sentence adds value; no fluff.
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 two actions and many categories, the description thoroughly explains return types for both actions. Output schema exists, so further detail is unnecessary.
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 description adds meaning by listing enumeration values and explaining that `category` is required for `get` and ignored for `list`. Provides the full list of category options.
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: 'Discover the regulatory field schema for each DPP category — what a COMPLIANT passport must contain.' It distinguishes between list and get actions and is distinct from sibling tools.
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 advises when to use: 'Use this to advise on requirements before creating products/passports, and to gap-check a draft against the rules.' Does not mention when not to use, but context is clear.
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!