Generate a lineup for a fantasy basketball game day that maximizes games started and player value, respecting locked players and IL moves. Preview recommendations before approval.
Optimal lineup for an ET game day (max games started, then value). Players whose games have started are locked; IL moves are included (blocked activations need a drop proposal). Read-only preview.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=true and openWorldHint=false, so safety is declared. The description adds real context beyond that: the optimization objective, the rule that started games are locked, IL inclusion, and that blocked activations require a drop proposal — meaningful behavior an agent cannot infer from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose and objective, then edge-case behavior. The parentheticals ('max games started, then value', 'blocked activations need a drop proposal') each earn their place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with one optional parameter and no output schema, the description covers objective, locking semantics, IL handling, and the drop-proposal requirement — the key behaviors an agent needs. The remaining gap is the `day` parameter format/default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single `day` parameter has 0% schema description coverage, so the description must carry it. 'ET game day' usefully fixes the timezone and the semantic meaning of the parameter, but gives no format or default-day behavior, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (optimize) and resource (lineup) and even the objective function — 'max games started, then value'. It is clearly distinguishable from generic tools, though it never names a sibling (e.g. lineup_steps or my_roster) that an agent might confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Read-only preview' tells the agent this does not apply changes, which is a usage signal, and the note that blocked activations need a drop proposal hints at the write path. But there is no explicit when-to-use/when-not or named alternative, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.