Frontier Signal

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds that values are recorded change notes from a JSON file, that notes may be absent, and that no new diff is calculated; it still lacks return structure or pagination detail.

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 sentences, front-loaded with the output and scope. Each sentence adds a useful clarification 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?

This is a low-complexity read-only tool with one optional parameter, and the description explains retrieval scope and non-computation. With no output schema, it names the returned fields but does not detail their structure, leaving a minor gap.

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 observed parameter has full schema description coverage, including the omit-for-latest default. The description does not add parameter-level meaning beyond what the schema already provides, so baseline 3 applies.

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

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

Specific verb and resource: returns deltas_vs_prev and recheck notes for a baseline cut, and explicitly says it does not compute new diffs. It does not name a sibling alternative, so it falls short of top-tier differentiation.

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?

Implied use is retrieving recorded change notes for a baseline cut, with a negative usage note against computing diffs. It gives no explicit when-to-use guidance versus siblings like latest_brief or list_observed_dates, and no prerequisite 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, non-destructive and closed-world, so safety is covered. The description adds genuinely new behavioral context: mention_count is a heuristic copied from the source JSON rather than true hit counts, and the tool does not fabricate categories or counts — a substantive data-fidelity guarantee that prevents misreading results.

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 sentences, front-loaded with the purpose and followed by the two caveats that matter most. No filler, though the phrase "the JSON cut" is left undefined and slightly compresses what could be a clearer provenance statement.

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 explaining results; it names categories and mention_count but leaves the response structure, ordering, typical cardinality, and what qualifies a category as "hot" unspecified. Adequate for a one-optional-parameter read tool, but not fully self-contained.

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 single `observed` parameter is fully documented in the schema, including the format and the omit-for-latest default. The description adds nothing about the parameter, so the baseline of 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?

"Return hot demand categories recorded on a public baseline" gives a specific verb (return) and resource (hot demand categories) with a stated data source. It is clear enough to distinguish from mutation-oriented or listing siblings, but it never explicitly contrasts itself with 'deltas' or 'latest_brief', which sound adjacent.

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 tools (deltas, latest_brief, list_observed_dates) that an agent would need to choose between. Only the schema's "omit for the latest committed cut" hints at usage, and that is parameter-level, not tool-level.

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, non-destructive, closed-world behavior. The description adds a useful failure-mode detail: a miss returns match_kind=none and the tool does not invent a programme, which is meaningful behavioral transparency beyond the 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 description is two short sentences, front-loads the lookup purpose, and immediately states the failure behavior. Every sentence carries useful information with 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?

For a simple two-parameter lookup with full schema coverage and safety annotations, the description provides the essential miss behavior and verification guarantee. It does not describe the full return shape, but no output schema exists and the core lookup semantics are adequately covered.

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 descriptions already explain both parameters, including exact/substring/fuzzy matching and the observed baseline date. The description adds little parameter meaning beyond the schema, so the baseline of 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 states a specific verb and resource: look up one verified programme by exact or fuzzy name. It distinguishes a single lookup from the list-oriented sibling list_buyer_programmes by specifying 'one', though it does not explicitly name alternatives.

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 implied through 'one' and 'by exact or fuzzy name', which suggests single-record lookup rather than listing. However, there is no explicit guidance on when to use this instead of list_buyer_programmes or latest_brief, and no exclusions or prerequisites are provided.

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 and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: gated watchlist sections are stripped from the returned content, and no brief is ever synthesised. What it omits is the failure mode when a date has no brief.

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 sentences, front-loaded with the core action, then the filtering behavior, then the no-synthesis guarantee. No filler and nothing to trim.

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 correctly carries the return-format burden by stating the payload is markdown and that gated sections are removed. The remaining gap is what happens on a date with no brief, which matters for a tool that explicitly refuses to synthesise.

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% with a single optional parameter that already documents the YYYY-MM-DD format and the omit-for-latest behavior. The description reinforces 'for a date' but adds no format or edge-case detail beyond the schema, so 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?

Specific verb and resource: 'Return the public Frontier Signal brief markdown for a date.' This clearly distinguishes it from data-oriented siblings like deltas or demand_mix, though it does not reference list_observed_dates, which is the natural companion for finding valid dates.

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?

'Omit for the latest public brief' gives one selection rule, and 'A brief is never synthesised' implicitly tells the agent not to expect generated content for dates without one. However, it never names list_observed_dates as the way to discover valid dates, so the when-to-use-versus-sibling guidance is only implied.

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, and closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the returned field set and the guarantee that an empty list means no match rather than invented data, which guards against hallucination.

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 tight sentences with the resource and scope front-loaded, followed by the return fields and the empty-result guarantee. No wasted wording.

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 returned fields and explains empty-result semantics. For a simple read-only list tool with fully documented parameters, this is nearly complete, missing only explicit sibling routing.

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 all four filters (type, status, category, observed) are already documented in the schema. The description adds no parameter-level meaning beyond that, so 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?

States a specific verb and resource ('List verified buyer programmes') and clarifies the source scope ('and other sources') plus the baseline origin. It is distinguishable from the singular sibling get_programme, 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?

Usage is implied by the listing verb and the type filter, but there is no explicit when-to-use guidance or routing versus siblings like get_programme or list_observed_dates. An agent must infer that this is the bulk-enumeration tool.

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 that 'no live fetch is performed,' which usefully clarifies that results come from locally checked-out data and may not reflect remote state, but it overlaps with openWorldHint=false and says nothing about ordering or staleness.

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 with the scope and the no-fetch caveat front-loaded. No filler, nothing to cut.

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 enumeration tool with no output schema, the description covers what is listed but not the shape of the return (date format, ordering, how many entries). Low complexity keeps this from being a serious gap, but it is not fully complete.

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 no parameter meaning the description needs to supply. 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?

Names a specific verb and resource: it lists the baseline dates (and public brief dates) available in the checkout. That is concrete enough to distinguish it from siblings like latest_brief or get_programme, though it never names them 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?

There is no guidance on when to call this rather than latest_brief, get_programme, or deltas. The phrase 'available in this checkout' hints at context but gives no conditions or exclusions for choosing this tool.

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