Fetch fresh headlines from a specified IOL section feed. Provide the section path to get current news for that section.
Get IOL section headlines. Returns fresh headlines from one public IOL section feed.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | IOL section path |
Changes observed during successful MCP inspections.
v1.17.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the only source of behavioral context. It usefully discloses that the feed is 'fresh' and 'public' and that exactly one section feed is returned, which implies a read-only call without auth. However, it does not describe output shape, result limits, or error behavior, so it is not fully transparent.
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?
Two short, front-loaded sentences communicate the verb, resource, freshness, and public-feed scope. The second sentence slightly echoes 'headlines' and 'section' but adds new facts ('fresh', 'public', 'one feed'), so there is little waste.
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-parameter read-only tool, the description covers the core facts an agent needs: what is returned, from what scope, and that the feed is public. Since there is no output schema, a note on the returned headline shape or count would strengthen it, but the low complexity makes this a minor gap.
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?
The single 'section' parameter is already fully documented in the schema with a description and a complete enum of valid IOL section paths. The description adds only the contextual note that one public feed is queried, which does not materially extend schema semantics. Baseline 3 applies.
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 ('Get'), a resource ('IOL section headlines'), and a scope ('one public IOL section feed'), which distinguishes it from IOL sibling tools like iol_article, iol_author, iol_news, and iol_sections. No ambiguity remains about what it returns.
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?
The description implies the tool is for retrieving headlines from a single named IOL section, but it never names alternatives or says when to prefer iol_sections, iol_news, or iol_article instead. Usage context is clear from the resource, but no explicit when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.