Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

nfhs_sports

Lists NFHS Network sport URL slugs and their two-team flags, helping you map sport routes and identify which activities use two-team formats.

Instructions

List NFHS Network sport slugs and two-team flags. Returns the sport-slug to flags map NFHS Network uses in its sport routes, currently the is_two_team flag for each of the nine two-team sports. The keys are the URL slugs used in /sports/{sport}/... routes; the nfhs-events activity filter instead takes the activity display names returned by nfhs-activities. This endpoint takes no parameters.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "nfhs_sports"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.3/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden, and it does disclose the meaningful behavior: a static lookup returning a slug-to-flags map covering the nine two-team sports, plus the explicit note that the endpoint takes no parameters. It does not mention auth requirements, caching, or whether the sport list can grow, which are minor gaps for a parameterless static catalog.

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?

Three sentences, front-loaded with purpose and return shape, then consumer-specific caveats. There is mild redundancy between 'the sport-slug to flags map NFHS Network uses in its sport routes' and 'The keys are the URL slugs used in /sports/{sport}/... routes,' which restates the same mapping idea twice.

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?

With no output schema and no annotations, the description does the necessary work by describing the returned map, its keys, and its flag values. It stops short of showing a concrete example payload or stating whether all sports or only two-team sports appear in the map, which would remove the last ambiguity for an agent consuming the result.

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?

The tool has zero parameters, which is the baseline-4 case, and the description reinforces this by stating 'This endpoint takes no parameters.' No additional per-parameter meaning is needed or missing.

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

Purpose5/5

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

The first sentence states a specific verb and resource ('List NFHS Network sport slugs and two-team flags'), and the following sentences pin down the return shape (a slug-to-flags map) and the exact field it carries (is_two_team). It also implicitly separates this tool from nfhs_activities and nfhs_events by naming which identifier each one consumes.

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 concrete routing guidance: the keys are the URL slugs used in /sports/{sport}/... routes, while the nfhs-events activity filter instead takes display names from nfhs-activities. That tells an agent which identifier source to use where, though it never states a plain 'use this tool when...' condition or an exclusion for the sibling nfhs_filters.

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