Dantes Exchange

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

With no annotations, the description carries the full transparency burden and mostly succeeds: it says this is a pre-payment manifest lookup, explicitly says it is not for executing the scan, and details the return contents. It does not explicitly state that the call is read-only or free, nor does it mention auth/rate limits, which is a minor gap.

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 uses three labeled sections ('WHEN', 'NOT for', 'Returns') that front-load the most important information. Every sentence earns its place and nothing is wasted or redundant with 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 one-parameter manifest getter with no output schema, it covers when to call, what not to do, and what will be returned. It is slightly incomplete on operational details such as whether the call itself costs or requires special access, though the pre-payment framing and endpoint-specific price hint mitigate this.

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 only says id is a required string, while the description adds that it is a capability id and frames it as the lookup key for schema, price, and when-to-use. It does not specify the id's format or source, but for a single simple identifier this is sufficient.

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?

Description opens with 'WHEN: Use when you already have a capability id and need schema, price, and when-to-use before paying,' which clearly states the verb, resource, and purpose. It also disambiguates from execution via 'NOT for: Do not use to execute the scan,' distinguishing it from invoke_capability.

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 ('already have a capability id ... before paying') and an explicit exclusion ('Do not use to execute the scan'). It does not name sibling tools like invoke_capability or search_capabilities directly, so the alternative routing is clear but slightly less explicit than it could be.

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 full burden and does so well. It discloses that semantic and economic evidence are kept separate and never combined, that benchmark figures appear only where measured, and that missing economic measurement returns NOT_MEASURED rather than a borrowed value.

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 WHEN, NOT for, and Returns sections. Every sentence contributes essential routing or behavioral information, and the most important usage boundary is front-loaded.

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 one-parameter tool with no output schema, the description adequately explains what the caller should expect, including the NOT_MEASURED fallback and the separation of evidence types. Some jargon like 'dated forward-return pack' and 'n, window, as-of' is not expanded, but the core invocation contract is sufficiently clear.

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 the one parameter 'id' already has a description. The description references 'listed skill' which maps to the capability id, but it does not add meaningful format, source, or constraint 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?

The description clearly identifies the tool as returning a dated forward-return pack for a listed skill, and the title supplies the 'get' verb and resource. The 'NOT for' clause explicitly distinguishes it from a live scan and from current-day hits, separating it from 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 an explicit WHEN condition ('need the dated forward-return pack for a listed skill') and explicit exclusions ('Do not use as a live scan... not today's hits'). It does not name sibling tools as alternatives, but the usage boundary is clear enough for an agent to route correctly.

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 does so: it warns that most names are blank because only desk-reached names are graded, that a blank means UNRATED and never Hold, that it is not Street consensus nor investment advice, and that reports inline for only 3 names at a time. These are non-obvious behavioral facts an agent could not infer from 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?

Front-loaded with WHEN, then NOT for, then Returns, which is exactly the priority order an agent needs. The three quoted user-phrasing examples are mildly redundant but serve as retrieval cues, so the text mostly earns its length.

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?

No output schema exists, yet the description inlines the full return shape including row fields, the grade enum, and what null versus blank means. Combined with the usage boundaries, an agent has everything needed to call and interpret the result.

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 states the up-to-20 batch limit and the 3-name report-inlining limit, which explains the practical effect of include_essay. It never names include_essay directly, leaving the boolean's exact semantics inferred rather than stated.

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 — retrieves Dantes' grade and analyst report for named symbols — and explicitly distinguishes itself from siblings by naming analyst-actions as the Street-consensus alternative. An agent can tell immediately what this returns versus get_capability or search_capabilities.

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 opens with an explicit WHEN clause keyed to the user's phrasing ("what does Dantes say about WING", "is NVDA a Strong Buy") and follows with a NOT for clause that names the excluded case (rating a market or a screen's survivors wholesale) and explains why. Alternatives and boundaries are both covered.

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 does so: it discloses token-to-seat binding scope, that only the caller's own seat is visible, the no_seat/no_desk failure reasons, the archive-vs-live distinction, and a data-interpretation caveat that a card is a dated scan result, not a recommendation. These are behavioral facts an agent cannot infer from 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?

The WHEN / NOT for / Returns structure is front-loaded and scannable, and each block earns its place. The Returns payload enumeration is dense but justified since no output schema exists; the description is 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?

No output schema and no annotations, so the description must cover behavior and return shape — it does both, enumerating the desk/cards/watchlist/setups structure and the ok:false reasons. Nothing an agent needs to call it correctly is absent besides the unused limit parameter.

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

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

Schema description coverage is 0%, so the description should compensate for both parameters. It explains include_archive ('pass include_archive:true for cards no longer live') but says nothing about the limit parameter despite its 1-400 maximum, so half the surface remains undocumented.

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

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

The description states a specific verb and resource — reading the caller's own Dantes Desk, watchlist and setups — and explicitly contrasts it with siblings ('Not a market screen and not another person's desk'). An agent can distinguish get_desk from get_dantes_rating or search_capabilities without inspecting 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?

It gives a WHEN block with concrete user utterances ('what is on my desk', 'which of my desk names are Strong Buy'), a NOT-for block ruling out market screening and other people's desks, and names the alternative behavior on failure (answers no_seat and say so rather than guessing). This is complete 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 full burden and does so: it discloses the token requirement, the anonymous-endpoint failure mode, the three failure reasons, the evidence-threshold caveat, the obligation to quote as-of date and n, dividend inclusion, and the need to name the scope behind any number. That is unusually complete mutation-free 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 WHEN / NOT for / Returns progression is well front-loaded and each block serves a distinct job. The deeply nested return-shape dump is dense and harder to scan than prose, but since no output schema exists it is doing necessary work rather than padding.

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

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

With no output schema and no annotations, everything an agent needs is in the text: return fields, failure reasons, and the interpretive constraints around quoting results. Rule-following caveats (quote as-of and n, say which scope) close the loop on misuse.

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 4 baseline applies; there is nothing for the description to disambiguate. The prose correctly adds no parameter guidance because 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?

Opens with a named trigger and states exactly what is returned: the forward log of grades Dantes issued live, measured alongside SPY over identical windows. It explicitly contrasts with the sibling get_dantes_rating, so an agent can distinguish 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 WHEN block quotes real user phrasings that should select this tool, and the NOT-for block names both the exclusion condition (not a backtest, not evidence until the completed-63 count hits its threshold) and the sibling alternative for per-name grades. Nothing 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?

With no annotations, the description carries the full transparency burden and does so thoroughly. It discloses the return envelope, the x402 PaymentRequired behavior with exact payment details, the fact that nothing executes or charges until payment verifies, and the nuance that a zero-result scan is a billable run rather than an error.

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, organized by WHEN / NOT for / Returns, and every sentence provides distinct decision-relevant information. The key usage trigger is front-loaded, keeping the reader from having to parse dense 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?

Given the absence of annotations and output schema, the description fully covers what is needed to invoke and interpret the tool: return format, payment flow, error semantics, and interaction with the get_capability sibling. It also signals that an unpaid call is not a real failure.

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 already covers both parameters with 100% description coverage: 'id' as capability id and 'input' as an object conforming to the capability's input_schema. The tool description adds little parameter-level meaning, so the baseline of 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 clear action ('invoke a listed skill') and the specific condition for using it (user wants matching names now and is ready to pay). Explicitly distinguishes itself from other operations by naming what it is NOT for, such as quotes, news, or unsupported chart patterns.

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 both positive and negative usage conditions. It names when to invoke, when not to invoke, and even routes the agent to read get_capability ta-primitives before refusing a named indicator. This is explicit contextual guidance beyond mere tool 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 behavioral disclosure burden. It usefully discloses return semantics: published datasets with as-of dates, universes, and the member ticker list when a `universe` is supplied. It also adds a meaningful negative guarantee that raw dataset files are never returned, which is not inferable from 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?

The description is well-structured with WHEN, NOT for, and Returns sections, and every sentence earns its place. It is front-loaded with the most important usage context and contains no filler.

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

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

Given the rich schema and optional parameters, the description provides enough context for an agent to know when to call the tool and what to expect back, especially since there is no output schema. It omits details like pagination behavior, rate limits, or explicit read-only status, but these are secondary for a simple listing tool and partly derivable from the schema.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters well, including the two enums. The description adds only a small amount of context around the `universe` parameter's effect, which largely duplicates the schema's own parameter description.

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 action and resource: listing published datasets and enumerating their equity universes, optionally returning member ticker lists. It is unambiguous about what the tool does, though it does not explicitly differentiate itself from the sibling capability 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 gives explicit positive guidance ('Use when you need what universes / as-of books a skill can run on') and explicit negative guidance ('Do not use to fetch prices or news'). It stops short of naming alternative sibling tools, so it lacks the full when-not-to-use-versus-alternative 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool records missing items to the operators' gaps board, that nothing is promised to the user, and gives the return shape for both success and failure. This is strong disclosure for a write/record type tool.

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 clearly structured with WHEN, NOT for, and Returns sections. Every sentence adds meaningful guidance, and the key usage conditions are front-loaded.

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 4-parameter tool with no annotations and no output schema, the description covers the trigger condition, exclusions, side effects, user-facing caution, and the success/failure return shape. Nothing essential is missing for an agent to select and invoke it correctly.

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

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

Schema coverage is 0%, so the description must compensate. It explicitly explains 'missing' as buildable data gaps and 'could_do' as what Dantes can still do, and the WHEN clause implies 'capabilities_tried' and 'question'. However, 'capabilities_tried' and the expected contents of 'question' are only implicit, not directly mapped.

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 (report the missing pieces after search_capabilities and get_capability) and names exactly what class of missing data is being reported: data column, indicator, history, or composition. It also implicitly differentiates itself from siblings by describing when the other tools have been exhausted.

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 WHEN clause naming the prerequisite tools and condition, and a NOT for clause explaining when not to use it: when a capability exists but refused the input shape. It even warns the agent not to promise that a gap will be built, which is critical behavioral 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. It discloses the return shape (capability ids with price, run requirements, nested when/not_for/returns) and the notable not_encoded field. It does not mention side effects or pagination, but the read-only nature is implied by the 'NOT for running a scan' guidance.

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

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

The description is organized into WHEN / NOT for / Returns blocks, each contributing distinct guidance. It is slightly wordy but efficient and front-loaded with the central trigger condition.

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 an agent to decide when to call search_capabilities and what to expect back, including the not_encoded caveat. However, it omits any definition of the category parameter and provides no example, which is a noticeable gap given the sparse schema.

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 explicitly define the query or category parameters. It implies query is the trader-language setup mentioned in WHEN, but category is completely undocumented, leaving an optional parameter ambiguous.

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 clear action—searching capabilities—and the trigger condition ('user named a setup in trader language'). It distinguishes itself from siblings like get_capability and invoke_capability by focusing on discovery/identification rather than retrieval or execution.

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 WHEN and NOT for sections explicitly state when to use the tool and what not to do ('Do not use to run a scan or to invent a skill'). It does not name sibling alternatives directly, but the exclusion is clear enough to guide tool selection.

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