List The Telegraph sections accepted by the headlines endpoint to find valid slugs like uk-news, world-news, politics, finance, culture, and opinion.
Get The Telegraph sections. Lists the The Telegraph sections that the headlines endpoint accepts, such as uk-news, world-news, politics, finance, culture and opinion. Each entry has a slug, a display name and a section 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 well: it discloses that this is a static enumeration of accepted slug values and describes the return shape (slug, name, url). It does not mention whether sections are stable/cached or exhaustive beyond the examples given, leaving a minor gap.
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 sentences: purpose first, then concrete examples and return structure. No filler, and the most actionable information (accepted section values) is front-loaded.
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 zero-parameter lookup with no output schema, the description supplies enough to call and interpret the tool, including entry fields. It could note that the listed slugs are the valid enum for sibling headline/section calls, but coverage is otherwise adequate.
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 tool takes zero parameters, so the baseline is 4. The description correctly implies no filtering input is needed and instead documents the output field semantics.
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 The Telegraph sections') and clarifies the exact role of the data: the sections the headlines endpoint accepts. This cleanly separates it from siblings like telegraph_headlines, telegraph_news, and telegraph_article.
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?
It establishes the practical use case by tying the output to the headlines endpoint's accepted values, which tells an agent to call this before filtering headlines. It does not explicitly name the sibling tool to use afterward or state when not to call it, so it falls short of 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.