Retrieve recent critical advisory items from ICHI's public RSS feed, including title, link, publish time, category, and description; set a limit up to 50.
Get the latest items (default 5, max 50) from ICHI's critical-advisory RSS feed (https://ichi.global/api/alerts): title, link, published time, category, description.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that results come from a remote third-party RSS endpoint and that limits are bounded (default 5, max 50), which hints at latency/cost, but says nothing about freshness, caching, or how feed fetch failures are surfaced.
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?
One front-loaded sentence with the resource and default/max limits stated before the return fields. The embedded URL is arguably extra weight but earns its place as provenance for the data source.
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 one-optional-parameter read tool with an output schema present, the definition covers source, size bounds, and key returned fields, which is enough to call it correctly. Only failure/refresh behavior is left unstated.
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 0% and the single 'limit' parameter has only a default. The description supplies the missing upper bound (max 50), which is real information the schema does not convey, though it doesn't say what 'limit' counts or what happens if values exceed 50.
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?
States a specific verb and resource (retrieve latest items from ICHI's critical-advisory RSS feed) and even names the backing endpoint, plus enumerates the returned fields. An agent can tell this is an external advisory-feed reader, distinct from get_current_index and get_source_health, though the description never says so explicitly.
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?
No guidance on when to call this versus the sibling tools, no prerequisites, no exclusions. The only usage signal is implicit in the 'default 5, max 50' limits, which says how much to fetch, not when to fetch it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.