The Market Calendar

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the freemium gating rule (free only for S&P 500 in the current month), the degraded fallback response, and the presence of a pro_required signal, which tells the agent to expect a paywall marker rather than real 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?

Two tightly packed sentences with the core purpose front-loaded and the access caveat second. Dense but every clause (outputs, free tier, fallback, pro_required) carries information; no filler or repetition.

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 must describe the return shape, and it does list the concrete fields (average return, share of years up, rank among all days) plus the pro_required marker. What remains unclear is the response envelope for the paywalled case, but for a two-parameter read tool this is close to 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?

Schema description coverage is 50%: the date parameter is documented as 'MM-DD or YYYY-MM-DD' and the asset parameter is a constrained enum, so the schema carries most of the burden. The description adds no extra parameter meaning (e.g. whether a single date or a range is expected), so baseline 3 is appropriate.

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

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

The description names a specific resource and scope: performance of an asset on one calendar date aggregated across all years, with named outputs (average return, share of years up, rank among all days). The word 'day' plus 'across all years' implicitly separates it from monthly_seasonality and window_seasonality, though it never names those siblings outright.

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 conveys the access condition ('Free for the S&P 500 in the current month') and what happens otherwise, which implies when the tool is fully usable, but it never states when to pick this tool over monthly_seasonality or window_seasonality. Usage is inferable from the day-scoped framing rather than explicitly guided.

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 and openWorldHint=false, covering the safety profile for this lookup tool. The description adds one genuinely useful behavioral detail — that times are US Eastern — but says nothing about lookahead/backfill behavior, whether the range is forward-looking, or result ordering. It meets the lower bar set by the annotations without exceeding it much.

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 no filler. The long parenthetical event list is dense but each item earns its place by helping an agent match user queries like 'CPI' or 'JOLTS' to this tool.

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 listing tool with no output schema, the agent still lacks the return shape (fields per release, event-time format) and the interaction between the two date parameters. The timezone note is a good start, but a 60-day-capped two-parameter tool deserves more specificity.

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%: 'start' is documented with a YYYY-MM-DD format and 'today' default, but 'days' has no description and a hidden 1-60 cap. The description only says 'date range', leaving ambiguous whether 'days' counts forward from 'start', overrides it, or interacts with it — real ambiguity the description should resolve.

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 (scheduled US economic releases) and enumerates concrete event types (FOMC, CPI, jobs, PCE, GDP, PPI, retail sales, ISM, JOLTS), so an agent can immediately tell what data comes back. It doesn't explicitly contrast with siblings, but the sibling set (seasonality/asset tools) is unrelated enough that differentiation isn't needed.

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 states what the tool returns but never says when to call it, what question it answers, or what alternatives exist. There is no exclusion or prerequisite guidance, so the agent must infer usage entirely from the resource 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing what is returned (the fixed market universe plus each market's data start date), which matters since no output schema exists.

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 no filler. The parenthetical market list is dense but earns its place by telling the agent exactly what coverage to expect.

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 zero-parameter, read-only enumeration tool with no output schema, the description covers what comes back (markets and their data start dates). It stops short of noting update frequency or that this list defines the valid universe for sibling tools, but nothing essential to calling it 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?

The tool takes zero parameters, so the baseline is 4. Nothing in the description is needed to explain inputs, and it does not mislead about configurability.

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 ('List') and resource ('markets covered'), then enumerates the exact coverage (S&P 500, Nasdaq, Bitcoin, Gold, etc.) and the accompanying attribute (data start dates). This clearly distinguishes it from the sibling seasonality tools, which compute patterns rather than enumerate coverage.

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?

Usage is only implied: an agent would infer this is the discovery call to make before using day_seasonality or window_seasonality, but the description never says when to call it or that it is a prerequisite/alternative to any sibling. No exclusions or conditions are 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=true and openWorldHint=false, so the safety profile is covered. Because there is no output schema, the description's enumeration of the computed outputs is genuinely additive: it tells the agent the call returns a rich analytic payload (ranks, cumulative seasonal path, extreme days) rather than a single figure, setting expectations about breadth of computation.

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 names the scope first ('one month for one asset') and then lists the outputs, with no filler or repetition. The trailing list is dense but each item is a distinct returned statistic, so the length is earned rather than 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?

For a two-parameter, read-only analytics call with no output schema, the description covers the essentials: both inputs are constrained by the schema and the full shape of the response is spelled out. The only material gap is the lack of any statement positioning it against monthly_seasonality, which leaves a selection ambiguity unresolved.

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 month parameter is documented in the schema ('1-12 or month name') and the asset parameter exposes a closed enum, so the schema carries most of the load. The description reinforces cardinality ('one month for one asset') but adds no format, default, or validity detail beyond the schema, matching the baseline 3.

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

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

The description states a specific verb+resource and scope: a deep-dive analytics view of one month for one asset, and it enumerates exactly which statistics are produced (average, median, % of years up, rank among 12 months, cumulative path, strongest/weakest days). It does not, however, explicitly distinguish itself from the very similar sibling monthly_seasonality, so the agent must infer the difference from the phrase 'deep dive'.

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?

Usage is only implied by the granularity wording ('one month for one asset'), which suggests calling this when a single-month drill-down is needed rather than the broader monthly_seasonality or seasonal_pattern tools. There is no explicit when-to-use, when-not-to-use, or alternative named, so an agent choosing among the eight siblings gets no routing help.

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 and openWorldHint=false, so safety is covered. The description goes beyond that by enumerating the returned statistics (average, median, share of years up, best/worst year), which is valuable since there is no output schema. It omits the historical span of the data, a minor gap.

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

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

Two sentences with zero filler: the first front-loads the output content, the second front-loads the usage triggers. Every clause 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?

For a one-parameter tool with no output schema, the description adequately conveys both what is computed and when to call it. The main missing piece is the lookback window / data vintage, which an agent might want when judging results.

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 is a single parameter whose allowed values are fully enumerated in the schema, so the schema does the heavy lifting despite 0% description coverage. The description only says 'of an asset' and adds no meaning (e.g. asset class coverage or granularity) beyond the enum 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 a specific verb set (average/median return, share of years up, best/worst year) scoped to 'each calendar month of an asset', which tells an agent exactly what the tool computes. It implicitly separates itself from day_seasonality by specifying calendar months, though it does not name that 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?

The 'Use for' clause supplies concrete trigger phrasings ('what's the best month for X', 'is September bad for stocks'), which gives clear context for selection. It stops short of stating when NOT to use it or pointing to day_seasonality/window_seasonality as 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 declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral: no indication of what statistic is returned (mean return, win rate, date range), no timeframe, no output shape, and it merely echoes the enum values.

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 single sentence is dominated by a 12-item hyphenated enum recital that duplicates the schema verbatim, while the actual tool behavior is compressed into a few words. Low information density for its length.

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

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

With no output schema and no annotations beyond the read-only/closed-world hints, the description should explain what statistics come back and over what horizon. It omits both, leaving the agent unable to predict the response or choose correctly among seasonality siblings.

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

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

Schema description coverage is 0%, so the description carries the burden, yet it only restates the enum list already present in the schema. It does not explain what each pattern denotes or what the selected pattern produces, so no meaning is added beyond the structured field.

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 phrase 'Statistics for well-known S&P 500 calendar effects' identifies the resource and domain, but supplies no verb (retrieve/compute/list) and never distinguishes itself from siblings like monthly_seasonality, day_seasonality, or seasonal_trends. An agent cannot tell from the text alone how this differs from the other seasonality tools.

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

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

There is no when-to-use guidance, no conditions, and no mention of alternatives among the seven seasonality-related siblings. The agent must guess that this tool is for pre-canned named effects rather than arbitrary windows.

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 and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the free tier is restricted to S&P 500 data touching the current month, and the full year plus other assets are gated behind Pro. It does not describe return shape or how a 'stretch' is bounded, which keeps it below 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?

Two sentences, no padding, with the core resource definition front-loaded and the access limitation second. It is tight, though the parenthetical '(link included)' is a minor waste of tokens.

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 must convey what comes back. It states the categories (bullish/bearish stretches) but not what a stretch contains, how it is dated, or whether year defaults to the current year. Combined with 0% parameter coverage, an agent has enough to attempt a call but not to predict the result.

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

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

Schema description coverage is 0% for both parameters, so the description carries the burden. It only implicitly hints at asset and year scope via 'the S&P 500's trends' and 'the full year'; the enum values and the year parameter's role/default are never explained, and the month dimension implied by 'touching the current month' is not tied to any parameter.

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 ('Bullish and bearish seasonal stretches') and its source ('as shown on The Market Calendar'), so an agent knows it returns seasonal trend windows. However, it never differentiates itself from near-identical siblings such as window_seasonality, seasonal_pattern, or monthly_seasonality, leaving the agent to guess which seasonal tool to call.

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

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

It provides a genuine access constraint: free users only get the S&P 500's trends touching the current month, while the full year and other assets are Pro. That tells the agent when the tool will return partial data, but no alternative tool is named for the Pro-only or other-asset cases, and there is no positive 'use this when...' 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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description goes beyond them by disclosing the paywall behavior, the pro_required fallback, and the exact aggregate fields returned. It does not discuss rate limits or latency, but the access model is unusually well disclosed.

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 core behavior front-loaded and the access constraint second. Nothing is wasted, though the second sentence packs paywall, fallback, and a flag name together tightly enough to be slightly hard 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?

With no output schema, the description usefully enumerates the return aggregates and the pro_required fallback, which is what an agent most needs. It omits edge cases (invalid MM-DD, windows crossing year boundaries, empty history) but is complete for normal invocation.

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 67%, and the schema already documents start/end as MM-DD and the asset enum. The description restates the MM-DD format but adds no new semantics such as window-length limits, timezone handling, or year range, so it does not compensate for the coverage gap.

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+scope: past-year returns over a calendar window defined by start/end MM-DD, and enumerates the outputs (average, median, % of years up, best/worst years). This is clearly distinguishable from siblings like day_seasonality and monthly_seasonality without opening either schema.

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

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

It conveys when the tool is free (S&P 500 windows inside the current month) versus when it degrades to covered months plus a Pro link, which is real usage context. However, it never says when to prefer this over monthly_seasonality or day_seasonality, so routing between the seasonality siblings remains inferential.

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