kalshi_get_series_list

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Calls GET /series'. It adds contextual value by explaining what a series is, but does not disclose additional behaviors like pagination, rate limits, or response size. With annotations covering the safety profile, a score of 3 is appropriate.

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 compact and front-loaded with the endpoint purpose, followed by a helpful example. The first sentence is slightly redundant ('Get Series List Endpoint for getting data') but the overall length is appropriate and every sentence adds value. No unnecessary fluff.

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?

The description explains the core concept of a series and states the endpoint's purpose, which is useful for a discovery tool. However, with no output schema and only 40% parameter documentation, it lacks guidance on how filters behave, what the response contains, or any pagination/ordering semantics. It is minimally sufficient but not rich enough for complex filtering scenarios.

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 only 40%, and the description does not compensate. It generically mentions 'specified filters' but provides no detail on what tags, category, include_product_metadata, or min_updated_ts do. The two parameters that have descriptions in the schema are not elaborated further, leaving the agent without meaningful guidance for the other three.

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 tool 'Gets data about multiple series with specified filters' and explicitly identifies the endpoint ('Calls GET /series'). It differentiates this list/browse endpoint from sibling tools like get_series (single series) and provides an illustrative example of series types, leaving no doubt about its purpose.

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 states the tool allows you to 'browse and discover available series templates by category', giving clear context for when to use it. It does not explicitly mention alternatives or when not to use it, but the use case is well implied and distinct from related single-series endpoints.

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