inflation-signal

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 richly: it discloses the grading thresholds that shape the output (e.g., mid scores reported as normal), the per-timeframe breakdown, payment amount, retry behavior on 402 challenges, and that the data is snapshot-based and informational only.

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 every sentence carries substantive information — purpose, output format, grading logic, payment, retry, and sibling comparison — with no filler. It could be more visually structured (single paragraph, many clauses), but the content is front-loaded and efficient enough for an agent to parse.

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 and no annotations, the description is exceptionally complete: it covers input semantics, output components (score, inflState, reading, period, timeframe breakdown), grading rules, payment mechanics, and when to use `pitch` instead. An agent needs nothing else to 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 100% (the schema already explains the `symbol` parameter with examples), so the baseline is 3. The description adds meaning beyond the schema by detailing the covered universe (47 series, 10 countries, US liquidity/rates/jobs), giving more concrete examples (US-PCE, US-PPI, US-FED, US-RRP, US-M2, JP-CPI, DE-CPI), and explaining how the symbol maps to the output verdict.

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

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

States a specific verb+resource ('Return the inflation-thermometer verdict for one official macro series'), names the covered universe, and distinguishes itself from the sibling `pitch` tool by scope and output detail. An agent can tell exactly what this tool does.

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 contrasts with `pitch` ('The free `pitch` tool shows a live verdict for this market's showcase symbol only — this tool answers ANY symbol in the covered universe'), giving a clear condition for selecting this tool. It also clarifies snapshot-based, informational-only behavior and payment expectations.

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?

The description explains the funnel phases and the effect of interest:false, but does not explicitly state side effects or outcomes of proceeding through the funnel (e.g., whether subscribing triggers a change). With no annotations, this leaves 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 somewhat wordy with redundant phrasing like 'FREE and OPTIONAL' and 'you may skip it'. The structure jumps between introducing the tool and listing phases, but overall it remains short and readable.

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 three optional parameters and no output schema, the description covers the essential context: when to use, the phase flow, the symbol limitation, and the interest flag. It does not explain what each phase returns, but that is not required without an output 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?

The phase enum is self-explanatory and listed in sequence. The symbol parameter is given additional context (only serves US-CPI in the sample, otherwise handled by evaluate_symbol). Interest is described as a way to bow out. Only the interest parameter lacks a schema description, but the tool description compensates.

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

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

The description clearly states the tool's purpose as an intro and subscription funnel for the inflation & liquidity signal agent. It explicitly names the phases and gives a direct action (skip it) that ties into its role.

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 says the intro is optional and that you may skip it and call evaluate_symbol / scan_bottoms / scan_tops directly. It also instructs to pass interest:false to bow out, providing clear when-to-use and when-not-to-use 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?

No annotations provided, so description carries full burden. It mentions 'FREE' and 'no payment needed', which is behavioral, but does not disclose auth needs, rate limits, or side effects. For a simple feedback tool, it is adequate but lacks depth.

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 concise sentences with no redundant information. Every phrase adds value: 'FREE', 'after using our signals', 'score 1-10 plus pros and cons'.

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 annotations, no output schema, and simple tool, description covers purpose and key parameters. However, it does not clarify whether pros/cons are optional or required (schema shows only score required), leaving minor 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?

With 0% schema coverage, description compensates by mentioning score range (1-10) and pros/cons fields. This adds meaning beyond the schema, but does not detail parameter types or constraints fully.

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 is a feedback tool for rating after using signals, specifying the verb 'leave a rating' and the resource 'score 1-10 plus pros and cons'. It distinguishes from siblings like 'evaluate_symbol' which focus on symbol analysis.

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 usage after using signals ('after using our signals'), providing context but not explicit when-not-to-use or alternatives. While siblings differ, no direct comparison is made.

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 burden of behavioral disclosure. It clearly states the paid nature, payment mechanism (x402/USDT), lack of account requirements, and the retry-with-header behavior on 402. It does not detail response contents beyond ranking, so not a 5.

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

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

Every sentence carries distinct information: purpose, payment, retry mechanics, and cold-start positioning. No filler; the most important facts 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?

Covers what the tool scans, how results are ordered, the payment/authorization flow, and the relationship to pitch. The return shape is only lightly described, but for a simple ranked list that is probably sufficient.

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 already documents limit's default and max, but the description adds important context: the tool scans all 47 series and returns the lowest ones ranked, so the limit parameter means 'how many of the ranked lowest to return', not a filter or search restriction.

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 action (scan all 47 macro series), a clear selection criterion (LOWEST/deflation-side), and an explicit ordering (ranked most-low first). No ambiguity about what the tool does.

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 concrete situational guidance: it is the best cold-start option because it requires no symbol selection, and it explicitly contrasts with the free pitch tool (count vs. names). It does not spell out when to prefer evaluate_symbol, but the primary routing decision 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 burden, and it delivers: it discloses the per-call cost and payment rail ($0.01 via x402 USDT on X Layer), the auth requirement (PAYMENT-SIGNATURE header on 402), retry behavior, and no-account friction. It also clarifies the ranking order and that the tool returns names, which is behavior beyond what the schema shows.

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

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

Three sentences, each carrying a distinct load: functionality, payment/auth/retry, and cold-start positioning with a pitch comparison. The most important purpose is front-loaded, and there is 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?

Without an output schema, the description still covers what is returned (names) and the ordering, plus cost, authentication, retry, and the primary use case. For a one-parameter, read-only scan tool, this is a complete and self-sufficient description.

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 already documents `limit` with default and max at 100% coverage, so baseline is 3. The description adds meaning by saying results are 'ranked most-high first,' so `limit` selects the top N of that ranked list. That is a small but useful addition, justifying a 4.

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 action and scope: 'Scan all 47 macro series and return those reading HIGHEST... ranked most-high first.' The 'HIGHEST' clearly contrasts with the sibling scan_bottoms, and the final sentence distinguishes it from pitch. This leaves no ambiguity about what the tool does.

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 frames when it is best used: 'BEST COLD START: you do not need to pick a symbol — this ranks the whole universe for you.' It contrasts itself with pitch ('tells you HOW MANY... this names them') and implies against symbol-specific alternatives. It does not explicitly name scan_bottoms or evaluate_symbol as when-not alternatives, but the cold-start context is strong.

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