Skip to main content
Glama

late_swap

Late Swap Entries

FanDuel NBA late swap: re-solve the OPEN slots of your existing entries; locked players stay in their slot.

Send the FanDuel entries CSV for the slate (after the first tip: the 'Edit entries' download; before lock: the entries-upload template). A player whose game has started keeps his exact column; every other slot is re-solved on fresh projections and OUT news with the salary cap and 4-per-team rule over the WHOLE lineup. Returns the same file with only those cells changed (csv, upload it at FanDuel > Edit entries) and a per-entry diff. Started slates are hidden by list_slates(playable=true); pass the slate_id from list_slates(playable=false), or omit it to use the FanDuel fixture id inside the file. NBA FanDuel classic only.

Responses:

200: Successful Response (Success Response) Content-Type: application/json

Example Response:

{
  "status": "Status",
  "csv": "Csv",
  "filename": "Filename",
  "slate_id": 1,
  "fd_slate_id": "Fd Slate Id",
  "date": "Date",
  "salary_cap": 1,
  "layout": "Layout",
  "mode": "Mode",
  "lock_buffer_minutes": 1,
  "entries_total": 1,
  "entries_changed": 1,
  "entries_unchanged": 1,
  "entries_infeasible": 1,
  "per_entry": [
    {
      "entry_id": "Entry Id",
      "contest_id": "Contest Id",
      "contest_name": "Contest Name",
      "status": "Status",
      "reason": "Reason",
      "locked": [
        {
          "col": 1,
          "label": "Label",
          "player_id": "Player Id",
          "name": "Name"
        }
      ],
      "swaps": [
        {
          "col": 1,
          "label": "Label",
          "in_id": "In Id",
          "in_name": "In Name"
        }
      ],
      "proj_before": 1.0,
      "gain": 1.0
    }
  ],
  "started_games": [
    "string"
  ],
  "closing_games": [
    "string"
  ],
  "open_games": [
    "string"
  ],
  "evaluated_at_utc": "Evaluated At Utc",
  "solves": 1,
  "warnings": [
    "string"
  ],
  "note": "Note"
}

422: Validation Error Content-Type: application/json

Example Response:

{
  "detail": [
    {
      "loc": [],
      "msg": "Message",
      "type": "Error Type",
      "ctx": {}
    }
  ]
}

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "template_csv": "<template_csv>"
    },
    "name": "late_swap"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoSlate date YYYY-MM-DD. Default: today in America/New_York.
modeNo'optimal' re-solves every open slot (an entry is edited only when it gains >= min_gain projected points, or holds an OUT/missing player); 'replace_out' replaces only open-slot players who are OUT, have no projection, or are avoided.optimal
sportNoOnly 'nba' is supported.nba
avoidsNoPlayer names or ids never brought into an open slot. An avoided player already in an open slot is swapped out (both modes) unless his game starts within lock_buffer_minutes; a locked player is never removed.
min_gainNoProjected points a healthy, valid entry must gain before it is edited (mode 'optimal' only).
platformNoOnly 'fd' (FanDuel) is supported.fd
slate_idNoV12 slate_id from /v1/slates, or the FanDuel fixture id (the prefix of every player/contest id in the file, e.g. 135843). Omit it to use the fixture id read from the template's contest_id.
template_csvYesRaw CSV of the FanDuel entries file for the slate: the 'Edit entries' download after lock, or the entries-upload template before lock. Rows keep their entry_id; the returned CSV is this file with only the open roster cells of entry rows changed.
lock_buffer_minutesNoA game starting within this many minutes takes no incoming player (the upload may land after its lock).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses that started players keep their exact column, that every other slot is re-solved on fresh projections and OUT news, that salary cap and the 4-per-team rule apply over the whole lineup, and that the return is the same file with only changed cells plus a per-entry diff. It does not state solver cost/runtime, quota consumption, or explicitly confirm nothing is submitted to FanDuel (only implied by "upload it at FanDuel > Edit entries").

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?

The core behavior is front-loaded in the first sentence and each subsequent sentence adds operative detail (input file, re-solve rules, output shape, slate_id lookup, sport scope). Slightly dense and paragraph-heavy, with minor redundancy between the header 'Late Swap Entries' and the opening 'FanDuel NBA late swap', but nothing is truly 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?

For a 9-parameter mutation-adjacent tool with no annotations and no output schema, the description covers input provenance, re-solve rules, edge behavior (lock buffer, OUT players), and the returned file/diff, with the 200 response example documenting the payload. It leaves out runtime/solve cost expectations and what `warnings` or `entries_infeasible` mean operationally, which would matter for a multi-entry solve.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it specifies which FanDuel file to supply as template_csv (post-lock 'Edit entries' download vs pre-lock upload template) and explains slate_id sourcing from list_slates(playable=false) or the fixture id embedded in the file's contest_id. It does not add anything for mode, avoids, min_gain, or lock_buffer_minutes, which remain schema-only.

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?

"FanDuel NBA late swap: re-solve the OPEN slots of your existing entries; locked players stay in their slot" gives a specific verb (re-solve), a specific resource (open slots of existing entries), and a scope constraint (locked players untouched). This clearly distinguishes it from sibling tools like generate_lineups or fill_template, which build lineups rather than edit existing entries.

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 states exactly when to use it (after the first tip, with the 'Edit entries' download; before lock, the upload template) and routes the agent to list_slates(playable=false) for started slates, including the fallback of omitting slate_id. It stops short of naming an explicit alternative to use instead for pre-lock construction (e.g., generate_lineups), so no true when-not 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.

Resources