Isoba — Dollar & Crisis Index

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

Annotations already cover safety (readOnly, idempotent, closed-world), so the description's value-add is the search methodology and the outcome reporting. It discloses the similarity criteria, the exclusion rules, and the four outcome measures tracked within 12 months, plus interpretive guidance ('history, not a forecast'). It omits edge behavior such as what happens when no close matches exist.

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?

Dense but front-loaded, with the core operation stated first and the constraint clauses and outcome list following. Every clause carries information, though the single run-on sentence requires close reading.

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 usefully enumerates the metrics returned (crisis meter peak, NBER recession, S&P 500 bear market, dollar index) and the qualifications on matches. It is close to complete for this search tool, though it does not specify the response shape or behavior on zero matches.

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 both parameters (date, count) are already documented with formats and defaults. The description implies a date comparison and a default of today but adds no syntax or semantics beyond the schema; the 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?

The description names a specific operation: finding historical days since 1990 whose 14 crisis-meter sensors, market-top risk, and recession risk most closely match a given day, and reporting what followed. This is clearly distinguishable from siblings like get_current_readings or get_readings_on_date, which retrieve readings rather than analogs.

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 (today) and the qualifying constraints on matches (at least half a year apart, at least a year prior), which implicitly tells the agent when this tool applies. It does not explicitly name alternative siblings or when not to use it, leaving that 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 already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered structurally. The description adds useful disclosure about what the response contains (comparisons, zone changes, anomaly share, sensors that switched on/off), which goes beyond the annotations, but says nothing about default behavior when `to` is omitted or how large ranges are 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?

Two sentences with the payload described first and the usage trigger second, which is the right front-loading. The enumeration is dense and slightly run-on, but every clause names something the agent actually gets back.

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 carries the burden of describing return content, and it does so field-by-field (market shock from→to, zone change, anomaly share, top movers, on/off sensors, filters). Combined with annotations and a fully documented two-parameter schema, an agent has everything needed to call 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% and both parameters already carry pattern and default documentation, so the schema does the heavy lifting. The description's phrase 'between two dates' confirms the range semantics but adds no new meaning beyond the schema baseline.

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 gives a specific verb-and-resource framing ('what moved between two dates and why') and enumerates the payload (per-instrument market shock with from→to and zone change, market-anomalies share, biggest-moving sensors, on/off transitions, filters). It is clearly a date-range diff tool, distinct from point-in-time siblings like get_readings_on_date or get_current_readings, though it never names those siblings explicitly.

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 concrete triggering contexts: the user previously asked ('since last week / since I last checked') or asks why a reading changed. That is a real routing signal against get_readings_on_date and get_monthly_history. It stops short of explicit when-not-to-use or naming 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?

Annotations already establish readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety is covered; the description goes further by disclosing the interpretive constraints the agent must honor (no forecast/signal language, mandatory attribution, advice disclaimer) and roughly what each metric contains. It stops short of stating return format, size, or failure behavior, which is acceptable given the strict annotation coverage.

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 front-loaded correctly with the data date and purpose, but the middle is a dense parenthetical chain that packs five metrics and their methodology into one breathless paragraph. The framing and citation rules are buried at the end rather than separated, so an agent scanning for presentation requirements has to read the whole block.

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 burden of describing the return payload, and it does so thoroughly by naming each indicator and its historical-comparison framing. Remaining gaps are minor: the 'link to the public daily record' format and the ordering/shape of the response are not specified, but nothing needed to invoke the tool correctly is absent.

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 no parameters, so the baseline is 4. The description correctly introduces no parameter semantics and instead spends its space on output meaning, which is the right allocation for a zero-argument 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 opens with a specific verb-and-resource statement, 'Today's readings with the data date', and then enumerates every component returned (Dollar System Index, Crisis meter, Market shock, anomalies, top/recession risk, weekly change, record link). That enumeration implicitly separates it from get_monthly_history and get_readings_on_date, but it never names a sibling or explicitly states the boundary, so differentiation is left to inference.

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 real guidance on how to present the output (state the data date, credit the source, frame as history not forecast, add the not-investment-advice line). What is missing is tool-selection guidance: nothing says when to call this versus find_similar_days, get_changes_since, or get_readings_on_date, which matters because 'what changed this week' overlaps a sibling by name.

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/idempotent/closed-world, so the safety bar is low, and the description adds meaningful behavior beyond them: it discloses the exact output content (counts, median, range, number of cycles), the data provenance caveat (no open crypto price history since 1990), and mandatory framing rules (describe as history, never as forecast/signal/advice). This is rich behavioral context not derivable from annotations.

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 core content is front-loaded ('what markets price now... and what happened over the next 12 months'), but the single paragraph runs long and packs an enumerated data-category list plus multiple compliance instructions into one sentence chain. Much of the framing/phrasing mandate is useful, yet the density and repetition of the coverage list dilute scanability.

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 input parameters and no output schema, the description carries the full disclosure burden and discharges it: it explains the return values (report counts, median, range, cycle count), the data scope and gaps, the required attribution, and how to phrase results. An agent has everything needed to invoke it and present results 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 tool takes zero parameters, so the baseline is 4. It nonetheless clarifies the implicit fixed configuration by noting the analog selection reuses the 'same 14 sensors as find_similar_days' and requires periods 'at least half a year apart,' which helps the agent understand what inputs drive the result even though nothing is user-supplied.

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 deliverable: current market-implied prices (Fed path from 2y yield, breakevens, yields) plus the historical 12-month outcomes following the 10 most similar days since 1990. It explicitly distinguishes itself by tying its selection method to the sibling find_similar_days ('same 14 sensors'), so an agent can separate it from get_current_readings and get_monthly_history without opening 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 strong context on what the tool returns and references find_similar_days as the underlying selection basis, implying when it is relevant (comparing today to historical analogs). However, it never states when to prefer this over get_current_readings, get_changes_since, or what_to_watch, and offers no explicit exclusions. Usage is inferable but not prescribed.

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/closed-world, and the description adds real context beyond them: data has a date and source that must be surfaced, attribution to "Isoba (LOKIO)" is required, and the reading must be framed as historical base rates rather than a forecast or signal. Those are genuine usage constraints the schema and annotations do not carry. What is missing is any note on freshness, coverage, or latency of the underlying data.

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 content is dense and front-loaded with the return payload, so the first clause orients the reader quickly. But it is one sprawling paragraph with stacked parentheticals ("for USD — what 1 euro costs", "for cash — the next year") and a long tail of editorial instructions that could be split into distinct sentences for scanability.

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, so the description must carry the return shape — and it does, covering price, date, source, monthly/annual change, similar-past-moment statistics (case counts, typical outcome, deciles, best/worst), holder risk, and the currency-specific "wait a week?" figure. For a one-parameter read tool, an agent can call it and interpret the result without further 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?

The single currency parameter is fully documented in the schema down to the ISO 4217 pattern and USD default, and the description reinforces the one-currency scope with its USD/EUR explanation. It adds no new semantics such as which currencies are actually supported or how a bad code is handled, so it lands at the baseline for full schema coverage.

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 — the "Your money" card for a single currency — and enumerates exactly what comes back (FX rate, gold, Brent, bitcoin, cash/inflation, plus change and historical-case stats). That is far more concrete than the title alone. It does not, however, distinguish itself from siblings such as get_current_readings or get_monthly_history, which cover overlapping subjects, so an agent still has to infer the split.

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 pick this over get_current_readings, get_expectations, or get_monthly_history; selection must be inferred from the payload description. What guidance exists is about how to frame the output (history not forecast, no buy/sell advice, flag when a user asks for personal advice), which is presentational rather than tool-selection 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?

Annotations already establish read-only, idempotent, closed-world behavior. The description adds valuable context beyond that: instrument-specific history start dates (DSI since 2006, others since 1990) and the per-month zone fields returned, though it omits response format or pagination details.

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 dense sentences with the purpose and usage front-loaded; the instrument list and date coverage are necessary context rather than 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?

For a read-only historical data tool with fully documented optional parameters and annotations, the description covers scope, data availability, and return contents. It could be slightly more complete by clarifying the response structure or pagination, but no output schema exists to carry that burden.

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 parameter meaning is largely supplied by the schema's detailed enum and date-pattern descriptions. The description adds only modest context by saying 'one or several instruments' and noting instrument-specific history start dates, which can affect valid date ranges.

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 operation: monthly averages of one or several instruments over a month range, plus per-month zone indicators. It is distinguishable from current/date-specific siblings by its monthly aggregation and historical range, though it does not explicitly name an alternative.

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 clear use case: trends and seeing what instruments showed around past events. It does not specify when not to use it or name a sibling alternative, so it falls short of full when/when-not 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?

Annotations already declare readOnly/idempotent/closed-world, but the description adds a genuinely behavioral point beyond them: values are 'computed point-in-time from data published by that day', which tells the agent there is no look-ahead bias and that historical answers are trustworthy. It also discloses coverage bounds (since 1990-01-01, filters since 2006), though it says nothing about payload size or latency for what is clearly a large response.

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 whole definition is effectively one long run-on sentence enumerating outputs ('the dollar index, crisis meter, market shock, market-top and recession risk with zones, the market-anomalies share, every sensor, the eight filters...'), which is hard to parse and includes vague filler like 'every sensor'. It is front-loaded and has no wasted preamble, but it would read far better as a short purpose sentence plus a compact output list.

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 enumeration of returned metrics is doing necessary work, and the point-in-time computation plus historical coverage boundaries give an agent enough to call correctly. The only real gap is response size/shape expectations for what is obviously a wide payload.

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 schema already documents the weekend/holiday rollback rule, so the description cannot add much for the single date parameter. Its one contribution, the 1990-01-01 lower bound, is a useful constraint not present in the schema, but it is stated in the context of outputs rather than the parameter, which keeps this at baseline.

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+resource ('what Isoba showed on any working day since 1990-01-01') and enumerates the returned metrics, so there is no ambiguity about what the call produces. It distinguishes itself from get_current_readings only implicitly, via the 'before 2008 / day of COVID' framing, rather than by naming the sibling.

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 closing line gives concrete usage questions ('what did it show before 2008 / on the day of COVID?') that make the historical-lookup use case clear and implicitly exclude 'what does it show now'. It stops short of naming an alternative tool (get_current_readings, get_monthly_history) or stating 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?

Annotations already establish readOnly/idempotent/openWorld=false, so the bar is lower; the description adds meaningful provenance context beyond them — point-in-time replay, only data published by each day, and look-ahead verification. It does not describe return shape or pagination, but the methodological disclosure is real added 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?

Front-loaded with the scope and the call-before-claiming directive, then the selectors. The long event list is bulky but each token is a usable enum value rather than filler, so it largely earns its space.

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 does well to explain defaults, section taxonomy, and event addressing, and it hints that summary is short. It never states what the record actually returns or how from_year/to_year constrain the replay, which is the remaining gap for a 4-param tool.

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 50%. The description compensates heavily for the two weak spots: it enumerates every valid section value and, more importantly, lists the full set of event ids/aliases (gulf, ltcm, lehman, covid, tariffs, or year) that the schema only gestures at. It says nothing about from_year/to_year semantics, leaving the remaining half 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?

States a specific verb+resource: it returns how Isoba behaved when replayed point-in-time over every working day since 1990, with look-ahead checks. This is plainly distinct from siblings like get_current_readings or find_similar_days, which cover live or analog data rather than historical self-performance.

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 a concrete usage directive ('Call it before claiming reliability') and explains the default (summary is short) plus the alternative selectors (section vs single event). It does not name sibling tools or explicit when-not-to-use conditions, so it falls 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 already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral detail: the distance is measured in points to the next zone boundary, the switching threshold is fixed at 80, and freshness/staleness is reported. It does not mention cost or limits, but for a pure read tool this is solid.

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 sentences, front-loaded with the computational content and closed with the use case. The first sentence is clause-heavy but each clause maps to a distinct output, so little is wasted.

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 burden of describing returns, and it does so: point distances, near-threshold sensors, and input freshness. For a zero-argument read tool this is close to complete, missing only the exact output shape.

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 baseline is 4; there is nothing for the description to disambiguate. Schema coverage is 100% and no inputs need explaining.

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 concretely what the tool computes: per-instrument distance in points to the next zone boundary, sensors nearest to switching (threshold 80), and freshest/stalest inputs. This is specific and clearly distinct from siblings like get_current_readings or get_changes_since, though it names no sibling explicitly.

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 supplies an explicit usage trigger ('Use for "what would change the picture?"'), giving an agent a clear scenario in which to reach for it. It stops short of naming alternatives or exclusions, so it is context without routing.

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