parlayapi_live_search

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

With no annotations provided, the description carries the sole burden of disclosing behaviors. It usefully states that no API key is required and that it returns search results for teams, players, and sport_keys. It does not mention any response shape, paging, or rate limits, but both the search nature of the tool and the presence of an output schema reduce the need for exhaustive detail.

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?

The description is only a few short sentences, opens with the command and resource, and includes a functional note about no API key required. It avoids repetition of the tool name and every word adds either use-case or operational context. Very strong structure.

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?

Given that this is a simple search operation with one required parameter and an output schema present, the description leaves the agent with a sane, full picture: what to search, what the result's role is, and a key operational note (no API key). It does not break down the response format, but the existence of an output schema makes that unnecessary.

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 schema gives only property titles and no descriptions (0% coverage). The description compensates for 'q' with its natural-language lookup purpose, and implies that 'limit' exists to cap a search result, but explicitly meaning the limit sentantic is left to the schema's default value of 25. That is enough basic understanding for an agent, but it is not comprehensive.

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 clearly states the action ('Search live teams, players, and sport keys') and wraps it in a concrete use case. It distinguishes the tool from siblings by emphasizing that it maps natural-language names to the exact sky_key needed for subsequent calls. This is specific, not tautological, and covers the tool's role.

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?

The description gives a clear when-to-use statement: when a user asks for a team, player, or league by natural-language name and the agent needs the exact sport_key for the next step. It does not explicitly name alternatives or say when NOT to use, but in a sibling list dominated by odds, props, and sports data calls, the intended context is easy to infer.

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