Latest versions, LTS windows, and EOL dates for 300+ products. Fresh ground truth for stale models.
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.2/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: listing products, getting all cycles for a product, and getting a single specific cycle. The descriptions explicitly state when to use each, reducing ambiguity for agents.
All tool names follow a consistent verb_noun pattern: get_cycle, get_product, list_products. The verbs are distinct and the nouns clearly indicate the resource type, and the pattern is uniform.
With only 3 tools, the count is minimal but appropriate for a focused purpose: querying version information. It covers the essential operations (list, get all, get one) without unnecessary bloat, though it's on the low end of the ideal range.
The tool surface covers the core workflow: discover products, retrieve product cycles, and drill into a specific cycle. It lacks update/create operations, which is fine for a read-only API, but might miss advanced queries like searching for a specific version across products, though the current set covers the main use cases.
get_cycleGet CycleAOne release cycle of a product: its latest patch version, release date, LTS/support/EOL dates and whether extended support exists. Use when you already know the major version, e.g. product=nodejs cycle=24. Answers: is Node 18 still supported? What is the newest 24.x patch?
| Name | Required | Description | Default |
|---|---|---|---|
| cycle | Yes | Release cycle / major version, e.g. '24' or '3.12' | |
| product | Yes | Product slug, e.g. 'nodejs' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by enumerating the returned data fields (latest patch, dates, support status) and framing example questions it can answer. No contradiction with 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 compact and front-loaded: the first sentence states the core function, the second provides usage context, and the third gives practical example questions. Every sentence earns its place with no 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 two-parameter read-only tool with strong annotations and no output schema, the description adequately explains what data will be returned and when to use the tool. It is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are already documented with examples ('cycle' as '24' or '3.12', 'product' as 'nodejs'). The description reinforces these examples but does not add significant semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving a single release cycle with specific fields (latest patch version, release date, LTS/support/EOL dates, extended support). It distinguishes itself from sibling tools like get_product and list_products by focusing on release-cycle-level details and includes concrete examples.
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 the tool ('Use when you already know the major version') and provides example queries. It does not explicitly mention when not to use it or point to alternatives, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_productGet ProductAAll release cycles for a product, newest first: latest patch version, release date, LTS status/date, end-of-life date, and end of active support. Answers: what is the CURRENT version of X? Which major versions are still supported? When does version Y reach EOL? Use exact slugs from list_products (e.g. nodejs, python, django, postgresql, ubuntu, amazon-eks).
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug from list_products, e.g. 'nodejs', 'python', 'react', 'postgresql' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a safe read-only, idempotent operation. The description adds valuable behavioral context by specifying ordering (newest first) and the exact data fields returned. It does not discuss pagination or response envelope, but for this simple tool the added transparency is solid.
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 compact, front-loaded with the core behavior, and every sentence serves a purpose: first explains output, second lists use cases and input guidance. There is no filler or repetition beyond acceptable reinforcement of the slug requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing key fields, ordering, and the questions it answers. It is complete enough to invoke correctly and interpret results for common versioning/EOL tasks, though it could be slightly richer about the exact response structure or pagination.
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 already fully describes the product parameter as a slug from list_products with examples, so the description adds little new semantic value beyond a few extra examples and emphasis on exact slugs. This meets the baseline for high schema coverage without meaningfully extending it.
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 returns all release cycles for a product, newest first, with specific fields like latest patch version, LTS status, and EOL date. It also lists concrete question types it answers, which distinguishes it from siblings like list_products and get_cycle.
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 use cases, such as finding the current version or EOL date, and explicitly instructs the agent to use exact slugs from list_products with examples. It does not explicitly contrast with get_cycle, so it lacks an exclusion clause for that sibling, but the guidance is still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsList ProductsAList every product slug tracked (nodejs, python, react, postgresql, ubuntu, …). Call this first when unsure of the exact product slug to pass to get_product.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that it returns a list of slugs with examples, which is slightly more than the bare annotations but does not disclose additional behavioral details like output format or pagination (though there are no params). This is adequate but not rich.
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?
Two sentences, no fluff. The first sentence states the core function with examples; the second gives a direct usage directive. Every word earns its place, and it is front-loaded with the verb 'List'.
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 zero-parameter read-only list tool, the description fully covers purpose and usage. It names the primary sibling (get_product) and explains when to use it. The absence of an output schema is not a gap here since the description says it returns slugs. Slightly more detail on return type (e.g., 'array of strings') would make it perfect, but it is complete enough.
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 tool has zero parameters, so schema coverage is 100% and there is nothing to explain about inputs. The description adds semantic value by enumerating example slugs, which indirectly clarifies what the tool returns and what kind of data the user can expect. Baseline for 0 params is 4, which 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 lists all tracked product slugs, with concrete examples (nodejs, python, react, etc.). It explicitly differentiates from get_product by explaining its role as a precursor when the slug is unknown, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance: 'Call this first when unsure of the exact product slug to pass to get_product.' This tells when to use it and relates it to a sibling tool. However, it does not mention get_cycle or give situations when not to use it, but the instruction is clear enough.
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.
No comments yet. Be the first to start the discussion!
