Fetch Manchester Evening News headlines for a selected section to track local news, sport, or events.
Get Manchester Evening News section headlines. Returns fresh headlines from one public Manchester Evening News section.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Manchester Evening News section slug |
Changes observed during successful MCP inspections.
v1.17.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the result is 'fresh headlines' and that the call is scoped to 'one public' section, but it does not describe the result format, number of headlines, pagination, or edge behavior. This is acceptable for a simple read tool, but not rich.
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 short and front-loaded, with the main action in the first sentence. There is slight redundancy between 'Get ... section headlines' and 'Returns fresh headlines from one public ... section,' but the overall length is appropriate and scannable.
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 headline retrieval tool, the combination of description and enum-based schema is largely complete: the agent knows what output to expect and which section values are valid. It would be stronger if it pointed to men_sections for slug discovery or men_article for full articles, but nothing essential to invoking this tool correctly is missing.
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 schema already provides 100% coverage for the single required `section` parameter, including an enum of valid slugs and a brief description. The description adds little beyond reinforcing that the tool handles 'one public' section, so it does not meaningfully compensate or extend the schema's parameter documentation.
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 the core action with a specific verb and resource: 'Get Manchester Evening News section headlines.' The phrase 'from one public Manchester Evening News section' clarifies scope, but it never explicitly distinguishes this tool from sibling tools such as men_sections or men_article, so an agent must partly infer that boundary from the name.
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 intended use is reasonably implied: retrieve fresh headlines from one MEN section. However, the description does not explicitly mention alternatives like men_sections for discovering valid section slugs or men_article for full article content, leaving the selection logic to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.