Fetch current headlines from a specified Daily Kos category feed; use dailykos-sections to find valid category slugs before querying.
Get Daily Kos category headlines. Returns current stories from one verified Daily Kos category feed. Use dailykos-sections to discover the complete accepted category set.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Daily Kos category slug |
Changes observed during successful MCP inspections.
v1.17.9Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' and 'Returns current stories' imply a safe read and describe the return content, but there is no disclosure of rate limits, pagination, or result count. It adds modest context ('one verified feed') without covering broader behavioral traits.
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 with the core purpose front-loaded and no filler. Slightly more economical phrasing could merge the second sentence's scope note, but it is efficiently organized.
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 single-parameter read tool with no output schema, the description covers purpose, scope, and how to obtain valid parameter values, which is close to what an agent needs. It is only marginally short of an explicit statement about the returned item structure or how it differs from sibling news tools.
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?
Schema description coverage is 100% and the single parameter is a fully enumerated slug, so the schema does the heavy lifting. The description reinforces the constraint that exactly one category may be supplied and points to dailykos-sections for the accepted set, but adds no syntax or format meaning beyond the enum itself. Baseline 3 applies.
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 Daily Kos category headlines') and narrows scope to 'current stories from one verified Daily Kos category feed'. It differentiates from the section-discovery sibling (dailykos-sections) but does not contrast with the closely related dailykos_news or dailykos_article, which are equally plausible retrievers.
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 gives one concrete routing instruction: 'Use dailykos-sections to discover the complete accepted category set,' which is genuinely useful for populating the required parameter. However, it offers no guidance on when to prefer this headline tool over dailykos_news or dailykos_article, leaving the primary selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.