Skip to main content
Glama

Prediction Markets Quant

NFL Power Ratings (PWR)

nfl_power_ratings
Read-only

The PredictionMarketsPicks NFL power ratings — PWR for all 32 teams: points per game above an average team on a neutral field, where PWR = Off PR + Def PR + ST PR. Includes each team's rank and tier. Use for "best NFL teams by power rating", "NFL power rankings 2026", "is Baltimore overrated", "how good is Kansas City", "NFL team ratings".

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": "nfl_power_ratings"
  }
}

Input Schema

NameRequiredDescriptionDefault
teamNoOptional team abbreviation (e.g. "KC", "SF", "LAR") — returns just that team's rating + rank.
tierNoOptional tier: Elite (PWR ≥+7), Contender (≥+4), Playoff (≥+1), Average (≥−2), Below Avg (≥−5), Rebuild (<−5).
limitNoMax teams to return, best rating first (default 32 = full board).

Output Schema

NameRequiredDescriptionDefault
as_ofNoWhen the ratings were generated.
countNoTeams returned.
teamsNoRank, team, PWR (points per game above average, neutral field) and tier.
seasonNoSeason.
sourcesNo
tell_userNoShow this sentence to the user first.
timestampNo
needs_inputNo
example_callNo
data_freshnessNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / limit / description
      Previous value: -"Max teams to return, best rating first (default 32 = full board). Values above 32 are clamped to 32."New value: +"Max teams to return, best rating first (default 32 = full board)."
    • changedInput schema / properties / tier / description
      Previous value: -"Optional: only teams in this tier — one of \"Elite\" (PWR ≥+7), \"Contender\" (≥+4), \"Playoff\" (≥+1), \"Average\" (≥−2), \"Below Avg\" (≥−5), \"Rebuild\" (<−5). A tier with no teams at current ratings returns an empty board, not an error."New value: +"Optional tier: Elite (PWR ≥+7), Contender (≥+4), Playoff (≥+1), Average (≥−2), Below Avg (≥−5), Rebuild (<−5)."
    • removedOutput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
  2. Changed2 schema fields changed
    • removedInput schema / properties / limit / anyOf
      Removed value: -[
      -  {
      -    "anyOf": [
      -      {
      -        "type": "number"
      -      },
      -      {
      -        "type": "string"
      -      }
      -    ]
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / limit / type
      Added value: +[
      +  "number",
      +  "string",
      +  "null"
      +]
  3. Changed6 schema fields changed
    • addedInput schema / properties / limit / anyOf
      Added value: +[
      +  {
      +    "anyOf": [
      +      {
      +        "type": "number"
      +      },
      +      {
      +        "type": "string"
      +      }
      +    ]
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedInput schema / properties / limit / default
      Removed value: -32
    • changedInput schema / properties / limit / description
      Previous value: -"Max teams to return, best rating first (default 32 = full board)."New value: +"Max teams to return, best rating first (default 32 = full board). Values above 32 are clamped to 32."
    • removedInput schema / properties / limit / maximum
      Removed value: -32
    • removedInput schema / properties / limit / minimum
      Removed value: -1
    • removedInput schema / properties / limit / type
      Removed value: -"integer"
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "additionalProperties": {},
      +  "properties": {
      +    "as_of": {
      +      "description": "When the ratings were generated."
      +    },
      +    "count": {
      +      "description": "Teams returned."
      +    },
      +    "data_freshness": {},
      +    "example_call": {},
      +    "needs_input": {},
      +    "season": {
      +      "description": "Season."
      +    },
      +    "sources": {},
      +    "teams": {
      +      "description": "Rank, team, PWR (points per game above average, neutral field) and tier."
      +    },
      +    "tell_user": {
      +      "description": "Show this sentence to the user first.",
      +      "type": "string"
      +    },
      +    "timestamp": {
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  5. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description contributes beyond that by explaining the semantics of the returned value (points per game relative to an average team on a neutral field, plus rank and tier), which an agent needs to interpret the output; it does not add freshness/pagination behavior, but the limit parameter and output schema cover those.

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?

Two sentences, front-loaded with the metric definition before any usage examples, with essentially no filler. The trailing list of quoted queries is slightly long but each maps to a distinct real intent, so it earns its space.

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 an output schema available and full schema coverage, the description only needs to establish what the metric is and when to reach for it, and it does both. The one gap is that it does not say whether ratings are current-week/season-to-date or how often they refresh, which matters for a ratings tool.

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%, including tier thresholds and the team abbreviation example, so the schema already does the heavy lifting for all three parameters. The description adds no parameter-level detail beyond confirming that rank and tier are part of the response; 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?

Names a specific resource (NFL power ratings / PWR for all 32 teams) and defines exactly what the number means: points per game above an average team on a neutral field. It also decomposes the metric (PWR = Off PR + Def PR + ST PR), which clearly separates it from siblings like nfl_win_probability or nfl_edge that answer different questions.

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 quoted example queries ("NFL power rankings 2026", "is Baltimore overrated", "how good is Kansas City") give concrete contexts where this tool is the right pick, which is strong implied routing. However, it never explicitly states when NOT to use it or names an alternative sibling such as nfl_win_probability for matchup odds, so there is no true exclusion guidance.

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.