tle
Server Details
TLE MCP — satellite tracking via Two-Line Element sets (tle.ivanstanojevic.me, free, no auth)
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-tle
- 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.7/5 across 8 of 8 tools scored. Lowest: 2.9/5.
Most tools have distinct purposes, but 'ask_pipeworx' and 'discover_tools' could cause confusion as both involve finding or accessing tools/data, potentially leading to misselection. The other tools are clearly differentiated, covering satellite data retrieval, memory operations, and catalog search.
The naming is mixed with no consistent pattern: 'ask_pipeworx' and 'get_tle' use verb_noun, 'discover_tools' and 'search_satellites' use verb_noun, but 'forget', 'recall', and 'remember' are single verbs, and 'list_recent' uses verb_adjective. This inconsistency makes the set less predictable, though names remain readable.
With 8 tools, the count is reasonable for the server's mixed scope of satellite data and general-purpose utilities. It's slightly broad but manageable, as each tool serves a purpose without obvious bloat or thinness for the apparent domain.
For satellite data, the tools cover retrieval (get_tle, list_recent, search_satellites) adequately, but lack operations like updating or deleting TLE data, which might be expected in a full lifecycle. For memory and tool discovery, basic CRUD is present (remember, recall, forget, discover_tools), but 'ask_pipeworx' adds a high-level interface that overlaps, creating minor gaps in a cohesive domain 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, the description carries full burden and does well: it discloses that Pipeworx 'picks the right tool, fills the arguments, and returns the result,' explaining the automated selection and execution process. However, it lacks details on rate limits, error handling, or data source limitations, leaving some behavioral aspects unspecified.
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, followed by practical examples. Every sentence earns its place by clarifying usage and providing concrete instances, with no redundant or vague phrasing. It efficiently communicates key information in a compact format.
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 (automated tool selection) and lack of annotations/output schema, the description is mostly complete: it explains the process and provides examples. However, it doesn't detail output format or potential limitations (e.g., data source availability), leaving minor gaps for a tool with no structured output documentation.
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%, with the parameter 'question' documented as 'Your question or request in natural language.' The description adds minimal value beyond this, only reinforcing natural language use through examples. Baseline 3 is appropriate since the schema adequately covers the single parameter.
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 from data source'), and distinguishes from siblings by emphasizing natural language processing versus manual tool selection. The examples reinforce this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use this tool for natural language queries instead of browsing tools or learning schemas, with clear examples ('What is the US trade deficit...', 'Look up adverse events...'). It directly contrasts with sibling tools like 'discover_tools' or 'search_satellites' by stating 'No need to browse tools or learn schemas.'
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 ranked results ('most relevant tools'), and provides output format ('names and descriptions'). However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions.
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 earn their place: the first explains what the tool does, the second provides critical usage guidance. It's front-loaded with the core functionality and wastes no words while being highly informative.
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 search tool with 2 parameters, 100% schema coverage, and no output schema, the description provides strong context about when and why to use it. The main gap is the lack of output format details beyond 'names and descriptions' - without an output schema, more detail about the return structure would be helpful. However, the usage guidance is exceptionally strong.
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 doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'describing what you need' which aligns with the query parameter but doesn't provide additional context. Baseline 3 is appropriate when 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 specific verbs ('Search the Pipeworx tool catalog') and resource ('tool catalog'), and explicitly distinguishes it from siblings by emphasizing it should be called FIRST when dealing with 500+ tools. It provides concrete examples of what the tool does (returns 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'), including a specific threshold (500+ tools) and context (finding tools for a task). It clearly positions this as an entry point tool for discovery among many options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetBInspect
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates a destructive operation ('Delete') but doesn't specify whether deletion is permanent, reversible, requires specific permissions, or has side effects. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.
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 with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
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 tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permanence, error conditions, or response format, nor does it provide usage guidance relative to siblings. The high schema coverage doesn't compensate for these gaps in 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%, with the single parameter 'key' documented as 'Memory key to delete'. The description adds no additional meaning beyond this schema information, such as key format examples or constraints. Baseline 3 is appropriate when 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 specific action ('Delete') and resource ('a stored memory by key'), distinguishing it from sibling tools like 'recall' (likely retrieve) and 'remember' (likely store). It uses precise verb+resource terminology that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'recall' or 'remember', nor does it mention prerequisites (e.g., needing an existing memory key) or exclusions. It states what the tool does but offers no contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tleAInspect
Fetch the Two-Line Element (TLE) set for a specific satellite by its NORAD catalog ID. Returns the satellite name, epoch date, and both TLE lines.
| Name | Required | Description | Default |
|---|---|---|---|
| norad_id | Yes | NORAD catalog number for the satellite (e.g. 25544 for the ISS, 20580 for Hubble Space Telescope). |
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 describes what the tool returns ('satellite name, epoch date, and both TLE lines'), which adds value beyond the input schema. However, it lacks details on error handling, rate limits, or data sources, leaving gaps in behavioral context 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, efficient sentence that front-loads the purpose and key details. Every word earns its place, with no redundant or unnecessary information, making it highly concise and well-structured.
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 required parameter, no nested objects) and no output schema, the description is mostly complete. It specifies the return values, which compensates for the lack of output schema. However, it could improve by mentioning error cases or data availability, slightly reducing completeness for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'norad_id' parameter well-documented in the schema. The description does not add any additional meaning or syntax details beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate when 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 specific action ('Fetch'), resource ('Two-Line Element (TLE) set for a specific satellite'), and scope ('by its NORAD catalog ID'). It distinguishes from sibling tools like 'list_recent' and 'search_satellites' by focusing on retrieving detailed TLE data for a single satellite rather than listing or searching multiple satellites.
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 'by its NORAD catalog ID,' suggesting this tool is for when you have a specific satellite ID. However, it does not explicitly state when to use this tool versus alternatives like 'list_recent' or 'search_satellites,' nor does it provide exclusions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_recentBInspect
List the most recently launched or updated satellites, sorted by epoch date descending.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of satellites to return. Defaults to 10. |
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 mentions sorting and a default limit, but doesn't disclose key behavioral traits such as pagination, rate limits, authentication needs, error handling, or what 'recent' means (e.g., time range). This leaves significant gaps for an agent to understand operational constraints.
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 ('List the most recently launched or updated satellites') and adds essential detail ('sorted by epoch date descending') without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on return format (e.g., what data fields are included), error cases, and behavioral constraints like rate limits or authentication. For a tool with zero annotation coverage, this leaves the agent under-informed.
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 fully documents the 'limit' parameter. The description adds no additional parameter semantics beyond implying recency filtering, which isn't parameterized. Baseline 3 is appropriate as the schema handles 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 action ('List') and resource ('most recently launched or updated satellites'), with specific sorting criteria ('sorted by epoch date descending'). It distinguishes from 'search_satellites' by focusing on recency rather than general search, though it doesn't explicitly differentiate from 'get_tle' (which likely retrieves specific orbital data).
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 retrieving recent satellites, but doesn't explicitly state when to use this tool versus alternatives like 'search_satellites' or 'get_tle'. No guidance on prerequisites, exclusions, or specific scenarios is provided.
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?
No annotations are provided, so the description carries the full burden. It discloses that it retrieves stored memories and works across sessions, but doesn't mention behavioral traits like error handling (e.g., what happens if key doesn't exist), performance (e.g., speed or limits), or side effects (e.g., if retrieval logs activity). It adds some context but lacks depth 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 appropriately sized and front-loaded: two concise sentences that directly state the purpose and usage without waste. The first sentence covers the core functionality, and the second provides essential guidance, making it efficient and well-structured.
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 (retrieval/list operation), no annotations, and no output schema, the description is adequate but has gaps. It explains what the tool does and how to use the parameter, but doesn't cover return values, error cases, or session persistence details. It meets minimum viability but lacks completeness for a tool with no structured output information.
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%, with the schema documenting the key parameter. The description adds value by explaining the semantics: 'omit to list all keys' clarifies the optional behavior, and it ties the parameter to retrieving context saved earlier. With one parameter and high schema coverage, this exceeds the baseline of 3.
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: 'Retrieve a previously stored memory by key, or list all stored memories (omit key).' It specifies the verb ('retrieve'/'list') and resource ('memory'), but doesn't explicitly distinguish it from sibling tools like 'remember' or 'forget' beyond mentioning it retrieves context saved earlier.
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 on when to use it: 'Use this to retrieve context you saved earlier in the session or in previous sessions.' It explains the key parameter behavior (omit to list all keys), but doesn't explicitly state when not to use it or name alternatives among siblings like 'list_recent' or 'search_satellites'.
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. It effectively describes key behavioral traits: the persistence differences between authenticated vs. anonymous sessions ('Authenticated users get persistent memory; anonymous sessions last 24 hours'), which is crucial context not inferable from the schema alone. It doesn't cover rate limits or error conditions, but provides substantial behavioral insight.
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 earn their place. The first sentence states the core functionality, and the second adds crucial behavioral context about persistence. No wasted words, and the most important information is front-loaded.
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 context about persistence behavior and usage scenarios. However, it doesn't mention what happens on success/failure, whether there are size limits for values, or how keys are namespaced. Given the simplicity of the tool, the description is mostly complete but has minor 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?
The schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions the types of data that can be stored, but this relates to the tool's purpose rather than parameter semantics. Baseline 3 is appropriate when 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 specific verb ('Store') and resource ('key-value pair in your session memory'), and distinguishes it from siblings by specifying it's for saving data (vs. recall, forget, etc.). It explicitly mentions what types of data can be stored ('intermediate findings, user preferences, or 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 ('save intermediate findings, user preferences, or context across tool calls'), but doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools (like recall for retrieval or forget for deletion). The guidance is helpful but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_satellitesCInspect
Search for satellites by name or keyword. Returns matching satellites with their NORAD IDs and TLE data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. Defaults to 10. | |
| query | Yes | Name or keyword to search for (e.g. "ISS", "Starlink", "GPS"). |
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 return of 'NORAD IDs and TLE data', which adds some context, but lacks details on permissions, rate limits, error handling, or whether this is a read-only operation. For a search tool, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded, with two clear sentences that state the purpose and output. There's no wasted text, and it efficiently conveys the core functionality, though it could be slightly more structured by including usage hints.
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 (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and output but misses behavioral details and usage guidelines. Without annotations or output schema, it should do more to explain the tool's full context, such as response format or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 100% coverage. It implies the 'query' parameter is for name or keyword searches, but the schema already describes this. No additional syntax or format details are provided, so it meets the baseline for high schema coverage without compensating with extra insights.
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: 'Search for satellites by name or keyword' specifies the verb (search) and resource (satellites), and 'Returns matching satellites with their NORAD IDs and TLE data' indicates the output. However, it doesn't explicitly differentiate from sibling tools like 'get_tle' or 'list_recent', which might offer alternative ways to access satellite data.
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 like 'get_tle' or 'list_recent'. It mentions the search functionality but doesn't specify scenarios where this is preferred over other tools, such as for fuzzy matching or when exact identifiers are unknown.
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!