Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

nfhs_highlights

Search published NFHS Network highlight clips by activity, state, gender, level, school, keyword, or date range, returning titles, durations, publishers, and thumbnails with cursor paging.

Instructions

Search NFHS Network highlights. Returns one page of published highlight clips with title, headline, subtitle, date, duration, publisher identity and logo, sport, game type, gender, level, categories and thumbnail. Filter by activity display name from nfhs-activities, state from nfhs-states, gender and level from nfhs-filters, school_key, a free-text search_term (at least 3 characters) and a YYYY-MM-DD from/to date range; sort by date or created_at. Page with start/size and use next_cursor for deep pages.

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_highlights"
  }
}

Input Schema

Name	Required	Description
`to`	No	Inclusive date upper bound as YYYY-MM-DD
`from`	No	Inclusive date lower bound as YYYY-MM-DD
`size`	No	Page size, 1 to 500; defaults to 20
`sort`	No	Sort order: date+asc, date+desc or created_at+desc
`level`	No	Level filter: varsity, junior varsity, freshman, sophomore or middle school
`start`	No	Zero-based result offset
`state`	No	Two-letter state code from nfhs-states
`cursor`	No	next_cursor from a previous page; the reliable way to page beyond 10000 results
`gender`	No	Gender filter: boys, girls or coed
`activity`	No	Activity name from nfhs-activities, matched case-insensitively
`school_key`	No	School key from nfhs-schools
`search_term`	No	Free-text term matched against highlight titles; at least 3 characters

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does disclose useful traits: results are "published" clips only, one page is returned, and next_cursor is required to page beyond roughly 10000 results, which implies a deep-paging ceiling. It says nothing about authentication, rate limits, default sort behavior, or how multiple filters combine, so the behavioral picture is only partial.

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 what the tool is, then returns, then filtering/sorting/paging. The long enumeration of returned fields is heavy but earns its place because there is no output schema; only minor trimming would improve it.

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 12-parameter, annotation-free, no-output-schema tool the description covers returns, filter sourcing, sorting options and pagination strategy, which is nearly everything an agent needs to call it correctly. Remaining gaps are environmental (auth, errors, filter combination rules) rather than about the call itself.

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

Parameters3/5

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

Schema description coverage is 100%, so every one of the 12 parameters is already documented in structured form, including the 3-character minimum, the YYYY-MM-DD bounds and the next_cursor semantics. The description restates the filter sources and the search_term minimum without adding format or interaction detail beyond the schema, so the baseline 3 applies.

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?

"Search NFHS Network highlights" gives a specific verb and resource, and the following sentence enumerates exactly what a result row carries (title, date, duration, publisher, sport, gender, level, thumbnail, etc.). It never explicitly separates itself from the sibling nfhs_search, so an agent that wants generic NFHS lookup still has to reason about which one covers highlights.

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?

The description explains the intended workflow well: filter values should come from nfhs-activities, nfhs-states and nfhs-filters, which tells the agent to resolve names before calling. It stops short of stating when-not-to-use or naming a sibling alternative, so there is clear context but no explicit exclusions.

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

Deploy Server