public

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 genuine extra context: 'Stateless taster; nothing is stored' and the stance that it surfaces conflict rather than smoothing it over, which is useful behavioral character beyond the structured fields.

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-loads the usage trigger, then adds two compact behavioral notes. Slightly stylized phrasing ('DSGHT surfaces the conflict rather than smoothing it over') is close to marketing but still conveys behavior, so it earns most of 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?

For a single-parameter, read-only analysis tool with no output schema, the description supplies the trigger, the statelessness, and the analytical stance. Nothing critical is missing, though it does not say what form the output takes or how conflicts are presented.

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?

One parameter with 100% schema description coverage, so the schema already documents 'text'. The description restates the input as pasted strategy text but adds no format, length, or structural guidance beyond what the schema provides. 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?

States a specific verb (detects) and a precise resource (structural contradictions / tensions in strategy text), and the phrase 'user pastes strategy text' distinguishes it from data-retrieval siblings like get_public_tensions and extract_assumptions. An agent can tell what it produces without opening the 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?

Gives an explicit trigger: 'Use when the user pastes strategy text and asks what is internally inconsistent.' That is clear usage context, but it names no alternatives or when-not-to-use conditions (e.g. vs. extract_assumptions or get_public_tensions).

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 read-only, idempotent, non-destructive, and open-world traits, so the bar is lower; the description still adds material context by declaring the operation stateless and non-persistent, and clarifying that monitoring and a Brier track record live only in the authenticated tier. That is real disclosure 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?

Front-loaded with the usage trigger, then the extraction scope, then the stateless/authenticated contrast. Three dense sentences with little waste, though the parenthetical and tier caveat make it slightly longer than strictly necessary.

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 result, and it does so by naming the assumption categories returned. Nothing critical for invocation is missing; only return format/pagination details are absent, which is minor for a single-input extraction 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 100% for the single 'text' parameter, so the schema already defines the input. The description adds only a light constraint on what kind of text qualifies (strategy/plan/memo), which is marginal over the schema's 'Strategy / plan / memo text to analyze' — 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 ('extracts the falsifiable, load-bearing assumptions') and pins the output further as 'dated/quantified bets + structural findings.' It also distinguishes itself from the sibling set by contrasting the stateless extraction with the authenticated persistent registry.

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 trigger: 'Use when the user pastes a strategy, plan, or memo and wants its hidden bets made explicit.' The 'stateless taster — nothing is stored' clause tells the agent when NOT to use it (persistence/monitoring needs the authenticated tier). It does not, however, route the agent away from the related sibling detect_tensions.

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, destructiveHint=false and openWorldHint=false, so 'offline' largely restates structured data. The description does add genuine extra context beyond annotations: results are deterministic and cited, and omitting year returns the full annual series rather than a single point.

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 core action and scope, then the usage trigger and argument guidance. No filler; every clause (deterministic, offline, cited, series-default) carries information.

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 3-parameter read-only lookup with no output schema, the description covers what the tool returns conceptually (a cited macro figure or full annual series) and how to invoke it. It does not specify units, citation format, or coverage gaps per jurisdiction, a minor but real gap given there is no output schema to fall back on.

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 description reinforces indicator (listing inflation | gdp_growth, matching the enum) and jurisdiction (format confirmed via CZ, DE, US). The real added value is the year semantics — omitting it yields the full annual series — which the schema does not state, only calling it an 'optional 4-digit year'.

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 (look up), resource (country's authoritative macro indicator), and enumerates the exact indicator values. The qualifying phrase 'deterministic, offline, cited' sharply separates it from recalling figures from memory and from sibling tools like resolve_country_claim or list_countries.

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 clear triggering condition: 'Use whenever you need a real macro figure instead of recalling one from memory.' That is strong positive guidance, but it names no alternative tool or exclusion (e.g. when to prefer resolve_country_claim or get_public_claims instead), so it stops short of full when/when-not coverage.

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, destructiveHint=false and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: claims come with a cited source page, the response includes a census by status, and uncited claims are counted but never served as sourced. That last point is a real output-shaping constraint not visible in any structured field.

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, front-loaded with the resource and scope, then the use condition, then the key behavioral caveat. No filler; every sentence carries information the agent needs.

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 the work of describing returns: claims with URL plus quoted passage, and a census of verified/cited/uncited counts. It does not mention pagination or ordering, though limit/offset in the schema imply it. Adequate for a simple read tool, with a small remaining 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?

Schema description coverage is 100%, so all five parameters are already documented in the schema, including the status enum and the limit/offset pagination. The description only loosely echoes status via 'verified, cited or uncited' and adds no syntax or format 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?

States a specific verb and resource ('get the evidence claims behind a published future-space'), and narrows the scope precisely to claims 'that carry a cited source page (URL + quoted passage)'. This is clearly distinguishable from siblings like get_public_forecasts, get_public_scenarios, or get_public_tensions without opening any 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?

Gives an explicit use condition: 'Use when you need quotable, source-backed facts on a covered topic.' It also implies an exclusion ('Uncited claims are counted, never served as sourced'), telling the agent this tool will not return uncited claims as sources. No sibling is named as an alternative, so it stops 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 readOnly, idempotent, non-destructive, closed-world; the description adds useful behavior beyond them by disclosing the append-only registry nature and what each entry contains (advance-stated probability/threshold/date plus resolution and Brier score).

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 resource definition and trailing with the usage trigger; dense but no filler, though the long first sentence packs several concepts that could be split.

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 fields, and annotations cover the safety profile; the only minor gap is not explaining how status values map to the returned entries.

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 (slug, status enum) are already documented with the default and allowed values; the description adds no extra syntax or meaning beyond that 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?

States a specific verb (get) and resource (append-only forecast registry of a published future-space) and enumerates the returned content (probability, threshold, date, resolution, Brier score), which cleanly separates it from siblings like get_public_claims and get_public_scenarios.

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 explicit triggering contexts – questions about DSGHT's forecast reliability or the dated checkable predictions a space makes – but does not name alternative tools or state when to prefer them (e.g. get_public_scenarios).

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful context that the payload is markdown and that only the latest report is returned, but says nothing about size, staleness, or failure when a space has no report.

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, zero filler, with the core action and output format front-loaded and the usage condition following. 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 read tool with a full annotation set and no output schema, the description covers action, scope, format, and usage trigger. It could still note behavior when no report exists or whether the result is paginated, but nothing essential to calling it correctly 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?

Schema coverage is 100% for the single slug parameter, and the schema itself points to list_public_spaces for sourcing the value. The description's phrase "for a published future-space" reinforces the parameter's meaning but adds no format or syntax detail beyond the schema, 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?

States a specific verb (Get) and resource (the latest full foresight report, in markdown) scoped to a published future-space. That distinguishes it from the artifact-level siblings get_public_claims/forecasts/scenarios, but it never names a sibling explicitly, so differentiation is implicit rather than stated.

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?

"Use when the user wants the detailed analysis, or a quotable, cited source on a covered topic" gives a clear selection condition. There is no explicit when-not or named alternative (e.g., use get_public_claims for a single claim), so it stops short of full routing 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 and non-destructive, so the safety profile is covered. The description adds that the result is a probability-weighted matrix tied to a *published* space, but says nothing about output shape, caching, or what happens with an unpublished/invalid slug.

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, zero filler, with the what-it-returns clause front-loaded before the usage guidance. Every sentence 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 single-param read tool whose annotations cover safety, the description supplies the purpose suffices definition. It partially compensates for the absent output schema by naming the return ('scenario matrix with probabilities'), though it could say more about matrix dimensions or probability semantics.

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?

Only one parameter and schema description coverage is 100%, where the schema already says 'future-space slug from list_public_spaces'. The description adds no syntax, format, or constraint detail 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 ('Get the scenario matrix') plus the scope qualifier ('for a published future-space'), which separates it from the single-forecast siblings like get_public_forecasts. An agent can identify the tool without opening the 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?

Gives clear triggering conditions: user asks how a domain might play out, what the plausible futures are, or wants to reason across scenarios rather than a single forecast. It implicitly contrasts with the single-forecast sibling but never names an alternative tool explicitly, so it stops 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one useful interpretive note — that it surfaces contradictions rather than averaging them — but says nothing about scope limits, missing-space behavior, or response shape.

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 tight sentences, front-loaded with the resource before the usage triggers. The final 'DSGHT surfaces contradictions rather than averaging them' sentence is slightly promotional but does add interpretive framing, 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?

For a single-parameter read tool with no output schema and full annotation coverage, the description supplies what to fetch and when. It is essentially complete, with only sibling disambiguation and return-character details left implicit.

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% and the single slug parameter is documented as coming from list_public_spaces, so the schema carries the full burden. The description adds no format, source, or validation detail beyond it; 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?

States a specific verb and resource ('Get the structural tensions ... for a published future-space') and glosses the resource with 'load-bearing contradictions,' which is more informative than the title alone. It does not explicitly differentiate itself from the sibling detect_tensions, so the agent must infer that 'public'/'published' is the distinguishing scope.

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 concrete trigger conditions: 'Use when the user asks what forces conflict, what could break a strategy, or what the tensions/paradoxes are.' That is clear usage context, but it names no alternative (e.g. detect_tensions) or exclusions, leaving the agent to infer when a sibling is preferable.

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 useful context beyond that by disclosing what the listing contains (per-country year coverage and source), which helps the agent interpret the result, though it says nothing about ordering, size, or pagination.

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 waste: the first states what is listed and for whom, the second states when to call it. Purpose and trigger are both 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?

With no output schema and no parameters, the description carries the burden and largely meets it by naming the returned fields (jurisdictions, indicators, year coverage, source). A brief note on the shape of the response would make it fully self-sufficient, but nothing needed to call it correctly 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; there is nothing for the description to disambiguate. It correctly does not invent parameter semantics for a no-arg listing 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?

States a specific verb and resource ('List the jurisdictions and macro indicators') and scopes it to the two downstream consumers, resolve_country_claim and get_country_indicator. It also names the payload contents (per-country year coverage and source), so an agent can distinguish it from sibling lookup tools without opening a 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?

Explicitly states the trigger: 'Call this to check coverage before resolving a claim or looking up an indicator,' naming both alternative tools it precedes. The when-to-use condition is unambiguous, leaving nothing 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 cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds meaningful context beyond them by disclosing the returned fields and the tool's role as an entry point, and there is no output schema to carry that burden instead.

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 zero filler: the return fields are front-loaded and the usage instruction follows immediately. Nothing repeats the name or annotations.

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 parameterless, read-only list tool with rich annotations and no output schema, the description is nearly complete. Minor gaps remain: no pagination/result-size guidance and no explanation of the 'DSGHT' term or what status/depth values mean.

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; the schema has no parameters to document and the description correctly spends no space on them.

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 ('DSGHT future-spaces published for public use'), and enumerates the returned fields (slug, topic, status, depth). It distinguishes itself from most siblings by emphasizing the public-discovery scope, though it never explicitly contrasts with the adjacent search_spaces tool.

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?

'Call this first to discover what foresight is available before fetching scenarios, tensions, or a report' gives clear sequencing and names the downstream tools (get_public_scenarios, get_public_tensions, get_public_report) it feeds. No explicit when-not-to-use or search_spaces alternative is given, 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 readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: the operation is 'deterministic and offline' and returns a cited verdict rather than a raw number. It does not say what happens for an unsupported jurisdiction or ambiguous subject, keeping it short of 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?

Three sentences, front-loaded with the WHENEVER trigger before the mechanism and the return shape. Parenthetical examples earn their space; the only slight drag is the redundant restatement of the jurisdiction example in both the sentence and the schema.

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 5-param, no-output-schema tool with solid annotations, the description covers the trigger, the jurisdiction-binding mechanism, and the return shape ('cited above/below verdict'). Missing only edge-case behavior (unsupported jurisdiction, how resolve_by interacts with a claim) for a full 5.

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 60%, and the description adds meaning for two of five params — jurisdiction (CZ, DE examples) and subject (inflation, GDP, interest rates) — while direction, threshold, and especially resolve_by get no explanation anywhere. Moderate coverage plus partial compensation lands at 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 and resource — it 'binds the claim to a jurisdiction' and 'returns a cited above/below verdict' — which is far more concrete than the title alone. It distinguishes itself from a generic memory answer (wrong jurisdiction risk), but it never names the nearest sibling tools (e.g. get_country_indicator) it must be told apart from, so routing still requires 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?

It gives an explicit trigger ('WHENEVER the user states or asks you to verify a numeric macro claim'), scopes it to specific subject matter (inflation, GDP, interest rates), and names the anti-pattern it replaces — answering from memory with a possibly wrong jurisdiction. That is about as close to explicit when/when-not guidance as a description gets.

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 safety (readOnly, idempotent, non-destructive, closed-world). The description adds real behavioral context beyond them: matching is plain-text ranked with no AI/semantic component, and only 'published' spaces are searched. It doesn't state result count, pagination, or empty-result behavior.

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 no filler; the primary purpose leads and the usage condition follows. Every clause carries information.

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 purpose, matching method, and the hand-off to retrieval tools, which is what an agent needs to decide to call it. With no output schema, it could briefly say what comes back (e.g. ranked space slugs/names) to close the loop before the follow-up get_public_* calls.

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 query parameter is already documented with an example, so the baseline is 3. The description goes further by specifying the fields the keyword is matched against (topic + report text), which tells the agent what kinds of terms will actually hit.

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 (find/search) plus the resource (published DSGHT future-space) and the matching mechanism (keyword over topic + report text). It is clearly distinguishable from list_public_spaces and from the get_public_* retrieval siblings, which it names.

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 an explicit trigger condition: use it to locate a space before calling get_public_scenarios / get_public_tensions / get_public_report when the slug is unknown. It does not mention list_public_spaces as the browse-style alternative, so the routing picture is slightly incomplete.

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