Barcode lookup, nutrition search, and product comparison for 3M+ crowd-sourced food products.
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.
Average 4.5/5 across 4 of 4 tools scored. Lowest: 3.8/5.
Each tool has a clearly distinct purpose: taxonomy resolution, product search, product details, and comparative analysis. No overlap or ambiguity exists between them.
All tools follow a consistent 'off_verb_noun' pattern with snake_case (browse_taxonomy, compare_products, get_product, search_products). The naming is predictable and immediately conveys the action and target.
With only 4 tools, the server stays well-scoped and avoids redundancy. This is an ideal size for a focused read-only API covering search, fetch, compare, and taxonomy lookup.
For a read-only crowd-sourced database, the toolset covers all essential workflows: discovering products (search), retrieving full details (get), comparing alternatives (compare), and resolving filter values (browse_taxonomy). No critical gaps are apparent.
off_browse_taxonomyBrowse Food Facts TaxonomyAResolve a human term to the canonical Open Food Facts tag ID that off_search_products filters on. Covers categories, labels/certifications, allergens, additives, countries, NOVA groups, and Nutri-Score grades. Pass a search term to resolve against the Open Food Facts vocabulary, which holds tens of thousands of tags; omitting it returns only a small reference list for each facet except NOVA groups and Nutri-Score grades, which are complete. Most tag IDs use the "en:" prefix (e.g. "en:organic", "en:gluten-free", "en:milk"); NOVA groups return bare digits "1"-"4" and Nutri-Score grades bare letters "a"-"e". Pass the id through to off_search_products exactly as returned. Category tags are frequently plural ("kombucha" resolves to "en:kombuchas"), so use the returned id rather than constructing one.
| Name | Required | Description | Default |
|---|---|---|---|
| facet | Yes | "categories" covers food categories (en:cheeses, en:breakfast-cereals). "labels" covers certifications (en:organic, en:fair-trade). "allergens" covers declared allergens (en:milk, en:gluten). "additives" covers E-numbers (en:e322). "countries" covers country-of-sale tags (en:france). "nova_groups" and "nutrition_grades" are closed vocabularies returned complete; the other five are resolved against the Open Food Facts taxonomy. | |
| limit | No | Maximum entries to return (1–100, default 20). There is no offset or page input: Open Food Facts returns only the first `limit` matches for a term and offers no cursor, so narrow the search term rather than paging. | |
| search | No | Term to resolve. Matched case-insensitively as a substring of the tag ID or display name. A single word works best ("hummus", not "hummus dip"). Omit only to see a small reference list — Open Food Facts cannot list the full vocabulary without a term, so an unfiltered call is not a view of the full facet. |
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. |
| tags | No | Matching tag entries. |
| error | No | Present when the call failed. Absent on success. |
| facet | No | The facet name that was queried (echoes the input). |
| shown | No | Number of tags returned. |
| notice | No | Caveat about the answer — that the listing is a limited reference list rather than the full vocabulary, that Open Food Facts was unreachable, or that nothing matched and why. |
| truncated | No | True when more tags exist beyond the limit. |
| total_in_facet | No | Total entries in this facet. Present only for nova_groups and nutrition_grades, whose vocabularies are closed and complete. Absent for the other facets: Open Food Facts reports no match total and cannot enumerate them, so no figure would be a real one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, open-world, and idempotent. The description adds substantial behavioral context beyond those: it describes the outcome when search is omitted (a small reference list, except for NOVA and Nutri-Score which are returned complete), the ID format patterns ('en:' prefix vs. bare digits/letters for NOVA and Nutri-Score), and the fact that category tags are often plural. This goes well beyond the annotation hints and informs the agent about the tool's return characteristics and pitfalls.
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 and front-loaded: the first sentence captures the core purpose. Subsequent sentences add specific, non-redundant details—each covers a distinct aspect (facet coverage, ID formats, pluralization, and the search-omission behavior). No sentence is filler; the length is justified by the necessary context. It remains structured enough for an agent to parse quickly.
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 comprehensive for an agent to call this tool correctly. It explains the purpose, the parameter semantics, the expected output (as input to off_search_products), and the edge cases (pluralization, format differences). It even covers the closed vs. open vocabulary distinction for facets. With schema coverage at 100% and an output schema present, the description fills all the gaps an agent would need for correct invocation and integration with the sibling 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 the baseline is 3. The description adds meaningful value over the schema: it explains the ID format conventions (e.g., 'en:organic', 'en:kombuchas'), the pluralization caveat, and that NOVA groups return digits '1'-'4' while Nutri-Score returns letters 'a'-'e'. It also clarifies that 'limit' is capped and there is no paging, which is already in the schema but reinforced. This enriches parameter understanding beyond the schema alone.
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 opens with a specific verb and resource: 'Resolve a human term to the canonical Open Food Facts tag ID that off_search_products filters on.' This clearly distinguishes it from sibling tools like off_search_products (which filters) and off_get_product (which retrieves a product), by stating its role as a resolver/translator for taxonomy tags. It also enumerates the covered facets, leaving no ambiguity about scope.
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 states when to use: to resolve terms before filtering via off_search_products. It provides conditional guidance: omitting search returns a small reference list, and it warns about the pluralization pitfall ('use the returned id rather than constructing one'). It also tells the agent to pass IDs exactly as returned, guiding the workflow. No alternatives are listed, but the sibling connection is clear, and the conditional behavior of the search parameter is well described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
off_compare_productsCompare Food Products Side-by-SideASide-by-side nutrition and scoring comparison for 2–10 products by barcode. Returns a normalized table of energy (kcal/100g), fat, saturated fat, sugars, salt, protein, fiber, Nutri-Score, NOVA group, and Green-Score. Designed for "which of these cereals is healthiest?" or "compare these pasta brands" workflows. Missing nutrition data for any product is preserved as absent — comparisons are not imputed. A batch is not all-or-nothing: barcodes that resolve are returned even when others fail, with confirmed-missing barcodes listed in not_found and failed fetches listed separately in failed. Scores carry regional formula caveats. Data under ODbL 1.0 — cite Open Food Facts in downstream use.
| Name | Required | Description | Default |
|---|---|---|---|
| barcodes | Yes | 2–10 barcodes to compare, returned as one row each in input order. Example: ["3017620422003", "7622210100146"]. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| failed | No | Barcodes whose fetch failed, with the per-barcode reason. Absent when every fetch completed. A barcode listed here is unknown, not absent from Open Food Facts — retry it with off_get_product before concluding anything about the product. |
| products | No | Comparison rows in input order — one per barcode whose fetch completed, whether or not a record exists. Barcodes whose fetch failed have no row here; they appear in failed. |
| not_found | No | Barcodes Open Food Facts answered for, confirming no contributor record exists. Not an error — the product may exist but not yet be entered. Never used for a fetch that failed. |
| succeeded | No | Number of barcodes that resolved to a found product. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly, openWorld, and idempotent hints, the description discloses key behaviors: missing data is preserved (not imputed), batches are not all-or-nothing with separate handling of not_found and failed barcodes, regional formula caveats exist, and attribution is required under ODbL 1.0. This adds substantial value over the 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 front-loaded with the core purpose, then covers exceptions, licensing, and caveats. It is slightly longer than necessary but each sentence adds distinct information, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameter constraints, error behavior, regional caveats, and licensing. An output schema exists, so return-value details are not required in the description. All essential information for correctly invoking the tool is present, and sibling tools provide further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already describes the barcodes parameter including min/max and input-order behavior. The description repeats the input-order detail and adds output-field information, but this does not clarify the parameter's semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares 2–10 products side-by-side by barcode, lists the specific nutrition and scoring fields, and gives concrete example workflows ('which of these cereals is healthiest?'). It distinguishes itself from siblings: off_get_product (single product), off_search_products (search), off_browse_taxonomy (browse).
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 explicit example use cases and explains the batch behavior (partial success, not_found vs failed). It does not explicitly name alternative tools for single-product lookups, but the comparison workflow is clearly the intended use. The distinction from siblings is implied rather than stated, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
off_get_productGet Food Product by BarcodeAFetch a packaged food product by barcode (EAN-13 or UPC) from Open Food Facts. Returns the product name, brand, quantity, ingredients (raw text and parsed list), allergens, additives, computed scores (Nutri-Score a–e, NOVA 1–4, Green-Score), nutrition per 100g and per serving, categories, labels, packaging, origins, image URL, and data completeness. Open Food Facts is a crowd-sourced database — a missing field means "not yet entered by contributors," not that the attribute is absent from the actual product. Computed scores carry regional formula caveats and are indicators, not absolute rankings. Data is under ODbL 1.0 — cite Open Food Facts in downstream use.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Subset of fields to return. Omitting returns all standard fields. Use to reduce payload when only scores or ingredients are needed. | |
| barcode | Yes | EAN-13 or UPC barcode (8–14 digits). The primary key for Open Food Facts. Example: "3017620422003" (Nutella FR). |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| barcode | No | Barcode as returned by the API. |
| product | No | Product data. Always present on a successful call — a barcode with no contributor record raises the not_found error instead of returning an empty result. |
| requested_fields | No | The field subset that was requested, when the caller passed `fields`. Absent means all standard fields were requested. Sections outside this subset are omitted because they were not requested — not because Open Food Facts lacks the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable behavioral context: it explains that missing fields mean data not yet entered by contributors (reinforcing open world), that computed scores are indicative with regional caveats, and that data is under ODbL 1.0 requiring attribution. This goes beyond the annotations by clarifying data interpretation and licensing, without contradicting any hint.
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 core purpose and then lists the return fields and caveats. While it is somewhat lengthy, each sentence adds relevant context (data interpretation, score limitations, license). The structure is logical, but given an output schema exists, some field enumeration could be trimmed without loss, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description equips an agent with everything needed to call the tool correctly: the primary key (barcode), optional field filtering, the full return set, and important data quality caveats (crowd-sourced, missing fields, score interpretation). It also covers licensing for downstream use. Combined with the existing annotations (read-only, idempotent, open-world), no critical context is missing.
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?
Both parameters (barcode and fields) are fully documented in the input schema with descriptions (100% coverage). The tool description adds no new parameter-specific guidance beyond the schema, so it doesn't enhance what the schema already provides. The baseline score of 3 is appropriate since the schema does the heavy lifting.
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 explicitly states the tool 'Fetch a packaged food product by barcode (EAN-13 or UPC) from Open Food Facts,' providing a specific verb and resource. It also enumerates the returned fields, making the tool's function unmistakable. Although it doesn't explicitly contrast with sibling tools, the barcode-based retrieval is distinct from search, compare, and browse, satisfying the distinction criterion.
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 says nothing about when to use this tool versus its siblings (off_search_products, off_compare_products, off_browse_taxonomy). It does not mention that this is the appropriate choice when a specific barcode is known, nor does it advise against using it for broad searches. The only implicit guidance is that barcode identification is required, but explicit routing to alternatives is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
off_search_productsSearch Food ProductsASearch Open Food Facts by full-text query, structured tag filters, or both at once. Returns a summary list with barcodes, product names, brands, Nutri-Score, NOVA group, and categories — enough for triage and selection, not full label data. Use off_get_product on the returned barcodes for complete details. A text query and tag filters combine: results match the query text and satisfy every filter provided (e.g. query "dark chocolate" with labels_tag "en:organic" and countries_tag "en:france" returns organic chocolate sold in France); additives_tag is the one exception, filtering only on searches with no text query. Tag filter values must be canonical tag IDs (e.g. "en:organic", "en:gluten-free") — use off_browse_taxonomy to resolve human terms to tag IDs. At least one search parameter is required. Data is crowd-sourced; result count reflects contributed products, not all products in the market. Data under ODbL 1.0 — cite Open Food Facts in downstream use.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Use with page_size to paginate results. Searches that include a text query serve only the first 10,000 results, so page * page_size must stay at or below 10,000 — a deeper request is rejected rather than sent. Tag-only searches have no published window, but Open Food Facts refuses deep pages unpredictably; narrowing the filters is more reliable than paging far in. | |
| query | No | Full-text search term across product names, brands, and ingredients. Combines with any tag filters — results match this text and satisfy the filters. Example: "dark chocolate 70%". | |
| sort_by | No | Sort order for searches without a text query. "unique_scans_n" surfaces the most-scanned products; omitting returns results in default order. Searches that include a text query are relevance-ranked and ignore this option. | |
| page_size | No | Results per page (1–50, default 20). Keep low for initial exploration; increase for comparison workflows. | |
| brands_tag | No | Brand slug (lowercased, hyphenated). Example: "nutella", "kelloggs". Matched exactly against the normalized slug — a partial or misspelled slug matches nothing rather than falling back to a near match, so put open-ended brand wording in query instead. | |
| labels_tag | No | Canonical label/certification tag ID. Example: "en:organic", "en:fair-trade", "en:no-gluten". Use off_browse_taxonomy with facet="labels". | |
| nova_group | No | Filter by NOVA food processing class. "1"=unprocessed/minimally processed, "4"=ultra-processed. Products without a NOVA score are excluded. | |
| additives_tag | No | Canonical additive (E-number) tag ID. Example: "en:e322", "en:e330". Use off_browse_taxonomy with facet="additives". Available only on searches with no query — full-text searches cannot filter by additive, so combining the two is rejected instead of silently returning nothing. | |
| allergens_tag | No | Canonical allergen tag ID. Example: "en:milk", "en:gluten". Use off_browse_taxonomy with facet="allergens". Selects products that declare this allergen; it cannot select allergen-free products, because a product with no allergen tags may simply have none entered yet. | |
| countries_tag | No | Canonical country tag ID. Example: "en:france", "en:united-states". Filters to products sold in that country. | |
| categories_tag | No | Canonical category tag ID. Example: "en:breakfast-cereals", "en:cheeses". Use off_browse_taxonomy with facet="categories" to discover valid values. | |
| nutrition_grade | No | Filter by Nutri-Score grade. "a" is highest nutritional quality, "e" is lowest. Products without a score are excluded. |
| Name | Required | Description |
|---|---|---|
| cap | No | The page_size that was applied. |
| page | No | Current page number (1-based). |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of products returned on this page. |
| total | No | Matching products in the database for this search. Exact unless total_is_lower_bound is true, in which case at least this many match and the real figure is unknown. |
| notice | No | Guidance about this result set — echoes the filters and suggests how to broaden when nothing matched, or names the current page and how far the backend will actually paginate when more results exist. |
| products | No | Matching products. Use barcodes with off_get_product for full label data. |
| truncated | No | True when more results exist beyond this page. |
| page_count | No | Products returned on this page (mirrors page_size except on the last page). Not the total number of pages. |
| total_is_lower_bound | No | True when the backend stopped counting at its ceiling and total is a floor, not the match total. Only text searches can hit it; add filters to bring the result set under the ceiling and get an exact count. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint, openWorldHint, and idempotentHint annotations, the description adds significant behavioral nuance: exact slug matching for brands (no fallback), page limit with text queries, unpredictable deep paging on tag-only searches, additives_tag only valid without query, allergens_tag unable to select allergen-free products, and licensing obligations (ODbL 1.0). These go well beyond the annotations and make the tool's quirks explicit.
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 long (over 250 words) but every sentence earns its place given the tool's 12 parameters and numerous edge cases. It is front-loaded with the core purpose, then logically organizes combination semantics, tag ID requirements, constraints, and data caveats. No filler or tautology — each clause addresses a specific agent need.
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 12 parameters, no required fields, an output schema, and multiple edge cases (page limits, additive exception, exact match behavior, allergen semantics), the description covers every important aspect an agent needs to call it correctly. It even anticipates failure modes (rejected deep pages) and data quality implications. The output schema exists, so the return format summary is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds cross-parameter semantics that the schema alone cannot: how query and tag filters combine (including the additive exception), the 10,000-result window interplay between page/page_size and query, the exact-match risk for brands_tag, and the meaning of sort_by being ignored when a query is present. It also provides examples for tag IDs and usage guidance for several filters.
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 states a precise verb+resource ('Search Open Food Facts') and distinguishes it from siblings by naming off_get_product for full details and off_browse_taxonomy for tag resolution. It clearly communicates the tool's scope (summary list for triage) and the three modes (query, filters, both).
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 tells when to use this tool vs alternatives ('Use off_get_product on the returned barcodes for complete details', 'use off_browse_taxonomy to resolve human terms to tag IDs'). It explains the combination semantics with a concrete example, the additive exception, the requirement of at least one parameter, and the crowd-sourced data caveat — all governing correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.