The Undesirables TCG Oracle

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

With no annotations, the description is the only disclosure source, and it is thorough: it advertises that the call is FREE, lists the full returned object, explains grade ranges (A+..F), calls out the momentum grade 'NA' on a drift spike, and notes that card_name is resolved to the best match. This goes well beyond the minimal 'returns a forecast'.

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 main action is in the first sentence, and every following sentence adds operational value: free status, return schema, concrete user queries, and an alternative route to market-level data. The dense field list is justified because there is no output schema to carry that 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?

The definition covers what the tool does, the two input modes, the complete output surface, representative example questions, and a sibling alternative for market overview. Since there is no output schema, the thorough return-field enumeration is essential and is provided.

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%, so the description must supply meaning. It does: card_name is 'resolved to the best match' and product_id is a TCGplayer product_id, and it frames them as alternatives ('Pass either... or...'). It lacks explicit guidance on precedence or behavior if both are supplied, which keeps it from 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?

The opening sentence names a specific verb ('Get'), a precise resource ('conformal-calibrated 30-day price forecast AND letter grades'), and scopes it to 'a single card.' The field list and 'single card' wording distinguish it from broader sibling tools like market_snapshot or sports_board.

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 explicitly states 'Use this when a user asks...' with concrete example questions, which tells an agent exactly when to select this tool. It also provides a clear alternative: the no-arg GET /api/v1/forecast for a market overview, so the agent knows what not to use this tool for.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the dashboard is public and free ('FREE — no payment required'), and 'View' implies a read-only operation. However, it does not explicitly state whether there are side effects, authentication requirements, or any limitations on usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loads the core action before listing the dashboard contents. The 'Use this when' section is a helpful structural cue, though 'FREE — no payment required' is slightly redundant since 'FREE' already communicates the same idea.

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 simple read-only dashboard tool, the description covers purpose, content, and usage triggers reasonably well. However, it is incomplete because the 'game' parameter is entirely unexplained, and there is no explicit statement about output format or whether the parameter is a filter.

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% and the description never mentions the 'game' parameter. The only parameter is an optional string with a default value, leaving agents with no guidance on what valid values look like, whether it filters the dashboard, or how it affects results. The description completely fails to compensate for the lack of schema-level documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'View TCG Oracle's public prediction accuracy dashboard' and lists the specific content it shows, including mean absolute error, hit rates, grade distribution, and recent prediction reports. This goes beyond a vague verb and resource, though it does not explicitly differentiate itself from sibling tools like oracle_scorecard.

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 gives explicit trigger scenarios: use when a user asks 'how accurate is the grading AI?' or wants to verify the model's track record. This is clear when-to-use guidance, but it does not mention when not to use the tool or suggest alternative tools, so it misses the full explicitness required for a 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?

With no annotations provided, the description carries the full behavioral burden and does so well. It explains the no-token_id feed behavior, the with-token_id soul card behavior, the sealed-soul 404 edge case, and the underlying merkle-commit and scoring 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 description is somewhat long but well-structured: key context, then parameter-dependent behavior, then explicit usage guidance. Each section earns its place; no redundant 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?

Given there is no output schema and no annotations, the description is remarkably complete. It covers both invocation modes, error behavior, data source, the feed contents, the per-soul card contents, and a human-readable reference URL, so an agent can select and call the tool 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 0%, so the description must explain token_id, and it does thoroughly. It defines the default/no-token_id case, the valid 1..minted range, and the 404 behavior for sealed souls, far exceeding what the bare schema 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?

The description clearly identifies the resource (the Undesirables fantasy league) and explains the two output modes: a league-wide feed or an individual soul's card depending on token_id. It is easy to understand what the tool does, but it does not explicitly differentiate from sibling tools by name.

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 includes a direct 'Use this when' section, listing concrete agent intents that route to this tool. It provides clear context for when to invoke it, though it does not mention exclusions or alternative sibling tools.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the 3-stage pipeline, the return values, the paid $0.10 fee, and the accepted payment rails. It does not mention failure modes, image format requirements, or latency, but it is substantially transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by pipeline details, outputs, pricing, and usage. Some details such as the audit reference and exact chain addresses are slightly extraneous, but the organization remains readable and purposeful.

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 the absence of an output schema, the description adequately describes the return values, payment cost, and settlement rails. The main gap is the unexplained `game` parameter, but the essential information an agent needs to select and invoke this tool correctly is present.

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%, and the input schema provides no property descriptions. While the description implies that `image_url` is a trading card image and that the grade relates to PSA/Beckett, it never explains the `game` parameter, acceptable values, or image URL constraints. The description only partially compensates for the missing schema documentation.

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: 'AI-grade a trading card image using a 3-stage pipeline.' It also clearly states the outputs, namely PSA/Beckett-calibrated subgrades and an overall condition score. However, it does not explicitly distinguish itself from the similarly named sibling tool `grade_or_not`.

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 includes an explicit 'Use this when' statement: a user has a card image and wants to know what grade it would receive from PSA or Beckett. This gives a clear triggering context, though it does not provide when-not-to-use guidance or name 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?

With no annotations provided, the description carries the burden of explaining behavior. It discloses that the call is paid ($0.10 USDC), combines several data sources, and returns a verdict with profit ranges. It does not mention side effects or assumptions, but this appears to be a read-only analytical tool and the main behavioral traits are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, well-structured, and front-loaded with the core question. Every section—answer, method, pricing, and usage guidance—adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the return concept (GO/NO-GO and profit scenarios), which matters because there is no output schema. However, missing parameter semantics and a lack of clarifying details about service tiers or currency/units leave meaningful gaps for an agent trying to call the tool 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 0%, so the description must compensate by explaining the four parameters. It indirectly references card, grading, price, and costs, but it never names raw_price, service_tier, or predicted_grade, nor clarifies their meaning, defaults, or how they affect the ROI calculation.

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: it answers whether to grade a card and calculates expected ROI. It also names the concrete output (GO/NO-GO verdict with best-case, predicted, and worst-case profit) and is clearly distinguishable from siblings like grade_card or market_snapshot.

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?

Explicit usage guidance is provided: 'Use this when: a user is deciding whether to submit a card for professional grading and wants to know if it's financially worth it.' It lacks explicit when-not-to-use or alternatives, so it does not fully earn a 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?

There are no annotations, so the description carries the burden. It discloses the free nature, the 404 behavior for out-of-scope cards, the pointer to the paid quote, the 'Informational only — not financial advice' caveat, and the transparency artifacts like merkle proof links. It does not explicitly declare read-only/no side effects or mention auth/rate limits, but the read-only intent is strongly implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well organized: coverage and derivation steps first, then failure behavior and paid alternative, then usage trigger and related URLs. A few phrases repeat the free/board concept, but every sentence adds relevant decision-making or invocation context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must convey return content, and it does: six derivation steps, price source, merkle proof links, and 404 behavior. It also provides the rated universe endpoint and a human page, giving an agent enough context to call the tool and recover when a card is outside the free board.

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%, so the description must compensate. It explicitly enumerates term_days as 7, 14 or 30, which is valuable. However, product_id is only implied to be the trading-card identifier on the free board; its format, source, or lookup is not directly explained, leaving a partial semantic 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?

The description states a specific, concrete behavior: a free worked derivation of safe lending terms for a trading card on the free board, including the exact derivation pipeline. It also clearly distinguishes itself from the paid /api/v1/loan-terms quote, so an agent knows this is the preview, not the full paid quote.

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 explicitly says 'Use this when: an agent wants collateral math for a card, or to explain how the Loan-Terms Oracle derives an LTV before paying for a full quote.' It also states the exclusion boundary clearly: cards off the free board return 404 and point to the paid quote endpoint.

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?

With no annotations present, the description carries the burden of behavioral disclosure. It transparently explains the tool is paid, the exact price, payment rails, and that it had previously been misdocumented as free, causing unbudgeted 402s. This is valuable beyond typical descriptions, though it does not discuss other operational traits like rate limits or output format.

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 key purpose is front-loaded in the first sentence, and the pricing and use-case notes are separated into concise blocks. The inclusion of audit and bug details adds length but is directly relevant to invoking the tool correctly. It is appropriately sized overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the high-level output (top movers, gainers/losers, volume leaders) and the essential cost/payment behavior, but leaves the `game` parameter semantics unexplained. Since there is no output schema and no mention of response structure, the picture is incomplete for an agent needing to call the tool 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?

The only parameter, `game`, has no description in the schema, and the description never explains or elaborates on what it does or how it affects the result. The phrase 'across all 25 supported card games' is ambiguous about whether `game` filters or is optional. The description adds no practical meaning to the 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?

The description clearly states the tool provides a 'Daily TCG market snapshot with top movers, biggest gainers/losers, and volume leaders across all 25 supported card games.' This is specific and understandable. It does not explicitly name or contrast sibling tools like `trending_cards` or `card_forecast`, so it does not fully achieve 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?

It gives explicit trigger contexts: 'Use this when: a user asks "what's trending in the card market?" or "what cards are going up/down in value?"' This is clear guidance, but it does not mention when not to use it or point to any specific alternative tool.

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?

With no annotations, the description carries the full burden, and it discloses important non-obvious behavior: the call is paid ($0.50 USDC), uses a specific financial method, and returns allocation weights, Sharpe ratios, and rebalancing recommendations. It does not mention edge-case behavior or data-source assumptions, but the core behavioral facts are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and every sentence adds distinct value: purpose, inputs/outputs, cost, and the decision trigger. It is front-loaded with the action and method, with 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?

For a complex paid optimization tool with no output schema, the description covers the purpose, required inputs, outputs, cost, and when to use it. The only notable omission is the meaning of the 'days' parameter and the accepted risk_tolerance vocabulary, which prevents it from being 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 0%, so the description must compensate. It explains 'cards' as comma-separated card names and mentions 'budget' and 'risk tolerance' as inputs. However, the 'days' parameter is never described, and valid risk-tolerance values are not enumerated, leaving a meaningful gap for correct invocation.

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 'Optimize' and a concrete resource: 'a trading card portfolio using Markowitz mean-variance analysis with Merton jump-diffusion Monte Carlo simulations.' This makes the tool's function unambiguous and distinguishes it from forecasting, grading, or marketplace siblings.

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 provides an explicit trigger condition: 'Use this when: a user has a budget and wants to know "how should I allocate my money across these cards?"' This gives clear context for when to call the tool. It does not list exclusions or alternative sibling tools, but that is not necessary given how specific the use case is.

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?

With no annotations, the description carries the full burden. It discloses that the tool is FREE, lists the three categories of returned data, and explains the merkle-commit anti-curation property. It does not describe exact response formatting or limitations, but for a zero-parameter public scorecard it provides solid 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?

The description is well-organized, with the core purpose front-loaded and a clear 'Use this when' section. The parenthetical example and merkle-commit explanation add trust-relevant detail, though the description is slightly more verbose than strictly necessary.

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 simple zero-parameter tool with no output schema, the description explains what will be returned and why it can be trusted. It lacks an exact response structure, but an agent can confidently invoke the tool and understand the high-level result contents.

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 has zero parameters and an empty input schema, so parameter semantics are not applicable. Per the baseline for 0-parameter tools, a score of 4 is appropriate; the description does not need to compensate for parameter documentation gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb 'Returns' and identifies a specific resource: the oracle's public accuracy scorecard. It lists concrete contents (conformal coverage, on-chain track record, blind study), making the tool's purpose clear. It does not explicitly distinguish itself from sibling tool check_accuracy, but the scorecard framing is distinct enough.

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 explicitly states when to use it: when an agent wants evidence that calibration claims are real, or for a trust-but-verify check before paying for forecasts or loan terms. This is strong contextual guidance, but it does not mention when not to use it or name alternative siblings.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It clarifies that the tool returns a 'recommended sequence' rather than executing actions, and it adds cost information with 'FREE — no payment required.' It does not describe potential limitations, but the core behavior is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the core purpose, and every element earns its place: the main explanation, the cost note, varied examples, and explicit usage guidance. There is 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?

For a single-parameter tool with no output schema, the description is largely complete: it explains the input, the kind of output, and when to use the tool. It falls slightly short of full completeness by not stating any limitations or what form the recommended sequence takes.

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 must compensate for the bare 'goal' parameter. It does so by explaining that the goal is natural language and supplying four concrete example goals. This makes the parameter's meaning and expected shape clear despite the lack of schema-level documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: 'Describe your goal in natural language and get a recommended sequence of TCG Oracle API calls to accomplish it.' It distinguishes this as an orchestrator/planner tool by saying to use it when unsure which tool to call first or when a multi-step workflow is needed.

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 provides explicit conditions for use: 'Use this when: you're not sure which tool to call first, or need a multi-step workflow recommendation.' This gives clear context, though it does not explicitly state when not to use it or name specific alternative sibling tools.

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

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

With no annotations, the description carries the full burden, and it delivers: it explains searchable fields, that rarity/condition words are ignored, that set-based queries produce separate printings, the presence of a 'set' field on results, and a fallback strategy. This materially shapes agent behavior beyond the raw 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?

The description is longer than average but well-structured: purpose and trigger conditions up front, then a tight bulleted search guide. Every bullet earns its place by changing how the agent forms queries or routes results.

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 zero annotations, zero output schema, and minimal parameter descriptions, this description is unusually complete. It covers result contents, downstream integration through product_id, pricing, query constraints, and troubleshooting steps. No critical information needed to invoke the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It richly explains query semantics: card name alone, adding the set, avoiding rarity/condition terms, and retrying with plain card names. It leaves the optional 'game' and 'limit' parameters mostly implied by their names/defaults, which is a minor 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?

The description names a specific verb ('search'), a bounded resource ('449K+ TCG products across 25+ card games'), and concrete return values ('card names and IDs, plus current market prices'). It clearly positions this as the lookup/entry-point tool for TCG cards, distinct from downstream tools like card_forecast and grade_or_not.

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 explicit trigger conditions: a user asks about a specific card, wants to find cards, or needs current pricing. It also instructs the agent to pass product_id to downstream tools. However, it does not explicitly contrast this with sibling lookup-ish tools like market_snapshot or trending_cards, nor does it state when not to use 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?

With no annotations, the description carries the full burden. It discloses the model family, output artifacts like percentiles and confidence intervals, and the $0.015 per-call cost. It does not mention failure modes or whether repeated calls are deterministic, but for a prediction tool it provides substantial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by model details, outputs, cost, and use-case trigger. The phrase 'complete mathematical transparency' is slightly redundant with the listed outputs, but overall every section 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?

The description covers purpose, model selection, outputs, cost, and when-to-use, which is solid for a simulation tool. However, it does not compare itself to the sibling tool card_forecast, and it omits guidance on the simulations parameter, leaving meaningful gaps for an agent trying to call the tool 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 0%, so the description must compensate. It explains the 'model' parameter well by naming 'gbm' and 'merton' options and the conformal default, but it leaves card_name, current_price, days, and especially simulations semantically unexplained. The simulations parameter, with a default of 20000, is a significant 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?

The description clearly states a specific verb and resource ('Predict future trading card value') and provides rich detail about the model and outputs. However, it does not differentiate itself from the sibling tool card_forecast, which likely overlaps in purpose, 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?

The 'Use this when' section gives explicit triggering examples: users asking about card value in 3 months or wanting price trajectory predictions. It gives clear usage context but does not mention alternatives or when not to use this tool, so it earns a 4 rather than a 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?

With zero annotations, the description carries the full disclosure burden and does so reasonably: 'FREE — no payment required' discloses cost behavior and 'public record' implies open access with no auth. The provenance explanation (lock_hash, merkle root, on-chain tx committed before outcome) is a meaningful behavioral trait — the data is verifiable rather than claimed. Minor gaps: no explicit read-only/no-side-effects statement and no failure behavior for invalid token_id.

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?

Four tight sections — purpose, cost note, usage guidance, and args — each earning its place. The purpose is front-loaded in the first sentence, and the verification explanation is dense but directly relevant to calling the tool correctly. No filler, no restatement of schema content.

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 single-parameter read tool with no output schema and no annotations, the description covers the essentials: what is returned, when to use it, the verification data included, and the parameter range. Gaps are minor — no formal return structure and no error-handling guidance for out-of-range token_id — but an agent can select and invoke this tool correctly from the description alone.

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% — the schema only declares token_id as an integer with no description. The description fully compensates: 'token_id: minted soul, 1-273' supplies the real-world meaning and the valid range. This is exactly the semantic value the schema lacks, giving an agent everything needed to supply the argument correctly.

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 the purpose with a specific resource ('ONE Undesirable soul') and enumerates exact contents ('every open (locked) prediction and its recent scored results'). Distinguishes from siblings via scope (single soul vs. souls_in_wallet's multi-soul scope) and the 'FREE — no payment required' note. The retrieval intent is unambiguous even though the verb is implied rather than literally 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?

Provides an explicit 'Use this when:' clause with two concrete scenarios — inspecting a specific soul's calls in detail and verifying a call. Explains why this tool fits verification by describing the on-chain lock_hash, merkle root, and commit transaction that make records checkable. However, it names no alternatives and gives no when-not-to-use guidance, leaving the choice against siblings implicit.

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?

With no annotations, the description carries the full burden, and it excels: it discloses the Ethereum mainnet source contract, the minted-IDs range, that any address can be queried without ownership proof, the deterministic prediction mechanism, the 30-day oracle scoring delay, and the UNRATED schedule with the exact maturity date.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well structured into labeled sections, with the core purpose and usage front-loaded. Every section earns its place: input semantics, behavior, return fields, edge-case expectations, and user-handling guidance all add value that would otherwise be absent.

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 has no output schema, so the description's explicit enumeration of souls[], wallet_totals, and best_soul is essential and complete. It also covers the expected UNRATED-before-2026-07-31 edge case and instructs the agent how to frame it, leaving no critical gap 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 description coverage is 0%, but the description fully compensates by defining address as a 0x-prefixed EVM address and calls as recent scored calls per soul with a 0-12 range and default 5. It also adds practical guidance to ask the user for their address because no wallet connection is required.

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: 'Show every Undesirable soul a wallet holds,' and then details the per-soul track record and recent calls. It clearly frames this as a wallet roster, distinguishing it from single-soul or scoring-focused sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit 'Use this when' triggers: ownership questions, performance checks, recent call queries, and most-accurate-soul comparisons. It does not explicitly name alternatives or state when not to use this tool, though the triggers are clear enough for selection.

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?

With no annotations provided, the description carries the full burden, and it does so thoroughly. It reveals that the tool is FREE, updates daily, reports dormant status in the off-season, includes a calibration verdict validated against a 90% target, and uses an on-chain merkle-committed stat panel for verifiability.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and efficient: it front-loads the core value, then adds behavioral details, and closes with explicit usage guidance. Every sentence adds meaningful information, and the 'provable, not vibes' phrase reinforces trust without bloating the definition.

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 no output schema and no annotations, the description covers a lot: output contents, update cadence, cost, off-season behavior, calibration context, and related use cases. The main gap is the lack of explicit guidance on the limit parameter and league value conventions, but the board's purpose and behavior are clear enough for an agent to invoke it.

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%, so the description must compensate. It gives useful context for the 'league' parameter via 'per live league' and an MLB example, but it does not explain the 'limit' parameter, valid league values, or expected formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: a daily sports movers board of hot, high-volume players per live league, with forecast context, grades, and headshots. It is specific about the resource and content, though it does not explicitly differentiate from sibling tools like market_snapshot or fantasy_league.

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 includes an explicit 'Use this when' section listing concrete use cases: 'who's hot in MLB', player ids for the paid forecast endpoint, and fantasy-adjacent market context. It does not state when not to use it or name alternative sibling tools, but the guidance is actionable.

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?

With no annotations, the description carries the behavioral transparency burden. It does reveal meaningful traits: the board is shared, agent entries are marked with an agent flag and model label, and scores are posted automatically on winning. However, it never explicitly states whether invoking the tool is read-only or what the call returns or affects, leaving some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, using two sentences to cover the board's identity, content, and automatic update behavior. Every clause adds useful information, and there is no filler or unnecessary 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?

For a parameterless leaderboard tool, this is nearly sufficient: it explains the data model, the agent-entry markings, and the auto-post rule, while 'Biggest Scores' implies ordering. The absence of an output schema means an explicit statement like 'returns the current leaderboard entries' would fully close the gap, but the description is adequate for 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?

The input schema has zero parameters, so there is nothing to document and schema coverage is trivially 100%. The description adds no parameter-specific meaning, but none is needed for a parameterless tool.

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 identifies a concrete resource: the Syndicate's shared 'Biggest Scores' leaderboard. It adds distinguishing content (humans and AI agents on one board, agent entries carry an agent flag and model label), but it lacks an explicit verb like 'get' or 'list,' so the operation must be inferred from the noun phrase and tool name.

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 implies the tool is used to view the leaderboard and that scores are posted automatically, but it never explicitly says when to use this tool instead of a sibling like syndicate_state or sports_board. There is no when-to-use, when-not-to-use, or alternative routing guidance.

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?

With no annotations, the description carries the behavioral burden and discloses key side effects: the world moves, rivals act, rackets pay, heat decays, and a new state is returned. It also states the per-crew/day constraint and empty-order passing behavior. It does not explicitly address persistence, reversibility, or error 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?

Front-loaded with a one-sentence purpose, followed by compact parameter details and edge-case behavior. The long actionType list earns its place because no enum exists in 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?

For a tool with no annotations, no output schema, and 0% schema coverage, it provides a strong end-to-end picture: input structure, valid actions, target source, empty-day behavior, and return content (events + new state). Minor gaps remain around session_id and error/validation 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?

Schema coverage is 0%, so the description compensates by fully specifying the orders item structure (agentId, targetId, actionType), enumerating all actionType values, and explaining that targetId comes from syndicate_state lists. It also explains empty-list semantics, though session_id is not described beyond its schema title.

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—'Submit one day of orders'—and resource, and tells the agent the tool returns the resolved day with events and new state. This clearly distinguishes the action from read-only siblings like syndicate_state and syndicate_leaderboard.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the intended invocation: submit one day's orders, with one order per crew member, and that an empty orders list passes the day. It also routes the agent to syndicate_state for valid targetId values, but doesn't explicitly list exclusions or when-not-to-use 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explains what happens on a new-game call (receiving sessionId, crew, capital, target list) and on a state re-read. However, it does not disclose important side effects such as whether starting a new game abandons an existing game, whether repeated calls without a session_id create multiple games, or any rate or resource limits. The strategy tip adds context but not behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well organized into context, invocation modes, a rules link, and a strategy tip. The essential instructions are clearly stated and the flow is logical. It is slightly longer than strictly necessary due to the introductory game context and strategy tip, but all content is relevant and no filler wastes the agent's attention.

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 simple single-parameter tool with no annotations and no output schema, the description covers the required invocation details and summarizes the new-game response contents. It lacks a detailed description of what a 'current state' re-read returns and does not mention edge cases like starting over or error handling, but the full rules link and explicit call modes make it reasonably 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?

The schema has a single optional session_id with 0% description coverage, so the description is the only source of parameter semantics. It fully explains the parameter: omitting it starts a new game, passing it re-reads the state. This completely compensates for the schema gap and leaves no ambiguity about how to use the 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?

The description clearly states the tool's resource and actions: it starts a new Syndicate game when called without a session_id and re-reads the current state when called with one. The verbs 'start' and 're-read' are specific, and the game resource is unambiguously described. It does not explicitly differentiate from sibling tools, 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?

The description provides explicit invocation conditions: 'Call with NO session_id to start a new game' and 'Call with your session_id to re-read the current state any time.' This gives clear context for both modes. It does not, however, exclude sibling tools or state when not to use this tool, leaving that implicit.

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?

With no annotations, the description carries the full burden. It discloses that the tool is read-only, free, returns proof_feed, and that the output is signed, chain-anchored, and checkable. This is strong, though it doesn't detail the format of the documentation output itself.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, stating core identity and purpose first. The standalone 'FREE.' fragment is slightly promotional but not harmful; the rest is dense and well-ordered.

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-input tool with no output schema, the description sufficiently explains what it returns (llms.txt docs plus proof_feed) and why to call it. Minor gaps like output format or size are not critical for a documentation endpoint.

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 input schema has zero parameters, so there is nothing for the description to explain. Baseline 4 applies, and the description makes no misleading parameter claims.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a documentation surface for the technocore.chat server (llms.txt) and states that it also returns proof_feed. It distinguishes itself from sibling tools like technocore_note and technocore_rooms by being the informational/docs tool, though it does not explicitly name any sibling it is not.

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 provides an explicit 'Use this when' clause with concrete triggers: learning the technocore API or the Flop Network agent ecosystem. It lacks explicit 'when not to use' guidance or named alternatives, but the covered use cases are clear and actionable.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It does state 'FREE, read-only', which clarifies the side-effect profile, but it does not describe error behavior, missing-key behavior, or response format. For a simple read tool this is adequate but not deeply transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the core action, and every sentence earns its place. The usage guidance is separated clearly, and there is no fluff or repetition of schema field names.

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 a low-complexity tool and no output schema, the description covers the core purpose and usage context well. However, it omits what the return value looks like and what happens when the optional key is omitted, which an agent may need to know 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 description coverage is 0%, so the description must compensate. It adds useful conceptual meaning by explaining that namespace is where agents publish state and that the note is key-value based, but it does not explicitly clarify the optional key parameter or its default behavior. Partial compensation, not full.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Read a shared key-value note from technocore.chat'. It also differentiates from sibling tools like technocore_info and technocore_room by emphasizing the key-value note semantics for cross-agent state publication.

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 provides an explicit 'Use this when' clause: when an agent needs a value another agent published to a technocore namespace, including config, observations, or coordination state. It does not explicitly name alternative tools or exclusions, but the usage context is clear.

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?

With no annotations, the description carries the full behavioral burden. It explicitly states 'FREE, read-only' and 'structurally incapable of posting', which strongly discloses the tool's safety profile. It stops short of explaining what happens on invalid room names or rate limits, but the core behavioral trait is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loads the core function and safety guarantee, and uses a clear 'Use this when' section. Every sentence adds value and nothing is redundant.

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, but there is no output schema and no annotations. The description covers purpose and usage context well, yet it omits parameter format guidance for 'room' and any meaning for 'limit'. This makes it adequate but not fully complete for 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 description coverage is 0%, so the description must compensate, but it does not. 'room' is only implied by context and never defined as an ID, name, or path; 'limit' is not mentioned at all. Without schema descriptions, this is a significant gap for an agent trying to pass valid arguments.

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 action ('Read the recent messages') on a specific resource ('one technocore.chat room'), and explicitly differentiates itself as read-only and incapable of posting. This clearly distinguishes it from siblings like technocore_rooms and technocore_note.

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 a direct 'Use this when' clause with a concrete example (following Flop Network testnet/faucet announcements) and the condition 'without joining'. It does not explicitly mention when not to use it or name alternatives, but the context is clear.

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?

No annotations are present, so the description carries the behavioral burden. 'FREE, read-only' explicitly discloses cost and side-effect profile, and the chat/notes server context clarifies what kind of resource is being listed. Pagination or return-shape details are missing, but they are minor for a simple read-only list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded: it states the action and resource first, then adds usage context and safety information. Every sentence earns its place with 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?

For a tool with one optional parameter and no output schema, the description supplies enough context to select and invoke it: what it lists, where, why, and the read-only/free nature. The lack of any mention of output format or the sibling single-room tool is a minor 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?

The only parameter, limit, has 0% schema description coverage, and the description never mentions it or its behavior. Since schema coverage is low, the description was expected to compensate, but it does not; only the property name and default value hint at meaning.

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 rooms on technocore.chat'. It is clear and actionable, though it does not explicitly contrast with the sibling technocore_room tool; the differentiation is implied by the plural scope 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?

The 'Use this when' sentence provides concrete triggers: discovering where agents coordinate or exploring the technocore ecosystem. It does not state when not to use the tool or point to alternatives such as technocore_room for single-room lookups, so it stops short of full exclusion guidance.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the per-call cost, clarifies that sales volume and view counts are absent, explains that risk percentages are regime-level constants rather than per-card fits, and states the coverage of 25+ TCG games. It does not cover auth or response structure, but the major behavioral caveats are addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core ranking behavior, followed by a correction note, risk-model caveat, scope, pricing, and usage triggers. It is longer than minimal but each section adds meaningful context. The structure is clear, though the correction note adds complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides enough context for a default call and gives important caveats, but it lacks any meaningful parameter semantics and does not describe the response shape beyond referencing `ranked_by`. Since there is no output schema and no annotations, these omissions leave the agent with partial but not complete information.

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%, and the description does not explain `game`, `limit`, or `min_price` at all. The only indirect hint is 'Covers all 25+ supported TCG games', which loosely suggests the `game` parameter but provides no format, allowed values, or empty-string semantics. The description must compensate for the fully undocumented schema and does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns top trading cards ranked by PRICE VELOCITY (drift), with highest absolute movement first. It also explicitly corrects a prior misconception about sales volume, which sharpens the core purpose and distinguishes it from volume-based market tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit trigger phrases like 'what cards are hot right now?', which is useful guidance. However, it also includes 'what's selling the most?' immediately after disclaiming that sales volume is NOT in the dataset, creating a mixed signal. It does not name alternatives or explain when not to use this tool.

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