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

The annotations already declare that the tool is read-only, open-world, idempotent, and non-destructive, so safety behavior is covered. The description adds the metric scope and macro-gauge framing, but does not disclose data freshness, source, aggregation window, or what 'delta' mode changes.

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 definition is two short sentences and is front-loaded with the core purpose. The internal ticket reference 'EH-422' is noise for an agent, but the rest is efficient.

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

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

An output schema and rich annotations reduce the burden, but the description still omits all parameter semantics and provides no sibling differentiation. For a tool with an unexplained 'delta' mode and 'source_checkpoint' input, the definition is not complete enough for confident fuller use.

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

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

There are two parameters with 0% schema description coverage, and the description does not mention either 'mode' or 'source_checkpoint.' It therefore adds no meaning beyond the schema and leaves the delta/checkpoint behavior unexplained.

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 specific verb and resource: 'Aggregate crypto market metrics,' and lists the key outputs: total cap, dominance, and 24h volume. It is clear what the tool returns, but it does not differentiate itself from siblings such as coinglass_macro_snapshot or cmc_quotes.

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?

Calling it 'A macro/liquidity gauge for the crypto market as a whole' implies when it is useful, namely for broad market or liquidity assessment. However, it gives no explicit when-to-use guidance, exclusions, or comparison to sibling macro tools.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new context about auth ('API key is resolved server-side, never accepted as an argument'), which usefully tells the agent not to hunt for a credentials parameter, but says nothing about pagination, result size, or how 'delta' mode behaves.

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

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

Three short front-loaded statements with no filler: purpose, exclusion/alternative, auth note. The only blemish is the awkward hard-wrapped line break mid-clause, which slightly hurts scanability but not content density.

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

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

An output schema exists so return values need no explanation, and annotations cover the safety profile. But with 0% parameter documentation in the schema, the description leaves mode=delta and source_checkpoint completely undefined, which is a material gap for an agent trying to call this correctly.

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

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

Schema description coverage is 0% across four parameters, so the description carries the full burden and fails: mode's empty/'delta' enum, start, limit, and especially source_checkpoint (an opaque anyOf object) are never explained. Only the generic listing semantics weakly imply what limit/start do.

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 first line names a specific resource and ordering ('cryptocurrency listings ranked by market cap') and parenthetically frames the scope as discovery/caps. It separates itself from a market-data feed, though it never distinguishes itself from the near-name siblings cmc_quotes and cmc_global_metrics.

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?

'Not a venue-specific OHLCV feed — use an emerald-exchange backend for tradable bars' is an explicit when-not plus an alternative, which is strong routing guidance. The gap is that the alternatives it names are outside the sibling set, while the actual siblings (cmc_quotes, cmc_global_metrics) go unaddressed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the useful 'latest' freshness signal and the comma-separated input convention, but says nothing about quote currency, data source, or latency. With annotations carrying most of the burden, a 3 is appropriate.

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

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

A single front-loaded sentence with an inline example and zero filler. Every element — the resource, the input format, and the sample value — 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 output schema means return values need not be described, and annotations cover safety, so the essentials are present. However, for a market-data quote tool the agent still cannot tell the quote currency, the venue, or how many symbols are practical per call — gaps that matter when choosing between this and sibling market tools.

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

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

Schema coverage is 0% and the schema only declares symbols as a bare string, so the description must compensate — and it does, explaining the comma-separated format and giving a concrete example ("BTC,ETH"). It stops short of stating symbol format constraints (uppercase, exchange prefixes) or behavior for unknown symbols.

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

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

The description states a specific resource (latest quotes) and the input form (comma-separated symbols), so the agent knows exactly what it returns. It does not explicitly distinguish itself from siblings like cmc_listings or cmc_global_metrics, which is the only thing keeping it from a 5.

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

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

There is no guidance on when to choose this over cmc_listings or cmc_global_metrics, no mention of prerequisites, rate limits, or which market/quote currency applies. The agent must infer usage purely from the tool name and the single example.

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

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

Annotations already declare readOnly=true, idempotent=true, openWorld=true, destructive=false, so the safety profile is covered elsewhere. The description adds only two hints — that the result is "bounded" (scope-limited, but with no stated bound) and that license rights come "from the operator" (implying a required credential), neither of which is concrete enough to act on.

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

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

A single semicolon-joined sentence with no wasted words, so it is concise and front-loaded. But the brevity crosses into under-specification rather than efficiency, leaving the clause about license rights without an actionable referent.

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

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

An output schema exists, so return values need not be described. The remaining gaps — undocumented parameters and no usage routing — are penalized in their own dimensions.

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 none of the five parameters (dataset, license_tag, mode, ticker, source_checkpoint) is explained. The critical ones — what license_tag must contain, what the const mode="delta" means, what source_checkpoint is for checkpointing — are invisible to the agent, and the description does nothing to compensate.

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

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

"Read a bounded snapshot" gives a verb and a vague resource but never names what is being read (ETF flows, sentiment, on-chain) or what a "snapshot" contains. Against siblings like cmc_global_metrics or fred_series_observations, an agent has no basis to prefer this tool, and it largely restates the title "Coinglass Macro 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?

There is no statement of when to use this tool, when not to, or which sibling covers overlapping macro data. The license clause reads as a constraint, not guidance, and leaves the agent to guess whether this is the right entry point for macro context.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds that records are 'sourced' with a source_url, which is genuine provenance context, but it is silent on pagination behavior, the semantics of mode='delta' and source_checkpoint, and default result size.

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

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

A single tight, front-loaded sentence with zero filler. It earns its place but is under-sized for a seven-parameter tool, so brevity edges toward terseness rather than pure efficiency.

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 output schema exists so return values need not be explained, and the annotations cover safety. But a 7-parameter tool with a delta/checkpoint sync mechanism and no explanation of it leaves an agent unable to use a substantial part of the interface 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 43%, so the description needs to compensate and does not — it says nothing about mode, limit, offset, or source_checkpoint, the four undocumented parameters. Only the since/until/outcome semantics are carried by the schema itself.

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

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

The description names the specific resource (FOMC decisions) and enumerates the returned fields (date, hike/cut/hold, target range, source_url), so an agent knows exactly what comes back. It lacks an explicit action verb and any statement of scope/ordering, but the tool's identity is unambiguous, and no sibling covers FOMC data.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of the sibling macro tools it might be combined with. Nothing tells the agent that this is a filtered, paginated listing or when the delta mode would be appropriate.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds no behavioral context beyond them — nothing about whether the list is static/curated, whether entries may change between package versions, or whether remote calls occur (relevant given openWorldHint=true).

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

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

It is a single short sentence, which is good, but the trailing internal ticket reference '(EH-422)' is noise that consumes attention without informing tool selection.

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

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

With an output schema present, return values need no explanation, and there are no parameters to document. Still, for an open-world data tool the description leaves unclear what an 'alias' contains and whether it is the intended entry point before calling the observation tools.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

It implies the tool returns the set of named macro/liquidity series aliases bundled with the package, but never states a verb ('list', 'return') or what an 'alias' is (name→series-ID mapping?). An agent can guess the resource but not the exact output shape from the description alone.

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

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

No guidance on when to call this versus fred_series_observations or fred_series_observations_asof, which the agent would likely need to discover valid series identifiers first. No exclusions, prerequisites, or sequencing hints are given.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds genuinely non-obvious vintage semantics: without realtime parameters you get today's latest revision, which may differ from historical vintages. It says nothing about pagination behavior with the 1000-record default limit or what mode='delta' / source_checkpoint do.

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

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

Two short sentences, front-loaded with the core purpose and followed by the default/override rule and the sibling pointer. No filler; the only minor inefficiency is that the second sentence does not also fold in the limit or mode semantics an agent will need.

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

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

An output schema exists, so return values need no explanation, but for an 8-parameter tool with zero schema description coverage the description leaves delta mode, checkpointing, and pagination entirely unexplained. An agent could call it, but would likely mis-set limit/offset or ignore mode.

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 carry parameter meaning, and it only covers three of eight: series_id vs. alias, plus realtime_start/realtime_end including the YYYY-MM-DD format. It is silent on mode (the sole enum), limit/offset pagination, and source_checkpoint, leaving most parameters cryptic.

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

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

The description names the resource (observations for a FRED series) and the two lookup keys (raw series_id or named alias), which lets an agent distinguish it from siblings like fred_series_vintage_dates. The verb is nominal rather than explicit ('Observations for...'), but the intent — retrieve time-series data points — is unambiguous.

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

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

It states the default behavior (today's latest revision) and the condition for overriding it (pass realtime_start/realtime_end to pin a vintage), and routes the single-date case to fred_series_observations_asof by name. It does not advise when to use alias vs. series_id or when the sibling alias-listing tool is needed, leaving a small gap.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds real semantics beyond that: data is frozen at the vintage and revisions published later are excluded, which is exactly the behavior an agent must understand before trusting a backtest.

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

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

Two short sentences, front-loaded with the identifying noun phrase and followed by the motivating use case. The literal backticks around vintage_date are a minor formatting artifact of scraped docstrings, but nothing is 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?

An output schema exists, so return values need not be described. However, for a 5-parameter tool with zero schema documentation, the description should still tell the agent how series_id and alias combine and how pagination behaves; that omission leaves the call signature under-specified.

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% across 5 parameters, yet the description only explains vintage_date. The critical ambiguity — whether to supply series_id or alias and whether both are allowed — plus the limit/offset pagination defaults (1000/0) are undocumented in both the schema and the 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?

States a specific retrieval action and its distinguishing qualifier: ALFRED point-in-time observations 'as known on vintage_date'. That is functionally different from the current-vintage sibling fred_series_observations, though the description never names that sibling to make the distinction explicit.

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 backtest framing ('reconstructs what a point-in-time backtest would actually have seen') implies when to reach for this tool, but the routing decision against fred_series_observations (current data) or fred_series_vintage_dates (available vintages) is left for the agent to infer rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds domain context that these are revision/vintage dates rather than observation dates, but says nothing about volume (default limit of 1000), pagination, or how a missing/ambiguous series_id is handled.

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

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

A single compact sentence with the key takeaway front-loaded and zero filler. The terseness is efficient rather than wasteful, though it leans on the `*_asof` glob shorthand that may not read clearly out of 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?

Return-value shape is covered by the output schema, but with four undocumented parameters at 0% coverage and no word on pagination behavior for a list that can return 1000+ dates, the definition is too thin for an agent to call it confidently in non-trivial cases.

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% across four parameters, and the description compensates for none of it — it never mentions alias, series_id, limit, or offset. The alias-vs-series_id distinction and the fact that both default to an empty string are left entirely unexplained, which is a real ambiguity for an agent building a call.

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

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

The description names a specific resource — every date the series was revised/published (vintage dates) — which is meaningfully distinct from the sibling fred_series_observations. The only weakness is the implicit verb and the unexplained `*_asof` shorthand, but an agent can still infer purpose from 'dates ... revised/published'.

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 an explicit downstream action: 'feed one into `*_asof`', which routes the agent to the sibling asof tools and explains why this list exists. It stops short of stating when NOT to call it (e.g., if you want values, use fred_series_observations), so it isn't a full 5.

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