Retrieve NDTV video metadata from a canonical video URL, including title, description, publication time, duration, and thumbnail details; excludes media and player URLs.
Get NDTV video metadata. Returns title, description, publication time, duration, and thumbnail metadata from one canonical NDTV video page. It does not fetch or return video media or player URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical NDTV video URL |
Changes observed during successful MCP inspections.
v1.17.9Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the negative behavior (no media/player URLs fetched) and the read-only nature is implied by 'Get ... metadata', but it omits permissions, error behavior for invalid/hostile URLs, and any rate-limit or caching context.
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 short sentences: purpose, return payload, and scope exclusion. The return-field list is front-loaded and earns its place because no output schema exists, and nothing is repeated from structured fields.
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-param read tool with no output schema and no annotations, the description covers purpose, the payload shape, and the key negative scope. It is largely complete; only edge-case behavior (invalid URL, non-video page) is absent, which is minor here.
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?
One parameter at 100% schema coverage with a schema description ('Canonical NDTV video URL'), so the baseline is already high. The description reinforces the constraint by emphasizing 'one canonical NDTV video page', adding the semantic that a non-canonical or listing URL will not work.
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 NDTV video metadata) and scopes it to 'one canonical NDTV video page', which implicitly separates it from the list-style sibling ndtv_videos/ndtv_latest_videos. It enumerates the returned fields, so the agent knows exactly what it gets. It never names a sibling explicitly, so it stops short of a 5.
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?
Usage is implied rather than stated: the agent must already hold a canonical NDTV video URL, and the negative note that it does not return media or player URLs tells the agent when this tool is the wrong choice. There is no explicit routing to ndtv_videos for listing videos or to ndtv_article for article content, so the guidance is only partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.