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, openWorld, idempotent, and non-destructive, so safety is covered. The description adds genuine context beyond that: it is a descriptive metadata call (channel catalog, client/server message shapes) and it clarifies the boundary that execution-authoritative data comes from other tools. Rate limits and output format are not mentioned, keeping it below 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?

The purpose is front-loaded in the opening clause, and the second sentence adds a meaningful scope boundary. The middle enumeration is dense but each listed lane earns its place; it is slightly long but not padded.

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 explained, and the description adequately covers what the tool exposes and where it sits relative to execution tools. Given zero params and rich annotations, this is nearly complete; only the absence of explicit usage routing keeps it from 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a no-argument discovery call and does not introduce any misleading parameter expectations.

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 verb ('Describe') and resource ('canonical market-data lanes for agents'), then enumerates exactly which lanes are covered: public WebSocket, REST snapshot/quote/orderbook, consumer SSE, and control-plane WebSocket. It is clearly distinguishable from the discover_* siblings by its market-data-lane scope, though it never names a 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?

The closing sentence implies usage: quote and order-book tool calls are 'the execution-authoritative path,' so this tool is for understanding the realtime/display lanes rather than fetching data. That is useful implied routing, but there is no explicit 'use this when / not when' statement or named alternative.

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 already declare readOnly/idempotent/non-destructive, but the description adds genuinely useful behavior: each balance is sourced from the lane the collateral settles on, distinguishing committed ledger balances from onchain ERC-20 balanceOf, and that values are raw integer strings requiring 10^decimals scaling. It doesn't cover auth needs or rate limits, 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?

Three sentences that are front-loaded with scope, then the data-source explanation, then the format caveat; each earns its place. The middle clause is dense but not 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?

An output schema exists and annotations cover the safety profile, so the description only needs to carry the sourcing and formatting context, which it does. Nothing an agent needs 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 chainId, include, and walletAddress descriptions already carry the semantics and the baseline is 3. The description restates the include behavior but adds no parameter-level detail the schema lacks (the decimals note describes output values, not parameters).

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 (collateral balances) scoped to a wallet, and clarifies the PM-default vs include=all scope. It never names a sibling like get_positions or list_collateral, so the agent gets no explicit routing signal, keeping it 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?

The description explains the default/all semantics and that chainId is needed only when multiple chains are active, which implies usage context. It gives no when-not guidance and doesn't contrast with get_positions or list_collateral, 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?

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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral traits — no note on caching, freshness, or whether 'release-bound' config can change between calls — so it stays at an adequate-but-minimal 3.

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 filler. The content enumeration comes first and the trigger condition is second, so the agent gets payload and timing up front.

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 both optional parameters are documented in the schema. The description is nearly complete for a low-complexity read tool; only the interaction between factoryType and the returned config is left implicit.

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%: chainId's conditional requirement and factoryType's enum/default are fully documented in the schema. The description says nothing about either parameter, 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 ('Get the ... factory configuration') and enumerates the contents the caller receives: collaterals with seed/buy minimums, creator lock, duration limits, and fees. This lets an agent separate it from neighbours like problee_list_collateral and problee_get_fees without opening a 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?

Explicitly names the moment to call it: 'Use this before creating markets to know protocol constraints.' That gives clear context, though it offers no exclusions or named alternative for related questions such as fee lookups.

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 beyond that: no mention of what 'detailed information' comprises, whether an unknown address errors, or how chainId affects the lookup.

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 a single short sentence, but brevity here is under-specification rather than conciseness. The one sentence merely duplicates the title and earns no place in an agent's decision-making.

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, but the description still omits the identifier semantics, chain scoping, and differentiation from sibling getters. For a tool sitting in a large family of overlapping market tools, this is inadequate.

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 (address, chainId), and the description does not compensate at all. It never says what 'address' identifies (market contract address?) or that chainId scopes the lookup across chains, leaving both 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?

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 guidance on when to use this tool versus the many sibling market-inspection tools. No prerequisites, no alternatives, no exclusions are 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, 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 (readOnly, idempotent, openWorld, non-destructive) already establish the safety and idempotency profile, so the bar is lower. The description adds the shape of the returned state, notably the conditional presence of a dispute or a human-vote session and the available-action flags. It says nothing about authentication, rate limits, or failure modes, and much of the payload detail overlaps the output schema, so this is a modest rather than rich 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 dense sentences with zero filler: the resource and its contents come first, and the sibling comparison closes it out. Every clause carries 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 re-explained, and annotations cover the safety profile. The description supplies the one thing structured fields cannot: how this differs from problee_get_market_state. A brief note on chainId-omitted behavior would make it fully complete.

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% with only two parameters, so the schema already carries address format and the chainId probing behavior. The description adds no parameter-level meaning (e.g., cross-chain lookup semantics when chainId is omitted), which is the expected baseline-3 outcome when 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 (per-market public resolution state) and enumerates the concrete contents: stage, reason, deadlines, action flags, in-progress dispute, and open human-vote session. It also explicitly separates itself from problee_get_market_state, so an agent can choose between the two 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?

The final clause gives a clear selection rule against the nearest sibling: use this for the richer resolution-pipeline view when the bare marketState enum is insufficient. It is strong comparative guidance, though it never states exclusions or when the lighter sibling is actually the better choice.

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 nothing beyond that: no statement about freshness, caching, what 'state evidence' contains, or whether the data is chain-specific. It neither contradicts nor enriches 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?

A single short sentence with no filler and the key noun phrase front-loaded after the verb. It is efficient, but the brevity is under-specification rather than disciplined concision, so it is only adequate.

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 not required. Still, for a tool whose name collides with several siblings and whose chainId parameter is undocumented, the definition leaves the agent without enough to call it correctly or prefer it over alternatives.

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. The description implies the market is identified by address but never explains the marketAddress format, and the chainId parameter is completely unaddressed — including whether it is required, defaults, or how it interacts with the address. The description does not compensate for the schema 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 verb (get) and a resource (canonical market state plus state evidence), so the basic intent is legible. However, 'state' is left undefined, and among siblings like problee_get_market_resolution_state, problee_get_market_chart, and problee_get_market_depth there is no hint which notion of 'state' this returns. An agent cannot confidently separate it from the resolution-state tool.

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 context, no exclusions, and names no alternative. With three or more sibling market-state tools, the agent is left to guess which one to call. 'Canonical' is the only implicit signal and it is not operationalized.

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 only cover the safety profile (readOnly/idempotent/no-destroy), so the description carries the behavioral burden and does so well: it discloses the two-tier finality model, that provisional rows appear seconds after inclusion, that finalized rows are ~20-24 min behind head and are the only settlement truth, and that provisional rows move balances only while cost-basis/aggregates stay finalized-tier.

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?

Dense but front-loaded: the core purpose and the valuation opt-in come first, then the finality semantics. Every sentence carries load, though the finality paragraph is packed tightly enough to reward slow reading.

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 raw return shapes need not be re-explained, yet the description still supplies the field-level semantics an agent needs (units, 0-1 price scale, finality column, provisional vs finalized columns). The only material gap is pagination behavior via limit/cursor.

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 add real meaning for the highlighted parameter (include="valuation" toggles currentPrices 0-1 and markValue) and clarifies the units of totalSpent/totalReceived/cost basis. It still leaves limit, cursor, chainId and marketAddress semantically undocumented, keeping it short of a 5.

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?

Opens with a specific verb+resource ('Get token positions for a wallet address') and immediately scopes the content: share balances plus cost-basis ledger fields. It distinguishes itself from the sibling list (e.g. problee_get_balance, problee_get_market_holders) by naming the ledger and valuation layers rather than a generic balance read.

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 tells the agent how to opt into valuation (include="valuation") and warns that mark prices may lag the chain, which is genuine usage guidance. However, it never states when to use this tool versus a sibling like problee_get_balance or problee_get_market_holders, so alternative 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds real value beyond them by declaring the deliberate scope limits: council decision heuristics and internal lifecycle enums are intentionally withheld, which tells the agent what it cannot learn here.

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 content enumeration first and the exclusion caveat second. Every clause is informative; the long item list is dense but each entry earns its place by naming a distinct rule family.

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 need not document return values, and for a zero-param reference endpoint that is sufficient. It communicates both what is covered and what is out of scope, leaving only minor gaps such as caching or refresh behavior.

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 the baseline is 4. There is nothing for the description to clarify about inputs, and none is needed.

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 (canonical public protocol rules) and enumerates the specific content returned: resolution windows, human-vote timing, council review interface, bonds, fund flows, and actor actions. It is distinguishable from config-style siblings like get_factory_config or get_fees, though it does not name those siblings 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 implied — this is the reference/constants lookup for protocol timing and economics — but there is no explicit when-to-use or when-to-prefer-an-alternative guidance. The only boundary given is an exclusion list ('deliberately not exposed'), which helps scope but is not a routing rule.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real non-obvious behavior: legacy RETURN aliases PNL with null return-percentage fields and no calculated return, amounts may be unavailable, settledMarkets counts only confirmed non-void traded markets, and reputation tier is deliberately black-box. Pagination/window edge behavior is left to the schema, keeping this short of 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?

A single dense paragraph, front-loaded with what the board is and then the sort-mode quirks in priority order. Every clause carries information, though the run-on style around legacy sorts and settledMarkets makes it harder to scan than a short list would.

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-shape explanation is correctly omitted, and the description supplies the quirks an agent needs (aliases, null fields, legacy adapter, black-box tier). Pagination and period/collateral interaction remain unaddressed, which is the main residual gap for a 7-parameter 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?

With 71% schema coverage the description still adds meaning: sort alias/legacy rules and board-to-entity mapping, the settledMarkets counting semantics, and period window intent. It omits limit, offset, generation, and collateral guidance, which the schema partially carries, so it complements rather than fully compensates.

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?

Opens with a specific verb+resource ('Ranked public leaderboard') and immediately enumerates the three distinct entity boards (traders via PNL/VOLUME, creators via CREATOR_QUALITY, voters via VOTERS), which no sibling tool provides. An agent can tell exactly what this returns and which sort values switch the resource type.

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 sort-mode breakdown — pick RETURN/PNL/VOLUME for traders, CREATOR_QUALITY for creators, VOTERS for voters — but there is no explicit when-to-use statement, no exclusion, and no named alternative. Sibling tools are all market/discovery oriented, so no routing conflict, but the description never says so.

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 declare this as a safe, idempotent, read-only, open-world read. The description adds some useful semantic context about the shape of returned data (canonical marketState vs. derived lifecycleStage/stageDeadline), but says nothing about pagination limits, cursor reuse, or result-emptiness behavior, which is where the real opaqueness lies for a 9-parameter list endpoint.

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 purpose followed by one dense field-semantics sentence and a short example; no padding. The backtick-heavy middle sentence is somewhat hard to parse but every clause carries 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 re-explained, and annotations cover the safety profile. However, for a 9-parameter paginated list with partial schema coverage, the description leaves pagination mechanics and several filters undescribed, making it only minimally complete.

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% and the description documents no input parameters at all — the only fields it names (marketState, lifecycleStage, stageDeadline) are outputs, not filters. It therefore fails to compensate for undocumented parameters such as chainId and pageSize, leaving that burden entirely on 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?

The description opens with a specific verb and resource ("List prediction markets on Problee") and the title adds the pagination/active scope, so the agent knows exactly what the tool returns. It does not, however, distinguish this tool from close siblings like problee_list_related_markets or problee_list_pending_resolution_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?

Usage is conveyed only by example ("List live CRYPTO markets on Base") and by a field-selection hint ("prefer lifecycleStage for display"). There is no explicit when-to-use / when-not-to-use statement and no reference to alternative list tools, so the guidance is implied 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=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.