Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

sportskeeda_topic

Get full content from a Sportskeeda topic, event, team, or player overview page: prose, headings, lists, tables, images, embeds, byline, and related stories.

Instructions

Get a Sportskeeda topic or entity overview's full content. Returns ordered prose, headings, lists, tables, images and embeds from a public topic, event, team or player overview page, plus available byline, modification text and related stories. Discover slugs with /sportskeeda/sitemap-items using tags.xml, tournaments.xml, teams.xml, players.xml or us-sitemap.xml. Pages without a CMS body return an upstream error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesCanonical Sportskeeda topic, event, team or player path without host

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does disclose real traits: the return structure (ordered prose, headings, lists, tables, images, embeds, byline, modification text, related stories) and a failure condition ('Pages without a CMS body return an upstream error'). Auth needs and rate limits are unstated, keeping it short of a 5.

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

Conciseness4/5

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

Four sentences, front-loaded with the core purpose, then return shape, then slug discovery, then the error note. Slight redundancy between 'topic or entity overview's full content' and 'topic, event, team or player overview page,' but no wasted filler.

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

Completeness4/5

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

For a one-parameter tool with no output schema and no annotations, the description is nearly self-sufficient: it explains what is returned, the error case, and how to obtain the slug. It stops short of stating auth requirements or response format details, so it is complete but not exhaustive.

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

Parameters4/5

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

Schema coverage is 100% and the single 'slug' parameter is fully documented, so the baseline is 3. The description adds meaning the schema lacks — that the slug is a canonical path 'without host' and how to discover slugs — which goes beyond the structured field.

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 opens with a specific verb+resource: 'Get a Sportskeeda topic or entity overview's full content.' It scopes the resource to topic/event/team/player overview pages, which implicitly separates it from article/news siblings such as sportskeeda_article, though no sibling is named explicitly.

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

Usage Guidelines4/5

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

It gives a concrete prerequisite path — discover slugs via /sportskeeda/sitemap-items with tags.xml, tournaments.xml, teams.xml, players.xml or us-sitemap.xml — which tells the agent how to satisfy the required parameter. It does not, however, state when an alternative tool (e.g., sportskeeda_article) is the better choice, so no explicit when/when-not routing.

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

Deploy Server

Other Tools