EOL Watch

Search items

search_items

Read-only

Lists published items of EOL Watch: retirements, end of support dates and breaking changes. Filter by cloud, kind of change, category, service, search text and effective date. Without status it lists upcoming items only, soonest first. To list ended items, breaking changes in effect or every item, send status ended, in_effect or all. Use it for questions such as what retires in the next 90 days or what is due for one service. It returns one page of compact rows as a Markdown table and as structured data, with the UTC day the countdowns were counted for (as_of). Call get_item for the full text of one item. This tool does not check an estate: that check runs in the reader's browser only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_items"
  }
}

Input Schema

Name	Required	Description
`q`	No	Search text of at most 100 characters. Every word must occur in the title, the summary, the service, the slug or an affected version.
`to`	No	Latest effective_date to include (YYYY-MM-DD). An item without a date never matches. A month, quarter or year is compared by its first day; use within_days for what is due or what ended.
`dir`	No	asc (the default) or desc. The added order ignores it.
`from`	No	Earliest effective_date to include (YYYY-MM-DD). An item without a date never matches. A month, quarter or year is compared by its first day; use within_days for what is due or what ended.
`sort`	No	date (the default): by effective_date, items without a date last; a list of ended items or of changes in effect (status=ended, status=in_effect) is ordered by the last day of each effective period. added: newest first by created_at, then by the later announcement date (items without one last), then by the soonest effective date, then by title. service: by service name.
`type`	No	Kinds of change to include. Leave it out for every kind.
`cloud`	No	Clouds to include. Leave it out for every cloud.
`limit`	No	Most items in one answer: 1 to 100, 25 by default.
`offset`	No	Number of matching items to skip. Send the next_offset of an answer to get the next page.
`status`	No	upcoming (the default): items whose effective period is not over, including items without a date. ended: retirements and end of support dates whose whole period is over. in_effect: breaking changes whose date has passed (a breaking change takes effect, it does not end, so it is never in ended). all: every item.
`service`	No	Service slug of at most 80 characters, as in the service_slug field. Two clouds can use the same slug, so send cloud with it.
`category`	No	Category group, as in the address of a category page.
`within_days`	No	Only items at most this many days from the as_of day (1 to 3650). With status upcoming: items due in the next N days, including an item whose month, quarter or year has started and is not over. With status ended or in_effect: items that ended or took effect in the last N days. With status all: all of these. Cannot be combined with from or to.

Output Schema

Name	Required	Description
`site`	Yes	The site the data comes from.
`as_of`	Yes	The UTC day (YYYY-MM-DD) every value that depends on the day was counted for.
`count`	Yes	Number of items in this answer.
`items`	Yes	The items of this page, as compact rows. Call get_item with the slug of a row for its full record.
`limit`	Yes	Most items one answer holds for this query.
`query`	Yes	The query as it was understood: every parameter with the value that was used.
`total`	Yes	Number of items that match the query.
`offset`	Yes	Number of matching items skipped before the first of this answer.
`license`	Yes	The license of the data.
`next_url`	Yes	Address of the next page of this list, at the data address, or null when this answer holds the last match.
`next_offset`	Yes	The offset of the next page, or null when this answer holds the last match.
`generated_at`	Yes	Moment this answer was built (ISO 8601, UTC).
`status_counts`	Yes	Number of items the query matches in each status, with every other parameter as it was used. An empty list of upcoming items can stand next to items that have ended or are in effect: send status=all to list them.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnlyHint=true and openWorldHint=false; the description adds the pagination model ('one page of compact rows'), the return format (Markdown table plus structured data), and the as_of day used for countdowns. It also discloses a hard scope limit — no estate checking — which an agent could otherwise wrongly assume.

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?

The most important facts — what it lists, the status default, and how to change it — are front-loaded in the first three sentences. It is on the long side for a description, with some density in the middle, but every sentence carries routing, return-format, or scope information.

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

Completeness5/5

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

Thirteen parameters, four enums, and a rich schema would normally demand heavy narrative, and this description covers the parts an agent needs: default status, sort/pagination behavior, return shape, and sibling routing. Return values are also backed by an output schema, so no further detail is required.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description still goes beyond it by explaining the effect of omitting status and by enumerating the status modes that route between upcoming, ended and in-effect results. It does not drill into the date-bound parameters (from/to/within_days), leaving that to the already-detailed schema.

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?

Opens with a specific verb and resource ('Lists published items of EOL Watch: retirements, end of support dates and breaking changes'), which immediately defines what the tool returns. It separates itself from get_item ('Call get_item for the full text of one item') and from the estate check that 'runs in the reader's browser only'.

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

Usage Guidelines5/5

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

States the default behavior ('Without status it lists upcoming items only, soonest first') and names the exact parameter values that switch modes ('send status ended, in_effect or all'). It also gives concrete example questions ('what retires in the next 90 days', 'what is due for one service') and an explicit exclusion: this tool does not check an estate.

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?