sleeper_search_playersSearch Sleeper’s player directory by name, with optional position filters, to identify players mentioned in trade proposals.
Search Sleeper’s player directory by name and optionally position. Useful for resolving names mentioned in a proposed trade.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| position | No | ||
| active_only | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that matching is by player name with an optional position filter, but discloses no deeper behavior such as match semantics, result limits, or handling of special entries. With annotations present, a 3 is fair.
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?
Two tight sentences: the core operation is front-loaded, followed by a single use-case sentence. No repetition of the title, no filler, and every phrase earns its place.
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 simple four-parameter, read-only search tool, the description supplies adequate selection and invocation context. The main gap is that with no output schema it does not indicate what a result record contains (e.g., player ID), which would fully serve the stated name-resolution use case.
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?
Schema description coverage is 0%, so the description must compensate. It gives real meaning to two parameters — 'query' is a player name and 'position' is a player position — but says nothing about 'limit' or 'active_only', leaving them to inference from their property names and schema constraints. This is only partial compensation.
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?
The description says exactly what the tool does: search Sleeper's player directory by name, with an optional position filter. The verb+resource is specific, and all siblings target different resources (leagues, rosters, transactions, matchups, drafts), so this is easily distinguishable.
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?
It gives a concrete scenario — resolving player names in a proposed trade — which tells the agent when to reach for this tool. It does not name alternatives or state when not to use it, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.