Galactic

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

Annotations cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, and the description still adds real context: loan_count/loan_balance_usd appear only when the loan book is read on-chain, trailing_90d_apy_percent is a share-price-change annualization and explicitly *not* an issuer-quoted yield, and unknown ids return a documented not_found payload. It omits auth/rate-limit details, but for a read-only data tool the interpretive caveat is the important disclosure.

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-loads what the tool is, then the usage trigger, then field semantics and the return/error shape. A dense but efficient description; the inline JSON key list is terse but earns its place given no output schema exists.

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, the description steps in to describe the return object and the not_found error shape, plus the conditional presence of loan fields. That covers what an agent needs; only minor gaps remain (no pagination/refresh semantics, and the JSON key listing is implicit about types).

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

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

Schema coverage is 100% and both parameters (asset, response_format) carry their own descriptions including the enum and default. The description's mention of "USD.AI and GAIB" loosely maps to the asset ids but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific resource with scope: on-chain figures for the USD.AI and GAIB compute vaults, and enumerates the data points it returns (tokens outstanding, share price, trailing 90-day figure). This is clearly distinguishable from siblings like get_asset, market_totals, or gpu_price_index.

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?

"Call this for tokens outstanding, vault share price, and the trailing 90-day figure" gives clear situational context for selecting the tool. It stops short of naming an alternative or stating when *not* to use it (e.g., versus get_asset for single-asset queries), so it lacks explicit exclusions.

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

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

Annotations already establish readOnly, non-destructive, and closed-world behavior, but the description adds substantial context beyond them. It documents error behaviors for unknown and ambiguous ids, announced-id behavior, which fields are included, and when price history is available.

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 purpose, then moves to usage, return shape, error cases, and unit details. Every sentence adds operational value for a tool without an output 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?

With no output schema and a read-only lookup, the description supplies the missing return and error context. It covers normal output, ambiguous and not-found cases, announced assets, units, and history conditions, leaving no major gaps.

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

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

Schema coverage is 100%, so the parameters are already documented. The description still adds useful meaning: the id may come from an ambiguous result, shared tickers return matching ids, history is newest-only and only when price is published, and price history units are USD per token.

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 the resource precisely as "One published asset, with per-chain supply and an optional daily price history," which clearly identifies a single-asset lookup. It also distinguishes this from sibling list_assets by saying to call it after list_assets or when the id is already known.

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 usage conditions: after list_assets, when the id is known, and when resolving an ambiguous result. It also warns not to guess among assets that share a display ticker, which is a clear exclusion case.

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

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

Annotations only cover the safety profile (read-only, non-destructive, closed-world), and the description goes well beyond that: it explains that on-demand is list price while spot blends spot, interruptible, and marketplace asking prices, states the two-provider inclusion threshold, and documents the not_found error shape.

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

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

Front-loaded with the resource and unit, then tiers of detail. Dense but nearly every clause earns its place; the field enumerations are long, though they substitute for the missing output 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?

With no output schema, the description carries return-shape responsibility and does so: it lists the per-class fields for on-demand/spot and for memory tiers, plus the unknown-model error payload. An agent has everything needed to call and parse 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 coverage is 100%, so baseline is 3, but the description adds the tier behavior of the empty model value (16, 64, 256, 512 GB) and clarifies that response_format=json returns the object with source numbers and omitted fields stripped.

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

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

States a specific resource and unit up front: the latest GPU rental price index in US dollars per GPU-hour. It is clearly distinct from siblings like market_totals and get_asset, which an agent can tell apart without opening the 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?

Gives explicit call conditions tied to the model parameter: omit it for every published model plus memory tiers, pass one name for that model only. It does not, however, name or exclude any sibling tool, so routing against market_totals is left to inference.

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

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

Annotations only cover the safety profile (readOnly, non-destructive, closed-world), but the description adds substantial operational context: live vs announced listing semantics, the 'launch date and no supply, price, or holders' distinction, and the data-quality gating rule that figures appear only when their check passed. The explicit warning that 'omitted fields are unpublished, not zero' is exactly the kind of non-obvious behavior an agent would otherwise misread.

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-loads purpose then routing then return shape in a logical order, and each section earns its place. It is long, but the length is largely justified by the absence of an output schema; a few of the per-figure glosses could be tightened.

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, the description carries the full burden and discharges it: the JSON envelope keys, the card fields, the conditions under which each figure is populated, the meaning of omission, and the as_of timestamp semantics are all covered. All 8 optional parameters are documented in the schema, so nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100% and every filter (chain, query, issuer, category, limit, offset, include_upcoming, response_format) is already documented in the schema with defaults and constraints. The description only restates the filterable facets ('ticker, name, category, chain, or issuer') without adding format or precedence detail, so baseline 3 applies.

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

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

Opens with a specific verb+resource ('List published tokenized assets') and immediately scopes what the results are ('Live assets are the galactic.inc screener universe'), which an agent can distinguish from get_asset, market_totals, and compute_vaults without opening any schema.

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

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

Explicitly says to call it 'to find an asset by ticker, name, category, chain, or issuer before get_asset', naming the sibling alternative and the condition that selects it. There is no explicit when-not-to-use or edge-case guidance, which keeps it short of 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?

Annotations only declare it is a safe, closed-world read; the description goes well beyond that by disclosing conditional output behavior: market_cap_usd is null and withheld until every listed asset is priced, holders only sums assets with a published count (missing is not zero), and multi-chain assets are counted per chain. These are exactly the subtleties an agent must know to interpret the response correctly.

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

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

It is long, but the sequence is well front-loaded: purpose, then when to call, then the conditional semantics, then the return shape. Nearly every sentence carries a distinct rule (null propagation, coverage counting, per-chain attribution), though the layout sentence could be trimmed slightly.

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, the description compensates by inlining the full response shape (field names for top level and both row types), plus formatting, units, and the as_of/block-time caveat. An agent has everything needed to invoke and interpret 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?

Only one optional parameter (response_format) with 100% schema description coverage, so the schema already does the work and the baseline is 3. The description never mentions response_format, so it adds nothing on this axis.

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 precisely what the tool returns — category and chain totals for the published asset universe — and immediately distinguishes itself from the per-asset siblings (list_assets, get_asset) whose market caps it explicitly says are unaffected. An agent can tell it apart from the other aggregate tool (compute_vaults) without opening a schema.

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

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

"Call this for asset counts, pricing coverage, and holder totals" gives a clear trigger, and the note that per-asset caps from list_assets/get_asset are not affected implicitly routes per-asset queries elsewhere. It stops short of an explicit when-not-to-use or prerequisite statement, so it is strong but not exhaustive.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely useful behavior: unapproved items are silently omitted and the response carries no source URL. The default markdown-vs-json rendering distinction is also disclosed, going beyond what annotations provide.

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

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

Front-loaded with the verb+resource, then usage, then response shape. Efficient overall, though the inline JSON sketch is slightly dense for a description and the 'limit defaults to 8' line repeats 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?

With no output schema, the description carries the return-value burden and does so: it names the matched/items envelope, the per-item fields (id, date, category, headline, lede, assets), the date format, and the ticker list. An agent has everything needed to call and interpret 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 100%, so the schema already documents all three parameters including the case-insensitive substring semantics and the 1-30 limit range. The description only restates the limit default and adds return-value structure, not parameter meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb (search) and resource (approved galactic.inc newsroom items) plus the scope qualifier 'approved'. No sibling tool (compute_vaults, get_asset, gpu_price_index, list_assets, market_totals) competes with news retrieval, so an agent can route unambiguously.

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

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

"Call this for recent headlines about an asset, an issuer, or a topic" gives a clear triggering context and names the accepted query subjects. There is no explicit when-not or named alternative, but the sibling set contains no overlapping tool, so the guidance is sufficient in practice.

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