Retrieve New Zealand Herald top stories from its public homepage as clean JSON.
Get NZ Herald top stories. Returns fresh New Zealand Herald top stories from its public homepage.
| 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 behavior disclosure burden. It does communicate that the tool reads from the public homepage and returns fresh stories, which implies a read-only, no-auth operation. However, it does not disclose output shape, ordering, number of stories, or pagination behavior, so the behavioral picture is only partially complete.
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?
The description is very short and front-loaded with the core action. The second sentence repeats 'top stories' but adds useful context about freshness and the public homepage, so redundancy is minor.
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?
This is a simple zero-parameter tool, so the description is close to sufficient: an agent knows to call it with no arguments and receive top stories. Still, with no output schema and no annotations, it would benefit from a brief note on the return format or a pointer to nzherald_headlines for headline-specific needs.
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 input schema is empty with zero parameters, so there is nothing for the description to explain about parameter usage. The baseline for zero-parameter tools is 4, and the description makes no incorrect claims about inputs.
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?
The description states a specific action and resource: 'Get NZ Herald top stories.' It also adds a scope cue by noting the stories come from the public homepage, which helps separate it from nzherald_article and nzherald_author. However, it does not explicitly distinguish itself from the similarly named nzherald_headlines sibling.
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?
There is no guidance about when to use this tool versus nzherald_headlines, nzherald_sections, or other news-feed tools. The phrase 'fresh' implies current content, but no exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.