Skip to main content
Glama
bealmot

sleeper-mcp

by bealmot

schedule_strength

Calculate the average strength of remaining opponents for each fantasy team to assess schedule difficulty and playoff implications.

Instructions

How hard each team's REMAINING schedule is.

Averages the strength of every opponent a team has left. This is the part of a playoff race nobody tracks by eye, and it decides bubble seeds: two teams with identical records can face schedules a touch-down apart per week.

Args: league_id_: override the configured league.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
league_id_No

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It transparently describes the underlying computation (averaging remaining opponent strength) and implies a read-only analytical operation, but says nothing about how results are structured, direction/interpretation, or any cost/rate considerations.

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?

Purpose is front-loaded in the first sentence, followed by supporting explanation and an Args block. The middle sentences add motivation and are mildly verbose, but the structure is clean and nothing is seriously wasted.

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?

An output schema exists, so return values need not be explained. The description adequately conveys what the tool computes and clarifies the sole parameter, leaving an agent able to invoke it correctly; only the interpretation of the numeric output is left implicit.

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 0% for the single parameter, but the description compensates by explaining it: 'league_id_: override the configured league,' which clarifies the default-configured context. That meaning is genuinely added beyond the bare schema, though there is only one param and detail is thin.

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 states a specific computation: it averages the strength of every remaining opponent to produce a schedule-difficulty figure. This is a clear verb+resource that an agent can distinguish from analytics siblings like playoff_odds or matchup_odds. It does not explicitly name a sibling, so it stops short of a 5.

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

Usage Guidelines2/5

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

There is motivational context ('this is the part of a playoff race nobody tracks') but no actual when-to-use guidance, no condition selecting this over sibling tools such as playoff_odds, and no exclusions. The agent must infer the usage scenario.

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