Search NDTV news stories by topic and return one page of 15 result cards. Use it to find public news coverage; unknown topics return a 404 error.
Search NDTV news stories. Returns one page of NDTV's public news topic results (15 story cards per page). Unknown topics return 404. The result page supports no sort or filter parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based result page | |
| query | Yes | Search terms |
Changes observed during successful MCP inspections.
v1.17.7Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers real operational detail: 15 story cards per page, 404 for unknown topics, and no sort/filter support. These are exactly the behaviors an agent needs (pagination size, error semantics, absent features) and they go well beyond the schema.
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?
Four short sentences with no filler, and the core purpose is front-loaded before the return-shape and limitation notes. Slightly clipped as a list of facts rather than clean prose, but every sentence 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?
With no output schema and no annotations, the description must explain result shape and error behavior, and it does: 15-card pages, 404 on unknown topics, no filtering. Missing only whether there is a total-page indicator or pagination termination, which is a minor gap for a 2-parameter search tool.
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% (query = search terms, page = 1-based page), so the schema already documents both parameters. The description adds the per-page result count, which is useful context, but does not clarify query syntax or paging edge cases beyond the schema baseline.
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: 'Search NDTV news stories'. An agent immediately understands this is a keyword search over NDTV content. However, it does not differentiate itself from close siblings like ndtv_news, ndtv_headlines, or ndtv_sections, so the agent has to infer the boundary.
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?
There is no explicit when-to-use guidance and no named alternative (e.g., ndtv_headlines for browsing, ndtv_article for a known story). The only usage-shaped information is a negative constraint about sort/filter, which constrains invocation rather than telling the agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.