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

With no annotations, the description must disclose behavior, but it only says the tool returns signals. It does not mention data freshness, whether it requires network access, whether it computes signals itself or just aggregates existing ones, whether it can fail for illiquid tokens, or what return shape to expect.

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 one sentence, which is concise, but it is front-loaded with a vague label rather than meaningful detail. It earns a pass for brevity but loses points because the one sentence is not sufficiently informative.

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?

There is no output schema and the tool has a single loosely-described parameter. For an agent to call this correctly, it needs to know what token identifier to provide and what 'signals' will look like. The description does not provide that context, especially given the many similar Polymarket sibling tools.

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 coverage for 'token' is 100% but the description only says 'Token to process' in the schema and never explains what a valid token looks like (address, symbol, market ID, condition ID?) in the description. Coverage being high gives a baseline of 3 per rubric, but the schema's own description is nearly tautological, so the combined meaning is weak and the description does not add the needed semantics.

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 it provides bid/ask/spread signals from Polymarket CLOB, which identifies the resource and general function. However, 'Poly Signals' is a vague label, and among many Polymarket-related siblings (poly-clob, poly-depth, poly-price, poly-walls, polymarket-odds), it does not clearly explain what distinguishes signals from raw market data.

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 siblings like poly-clob, poly-walls, or trading-signal. The parameter 'token' hints at usage, but the description does not state what sort of token (e.g., market condition ID, token ID) or whether it complements or replaces other Polymarket tools.

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