Problee

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered structurally. The description adds that the payload is protocol documentation (auth schemes, reconnect/replay behavior) which is meaningful context, but it does not disclose return format, size, or how the wallet-scoped channel differs operationally.

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?

A single dense sentence that front-loads the primary content (transport) before the secondary topics (bridge, channels, fallback). No filler, though the enumerated list is packed enough to border on a table of contents.

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?

An output schema exists, so return-value explanation is unnecessary, and with no input parameters the description need only frame what the documentation covers. It does that adequately, though it omits guidance on when this discovery call is the right one to make.

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 tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to compensate for. Baseline 4 applies.

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 states a specific verb ("Describe") and enumerates the exact subject matter: WebSocket transport details (URL, auth, message shapes, reconnect/replay), the WS↔webhook taxonomy bridge, auto-delivered channels, and webhooks as fallback. An agent can tell it is a documentation/transport-description tool. However, it does not differentiate itself from the closely overlapping sibling problee_discover_webhooks, nor reconcile with the name problee_discover_events.

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 statement of when to call this versus alternatives, no prerequisites, and no exclusion conditions. Given siblings like problee_discover_webhooks and problee_list_webhook_event_types that cover adjacent territory, the absence of routing guidance is a real gap.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: this is a descriptive documentation surface, not an execution path, and the authoritative execution lane lives elsewhere. It does not discuss caching, freshness, or rate limits, but the core behavioral framing is present.

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 sentences, with the purpose front-loaded and the caveat about execution authority placed at the end where it belongs. The parenthetical enumerations inside the first sentence make it dense, but every clause maps to a distinct lane rather than padding.

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?

With zero parameters and an output schema present, the description's job is scoping only, and it delivers that by naming the lanes covered. An agent knows what it will learn from a call and where that knowledge does not extend (execution). No material gap for a parameterless discovery tool.

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 tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. The listing of lanes is informational rather than parameter-related, which is appropriate here.

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?

States a specific verb and resource ('Describe the canonical market-data lanes') and enumerates exactly what it covers: WebSocket subscribe/channel/message shapes, REST snapshot/quote/orderbook, consumer SSE, and the agent control-plane WebSocket. That enumeration distinguishes it from sibling discovery tools like problee_discover_events or problee_discover_webhooks, though it doesn't name them directly.

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 closing sentence tells the agent that quote/order-book tool calls remain the execution-authoritative path and this only describes realtime/display lanes, which implies when to reach for it. It stops short of stating when to use this versus the other problee_discover_* tools, so the routing decision is only partially supported.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds that the listing includes data schemas and examples, which is useful content context beyond the annotations, but says nothing about rate limits, freshness, or whether the catalog is static.

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 with no filler: the capability statement is front-loaded and the routing note follows. Every clause carries information an agent can act on.

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?

With an output schema defined, return values need not be described, and the annotations carry the safety profile, so the remaining burden on the description is light. It covers what is listed and where it fits in the publishing workflow; only a clearer tie-in to when this discovery step is needed is missing.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-level detail is omitted because no parameters exist.

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 gives a specific verb and resource: "List the built-in market surface renderer types," plus the payload detail ("with data schemas and examples"). The resource 'renderer types' is distinct from the other problee_discover_* siblings, though the description never explicitly contrasts itself with them.

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 routes agents by skill level: beginners should call problee_publish_market_surface, while problee_push_content is the advanced raw envelope path. That is clear contextual routing, but it frames the downstream publishing choice rather than stating when to call this catalog tool (e.g., before publishing) or when to skip it.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive safety. The description adds a key data-model convention: there is no closed enum and agents invent their own type values, which is not captured in structured fields.

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 sentences, front-loaded with the purpose and a critical convention. No filler or repetition; every sentence 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?

Output schema exists, so return values need not be explained, and annotations cover safety. The description is adequate for a zero-param discovery tool, though it could clarify when to invoke it relative to other discover_* 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?

Zero parameters, and schema coverage is trivially 100%. Per calibration, 0 params yields a baseline of 4. The description adds no parameter semantics because none exist.

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?

States a specific verb ('Describe') and resource ('resolutionSource envelope shape and conventions agents use'). The resource is distinct from sibling discover tools like events, market_data, renderers, and webhooks, so an agent can tell it apart without opening schemas.

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?

No explicit when-to-use or when-not-to-use guidance. The description states what the tool describes but does not name alternatives or conditions that select it over sibling discovery tools like problee_discover_events.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds content-level transparency (it tells you the doc's depth: algorithm, envelope shape, replay tolerance). It does not disclose anything further behavioral — versioning, whether it reflects live server config, or freshness — so a 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?

A single front-loaded sentence with a tight parenthetical enumeration; every clause earns its place and nothing is redundant or buried.

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 zero-parameter discovery/doc tool with an output schema present, the description need not explain return values, and it adequately conveys what the call yields. Minor gap: it doesn't note whether the returned scheme description is versioned or static.

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 tool takes zero parameters (empty object schema, 100% coverage), so per the rubric the baseline is 4. There are simply no parameters for the description to explain.

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?

Specific verb ("Describe") plus a precisely named resource ("the Standard Webhooks signing scheme") and an enumeration of exactly what the doc covers: headers, HMAC-SHA256, envelope shape, replay tolerance, and the url_verification handshake. An agent knows this returns webhook-signature documentation, not event listings. It does not explicitly distinguish itself from the sibling problee_list_webhook_event_types, so it falls short of a 5.

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?

"So a receiver can verify deliveries without reading source" clearly states the intended context: use this when implementing or validating a webhook receiver. That is a concrete usage cue. However, no when-not condition or explicit alternative (e.g., list_webhook_event_types for event payloads) is given.

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

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

Annotations cover safety (readOnly, idempotent, openWorld, non-destructive), and the description adds real behavioral depth beyond them: balances come from the lane the collateral settles on (committed ledger balance batched to Base vs onchain ERC-20 balanceOf), and values are raw integer strings in native decimals requiring division by 10^decimals.

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?

Three tight sentences, front-loaded with purpose then mechanics. The lane/decimals explanation is dense but each clause earns its place; no filler or repetition of the title.

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?

With an output schema present and annotations covering the safety profile, the description need only supply what structured fields omit, and it does: balance-source semantics, the default/all scope, and the decimals conversion caveat. Nothing essential for a correct call is missing.

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 nonetheless adds meaning the schema lacks, clarifying that a committed collateral is a venue-held ledger balance and an onchain one is an ERC-20 balanceOf, plus the decimal-string formatting of returned amounts.

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?

States a specific verb and resource ('Get collateral balances for a wallet') and immediately scopes it (PM by default, include="all" for every supported collateral). Distinguishable from the nearby list_collateral, which enumerates available collaterals rather than a wallet's balances.

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?

Explains the include default-vs-all condition and that chainId is optional only when a single chain is active, giving clear context for invocation. It stops short of naming an alternative sibling (e.g. get_positions) or stating when-not to use this tool, so it is clear but not fully routing.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: unauthenticated/free accounts get a degraded payload (5 markets, analyst average only, 1 headline) and a meta field that reports what was withheld. That truncation and metadata-signaling behavior is exactly the kind of trait annotations cannot express.

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?

Front-loaded with the payoff (all markets' research in one call) followed by the record shape, filters, paging, and the free-tier caveat; dense but every clause carries information. The trailing "Research, not financial advice" disclaimer is the only mild padding, and the long run-on sentence is harder to scan than it needs to be.

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?

With an output schema present, the description needn't explain return values, and it still covers scope, record contents, filtering axes, pagination, and authentication tiers. Nothing an agent needs to call this correctly is missing.

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 all seven parameters are already documented in the schema. The description restates the filter axes (segment, category, ids, all) and cursor paging without adding syntax, precedence rules, or format detail beyond it, so baseline 3 applies.

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?

States a specific verb and resource — fetching one compact research record per market — and enumerates exactly what each record contains (question, rules, chance, 24h move, headlines, analyst average/gap/reasons, top-trader lean). The scope phrase "Every market's research in one call" cleanly separates it from per-market siblings like problee_get_market_research and plain listing tools such as problee_list_markets.

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?

Gives concrete selection guidance: filter by segment, category or ids, or all, then page with cursor, and it states the access-tier condition for the free preview. It stops short of explicitly naming when to prefer a narrower sibling (e.g., single-market research), so it is strong context rather than full routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the bar is lower. The description still adds ordering ('newest first'), discoverability semantics (delta-only), and access-tier behavior for specific change types, which the annotations do not convey. It omits any rate-limit or polling-cadence guidance.

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?

Front-loaded with the core delta semantic and dense enough to cover categories, chaining, and tier gating in two sentences. Slightly clause-heavy with parentheticals, but nothing is wasted.

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?

With an output schema present, return shape need not be explained, and the description covers the key operational facts (delta semantics, chaining, ordering, tiers). Pagination via `cursor` is left to the schema, which is the main remaining gap for a 5-param tool.

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 is only 40% across 5 params. The description compensates for the critical `since` param by explaining chaining (use the previous answer's `until`) and effectively enumerates the `types` enum values as change categories. However, `ids`, `cursor`, and `segment` get no mention anywhere except partial schema text, leaving real gaps.

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?

States a specific verb (return only what changed) plus the exact resource scope: headlines, analyst views, price moves, market opens/closes, trader moves. The delta framing ('since your last call') cleanly distinguishes it from the sibling problee_get_context that returns full state.

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?

Gives explicit workflow guidance ('Call again with since = the answer's until') and flags tier gating ('API Pro' for trader moves, 'Plus and API Pro' at the end). It does not name the full-context alternative (problee_get_context) that a caller would use when they need a full snapshot, so routing is clear but not complete.

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

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

Far beyond what the annotations provide. It discloses engine-scoped approvals that drop out per settlement venue, that settlement-committed collaterals emit no approval (fills go on the commit ledger), that human identity is never chain-local periphery, and that addresses are UUPS/permanent. This is unusually rich operational context.

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 core purpose is front-loaded in the opening clause, but the remainder is a dense run-on covering approvals, settlement semantics, creator roles, and identity services. Much of it is useful, yet the lack of sentence breaks and mixed scope makes it harder to parse than it needs to be.

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?

An output schema exists, so return values need no explanation, and the description covers the behavioral complexity (approvals, settlement, permanence) thoroughly. It is complete for invocation, though the sprawl of tangential notes (identity service, cancel claims) dilutes rather than sharpens the essential guidance.

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% for both optional filters (chainId, collateral), so the schema already documents them fully. The description's 'per-chain' and 'per collateral' phrasing aligns with the filters but adds no format or syntax detail beyond the schema. Baseline 3 applies.

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 states a specific resource set: per-chain collateral addresses (MarketRouter proxies, OutcomeToken1155, factories) plus the one-time trading approvals. An agent can tell this apart from list_collateral or get_factory_config by content, though it never names those siblings to explicitly disambiguate.

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 concrete usage conditions: creator agents must pick a collateral with creation=true, cancellations and direct claims need no approval, and agents should verify against /trade/prepare or /trade/simulate rather than assuming permanence. It stops short of explicitly routing between this tool and sibling discovery endpoints.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: these are factory defaults read from live config and may not match a given market, which is a staleness/authority caveat not expressible in annotations.

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 sentences, front-loaded with the core purpose and followed by the actionable caveat. The parenthetical enumerations are dense but each carries distinct information about lane-specific fee behavior rather than filler.

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?

With an output schema present, return values need not be described, and the description supplies the one thing the schema cannot: that these are defaults needing per-market verification. Complete for a zero-parameter, well-annotated read tool.

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 tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter discussion and would gain nothing by doing so.

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 states a specific resource (canonical two-lane protocol fee schedule) and enumerates exactly what each lane covers (LMSR buy/sell+claim, ORDERBOOK place/taker fee/claim). It is clearly a read of factory-level fee defaults, though it never explicitly contrasts itself with the nearby problee_get_factory_config or problee_get_rules sibling.

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 concrete routing guidance: treat these as DEFAULTS and confirm the per-market value via tradingRules on market detail or fee on problee_get_quote before executing. That names the alternatives and the condition that selects them, though it does not state when this tool itself should be skipped entirely.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing on top of that: no mention of what the payload contains, whether the market must exist, or what happens for an unknown address.

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?

One sentence with zero padding, which is structurally clean. However, it is a verbatim restatement of the title, so the sentence does not really earn its place as a description.

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?

An output schema exists, so return values do not need explanation, but the description still omits the two things an agent needs here: how to supply/format 'address' and 'chainId', and how this differs from the many sibling market-read tools. Given the crowded sibling set, that is a real gap.

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% for two parameters, so the description is the only place that could explain them — and it says nothing. It does not specify the expected format of 'address' (hex? checksummed?) or what chainId defaulting behavior is, leaving a low-coverage schema entirely undocumented.

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?

Tautological: description restates name/title.

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 when-to-use guidance at all, no stated alternative, and no indication of when to pick this over list_markets or the other market-read siblings. The agent gets no routing signal beyond the name itself.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description usefully adds the window default (ALL) but says nothing about response shape, timezone/timestamp semantics, or what 'latest' frame means beyond the schema.

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 short sentences plus a one-line example, front-loaded with the core action and the window default. Slightly telegraphic ('price history + latest') but no wasted prose.

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?

An output schema exists, so return values need not be described. However, with a required address parameter and an undocumented chainId at 0% schema coverage, the definition leaves real gaps an agent must guess at before invoking.

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 is 0%, so the description carries the burden. It clarifies the window parameter's default and accepted values, but leaves address (the required param) and chainId entirely unexplained — no format hints (contract address vs. market id) or how chainId is resolved.

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?

States a specific verb (get) and resource (price history + latest frame for a market), which is clear enough to distinguish it from siblings like problee_get_market_trades or problee_get_market_depth. It stops short of explicitly naming what those siblings cover, so the differentiation must be inferred.

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 example ('Read the 1D price history for a market') and the window options imply how to use it, and the default (ALL) is stated. There is no explicit when-to-use vs. when-to-use-an-alternative guidance, e.g. charting vs. trade-by-trade retrieval.

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

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

Annotations already cover readOnly/idempotent/destructive/openWorld, so the bar is lower and the description still adds value: it distinguishes a simulated LMSR buy ladder from a live aggregated order-book snapshot and implies a point-in-time snapshot. It doesn't mention auth or rate-limit behavior, but the mode semantics are a genuine addition.

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 sentences, no waste, and the mode/discriminator detail is front-loaded before the routing hint to the sibling tool.

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?

An output schema exists, so return-value detail needn't be in the description; what's left — the two possible depth shapes and where to go for full depth — is exactly what an agent needs to call this 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 address/chainId semantics are already fully documented and the description adds nothing about them. The `kind` discriminator it mentions refers to the response shape rather than an input, so param-level value is baseline.

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?

States a specific verb+resource (market depth, 5 levels) and names the two modes it can return, discriminated by `kind`. It explicitly situates itself against the sibling problee_get_orderbook, so an agent can tell them apart without opening either 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?

Frames itself as the 'discovery-sized view' and routes full-depth consumers to problee_get_orderbook, which is clear context. It doesn't state an explicit when-not condition (e.g. when depth beyond 5 levels is unnecessary), but the alternative routing is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered and the description does not contradict it. However, the description adds no behavioral context beyond annotations (no cost of chain probing, no aggregation/caching behavior, no failure modes), so it is adequate rather than additive.

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?

A single sentence with the purpose front-loaded and zero filler; every clause maps to a returned metric. It is efficient, though the compressed colon-list format is more enumeration than structured guidance.

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?

With a full output schema, 100% parameter description coverage, and annotations covering the safety profile, the description supplies enough for an agent to call this read-only analytics tool correctly. The remaining gap is usage/routing context, which is a sibling-selection concern rather than a calling concern.

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% and both parameters (address, chainId, including the 'probes enabled chains if omitted' fallback) are documented in the schema. The description's only extra hint is 'per outcome' grouping, which is marginal, so the baseline 3 applies since the schema does the heavy lifting.

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?

States a specific resource (market holder distribution) and enumerates exactly what is returned: distinct holders, verified-human count, whale count, and total shares per outcome (open interest). This distinguishes it from data-oriented siblings like get_market_state or get_market_depth by content, but it never names an alternative, so it stops short of explicit sibling differentiation.

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 when-to-use, when-not-to-use, or alternative routing guidance; the agent must infer relevance purely from the metric list. No prerequisites are stated either (e.g., that chainId probing may be needed), so the definition leaves selection entirely to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the 7-day lookback, newest-first ordering, and the hard limitation that only titles and links are returned (no article body).

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?

A single dense sentence, front-loaded with the resource and window before the returned-field list. The enumeration of fields is slightly verbose, but every element conveys something the caller needs, and there is no filler.

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 read-only lookup with full annotations and an output schema, the description is nearly complete: it covers scope, window, ordering, and the titles-and-links-only constraint. The gap is the undocumented chainId parameter and the absence of any sibling routing hint.

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 is only 50%: address is documented in the schema but chainId has no description anywhere. The description says nothing about either parameter, so it fails to compensate for the undocumented chainId, which an agent cannot confidently supply.

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?

States a specific verb and resource: reading a market's recent news headlines, with the time window (last 7 days) and ordering (newest first). It is immediately distinguishable from most siblings, though it never names the closest alternative, problee_get_market_research, which an agent may confuse it with.

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 explicit when-to-use guidance, no prerequisites, and no named alternative. 'Research, not advice' is a scope disclaimer rather than routing guidance, so the agent must infer that this is the news-lookup tool versus get_market_research or get_market.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful content context (dated, sourced, AI-authored) and a 'not advice' disclaimer, but says nothing about volume, pagination, or freshness beyond 'dated'.

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 compact sentences with the resource and scope front-loaded and zero filler. Every clause 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?

An output schema exists, so return values need not be described, and annotations cover the safety semantics. The description is nearly complete, lacking only differentiation from sibling retrieval tools and clarification of the undocumented chainId parameter.

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 is only 50%: 'address' is documented, but 'chainId' carries no schema description. The description adds no meaning for either parameter and never explains how chainId interacts with the market lookup, so it fails to compensate for the coverage gap.

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?

States a specific verb+resource: reading 'dated research, sources and published AI analyst takes' for a binary market. It clearly signals a research-retrieval tool, but does not explicitly differentiate itself from the close sibling problee_get_market_news or explain what 'AI analyst takes' contains versus news.

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?

Gives situational context ('for a binary market' and 'Research, not advice') but offers no when-to-use versus alternatives, no prerequisites, and no pointer to sibling tools like problee_get_market_news. The agent must infer when this is the right call.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavior: action details are conditionally present depending on whether their 'public surface' is available, warning the agent not to expect those fields every time. It stops short of describing error cases (unknown address, unsupported chain).

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 with the payload contents front-loaded; no filler. The phrases 'public surface' and 'public resolution state' are mildly jargon-y and require interpretation, which keeps it just below a 5.

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?

An output schema exists, so the description need not explain return values, and annotations cover the safety profile. The remaining gap is sibling differentiation against get_market_state, which matters given 30+ sibling getters.

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 is 100% and both parameters (address, chainId) are documented in the schema, including the chain-probing fallback when chainId is omitted. The description adds no syntax, default, or format detail beyond that, so baseline 3 applies.

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 names the resource precisely and enumerates the returned surface: stage, reason, deadlines, action flags, and final outcome. It never distinguishes itself from the closely named sibling problee_get_market_state, so an agent could plausibly pick either for market status questions.

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 when-to-use or when-not-to-use guidance, and no alternative is named despite at least two overlapping siblings (get_market_state, list_pending_resolution_markets). The agent must infer the use case purely from the field list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without the description. The description adds nothing behavioral beyond the annotations -- no note on whether state is cached, how fresh the deadline/trading-end values are, or any latency/auth caveats. It only enumerates return fields, which the output schema already provides.

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?

One short sentence with zero filler and the key information front-loaded. It is appropriately sized for the tool, though the bare field list style leaves it feeling more like a schema echo than an orientation sentence.

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?

An output schema exists, so return values need not be re-explained, but the description still omits parameter guidance in the face of 0% schema coverage and gives no basis for choosing this tool over the several sibling market-state/read tools. For a tool in a crowded family, this is too thin to route an agent reliably.

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% for both parameters, so the description should carry the burden of explaining marketAddress and chainId. It mentions neither: there is no indication of the identifier format, or that chainId is optional and what the default chain is. The description therefore leaves the parameters entirely undocumented.

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 gives a clear verb ("Get") and names the specific state fields returned (marketState, lifecycleStage, stageDeadline, tradingEndsAt, outcome), which conveys the resource's nature. However, it reads as a field dump rather than a purpose statement and does nothing to distinguish it from near-neighbors like problee_get_market or problee_get_market_resolution_state, which an agent could easily confuse it with.

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 when-to-use guidance, no condition under which this tool is preferred, and no mention of the overlapping siblings (get_market, get_market_resolution_state) that would be the natural alternatives. The agent is left to infer the choice entirely.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the newest-first ordering, which is genuine behavioral context, but it adds nothing about pagination, the limit default/cap, or chainId probing behavior.

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?

A single tight sentence with the scoping key ('for a market') front-loaded. Its only inefficiency is enumerating return fields that the output schema already documents.

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?

An output schema exists, so return-value detail is redundant rather than necessary, and annotations cover safety. What is missing is paging/limit behavior and how this trade feed relates to the sibling fill/chart tools, which is material for a market-data query.

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 is 67%: address and chainId carry inline descriptions while limit has only a default/min/max. The description adds no parameter semantics (e.g., what limit does or how chainId omission is resolved), so it does not compensate for the uncovered parameter.

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?

States a specific verb+resource ('Recent trades for a market') and characterizes the return payload (side, size in wei, post-trade price, trader wallet). It does not distinguish itself from near siblings like list_trade_fills or get_market_chart, so a 4 rather than a 5.

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 offers no when-to-use guidance and names no alternative. It never explains the relationship to list_trade_fills (individual fills vs. trades) or get_market_chart, leaving the agent to infer routing on its own.

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

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

Annotations already declare the read-only/idempotent profile, and the description goes well beyond them: it discloses the two-tier finality model, that provisional rows fold mined-receipt trades immediately, that finalized is the only settlement truth (~20-24 min lag on Base), and that provisional updates affect share balances only while cost-basis and aggregates stay finalized-tier. That is exactly the kind of non-obvious behavioral context an agent needs.

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?

Front-loaded with the core purpose, then progressively adds valuation and finality detail. Dense but every sentence carries distinct information; only the parenthetical "0-1 scale"/units repetition slightly pads.

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?

An output schema exists so return values need not be restated, and the description covers finality semantics and valuation opt-in thoroughly. The remaining gap is that half the input parameters (pagination and filtering) are unexplained for a tool whose schema documents almost nothing.

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 is only 17%, so the description must compensate. It does explain include="valuation" and the semantics of the returned valuation fields, but limit, cursor, chainId, marketAddress, and walletAddress remain undocumented in both schema and description. Partial compensation, not full.

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?

States a specific verb+resource ("Get token positions for a wallet address") and enumerates the concrete payload it returns: share balances, cost-basis ledger, per-outcome cost basis, and sell-realized P&L. This is clearly distinguishable from wallet-level siblings like problee_get_balance.

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?

Usage is implied through the include="valuation" opt-in and the finality-tier explanation, which tells the agent when provisional rows are useful. However, it never names alternatives (e.g., get_balance, list_trade_fills) or states when NOT to use this tool, so routing guidance is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is fully covered. The description adds useful scoping by calling the content 'canonical public protocol facts' (i.e., static reference data rather than live market state), but discloses nothing about freshness, versioning, or how the payload relates to the action flags it points to.

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 with no filler; the topic enumeration is front-loaded. The second sentence about where actions live is a genuine routing hint rather than padding, though it could be folded more economically.

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?

With an output schema present, return values need no explanation, and a zero-parameter read-only tool has a light burden. The description is adequate, though it would be stronger if it explicitly distinguished this global rules reference from the capability catalogue and per-market action flags it references.

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 tool takes zero parameters and schema coverage is trivially 100%, so the baseline is 4. There is no parameter semantics for the description to add meaning to.

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 names a specific resource (canonical protocol rules) and enumerates concrete topic areas: resolution timing, final review, bonds, fund flows, actor conditions. An agent can distinguish this static reference endpoint from market-specific siblings like problee_get_market or problee_get_market_resolution_state, though it never explicitly says 'static/reference' to contrast with per-market tools.

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 routes the agent elsewhere for actions ('listed in the capability catalogue and each market's action flags'), which is a partial alternative pointer, but there is no explicit when-to-call framing for the rules themselves and no stated prerequisites or exclusions relative to the many sibling get_* tools.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description meaningfully adds "Unauthenticated" (an auth requirement not captured by annotations) and pins the return precision to milliseconds.

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?

Three short sentences, front-loaded with the return value and unit, then the usage trigger, then the auth note. The trailing "Examples: Current server epoch ms" adds little but wastes only a few tokens.

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 no-argument utility with an output schema, annotations covering safety, and both unit and auth disclosed in the description, an agent has everything needed to call and interpret it. Nothing material is missing.

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?

Zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies; the epoch-ms detail usefully pins the return format even though it is not a parameter.

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?

States a specific verb (Return) and resource (protocol server wall-clock time) with explicit unit (Unix epoch milliseconds). No sibling tool overlaps this capability, so the agent can select it unambiguously.

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?

"Use before quoting to measure client clock skew" gives a concrete trigger condition for calling it. It doesn't name alternatives or exclusions, but no sibling performs this function, so the omission is minor.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful scope about what the manifest contains but does not disclose caching, update cadence, or lifecycle behavior beyond the annotations.

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 sentences, front-loaded with the verb and resource. The second sentence earns its place by scoping the tool against market-collateral discovery. No wasted clauses.

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 tool is simple (zero params, output schema present, annotations cover behavior). The description covers what is returned and what it is not, which is sufficient for correct invocation. Slightly more routing among siblings would push it higher, but it is complete for the tool's complexity.

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?

There are zero parameters, which establishes a baseline of 4. The description correctly implies the tool takes no inputs by framing it as a manifest retrieval. No evidence to justify deduction.

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 names a specific resource (participation-token release manifest) and enumerates what it returns: versioned profile, deployment evidence, stage, and distributor release IDs. It is clear what the tool does, and the closing sentence distinguishes it from market collateral discovery. However, it does not explicitly call out sibling get_* config tools, so it stops short of a 5.

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?

Usage is implied by the manifest/versioning framing, and one exclusion is given ('separate from live market collateral discovery'). There is no explicit when-to-call guidance or named alternative among the many siblings, so it remains at minimum-viable rather than strong.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavior the structured fields cannot convey: two result tiers, the ~20-24 min finality lag on Base, finality-fencing, and the guarantee that 'not_found' is never returned for a seen transaction so polling never regresses. This is exactly the kind of extra context that lifts it above the annotation baseline.

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?

It is front-loaded and the closing imperative ('Act on provisional; settle on finalized') earns its place, but the middle is dense with compressed jargon ('finality-fenced', 'carries the envelope itself') that adds parsing cost for a two-parameter lookup tool.

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?

An output schema exists, so return values need not be explained, and the description covers the tiering model, latency expectations, and the not_found semantics an agent needs to poll correctly. Nothing material is missing for correct invocation.

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 is 100% and both parameters (txHash, chainId) are fully documented in the schema, so the baseline of 3 applies. The description adds meaning about what the lookup returns but no syntax, format, or constraint detail beyond what the schema already provides.

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?

States a specific verb+resource ('Look up a submitted trade by transaction hash') and frames its role as 'the by-tx path for crash recovery', which implicitly distinguishes it from the list/market-oriented siblings like problee_list_trade_fills and problee_get_market_trades. It never names those alternatives explicitly, so the differentiation is inferred rather than stated.

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?

Gives clear situational guidance ('crash recovery') and a decision rule for the two result tiers ('Act on provisional; settle on finalized'). It does not, however, tell the agent when to prefer this tool over the trade-listing siblings, leaving that comparison to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the scope constraint (results are key/tier dependent), which is genuine extra context, but says nothing about rate limits, auth requirements, or whether the catalog is static or dynamic.

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?

A single sentence with the scope front-loaded and a tight clarifying parenthetical. Every clause earns its place and there is no redundancy or filler.

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?

With an output schema present and zero input parameters, the description need not explain return values, and it correctly focuses on scope. It is nearly complete, though it could note that this is a bootstrap/discovery call useful before invoking the other endpoints.

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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a no-parameter tool is 4; the parenthetical explaining that output is scoped to the current key is a small bonus but no schema semantics need compensating.

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?

States a specific verb ('List') and resource ('protocol capabilities') plus a scope qualifier ('available at the authenticated agent tier'), and the parenthetical clarifies that the payload is the endpoint catalog for the current key. It reads clearly against siblings like problee_list_chains or problee_list_markets, though it never explicitly contrasts itself with them.

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 tier scoping and 'for the current key' phrasing imply the usage context (discovering which endpoints your credential can reach), but the description never states when to call this versus the many other list/discover siblings, nor any prerequisites or exclusions. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, and the description adds nothing beyond that safety profile. It does not say whether the list is static or dynamic, whether it reflects the server's enabled networks, or whether the set is exhaustive/unfiltered — with annotations covering the basics, the description still contributes no extra behavioral context.

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?

A single short sentence, front-loaded with the verb and resource, with no filler or redundancy. Nothing could be trimmed without losing meaning.

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?

An output schema exists, so return values need not be explained, and a zero-parameter discovery tool has little else an agent needs. The only residual gap is whether the chains returned are the complete supported set or scoped to the current environment, which is minor for this tool's simplicity.

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 tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. Schema coverage is 100% (vacuously) and the empty input object matches the description's claim of listing all chains with no filtering.

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?

Clear verb+resource: 'List all supported blockchain networks' tells the agent exactly what it returns. It is distinguishable from siblings like problee_list_capabilities or problee_list_collateral by resource, though it never names or contrasts with any sibling explicitly.

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?

Usage is only implied: an agent would infer you call this to discover valid chain identifiers before calling chain-scoped tools such as problee_get_balance. There is no explicit when-to-use statement, no prerequisites, and no mention of alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the meaningful behavioral constraint that chainId becomes required when multiple chains are active, but says nothing about pagination, auth, or result size for an open-world listing.

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 short sentences, zero filler, with the returned-field list and the chainId condition front-loaded. Nothing could be removed without losing information.

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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. For a single-optional-parameter read tool the description covers the one non-obvious behavior; the only minor gap is the absence of any hint about how this relates to sibling chain/contract 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 description coverage is 100% and the single chainId parameter is documented identically in the schema ('Optional only when exactly one chain is active; required when multiple chains are active'). The description restates rather than extends that, so baseline 3 is correct.

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 states a specific verb and resource ('List public launch collateral tokens') and even enumerates the returned fields (symbol, address, decimals, chainId), so the agent knows exactly what this returns. It does not explicitly differentiate itself from near siblings like problee_list_chains or problee_get_contracts, which keeps it from a 5.

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 only usage guidance is the conditional rule for chainId ('optional only when exactly one chain is active'), which is invocation guidance rather than when-to-use guidance. It never says when to reach for this tool instead of problee_list_chains or problee_get_contracts, so selection is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by noting the bridged webhook equivalence and where connection details live, but does not go beyond that on side effects or limits. No contradiction with annotations.

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 tightly written sentences with zero filler, and the primary listing behavior is front-loaded ahead of the cross-reference.

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?

An output schema exists, so return values need not be spelled out, and the description is complete enough for a parameterless read tool. The only real gap is the unresolved distinction from the sibling problee_list_webhook_event_types.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4. The description correctly implies a parameterless full listing.

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?

States a specific verb (List) and resource (protocol WebSocket event types) plus the fields returned: description and webhook equivalent. It distinguishes itself from problee_discover_events, but does not differentiate from the closely-named sibling problee_list_webhook_event_types, leaving that boundary ambiguous.

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 points to problee_discover_events for full connection details, which gives a partial routing signal. However, it never states when to choose this tool over the very similar problee_list_webhook_event_types sibling, so usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the board is public/display-parity data, amounts may be unavailable, settledMarkets counts only confirmed non-void markets, and legacy RETURN yields null percentage fields.

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?

Five dense sentences that front-load the core purpose and then layer caveats; each clause carries real information. It is jargon-heavy and slightly list-like, but there is no filler sentence that could be cut.

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?

With 7 parameters, zero required, an output schema and full annotations, the description covers what matters: board identity, sort aliases, and result-shape caveats. Pagination, category and collateral are left to the schema, which is acceptable given their descriptions.

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 is 71% and the sort/period $defs are already richly documented, yet the description still adds value: RETURN aliases PNL with null return-percentage fields, RISK_ADJ_PNL is a legacy adapter, and CREATOR_QUALITY returns creators rather than traders. It does not address limit/offset/category/collateral, but those carry schema descriptions.

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?

States a specific resource (a ranked, public participant leaderboard showing 'the same data people see') and a specific verb via the tool name. It clearly differentiates from siblings like get_market_holders or list_markets by returning participant rankings, though it never explicitly says so.

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?

No statement of when to reach for this tool versus alternatives, and no prerequisites or exclusions. The sort/period discussion reads as parameter semantics rather than usage guidance; the agent must infer that this is the canonical read for participant rankings.

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

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

Annotations already declare readOnly/ idempotent/ non-destructive, so the safety bar is low. The description adds genuine behavioral context beyond them: ordering ('newest first') and the 'black-box reputation tier' plus frozen-at-write pricing semantics of the payload.

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?

A single front-loaded sentence begins with the core action, and every element earns its place. It is dense with stacked parentheticals, slightly straining readability, but not verbose.

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?

An output schema exists, so return values need not be explained. The description covers purpose, ordering, and payload semantics adequately for a read-only list tool; only auth/permission prerequisites are unaddressed, which matters little for a read call.

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 is 67%; cursor and address carry descriptions, while limit is defined only by numeric bounds. The description adds no parameter-level meaning (the field list it gives refers to response content, not inputs), so it does not compensate for the gap. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Read human comments on a market') and enumerates the returned content (body, timestamps, wallet, reputation tier, position, frozen prices). It is clearly distinguishable from sibling list tools like problee_list_market_trades or problee_get_market_holders.

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 closing phrase 'for trade decisions' implies the intended use case, giving implied usage guidance. However, it never states when to prefer this over alternatives such as reading trades or holders, and names no exclusions or prerequisites.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description goes beyond them by explaining the relationship between the returned `marketState`, derived `lifecycleStage`, and `stageDeadline`, and by telling the agent which field to prefer — genuine behavioral guidance. It omits pagination/auth/rate-limit behavior, so not a 5.

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 short blocks with the purpose front-loaded and a concrete example appended. Every sentence earns its place, though the em-dash field-preference sentence is slightly dense and could be split.

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?

An output schema exists, so return values need no explanation, and the description still adds useful field-interpretation guidance. With 11 optional filters, it says nothing about how filters combine or about the cursor-only-applies-to-`new` pagination caveat (schema-only), which keeps it short of a 5.

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 73%; most filters (sort, cursor, search, creator, pricingModel, sourceTokenId/ConditionId) are richly documented in the schema itself, while chainId, category, and pageSize carry none. The description adds no parameter-level meaning beyond the schema, so the adequate-but-minimal baseline applies.

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?

States a specific verb and resource ('List prediction markets on Kellian') and the title confirms pagination. It does not distinguish itself from siblings like problee_list_pending_resolution_markets or problee_list_related_markets, but the general-purpose listing role is unambiguous.

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 single example ('List live CRYPTO markets on Base') implies when the tool is useful, and the hint to prefer lifecycleStage for 'deciding what is possible right now' implies an intent. There is no explicit when-not guidance or named alternative such as problee_get_market for a single market.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds only the scoping phrase 'canonical resolution pipeline' and mentions cursor/limit implicitly, but says nothing about default page size behavior or result ordering beyond what the schema states. With annotations carrying the behavioral load, a 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?

Two short sentences, front-loaded with the purpose before the parameter list. Nothing is wasted, though the parameter enumeration is arguably redundant given the schema.

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?

An output schema exists so return values need not be explained, and pagination is schema-documented. Still, for a filtered list tool sitting among many similar list/state endpoints, the description omits which resolution states belong to the 'pipeline' and how it differs from problee_list_markets, leaving a real selection gap.

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%: enums (category, marketState), the cursor's opaque semantics, and the 1–100 default-50 limit are all documented in the schema. The description merely echoes the parameter names ('optional category, marketState, cursor, and limit') without adding meaning, so the baseline 3 applies.

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?

States a specific verb and resource ('List markets') scoped to 'the canonical resolution pipeline', which separates it from the generic problee_list_markets to a degree. However, it never names the sibling it is not, and 'pending resolution' in the tool name versus 'canonical resolution pipeline' in the description leaves ambiguity about whether resolved/void markets are included.

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 only enumerates available filters; it gives no when-to-use guidance and never contrasts this tool with the very similar problee_list_markets or problee_get_market_resolution_state siblings. An agent must guess which listing endpoint fits the task.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, covering the safety and idempotency profile. The description adds only 'canonical discovery set', with no mention of pagination, result ordering, or behavior when no related markets exist; an output schema exists, so return-shape disclosure is not required.

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 short sentences, scope front-loaded in the first. Both sentences carry information (scope, then usage), though the second is vague enough to be of limited value.

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?

With a rich schema, full annotations and an output schema present, the definition covers the essentials for a read-only discovery tool. The one gap is not clarifying its relationship to the broader problee_list_markets sibling.

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 address, chainId and limit are already fully documented with bounds and patterns. The description adds no parameter semantics beyond what the schema provides, which is the expected baseline.

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?

States a specific verb (List) and resource (related markets) with the scoping constraint 'same category and chain' and labels it the 'canonical discovery set'. However, it does not differentiate itself from the very similar sibling problee_list_markets, leaving the agent to infer when this narrower discovery set is preferable.

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 phrase 'Useful for context around a market before trading or creating' implies a usage context but gives no explicit when/when-not and names no alternative tool. It is implied guidance rather than routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial context beyond them: the two-tier provisional/finalized model, that provisional fills never appear on cursor pages, ingest freshness (~1.52s), and txHash null with pending publicationState until batch publication. This is exactly the behavioral detail an agent needs.

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 purpose and ordering are front-loaded, and the density is largely justified by the tool's complexity. Some material (exact ingest latency figures, txHash lifecycle) is more operational detail than a selector needs, so it is not maximally tight.

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 an output schema already defines return values, the description covers everything else an agent needs: pagination semantics, finality tiers, and publication state. Nothing required to call it correctly is missing.

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 is 100%, so the schema already documents limit, cursor, chainId, and walletAddress; baseline 3 applies. The description only lightly enriches cursor semantics ('keyset cursor on (timestamp,id)') and adds no format details beyond the schema.

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?

States a specific verb and resource ('List a wallet's fills') with the scope ('for history and P&L') and ordering ('newest first; keyset cursor'). It implicitly distinguishes itself from the market-level sibling problee_get_market_trades by scoping to a single wallet, so an agent can route correctly.

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?

Gives clear context for use (history and P&L) and names an alternative for a distinct need: replay private order lifecycle gaps through problee_list_order_events / POST /orderbook/events. It lacks an explicit when-not-to-use versus the market-trades sibling, so it falls short of 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint. The description adds that results include payload shape hints, walletFilters matching field, and bridged source event—useful behavioral context about returned data beyond safety annotations.

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?

Single sentence, front-loaded with the core action and then the returned data. No filler or repetition.

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?

With no parameters, an output schema, and annotations covering safety profile, the description supplies enough context (what the list contains) for an agent to invoke and interpret the tool. Nothing essential is missing.

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?

Zero parameters, so baseline 4. Schema and description have no parameters to document; the description does not need to compensate.

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?

States a specific verb ('List') and resource ('event types agents can subscribe a webhook to'), and enumerates return contents (payload shape hints, walletFilters, source realtime/WebSocket event). It does not explicitly differentiate from sibling problee_list_event_types or problee_discover_webhooks, so 4.

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?

No explicit when-to-use or alternatives; usage is implied by the purpose (discovering webhook event types). Sibling tools like problee_list_event_types and problee_discover_webhooks are not mentioned, leaving the agent to infer selection.

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