fantasy-mcp

Overview Schema Source Related Servers Discussions Admin

Get Transactions

get_transactions

Retrieve your fantasy league's transaction log, including adds, drops, waiver claims, and trades. Filter by team or limit to see recent activity or check pending waiver status.

Instructions

League transaction log: adds, drops, waiver claims (including pending), and trades.

Use this for "who dropped X", "did my waiver claim go through", recent trades, or waiver activity. Newest first. A pending waiver claim has status PENDING; its processed field is when ESPN will run it (already executed claims/trades have processed set to when they ran). Lineup moves (bench/slot changes, not adds or drops) are hidden unless include_lineup_moves is true -- they rarely matter for these questions.

Args: team -- id or name/abbreviation (case-insensitive, partial name ok) to filter to one team's transactions, including trades where that team is the other side; omit for the whole league. limit -- 1 to 100, default 25.

Each row: id, type (WAIVER, FREEAGENT, TRADE, LINEUP, or DRAFT), status (e.g. PENDING, EXECUTED, DECLINED, VETOED), espn_type (ESPN's raw type, e.g. TRADE_ACCEPT), week, team (who initiated it), proposed/processed (UTC timestamps), bid (FAAB dollars, 0 if none), items (action ADD/DROP/ LINEUP/TRADE/DRAFT, player_id, name -- null if not in the player index -- position, pro_team, from_team/to_team, from_slot/to_slot), and a one-line summary.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`team`	No
`limit`	No
`include_lineup_moves`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.1Sep 16, 2026

TDQS

A4.7/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 behavioral burden. It discloses sorting ('Newest first'), pending/processed semantics, filtering behavior for team including trades where the team is the other side, hidden lineup moves, and response field details. This is unusually transparent for a read-only log tool.

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?

The description is dense but every sentence adds value: scope, use cases, ordering, status semantics, filtering, parameter meaning, and output fields. It is front-loaded with the most important identification sentence and flows logically into usage, behavior, args, and return shape.

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 transaction log tool with three optional parameters and an output schema, this description covers all the behavioral nuances an agent needs: pending status, processed timestamps, team-side trade filtering, lineup move suppression, and the meaning of each returned field. Nothing critical is missing.

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 description coverage is 0%, so the description must explain parameters. It does explain team (id or name/abbreviation, case-insensitive, partial name ok, omit for whole league), limit (1 to 100, default 25), and include_lineup_moves is described in the prose though not in the Args section. This is strong coverage, though including all params in the Args section would make it complete.

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?

The description opens with a precise statement: 'League transaction log: adds, drops, waiver claims (including pending), and trades.' This clearly identifies the resource and scope. It also separates this tool from sibling tools by listing its specific transaction types and typical use cases.

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 gives explicit use cases: 'who dropped X', 'did my waiver claim go through', recent trades, or waiver activity. It also explains when not to care about lineup moves and how to include them. It does not explicitly contrast with sibling tools like get_free_agents, but the scope is clear enough for selection.

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

Deploy Server