Lists the 24 Variety verticals accepted by variety-headlines, such as film, tv, music, biz, awards, legit and voices, providing each slug, display name and URL.
Get Variety sections. Lists the 24 Variety verticals accepted by variety-headlines, such as film, tv, music, biz, awards, legit and voices. Each has a slug, a display name and a url. Takes no parameters.
| 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?
No annotations are provided, so the description carries the full burden, and it does well: it declares 'Takes no parameters', fixes the result count at 24, and describes the returned fields (slug, name, url) despite there being no output schema. It does not state whether the list is stable or cached, but for a static lookup that is minor.
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?
Three tight sentences, front-loaded with the purpose, then the relationship to the sibling, then the return shape. No filler; every sentence adds information.
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-param, read-only enumeration tool with no output schema and no annotations, the description covers purpose, scope (24 items), example values, and the return fields. Nothing an agent needs in order to call it 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?
Zero parameters, so the baseline is 4. The description reinforces this with 'Takes no parameters', leaving no ambiguity for the agent.
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+resource ('Get Variety sections') and immediately disambiguates by describing them as the 24 verticals accepted by `variety-headlines`, with concrete examples (film, tv, music, biz). An agent can distinguish this from variety_headlines, variety_news and variety_article without opening any schema.
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 link to `variety-headlines` strongly implies the use case: call this to discover valid section values before requesting headlines. However, it never states this explicitly ('use these slugs to filter variety-headlines'), so the routing instruction is left slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.