Get France 24 English-edition headlines for a chosen section, such as Africa, Europe, or Business-Tech, using a section slug.
Get France 24 section headlines. Returns fresh headlines from one public France 24 English-edition section.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | France 24 section slug |
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 carries the burden of behavioral disclosure. It mentions 'fresh headlines' and 'public English-edition section', which provides some context about freshness and language scope, but it does not disclose return format, pagination, or any side effects. This is adequate but minimal.
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 two short sentences with no filler. The core action is front-loaded ('Get France 24 section headlines'), followed by one clarifying clause about freshness and scope. Every word earns its place.
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 should specify what the agent will receive. It only says 'headlines' without indicating whether the result is a list of strings, objects with titles/links, or anything else. For a simple tool it might be acceptable, but the description leaves the return shape ambiguous.
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 covers the single parameter 'section' fully with an enum and description ('France 24 section slug'), so schema coverage is 100%. The description adds a bit of meaning by saying the tool fetches from a specific section, but it does not elaborate on how to use the slug or what values are valid beyond the enum. The description adds marginal value over the schema.
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 clearly states the action ('Get') and the resource ('France 24 section headlines'), and specifies that it returns headlines from a single public English-edition section. This is specific enough to distinguish from sibling tools like france24_article or france24_sections, though it does not explicitly name alternatives.
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 gives no guidance on when to use this tool versus alternatives. It does not mention when to prefer headlines over france24_news or france24_sections, nor does it exclude any cases. The usage context is only implied by the verb 'Get' and the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.