Skip to main content
Glama

public

by ai.dsght

resolve_country_claim

Use this WHENEVER the user states or asks you to verify a numeric macro claim (inflation, GDP, interest rates): settle it against the claim's OWN country's authoritative series instead of answering from memory, which risks the wrong jurisdiction (e.g. U.S. CPI for a Czech claim). Binds the claim to a jurisdiction (CZ, DE, ...) and returns a cited above/below verdict. Deterministic and offline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subjectYese.g. "inflation", "GDP growth"
directionYes
thresholdYes
resolve_byNoISO date the claim resolves by, e.g. 2022-12-31
jurisdictionYesISO code, e.g. CZ, DE

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool 'returns a cited above/below verdict' and is 'deterministic and offline'. This covers the key behavioral aspects—output format, no external dependencies, and deterministic nature. No contradictory information.

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

Conciseness4/5

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

The description is two sentences long, with the key usage front-loaded. It conveys necessary context without extraneous content. The second sentence is slightly dense but acceptable for the information density required.

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

Completeness4/5

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

Given no output schema, the description adequately explains return value (cited above/below verdict). It covers the main use case, parameter intent, and behavioral traits. The tool has moderate complexity (5 params), and the description provides sufficient context for correct invocation.

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

Parameters3/5

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

Schema description coverage is 60% (3 of 5 parameters have descriptions). The description reinforces that 'subject' and 'jurisdiction' are used in context, but does not add meaning beyond the schema for parameters like 'resolve_by' or 'threshold'. It partially compensates but does not fully cover the missing 40%.

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

Purpose5/5

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

The description clearly states the specific verb ('resolve a claim') and resource ('numeric macro claim... against the claim's OWN country's authoritative series'). It distinguishes this tool from siblings by emphasizing that it settles claims with authoritative data rather than relying on memory, which could cause jurisdictional errors.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool ('WHENEVER the user states or asks you to verify a numeric macro claim') and warns against answering from memory to avoid wrong jurisdiction. It does not explicitly name alternatives or list when not to use it, but the guidance is clear and actionable.

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

All public toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

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).

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources