Scrutica

scrutica_get_sovereign_program

Read-only

Fetch detailed data on a national sovereign AI compute program. Returns: announced_usd, announced_govt_only_usd, committed_usd, disbursed_usd, reality_ratio, status, key_partners, governance_reach, NVIDIA/US dependency, source_count. 'list_all' returns a summary table of all tracked programs.

READ THE TWO ANNOUNCED FIELDS BEFORE COMPARING COUNTRIES. announced_usd is the all-capital headline and rolls private commitments in with government money, so it is NOT comparable across countries as-is: the UAE line ($518.74B) and France ($201.34B) are dominated by private vehicles (Stargate UAE, SoftBank), while the US line ($2.6B) is essentially NAIRR alone. announced_govt_only_usd is the government-only figure and is the comparable one. reality_ratio = disbursed_usd / announced_govt_only_usd (falling back to announced_usd only when no government-only figure exists). It is deliberately NOT disbursed_usd / announced_usd. Each row includes reality_ratio_denominator_usd and reality_ratio_denominator_field so the division is reproducible from the payload. reality_ratio is null for most programs because disbursed_usd is unpublished — see reality_ratio_unavailable_reason. Absence concentrates in the least transparent programs (Saudi, China, Korea, UAE all report no disbursed figure), so a ranking by reality_ratio is a ranking of DISCLOSURE, not of execution; do not present it as the latter.

Input Schema

TableJSON Schema

Name	Required	Description
`country`	No	ISO 3166-1 alpha-2
`list_all`	No	Return summary of all sovereign programs instead of a single record
`program_id`	No	Scrutica sovereign-program ID in the form 'sovereign-<country_code>' (e.g. 'sovereign-ae'), as returned by scrutica_search and list_all. The bare country_code is also accepted. Regional programs use non-ISO codes ('sovereign-eurohpc', 'sovereign-nato-aukus', 'sovereign-africa-regional') and are reachable ONLY via program_id or list_all — the 2-letter country parameter cannot match them.

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint annotation by disclosing the fallback behavior of reality_ratio (denominator selection), the reproducibility fields, and the systematic absence of data for least transparent programs. This level of behavioral detail is exceptional and prevents misinterpretation.

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 dense and front-loaded with the core purpose and return fields, followed by crucial interpretation warnings. Every section earns its place, though a small amount of redundancy around 'the comparable one' could be trimmed without losing clarity.

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?

With no output schema, the description does an excellent job explaining the critical returned fields and their caveats. It is slightly incomplete regarding secondary field values and what happens when no parameters are provided, but the essential usage context is fully covered.

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 coverage is 100%, so the parameter descriptions already fully document country, list_all, and program_id. The tool description mostly repeats the list_all behavior rather than adding new parameter-level semantics, so the baseline score of 3 is appropriate.

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 opens with a specific verb and resource: 'Fetch detailed data on a national sovereign AI compute program.' It also lists the returned fields, making the tool's function unmistakable while naturally distinguishing it from sibling tools like scrutica_get_company and scrutica_get_facility.

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

Usage Guidelines5/5

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

Provides explicit usage guidance: the reader is told to read the two announced fields before comparing countries, that announced_usd is NOT comparable across countries, and that reality_ratio rankings are rankings of disclosure, not execution. It also names the list_all alternative for summary data and clarifies that regional programs are only reachable via program_id or list_all.

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

All Scrutica tools Inspect

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.4/5.0

Disambiguation5/5

Each tool targets a clearly distinct resource or action: canonical entity/facility/program lookups, free-text search, supply-chain traversal, BIS query versus BIS change-log, FLOP estimation, and methodology docs. Cross-references explicitly redirect likely-confused intents, such as using scrutica_query_export_controls for entity designations and scrutica_entity_list_changes for changes, so misselection is unlikely.

Naming Consistency4/5

The naming is mostly consistent: scrutica_get_* for canonical lookups, plus clear action-style names like scrutica_search, scrutica_query_export_controls, and scrutica_estimate_flops. The main deviation is scrutica_entity_list_changes, which reads as a noun phrase rather than a verb-first tool name, so the pattern is coherent but not perfectly uniform.

Tool Count5/5

Ten tools is well calibrated for this server's broad but focused domain coverage. Each meaningful data area gets one or two dedicated tools—companies, facilities, sovereign programs, supply chain, export controls, scenarios, methodology, and FLOP estimation—with no count-inflating duplicates.

Completeness4/5

The read-side surface is largely complete: search, get-by-ID, change-tracking, relationship traversal, scenario retrieval, and methodology lookup all exist. The main gap is that some methodology topics describe metrics or indices—such as cost-index and compute-visibility index—without an obvious dedicated tool for retrieving those metric values directly.

Resources

Need Help?