Industry Pulse

Get Release Radar, the daily AI releases

release_radar

Read-onlyIdempotent

Get Release Radar, the day's AI releases from their makers' own posts. Use it for "what did AI labs ship today?", "give me today's Release Radar" or "what AI releases came out on 2026-10-21?". Optional: date as YYYY-MM-DD (a GMT+7 day; default the newest issue). Returns the issue's headline, lede, page url and up to 6 items, each from its maker's own blog, changelog or release feed, with a 0 to 100 score, a one-line reason it was picked and a link per source; the days that have an issue; and rulesUrl, the page that explains the scoring. A new issue comes out every day at 07:00 GMT+7.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

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

Input Schema

Name	Required	Description	Default
`date`	No	The issue's day as YYYY-MM-DD (GMT+7). Default: the newest issue.

Output Schema

Name	Required	Description
`asOf`	Yes	When the returned issue's window closed
`note`	Yes
`as_of`	Yes	ISO 8601 time the data was published by its source or fetched from it. A cached answer keeps the time of its fetch.
`brief`	Yes
`source`	Yes	Who the data comes from, to cite and to check it against.
`rulesUrl`	Yes
`available`	Yes	Days with a published issue, newest first
`untrusted_source`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 12, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the bar is lower; the description still adds real operational context the annotations cannot: a fixed daily publish time (07:00 GMT+7), the GMT+7 day boundary, the candidate pool (makers' own blogs, changelogs, release feeds) and the 0-100 scoring with a rulesUrl. Its one weakness is that the item-level return details largely restate what the output schema already encodes.

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

Conciseness3/5

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

The purpose and usage examples are front-loaded and earn their place, but the second half is a semicolon-chained inventory of return fields that duplicates the output schema and makes the definition longer than it needs to be. It is readable but bloated for a one-optional-parameter tool.

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 optional-parameter read tool with full annotation coverage and an output schema, nothing an agent needs to call it correctly is missing; the freshness cadence and timezone rule are the genuinely load-bearing additions. It loses a point only for spending completeness budget on return-field detail the output schema already handles.

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 coverage is 100% and the single parameter already carries pattern and default in its own description. The description's 'date as YYYY-MM-DD (a GMT+7 day; default the newest issue)' is essentially a restatement, adding only a concrete example date rather than new syntax or edge-case meaning.

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 leads with a specific verb and resource ('Get Release Radar, the day's AI releases from their makers' own posts') and immediately grounds it in concrete agent-facing questions ('what did AI labs ship today?'). That makes it distinguishable from generic siblings like daily_digest or latest_events without opening either schema.

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 gives clear when-to-use context through three quoted example queries, including a dated one that shows the optional date path. It stops short of stating when NOT to use it or naming an alternative sibling for overlapping needs, so it is strong context rather than full routing guidance.

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

All Industry Pulse 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.