archive
Server Details
Archive MCP — wraps the Internet Archive APIs (free, no auth)
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-archive
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 8 of 8 tools scored. Lowest: 2.9/5.
Most tools have distinct purposes, such as search for Internet Archive queries, get_metadata for item details, and wayback_check for Wayback Machine snapshots. However, ask_pipeworx overlaps with discover_tools in helping users find tools or information, which could cause confusion, though their descriptions clarify different use cases.
The naming is mixed, with some tools using verb_noun patterns like get_metadata and search, while others like ask_pipeworx and discover_tools are more descriptive phrases. There is no consistent convention, but the names are generally readable and descriptive of their functions.
With 8 tools, the count is well-scoped for the server's purpose, covering Internet Archive operations, memory management, and tool discovery. Each tool serves a clear role without being excessive or insufficient for the domain.
The server covers core Internet Archive functions like search, metadata retrieval, and Wayback Machine checks, but lacks operations for managing or uploading to the archive. Memory tools (remember, recall, forget) are included, but their integration with the archive domain is not fully clear, leaving minor gaps in coverage.
Available Tools
8 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
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 of behavioral disclosure. It effectively describes key traits: the tool acts as an intelligent intermediary ('Pipeworx picks the right tool, fills the arguments'), handles natural language input, and returns results. However, it lacks details on limitations, such as rate limits, error conditions, or data source constraints, which would be helpful for a tool with no annotation 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 front-loaded with the core functionality in the first sentence, followed by explanatory details and examples. Every sentence earns its place: the first defines the tool, the second explains the mechanism, the third provides usage guidance, and the examples concretize it. No wasted words, and the structure is logical and efficient.
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 (acting as an intelligent query router with no annotations and no output schema), the description is mostly complete. It covers purpose, usage, and parameter semantics well. However, it lacks information on output format, error handling, or limitations, which would be beneficial for an agent to use this tool effectively in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the parameter's purpose beyond the schema's 'natural language' note: it emphasizes that questions should be in 'plain English' and provides examples that illustrate the expected format and scope (e.g., factual queries, data lookups). This enhances understanding but doesn't fully detail constraints like length or supported topics.
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: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask'), resource ('answer'), and mechanism ('Pipeworx picks the right tool, fills the arguments'), distinguishing it from sibling tools like 'search' or 'discover_tools' by emphasizing natural language input without manual tool selection.
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 states when to use this tool: 'No need to browse tools or learn schemas — just describe what you need.' It provides clear alternatives by implication (e.g., use other tools if you want to browse or learn schemas) and includes concrete examples ('What is the US trade deficit with China?', etc.) that illustrate appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
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 of behavioral disclosure. It effectively describes key behaviors: it's a search operation (implied read-only), returns the most relevant tools, and emphasizes calling it first in specific scenarios. However, it doesn't mention potential limitations like rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: two sentences that each earn their place. The first sentence explains what the tool does, and the second provides crucial usage guidance without any wasted words.
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 moderate complexity (search operation with 2 parameters) and no annotations/output schema, the description is quite complete. It explains purpose, usage context, and behavioral aspects well. The only minor gap is lack of information about return format or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by implying the 'query' parameter should describe what you need to do, but doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.
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 with specific verbs ('search', 'returns') and resource ('Pipeworx tool catalog'), distinguishing it from siblings by emphasizing its role in discovering tools from a large catalog. It explicitly mentions searching by describing needs and returning relevant tools with names and descriptions.
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 guidance on when to use this tool: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This gives clear context and distinguishes it from alternatives like generic search tools by specifying the scenario of a large tool catalog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetCInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
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 for behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this operation is reversible, what permissions are required, what happens if the key doesn't exist, or what the response looks like. This leaves significant behavioral gaps for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.
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 destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't address critical context like error conditions, return values, or behavioral implications of deletion. The 100% schema coverage helps with parameters but doesn't compensate for the lack of operational guidance.
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 the single 'key' parameter adequately. The description adds no additional semantic context about the key format, constraints, or examples beyond what the schema provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a stored memory by key'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'recall' or 'remember' that might also manipulate memories, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'recall' (likely to retrieve memories) and 'remember' (likely to store memories), there's no indication of when deletion is appropriate or what prerequisites might exist for using this destructive operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_metadataAInspect
Get full metadata for an archived item by identifier. Returns title, creator, date, format, size, and access details.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Archive.org item identifier (e.g., "principleofrelat00eins", "ApolloMissionsMoonLandings") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves metadata but doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or response format. This is a significant gap for a tool with no annotation 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 a single, well-structured sentence that front-loads the purpose and includes essential details (e.g., identifier source). There's no wasted text, making it highly efficient.
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 low complexity (1 parameter, no nested objects) and high schema coverage, the description is adequate for basic use. However, with no output schema and no annotations, it lacks details on return values, error cases, or behavioral constraints, leaving gaps for an agent to operate effectively.
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 the single parameter 'id' with examples. The description adds minimal value by restating the parameter's purpose ('by its identifier'), but doesn't provide additional syntax or format details beyond the schema. With 0 parameters beyond the one covered, baseline 4 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 specific action ('Retrieve full metadata'), the resource ('an Internet Archive item'), and the method ('by its identifier'). It distinguishes from sibling tools like 'search' (which likely finds items) and 'wayback_check' (which likely checks availability).
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 when you have a specific identifier and need metadata, but doesn't explicitly state when to use this versus 'search' (e.g., for finding items without an ID) or 'wayback_check' (e.g., for availability). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
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 of behavioral disclosure. It describes the core functionality (retrieve by key or list all) and persistence scope ('session or previous sessions'), but doesn't mention error handling, performance characteristics, or data format of retrieved memories. It adequately covers the basic behavior but lacks depth.
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 perfectly concise with two sentences that each serve distinct purposes: the first explains the dual functionality, the second provides usage context. Every word earns its place with zero 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 simple retrieval tool with 1 optional parameter and no output schema, the description provides good context about what the tool does and when to use it. However, it doesn't describe the format of returned memories or error conditions, leaving some gaps in 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?
The schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the semantic meaning of omitting the key parameter ('omit to list all keys'), which clarifies the dual-purpose nature of the tool beyond what the schema's technical description provides.
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 with specific verbs ('retrieve', 'list') and resources ('previously stored memory', 'all stored memories'). It distinguishes this retrieval/list operation from sibling tools like 'remember' (store), 'forget' (delete), and 'search' (search).
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 guidance on when to use this tool: 'to retrieve context you saved earlier in the session or in previous sessions.' It also specifies when to omit the key parameter ('omit key to list all keys'), giving clear operational instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
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 of behavioral disclosure and does so effectively. It reveals important behavioral traits: memory persistence differences between authenticated users (persistent) vs. anonymous sessions (24 hours), and the tool's purpose for cross-tool context management. It doesn't mention rate limits or error conditions, but covers the essential behavioral aspects.
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 perfectly sized at two sentences, front-loaded with the core purpose, and every sentence earns its place by providing essential information about usage and behavioral characteristics without any wasted words or 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 2-parameter tool with no annotations and no output schema, the description provides good contextual completeness. It covers the tool's purpose, usage scenarios, and key behavioral traits (persistence differences). However, it doesn't describe what happens on success/failure or return values, which would be helpful given the lack of output schema.
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 description coverage, the schema already documents both parameters thoroughly. The description doesn't add significant meaning beyond what the schema provides - it mentions 'key-value pair' but doesn't elaborate on parameter usage, constraints, or examples beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
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 with specific verb ('store') and resource ('key-value pair in your session memory'), and distinguishes it from siblings like 'recall' (retrieval) and 'forget' (deletion). It explicitly mentions what types of data can be saved (intermediate findings, user preferences, context across tool calls).
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 context for when to use this tool ('to save intermediate findings, user preferences, or context across tool calls'), but doesn't explicitly state when NOT to use it or name specific alternatives among siblings. It implies usage scenarios without explicit exclusions or comparisons to tools like 'recall' or 'forget'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchBInspect
Search Internet Archive for texts, audio, video, and software by keyword. Returns item titles, identifiers, descriptions, and media types.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (1-100, default 20) | |
| query | Yes | Search query (e.g., "subject:astronomy", "creator:NASA", "moon landing") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions support for Lucene query syntax, which adds some context, but it does not cover important aspects such as rate limits, authentication needs, pagination behavior, or what the response format looks like (especially since there is no output schema). This leaves significant gaps for a search 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 concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and key feature (Lucene query syntax). Every sentence earns its place without unnecessary elaboration, making it easy 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?
Given the complexity of a search tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., rate limits, response format) and does not compensate for the absence of structured data. While it covers the purpose well, it falls short in providing enough context for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters ('query' and 'limit') with descriptions. The description adds minimal value by implying the query syntax (Lucene) but does not provide additional details beyond what the schema offers. Baseline 3 is appropriate as 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 clearly states the tool's purpose with a specific verb ('Search') and resource ('Internet Archive'), listing the types of items it searches for (texts, audio, video, software, and other items). It distinguishes itself from sibling tools like 'get_metadata' and 'wayback_check' by focusing on search functionality rather than metadata retrieval or Wayback Machine checks.
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 by specifying what the tool searches for and mentioning Lucene query syntax, but it does not explicitly state when to use this tool versus alternatives like 'get_metadata' or 'wayback_check'. No exclusions or specific contexts are provided, leaving the agent to infer usage based on the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wayback_checkAInspect
Check if a URL was archived and retrieve the closest snapshot. Returns capture dates and direct link to the archived version.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to look up (e.g., "https://example.com/some-page") |
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 of behavioral disclosure. It mentions the tool's purpose but lacks details on error handling, rate limits, authentication needs, or what happens if no snapshot exists. This is a significant gap for a tool that interacts with an external service.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('check whether a URL has ever been archived') and adds necessary detail ('retrieve the closest available snapshot') without any wasted words or 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?
Given the tool's moderate complexity (interacting with an external archive service), no annotations, and no output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, output format, or error cases, which are important for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents the single 'url' parameter. The description adds no additional parameter semantics beyond what the schema provides, such as URL format constraints or examples beyond the schema's example, meeting the baseline for high schema coverage.
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 specific action ('check whether a URL has ever been archived') and resource ('Wayback Machine'), and distinguishes it from siblings by mentioning 'retrieve the closest available snapshot' which suggests a different function than 'get_metadata' or 'search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking URL archival status and retrieving snapshots, but provides no explicit guidance on when to use this tool versus the sibling tools 'get_metadata' or 'search', leaving the agent to infer based on the described functionality.
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!