Skip to main content
Glama

get_latest_news

Retrieve current New York Times news articles with options to filter by section, source, and pagination for targeted information access.

Instructions

Get the latest news items from the NYT news wire (real-time news feed).

Args: limit: Number of items to return (default: 20) offset: Pagination offset (default: 0) source: News source - "nyt" or "inyt" (default: "nyt") section: News section (default: "all"). e.g. "u.s." or "technology". Use the 'nyt://reference/sections' resource for available section names.

Returns: Formatted response with news_items array containing title, abstract, url, section, subsection, published_date, and byline

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
sourceNonyt
sectionNoall

Implementation Reference

  • The primary handler function for the 'get_latest_news' MCP tool. Registered via the @mcp.tool() decorator. Defines the tool's input parameters, documentation, and delegates execution to the helper function in tools.py.
    @mcp.tool()
    async def get_latest_news(
        limit: int = 20,
        offset: int = 0,
        source: tools.NewsSource = "nyt",
        section: str = "all",
    ) -> dict:
        """
        Get the latest news items from the NYT news wire (real-time news feed).
    
        Args:
            limit: Number of items to return (default: 20)
            offset: Pagination offset (default: 0)
            source: News source - "nyt" or "inyt" (default: "nyt")
            section: News section (default: "all"). e.g. "u.s." or "technology". Use
                the 'nyt://reference/sections' resource for available section names.
    
        Returns:
            Formatted response with news_items array containing title, abstract, url, section,
                subsection, published_date, and byline
        """
        return await tools.get_news_wire(limit, offset, source, section)
  • Type definition for 'NewsSource' parameter used in the get_latest_news tool handler for input validation (Literal['nyt', 'inyt', 'all']).
    type NewsSource = Literal["nyt", "inyt", "all"]
  • Core helper function implementing the NYT news wire API call, parameter handling, HTTP request via NytClient, and response formatting for the get_latest_news tool.
    async def get_news_wire(
        limit: int = 20,
        offset: int = 0,
        source: NewsSource = "nyt",
        section: str = "all",
    ) -> dict:
        """
        Get the latest news items from the NYT news wire (real-time news feed).
    
        Args:
            limit: Number of items to return (default: 20)
            offset: Pagination offset (default: 0)
            source: News source - "nyt", "inyt", or "all" (default: "nyt")
            section: News section (e.g., "all", "world", "business") (default:
                "all"). To see the latest list of sections available, refer to the
                get_news_sections tool.
    
        Returns:
            Formatted response with news_items array containing title, abstract, url, section,
            subsection, published_date, and byline
        """
        params = {
            "limit": limit,
            "offset": offset,
        }
    
        client = get_client()
        response = await client.make_nyt_request(
            f"news/v3/content/{source}/{section}.json", params
        )
    
        return format_news_items_response(response)
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'real-time news feed' and describes the return format, which adds some context. However, it lacks details on rate limits, authentication needs, data freshness, or potential errors (e.g., invalid sections). For a tool with no annotations, this is a significant gap in behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by organized sections for 'Args' and 'Returns' with bullet-like formatting. Each sentence adds value: the purpose sets context, parameter details are essential given low schema coverage, and return format clarifies output. There is no wasted text or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, 0% schema coverage, and no output schema, the description does a decent job but has gaps. It fully documents parameters and return format, which is crucial. However, it lacks behavioral context (e.g., rate limits, errors) and usage guidelines versus siblings. For a tool with this complexity and lack of structured data, it's adequate but incomplete, meeting minimum viability with clear room for improvement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for all four parameters: 'limit' (number of items, default 20), 'offset' (pagination offset, default 0), 'source' (news source options and default), and 'section' (news section, default, example, and reference for available names). This adds substantial meaning beyond the bare schema, effectively documenting parameter usage and constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the latest news items from the NYT news wire (real-time news feed).' It specifies the verb ('Get'), resource ('latest news items'), and source ('NYT news wire'), making the action and target explicit. However, it doesn't explicitly differentiate from siblings like 'get_most_popular' or 'search_articles', which likely serve different purposes (e.g., popularity-based vs. search-based retrieval).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It mentions a 'real-time news feed' but doesn't clarify how this differs from siblings like 'get_archive' (historical news) or 'get_most_popular' (popular articles). There are no explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage based on tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jeffmm/nytimes-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server