List current public GhanaWeb TV video cards for a chosen category (news, sports, business, entertainment) with metadata and detail URLs; media files are not returned.
List GhanaWeb TV videos. Returns current public video cards for one GhanaWeb TV category, including metadata and a canonical detail URL. This endpoint does not retrieve video media.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Video category from ghanaweb-video-sections |
Changes observed during successful MCP inspections.
v1.17.7Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that results are 'current public' cards and that media is not returned, but it omits operational context such as pagination, ordering, rate limits, or auth requirements. Some behavioral value is added, but not enough for a high score without annotations.
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 sentences, front-loaded with the core purpose and followed by output scope and an exclusion. No filler; every sentence adds useful 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 simple one-parameter list endpoint with no output schema, the description adequately explains what is returned (cards with metadata and a detail URL) and what is not (media). Minor omissions like pagination are acceptable given the simplicity.
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 coverage is 100%, with the single 'section' parameter fully described including an enum. The description adds only 'one GhanaWeb TV category,' which restates what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
The description states a specific verb and resource ('List GhanaWeb TV videos') and scopes it to one category. It also distinguishes the tool from the video detail tool by clarifying 'This endpoint does not retrieve video media,' so an agent can tell it apart from siblings like ghanaweb_video without opening schemas.
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 description implies usage (list videos for a given category) but gives no explicit when-to-use, when-not, or named alternatives. An agent can infer the context but is not routed to ghanaweb_video_sections for categories or ghanaweb_video for single-video retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.