public

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

With no annotations provided, the description carries full transparency burden. It discloses statelessness ('nothing is stored') and the non-modifying nature ('surfaces the conflict rather than smoothing'), but omits details on authentication, rate limits, or output format. The hint about return values is insufficient for a tool without output schema.

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 concise at two sentences, front-loaded with usage guidance, and every phrase adds value. 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?

Given the tool's simplicity (one param, no output schema, no annotations), the description adequately covers purpose, usage, and key behavioral traits. However, it lacks differentiation from sibling tools and does not describe the output structure, which would be helpful for an agent.

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 input schema covers 100% of parameters with a clear description of 'text'. The tool description adds minimal value beyond the schema, simply reinforcing the usage context; it does not elaborate on format, constraints, or examples.

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

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

The description clearly states the tool detects structural contradictions in strategy text, using specific language like 'bets on two things that cannot both hold.' It distinguishes itself from sibling tools by emphasizing it's a stateless taster that surfaces conflicts rather than smoothing them over.

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 explicitly says 'Use when the user pastes strategy text and asks what is internally inconsistent,' providing a clear trigger. However, it does not mention when not to use it or compare to alternative sibling tools like extract_assumptions.

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

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

With no annotations, the description carries full burden. It discloses statelessness ('nothing is stored') and hints at output content ('dated/quantified bets + structural findings'). However, it lacks details on exact response format or potential side effects, which are minimal here. Adequate for a simple stateless tool.

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 use case, no redundant words. Efficiently conveys purpose and key behavioral trait (statelessness).

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 tool with one parameter and no output schema, the description covers purpose, usage, statelessness, and output content hints. It explains the output as 'falsifiable, load-bearing assumptions (dated/quantified bets + structural findings)', which is sufficient to set expectations.

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% (one parameter described). The description adds context ('when the user pastes...') but does not add semantic meaning beyond what the input schema provides ('Strategy / plan / memo text to analyze (plain text)'). 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 clearly identifies the verb ('extracts') and the resource ('hidden bets' from strategy/plan/memo text). It distinguishes from siblings by mentioning the persistent registry alternative, but does not directly compare to sibling tool 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?

The description explicitly states when to use: 'when the user pastes a strategy, plan, or memo and wants its hidden bets made explicit.' It implies not to use this for persistent storage by noting it's a 'stateless taster' and referencing an 'authenticated tier' alternative, though no specific alternative name is given.

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

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

With no annotations, the description carries the full burden. It describes the tool as 'deterministic, offline, cited', which adds behavioral context. However, it lacks details on error handling (e.g., invalid jurisdiction) and does not specify the return format or what happens with the optional year omitted.

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 sentences, front-loaded with the purpose, and no unnecessary words. Every sentence adds value, making it highly concise and well-structured.

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?

The description covers purpose, usage, and parameter behavior adequately for a 3-parameter tool. However, without an output schema, it does not specify the return value format (e.g., number, series) or error scenarios, leaving some gaps.

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

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

The description adds meaning beyond the input schema by explaining the effect of omitting the year ('omit for the full annual series') and reiterating the indicator values. This helps the agent understand parameter behavior beyond the schema descriptions.

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

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

The description clearly states the tool's action: 'Look up a country's authoritative macro indicator (inflation | gdp_growth) directly'. It specifies the exact resource (macro indicators) and verb (look up), and the sibling tools are unrelated, so differentiation is inherent.

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 advises 'Use whenever you need a real macro figure instead of recalling one from memory', providing clear context for when to use the tool. It does not explicitly state when not to use it or name alternatives, but the context is sufficient given the sibling tools are not alternatives for this task.

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

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

The description indicates it retrieves a report in markdown format, implying read-only behavior. However, it does not disclose potential error states, authentication needs, or rate limits. For a simple retrieval tool, this is adequate but not exhaustive.

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 no wasted words. The description is front-loaded with the action and then the usage context.

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 tool with one parameter and no output schema, the description adequately covers what it returns (latest markdown report) and when to use it. It could mention the output format more explicitly, but 'markdown' is stated.

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

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

The schema already describes the 'slug' parameter as 'future-space slug from list_public_spaces', providing full meaning. The description does not add extra parameter details, so it meets the baseline for 100% 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 clearly states the tool retrieves the latest full foresight report in markdown for a published future-space. It distinguishes from siblings like 'get_public_scenarios' and 'get_public_tensions' by specifying it provides detailed analysis and quotable sources.

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 explicitly says 'Use when the user wants the detailed analysis, or a quotable, cited source on a covered topic,' providing clear guidance on when to invoke this tool over 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?

No annotations and description lacks behavioral details like read-only nature, auth requirements, or output format (e.g., matrix structure). Only mentions 'scenario matrix with probabilities'.

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

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

Two concise sentences: first states purpose, second gives usage context. No wasted words.

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?

Adequate given no output schema; explains what the tool returns (scenario matrix with probabilities) and usage context. Could detail expected output structure.

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 clear slug description. Description adds no extra semantic value beyond schema, so 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?

Description clearly states it returns a scenario matrix with probabilities for a published future-space, distinguishing it from sibling tools like get_public_report or list_public_spaces.

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 tells when to use: when the user asks about plausible futures or wants to reason across scenarios, implying alternatives like single forecast.

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

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

With no annotations, the description carries the full burden. It discloses that DSGHT 'surfaces contradictions rather than averaging them,' clarifying the tool's behavioral trait. It doesn't address auth or rate limits, but for a read tool this is acceptable.

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 no wasted words. The purpose is front-loaded, and every sentence adds value. Ideal conciseness.

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

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

Given the tool's simplicity (one required param, no output schema), the description fully covers purpose, usage, and behavioral context. It adequately differentiates from 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 coverage is 100% for the single parameter 'slug', and the description only mentions 'slug from list_public_spaces', adding little beyond the schema description. Baseline 3 is appropriate as the schema already does the heavy lifting.

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

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

The description clearly states 'Get the structural tensions — the load-bearing contradictions — for a published future-space.' It uses a specific verb ('Get') and resource ('structural tensions'), and distinguishes from siblings like 'detect_tensions' and 'extract_assumptions' by focusing on published future-spaces.

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

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

Provides explicit usage guidance: 'Use when the user asks what forces conflict, what could break a strategy, or what the tensions/paradoxes are in a covered domain.' It gives clear context but does not explicitly state when not to use or name alternatives like '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?

No annotations provided, but the description implies a read-only listing operation. It does not detail side effects, but given the simplicity, this is sufficient.

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 redundancy. First sentence defines purpose and content; second gives usage guidance. Efficient and well-structured.

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?

Complete given tool simplicity: no parameters, no output schema. Description covers what is returned and when to use it, plus references to sibling tools.

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?

No parameters, so baseline 4. The description adds context about what is listed and its relation to other tools, going beyond schema which has no fields.

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?

Clearly states it lists jurisdictions, macro indicators, year coverage, and source, and names the sibling tools it supports, distinguishing it from other 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?

Explicitly instructs to call it before resolving claims or looking up indicators, providing direct usage guidance and implicit when-not-to-use (not for other purposes).

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

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

No annotations provided, so description carries full burden. It discloses that the tool lists public spaces with specific fields, implying a read-only operation. It does not mention authentication, rate limits, or potential side effects, but for a simple list tool, this is adequate.

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 no fluff. The first sentence states purpose and payload; the second provides usage context. Front-loaded and efficient.

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

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

Given no output schema, the description includes key return fields and usage positioning. It doesn't detail ordering or pagination, but for a simple discovery tool, completeness is high. The workflow guidance adds significant context.

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?

No parameters exist, so schema coverage is 100% vacuously. The description adds value by listing the output fields (slug, topic, status, depth), giving context beyond the empty schema.

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 uses specific verbs ('List') and resource ('DSGHT future-spaces published for public use') with enumerated fields (slug, topic, status, depth). It also positions itself as an initial discovery tool before fetching scenarios, tensions, or reports, distinguishing from siblings.

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 'Call this first to discover what foresight is available before fetching scenarios, tensions, or a report,' providing clear workflow context. However, it doesn't explicitly state when not to use it, leaving some implicit guidance from sibling relationships.

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

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

No annotations are provided, so the description carries full burden. It discloses the tool is deterministic and offline, and returns a cited verdict. However, it doesn't mention prerequisites, error behavior, or any side effects. For a non-destructive tool, this is adequate but could be more transparent about input validation or output structure.

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 sentences, immediately stating the primary use case. Every sentence adds value: first sentence explains when and why, second states output and properties. No unnecessary words; highly efficient.

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

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

Given no output schema, the description only says 'returns a cited above/below verdict', lacking details on the full return format (e.g., cited value, source). The tool has 5 parameters and no output schema, so more completeness on output would be beneficial. However, the description adequately covers the core behavior.

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% (3 of 5 params described). The description adds context that the claim is numeric macro (subject) and binds to jurisdiction. It doesn't elaborate on format for resolve_by or threshold beyond schema. The enum for direction is covered by schema. Overall, the description adds some value over schema but does not fully compensate for the undocumented parameters.

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

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

The description clearly states the tool resolves numeric macro claims by comparing to the country's authoritative series, distinguishing it from memory or generic data. It uses specific verbs like 'resolve' and 'verify', and contrasts with sibling tools like get_country_indicator by emphasizing the claim resolution functionality.

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 explicitly says 'Use this WHENEVER the user states or asks you to verify a numeric macro claim...' and advises against answering from memory. It does not name alternative sibling tools but implicitly excludes them by focusing on claim settlement. The context is clear, but no explicit 'when not to use' or alternative tool mentions 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?

With no annotations, the description must disclose behavioral traits. It mentions plain-text ranking and absence of AI, but omits details like return format (single result vs. list), handling of no results, and whether only published spaces are searched. These gaps limit transparency.

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 no redundancy. The first sentence states purpose and method, the second gives usage guidance. Information is front-loaded and efficiently presented.

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?

While adequate for a simple tool, the description does not specify the output format (single result vs. list, structure of matches). Without an output schema, this hinders an agent's ability to process results correctly. More detail on return type would improve completeness.

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 input schema has 100% coverage with a single parameter. The description adds value by explaining that the query searches both topic and report text, and provides an example ('open banking consent'), going beyond the schema.

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

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

The description clearly states the tool's purpose: finding published future-spaces by keyword search. It uses a specific verb ('Find') and resource ('published DSGHT future-space'), and distinguishes from sibling tools (get_public_scenarios, etc.) which require a known slug.

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 explicitly advises using this tool when the slug is unknown before calling get_public_scenarios, get_public_tensions, or get_public_report. This provides clear context for when to use it versus alternatives.

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