Lists the 18 News18 RSS section slugs accepted by news18-headlines, with each section’s slug, display name, and URL for targeted headline retrieval.
Get News18 RSS sections. Lists the 18 News18 section slugs accepted by news18-headlines, such as india, world, cricket, explainers and education-career. Each entry has its slug, display name and url.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.17.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose that this is a read/list operation with no inputs and returns slug/name/url per entry. That is solid behavioral context for a catalog tool, though it says nothing about caching, rate limits, or failure modes (minor for a static section list).
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?
Three tight sentences, front-loaded with the purpose, followed by the routing hint and the return shape. No filler or repetition.
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?
There is no output schema, so the description correctly names the returned fields (slug, name, url) and enumerates representative values. For a no-param, read-only catalog tool this covers everything an agent needs to call it and use the result.
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?
Zero parameters, so the baseline is 4 and there is nothing for the description to clarify. The description does not need to compensate for any schema gaps.
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 ('Get News18 RSS sections') and immediately ties the output to the sibling that consumes it ('accepted by news18-headlines'). The concrete slug examples (india, world, cricket, explainers, education-career) make the resource unambiguous versus other news18_* tools.
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?
Explicitly frames the tool as the discovery step for news18-headlines by saying the slugs are 'accepted by' it, which routes the agent correctly. It stops short of an explicit 'use this before calling headlines / do not call with a free-text query' instruction, so it is clear context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.