EOL Watch

Get one item

get_item

Read-only

Returns one published item in full: its dates, summary, impact, migration path, replacement, affected versions and sources, as Markdown and as structured data. Use it with the slug of a row that search_items returned; the address of the item page or its short address works too. An unknown slug is answered as an error, and so is a withdrawn item, with the notice that it was withdrawn.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "get_item"
  }
}

Input Schema

Name	Required	Description	Default
`slug`	Yes	Slug of the item, as in the slug field of a row. The address of the item page, of its Markdown or JSON form, or its short address is accepted too.

Output Schema

Name	Required	Description
`url`	Yes	Page for this item on the site.
`slug`	Yes	Stable identifier of the item. Never changes once published.
`type`	Yes	Kind of change: retirement, end_of_support or breaking_change.
`cloud`	Yes	Cloud the item belongs to: azure, aws, gcp, oci or multi.
`title`	Yes	Short headline of the lifecycle change.
`impact`	Yes	What stops working and who is affected.
`service`	Yes	Display name of the affected service.
`summary`	Yes	One or two plain sentences describing the change.
`category`	Yes	Kind of thing affected, for example service, runtime, kubernetes or database.
`json_url`	Yes	The same item as JSON.
`short_url`	Yes	Short address of the item page. It redirects to url.
`created_at`	Yes	Timestamp (ISO 8601, UTC) when the item was first published here.
`source_url`	Yes	Page the item was verified against: an official vendor page, or the endoflife.date page for the few products where it is the only source of the date.
`updated_at`	Yes	Timestamp (ISO 8601, UTC) of the last change to the item.
`vendor_ref`	Yes	Vendor reference for the announcement, or null.
`replacement`	Yes	Recommended replacement, or null when the vendor names none.
`source_note`	Yes	A note on the address of the source. Set when the id of an Azure Updates address names a day, effective_date has day precision and the two days differ. Null when this check does not apply or finds no difference.
`estate_check`	Yes	What the estate check reads to detect resources this item affects, as the item page lists it. Null when the item has no estate check rules. The check runs in the browser of the reader: no address of this site takes a file, a resource ID or a subscription ID.
`markdown_url`	Yes	The same item as Markdown.
`service_slug`	Yes	URL-safe identifier of the service.
`announced_date`	Yes	Date the vendor announced the change (YYYY-MM-DD), or null when not stated.
`effective_date`	Yes	Date the change takes effect (YYYY-MM-DD), or null when not announced. For month, quarter and year precision this is the first day of the period.
`migration_path`	Yes	Steps to take before the effective date. May contain Markdown.
`last_checked_at`	Yes	Timestamp (ISO 8601, UTC) of the last successful recheck against the source.
`affected_versions`	Yes	Versions affected. Array in JSON, joined with "; " in CSV.
`extra_source_urls`	Yes	Additional sources: official pages, or an endoflife.date page. Array in JSON, joined with "; " in CSV.
`effective_precision`	Yes	How exact effective_date is: day, month, quarter or year.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description doesn't need to argue safety. What it adds is genuine behavioral context beyond the annotations: unknown slugs raise an error, and withdrawn items also raise an error with an explicit withdrawal notice — a failure mode an agent must plan for.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the return content and followed by input sourcing and error behavior. The field enumeration is dense but earns its place by telling the agent what it will get; no filler or restated title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with an output schema, the description covers purpose, input sourcing, and the two notable failure modes. Return-value detail is largely duplicated rather than omitted, so nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'slug' parameter already documents the accepted alternate forms. The description's sentence about the item page address or short address largely restates the schema, adding little new meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 — 'Returns one published item in full' — and enumerates the payload (dates, summary, impact, migration path, replacement, affected versions, sources), so the agent knows exactly what this fetches. The distinction from search_items is made explicit by requiring a known slug, which sets it apart from a sibling search tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It tells the agent precisely how to source the input: 'Use it with the slug of a row that search_items returned,' naming the sibling and the chaining pattern. It stops short of stating when not to use it (e.g., that it should not be used to discover items in the first place), but the routing context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All EOL Watch tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?