polymarket_search

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose that the endpoint is credential-free and returns normalized event results, which is useful context. However, it does not mention pagination, rate limits, or what 'normalized event results' actually contain, leaving some behavior unexplained.

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 at three sentences and front-loads the core purpose. The third sentence recapping enum values is mildly redundant given the schema, but the text remains focused and efficiently sized.

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 search tool with no output schema and no annotations, the description supplies the essential operational context: credential-free access, normalized result output, and valid enum ranges. It does not detail result fields or parameter interactions, but the required q and optional filters are self-explanatory from the schema, so an agent can still invoke it correctly.

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 100%, so the baseline is 3. The description only restates the status and sort enum values already in the schema and adds no extra meaning about default behaviors, parameter interactions, or how optional flags like include_tags and include_profiles affect results.

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 opening phrase 'Search Polymarket events' names a specific verb and resource, and the second sentence narrows this to the public search JSON endpoint that returns normalized event results. This clearly identifies what the tool does without needing to inspect the schema.

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?

There is no guidance on when to use this tool versus sibling Polymarket tools such as polymarket_events, polymarket_markets, or polymarket_market_detail. The credential-free note implies broad accessibility, but no when-to-use or when-not-to-use decision rules are provided.

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