Find the most relevant published DSGHT future-space by keyword (topic + report text, plain-text ranked, no AI). Use this to locate a space before calling get_public_scenarios / get_public_tensions / get_public_report when you do not already know the slug.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | search terms, e.g. "open banking consent" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, the description carries full burden. It discloses the search is plain-text ranked and does not use AI. It also mentions it searches topic and report text. However, it does not address potential behavioral aspects like rate limits, authentication needs, or what happens if no results are found. Still, the disclosed details are informative and non-contradictory.
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, each adding value. It front-loads the purpose and follows with usage context. No redundant or extraneous information. It is efficiently communicated.
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 has one parameter and no output schema, the description covers core functionality well. It names sibling tools that follow from this search. However, it does not mention the output format (e.g., returns slugs, names, or a list) or error handling. This minor omission prevents a perfect score, but in context, the description is still very useful.
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 one parameter 'query' with a brief description. The tool description adds significant meaning by explaining that the query searches topic and report text, and that ranking is plain-text based without AI. This goes beyond the schema's generic description, fully enhancing parameter understanding.
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 the tool searches for published DSGHT future-spaces by keyword, specifying it searches topic and report text, and distinguishes it from sibling tools by noting it's used before other space-specific tools. The verb 'find' and resource 'published DSGHT future-space' are specific and unambiguous.
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 this tool: 'Use this to locate a space before calling get_public_scenarios / get_public_tensions / get_public_report when you do not already know the slug.' This provides clear context and exclusion guidance, helping the agent decide between this and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct function: text analysis (detect_tensions, extract_assumptions), retrieval of published foresight (get_public_report, etc.), listing available resources (list_countries, list_public_spaces), searching (search_spaces), and macro claim resolution (resolve_country_claim). Even similar-sounding tools like detect_tensions and get_public_tensions are clearly differentiated by purpose (user-provided text vs. published analysis).
All tool names follow a consistent verb_noun pattern with underscores: detect_tensions, extract_assumptions, get_country_indicator, get_public_report, get_public_scenarios, get_public_tensions, list_countries, list_public_spaces, resolve_country_claim, search_spaces. The verbs are specific and the nouns are descriptive, making the naming predictable and easy to understand.
With 10 tools, the server covers its domain—strategic foresight and macro indicators—without being overwhelming. Each tool serves a clear purpose, and the count is appropriate for the scope: text analysis, resource listing, retrieval, search, and claim resolution. There is no unnecessary bloat or deficiency.
The tool set covers the core workflows: analyzing user-provided strategy text, retrieving published foresight reports/scenarios/tensions, listing available spaces and countries, searching, and resolving macro claims. A minor gap is the lack of a tool to retrieve a specific extracted assumption (though extraction is stateless by design). Overall, the surface is largely complete for a public-facing server.
