Skip to main content
Glama
bealmot

sleeper-mcp

by bealmot

set_lineup

Set your fantasy football starting lineup for a week by supplying player names in slot order, with a dry run by default until confirmed.

Instructions

WRITE. Set your starting lineup for a week.

Takes player NAMES in SLOT ORDER. The slots come from your league's own roster_positions, so a superflex or 3-WR league works correctly without configuration — call league_info to see the order you must supply.

In-week changes work, including on a lineup containing players whose games have already kicked off; only the locked players themselves are immovable.

Args: players_in_slot_order: One name per starting slot, in order. Use a team code for a defence, e.g. "NE". league_id_: Defaults to SLEEPER_LEAGUE_ID. roster_id_: Defaults to SLEEPER_ROSTER_ID. week: NFL week. 0 (default) uses the current week. confirm: Must be True to send. Default False = dry run.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
weekNo
confirmNo
league_id_No
roster_id_No
players_in_slot_orderYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses WRITE behavior, confirm=True to send versus default dry run, and in-week changes including players whose games have kicked off, with only locked players immovable.

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?

Front-loads WRITE and the purpose, then moves into argument-specific guidance. Every sentence adds useful detail without redundant repetition, and the args section is appropriately structured for a five-parameter tool.

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 mutation tool with no annotations, 0% schema descriptions, and an output schema, the description covers prerequisites (league_info), slot-order mechanics, dry-run/confirm safety, and edge cases like in-week changes and locked players. Nothing critical is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate fully. It documents all five parameters: players_in_slot_order (names in slot order, use team code for defense), league_id_ and roster_id_ defaults, week (NFL week, 0=current), and confirm (True to send, False=dry run).

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?

States 'WRITE. Set your starting lineup for a week' — a specific verb and resource. The action is unambiguous against siblings like set_keepers and set_ir, even without naming an alternative.

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?

Gives clear context: use this to set a weekly starting lineup, and call league_info to see the required slot order. It does not name when-not-to-use or alternatives, so exclusions are absent.

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