Skip to main content
Glama

nfhs_activities

Read-only

List the complete NFHS Network activity list and return each activity's name, sport/two-team/indoor/championship/top-sport flags and icon URL. Use this discovery tool to get the exact activity names the nfhs_events and nfhs_highlights activity filter accepts; the filter matches those names case-insensitively, so do not invent slugs. is_sport=true returns only sports and is_top_sport=true returns the 12 promoted top sports; a valid empty filter result is count 0 with an empty list. This is one anonymous JSON read with no upstream key or cookie.

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

Input Schema

NameRequiredDescriptionDefault
is_sportNoOptional sport flag filter. true returns only sports, false returns non-sport activities such as graduation and band performance.
is_top_sportNoOptional top-sport flag filter. true returns the 12 activities the site promotes as top sports.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag read-only and open-world access, but the description adds what those hints do not: this is an anonymous JSON read requiring no upstream key or cookie, and an empty filter result is a valid count of 0 with an empty list rather than an error. That auth and empty-result context is exactly the kind of behavior an agent needs before calling.

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

Conciseness5/5

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

Three compact sentences, front-loaded with the return contents and then the purpose, with no filler or repeated wording. Every clause carries actionable information.

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

Completeness5/5

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

For a two-optional-flag discovery read with an output schema present, the description covers purpose, downstream use, filter behavior, and empty-result semantics. Nothing an agent needs in order to call it correctly is missing; return-shape detail is appropriately delegated to the output schema.

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 both optional parameters are already documented in the schema. The description's statements about is_sport=true and is_top_sport=true returning 12 promoted top sports restate the schema rather than extending it (it adds only the filter-matched names are case-insensitive, which is usage guidance, not parameter semantics). Baseline 3 is appropriate.

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?

"List the complete NFHS Network activity list" is a specific verb plus resource, and the description enumerates what each entry carries (name, sport/championship/etc. flags, logo URL). It also positions itself against siblings by naming the downstream consumers (nfhs_events, nhnls activity filters), so an agent can tell it apart from tools that consume the values.

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

Usage Guidelines5/5

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

Explicitly states when to use it ('discovery tool to get the exact activity names the nhfs_activities filter expects') and gives a concrete prohibition with rationale: don't invent slugs, since matching is by exact name and case-insensitive. It also explains what each filter flag selects and what a legitimately empty result looks like, leaving nothing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.