AI compute infrastructure intelligence: facilities, supply chains, sovereign AI, export controls.
Scored across 10 tools
Most tools target a clearly distinct resource (company, facility, supply chain, sovereign program, scenario, methodology) with search as the explicit resolver step. The only real overlap is scrutica_entity_list_changes vs scrutica_query_export_controls, which both draw on the BIS Entity List, but the descriptions sharply separate change-log freshness questions from single-entity row lookups. Minor residual risk of picking the change-log when a simple designation lookup is wanted.
All names share the scrutica_ prefix and snake_case, with a dominant verb_noun shape (get_company, get_facility, get_supply_chain, query_export_controls, estimate_flops, search). Deviations are small: entity_list_changes inverts the pattern and the verbs get_/query_/search/estimate are mixed, but each verb is used semantically consistently. No style chaos.
Ten tools is well within the sweet spot, and each one covers a distinct slice of the domain (search, two entity detail views, export controls, change log, supply chain, sovereign programs, scenarios, methodology, FLOP estimation). No obvious filler or redundant tool.
Core retrieval paths exist (resolve via search, then get_company / get_facility / get_supply_chain / query_export_controls), but there are notable gaps: no listing/browse tool for facilities or companies beyond free-text search, no threshold-based facility query despite the descriptions referencing a threshold table and query tools, and methodology topics like cost-index, compute-visibility-index and chokepoint-cascade have documentation but no corresponding data tools. Scenario access also requires knowing the scenario key in advance.
What CHANGED in the BIS Entity List, as bounded change-log summaries. Backed by the same derivation the public /export-controls/changes page and its RSS feed render. PREFER this over scrutica_query_export_controls for freshness questions ("what changed this month", "latest additions", "recent removals"): designation rows arrive already grouped into per-Federal-Register-notice change events, so you do not re-derive notice grouping from citation strings. Each event includes: canonical FR citation and link, notice title / publication date / document number where the citation resolved to one FR document, a derived event date labeled with the source column it came from, entry / entity / address / removal counts (entry_count counts entries as the Register does: an entity under two destinations is two entries), per-country counts, a bounded sample of entity names, and the entities cross-referenced to compute-infrastructure organizations. Removal actions are returned separately as date-keyed events — a screening list maintained from additions alone over-blocks forever. Also returns a last-N-ISO-week activity rollup counting BOTH additions and removals. Zero-count weeks are a real quiet-Federal-Register signal, not missing data. Results are bounded summaries, never row dumps: at most 24 events per call (default 6, newest first), with any truncation declared in metadata. Cite totals from the count field and per-event entry_count, never by summing a sampled list. Do NOT use this to look up one entity's designation rows — use scrutica_query_export_controls (substring match on the published name). Use company_id here only to scope the log to notices touching an organization you already resolved. Authority tier: Federal-Register-anchored designations are Tier 1 (primary source). Each entry is dated by the effective date of the Federal Register notice that added it, the notice the Entity List's own eCFR citations for the entry resolve to (a removed record: the notice its entry was dated by while the Register printed it, else its own citation's notice), except where no citation resolves to a notice; the event date is derived (modal designation_date, falling back to modal effective_date) and labeled with its source.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max change events to return (default 6, max 24), newest first. The count field always reports the full total in scope. At the Federal Register's Entity-List cadence the default already reaches back several months. | |
| weeks | No | ISO-week span of the activity rollup (default 8 — the change-log page's own window; max 52). | |
| company_id | No | Scope to change events touching one organization. Canonical Scrutica org ID ('org-<slug>'); the id space is the matched_org_id values in the BIS cross-reference, so designated entities without a compute-substrate cross-reference never appear under a scope. Kept events retain their full entity context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true/title, so the description carries the rest and does: hard bounds (24 events max, default 6, newest first), truncation declared in metadata, removal actions returned as separate date-keyed events, zero-count weeks as a real signal rather than missing data, and authority tiering for FR-anchored designations. It even warns against the specific misuse of summing a sampled list to get totals.
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 one-line purpose, then routing, then return contents, then bounds, then authority tier — a sensible order with each block doing distinct work. The final paragraph on notice-dating derivation is dense and partly methodology that could live behind scrutica_get_methodology, costing it a point.
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?
No output schema exists, yet the description enumerates the returned fields (canonical FR citation and link, notice title/date/document number, derived event date with source column, entry/entity/address/removal counts, per-country counts, sampled entity names, compute-infrastructure cross-references) plus the ISO-week rollup. For a bounded-summary tool this is as complete as an agent needs to call it and interpret the result correctly.
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%, so the baseline is 3; the description adds guidance beyond the schema by telling the agent to scope only to organizations already resolved and noting that unmatched entities never surface under a scope. The company_id caveats largely restate the schema's own id-space note, and limit/weeks semantics are covered in the schema, so this is useful reinforcement rather than new parameter knowledge.
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+resource+output shape: 'What CHANGED in the BIS Entity List, as bounded change-log summaries,' and pins it to a known public artifact ('the same derivation the public /export-controls/changes page and its RSS feed render'). It is immediately distinguishable from scrutica_query_export_controls, which is named as the wrong tool for this job.
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?
Explicit routing both ways: 'PREFER this over scrutica_query_export_controls for freshness questions ("what changed this month", "latest additions", "recent removals")' and 'Do NOT use this to look up one entity's designation rows — use scrutica_query_export_controls.' It also constrains company_id to orgs 'you already resolved,' giving an ordering prerequisite, not just an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate hypothetical peak and sustained throughput for a user-specified hardware configuration and precision. Sustained throughput equals dense peak throughput multiplied by accelerator count and utilization. The reported bounds are fixed at 0.7 and 1.15 times that result; they are model assumptions. Retain the bounds and is_estimated flag when quoting the estimate. This tool does not verify a named facility's inventory, availability or regulatory compliance. Named-facility estimates have separate evidence requirements documented at /methodology#flop-estimation.
| Name | Required | Description | Default |
|---|---|---|---|
| sparsity | No | Structured-sparsity mode, accepted and echoed in the response. Both values currently apply a 1.0 multiplier. | dense |
| precision | No | bf16 | |
| unit_count | Yes | Number of accelerators | |
| utilization | No | Fraction of dense peak throughput sustained (0–1; default 0.40). | |
| hardware_type | Yes | GPU / accelerator model |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation. It discloses the calculation model (dense peak × unit_count × utilization), the fixed bounds (0.7 and 1.15), the instruction to retain the bounds and is_estimated flag, and its limitations regarding facility verification. This is rich behavioral context that a caller needs.
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, zero filler. The purpose is front-loaded, the calculation and bounds follow, and the retention/limitations are compactly stated. 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?
The description covers the purpose, the calculation method, output bounds, the is_estimated flag, and points to methodology for named-facility edge cases. It lacks an explicit description of the full output structure (e.g., units, exact fields), but since the bounds and flag are mentioned, and no output schema exists, this is a minor gap. It is sufficiently complete for an agent to call it correctly.
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?
With 80% schema description coverage, the baseline is 3. The description adds meaning to unit_count and utilization via the formula, and mentions precision and hardware configuration. However, it does not explain sparsity or precision beyond what the schema enums already convey, and the precision parameter lacks a schema description. The added formula justifies a 4, but it does not fully compensate for the undocumented precision parameter.
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: 'Estimate hypothetical peak and sustained throughput for a user-specified hardware configuration and precision.' It names the specific verb (estimate) and resource (throughput), and it is distinct from all sibling tools, which handle entities, facilities, or search. No ambiguity about what this tool does.
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 provides context for when to use it: it's for hypothetical estimates, and it explicitly states what it does NOT do (verify facility inventory/availability/compliance) and points to separate requirements for named-facility estimates. However, it does not name alternative tools or provide an explicit 'use this when...' statement, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch complete details for a single organization (company, government entity, holding company) by canonical Scrutica ID. Returns: legal name, country of HQ, organization type, parent / subsidiary references, supply-chain edge counts. US government listings that are not export controls: us_restrictive_listings holds the rows that name the organization, each with its list (dod_1260h: the Defense Department's Section 1260H list of "Chinese military companies"; ofac_ns_cmic: OFAC's Non-SDN Chinese Military-Industrial Complex Companies List; dhs_fascsa_exclusion: a Homeland Security FASCSA exclusion order), whether it is on the current list, the name as printed, its source (Federal Register notice or OFAC list file) and how it was matched (resolution 'name' or 'alias'; 'ambiguous' when the printed name matches several organizations, which are listed). on_1260h and on_ns_cmic are true when a current row resolves to the organization, false when no current row names it, and null when a current row names it among several organizations (unless the stored flag already reads true) or the rows cannot be read: names that match no record are not resolved, so false is not proof of absence. on_ofac_sdn is always null: OFAC's SDN list is not ingested. Use scrutica_query_export_controls for BIS designation details. Use scrutica_get_supply_chain for full edge graphs.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Alias for company_id. | |
| org_id | No | Alias for company_id. | |
| entity_id | No | Alias for company_id. | |
| company_id | No | REQUIRED. Canonical Scrutica organization ID. Format: 'org-<slug>' (e.g. 'org-nvidia', 'org-tsmc', 'org-huawei'). Resolve via scrutica_search first — do NOT guess slugs. Optional in the schema only so the aliases below can stand in; supply exactly one of these. | |
| organization_id | No | Alias for company_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint is already declared, so the bar is lower, yet the description adds substantial value: it documents the tri-state semantics of on_1260h/on_ns_cmic (true/false/null), explains why false is not proof of absence, details the ambiguity case, and warns that on_ofac_sdn is always null because SDN is not ingested. That is exactly the kind of unstated behavior an agent could otherwise misread.
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 purpose and return fields, then the listing caveats. The listing paragraph is dense and somewhat field-documentation-heavy, but since no output schema exists it earns its place; a little tightening would help.
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 must describe return values, and it does so thoroughly, including the null/ambiguous edge cases for listing flags. Minor gap: nothing on error behavior when an ID does not resolve.
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 schema itself documents the company_id format and states that the other four parameters are aliases, so the description need not repeat it. The description names the canonical ID as the key but adds no syntax or disambiguation detail beyond the schema, so the baseline 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 (fetch) and resource (complete details for a single organization) and pins the retrieval key to the canonical Scrutica ID. The 'Returns:' line enumerates exactly which fields come back, which distinguishes it from search and list 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 routes two adjacent needs elsewhere: scrutica_query_export_controls for BIS designation details and scrutica_get_supply_chain for full edge graphs, and the schema directs resolving IDs via scrutica_search first. It does not spell out when not to call it (e.g. bulk lookups), so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch complete details for a single Scrutica facility by canonical ID. Returns: roles[] — each organisation the record names, under the relationship its own source ESTABLISHES (site owner, site operator, AI hardware owner, or another relationship such as PeeringDB listing holder, lessee, developer), with the reason, source URL, quote and authority tier; withheld_roles[] — recorded attributions the cited source does not establish, with the reason; then country, place (the city, town or census-designated place containing the site, else its county; then state and country) with place_basis saying how it was derived, the source's own location cells verbatim (source_location_cells), power capacity (MW), GPU inventory (where disclosed), location (lat/lng), facility type, status, data_source, source_url, is_estimated flags, and any logged data-quality flags (cross-source divergence investigations). present_inventory is Scrutica's partition-by-partition compute evidence (the verdict the facility page, threshold table and query tools use): each accelerator partition admitted at its cited 16-bit rate (rate_format names FP16 or BF16, as the vendor prints it; rate_sparsity says dense, or unstated where the vendor labels the rate neither way) or held with a reason; one held partition withholds the facility figure. Read facility_peak_pflops_16bit, dense_16bit_tflops_per_accelerator and peak_pflops_16bit. The deprecated facility_peak_pflops_fp16, dense_fp16_tflops_per_accelerator and peak_pflops_fp16 keep their earlier meaning, a figure at an FP16 rate: they are null for a BF16 partition, and the facility figure is null unless every partition is admitted at FP16. facility.peak_pflops_fp16 and h100_equivalent_gpus are the record's catalogue scalars, a different basis. Describe an organisation as the site's owner ONLY where roles[] names it "Site owner"; a recorded organisation is not by itself evidence of title or operation. Where a role's evidence covers only part of the record, that role's scope_extent is "part", scope names the part, and the role reads "…, for "; state the role of that part only, never of the whole site. For BIS Entity List designations tied to an organisation recorded at the facility, look it up via scrutica_query_export_controls — this tool does not compute ownership-chain BIS exposure. Resolve facility IDs first via scrutica_search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Alias for facility_id. | |
| entity_id | No | Alias for facility_id. | |
| facility_id | No | REQUIRED. Canonical Scrutica facility ID. Format: 'fac-<slug>' (e.g. 'fac-tsmc-arizona-fab21-p2', 'fac-tsmc-fab-18'). Resolve via scrutica_search first — do NOT guess slugs. Optional in the schema only so the aliases below can stand in; supply exactly one of these. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, but the description adds substantial behavioral context beyond that: roles vs withheld_roles, scope_extent and part-site role semantics, present_inventory admission rules, deprecated FP16 field behavior, null propagation, and BIS routing. It also warns how to describe organisations only where roles[] establishes a relationship, which is important interpretive 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?
The description is front-loaded with the core action, then proceeds through returns, inventory semantics, caveats and alternatives. It is dense and long, but much of that density is warranted because there is no output schema; a few passages around deprecated fields and catalogue scalars are verbose but still earn their 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?
Given the tool's complexity and the absence of an output schema, the description is unusually complete. It explains the return structure, derivation semantics, withheld roles, inventory partitions, null behavior, role scoping, and when to use sibling tools, leaving little an agent would need to infer before calling it.
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 facility_id plus two aliases fully documented, including the 'fac-<slug>' format and the warning not to guess slugs. The description reinforces the canonical ID and search-first resolution, but it does not add parameter meaning beyond what the schema already provides, so the 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 first sentence states a specific verb and resource: fetch complete details for a single Scrutica facility by canonical ID. It distinguishes this from sibling retrieval/search tools by naming scrutica_search for ID resolution and scrutica_query_export_controls for BIS exposure. An agent can identify the tool's purpose 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?
The description gives explicit workflow guidance: resolve facility IDs first via scrutica_search, and use scrutica_query_export_controls for BIS Entity List designations. It also states what this tool does not compute, namely ownership-chain BIS exposure, leaving no ambiguity about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return methodology documentation for a Scrutica metric or index. Topics: 'flop-estimation', 'cost-index', 'compute-visibility-index', 'supply-chain-weighting', 'chokepoint-cascade', 'sovereign-execution-classification'. Returns the canonical URL + section anchor + summary. Use this when a user asks "how did you calculate X".
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
ReadOnlyHint is true, and the description adds valuable detail about the return shape (canonical URL + section anchor + summary). This exceeds the annotation's simple safety signal, though it doesn't describe edge cases or additional 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?
The description is compact and front-loaded: purpose in the first sentence, topics in the second, and return/usage in the third. No filler words, and every sentence adds distinct 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 one-parameter tool with a clear enum and a read-only action, the description covers purpose, usage trigger, topic list, and return format. Even without an output schema, the agent knows what to expect. It is complete for the tool's simplicity.
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 0%, so the description must compensate. It does by listing all enum values in prose and explaining that the topic refers to a 'metric or index,' which adds context beyond the bare enum. Given the single parameter's simplicity, this is sufficient.
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 opens with a specific verb+resource: 'Return methodology documentation for a Scrutica metric or index.' It clearly distinguishes this from sibling tools focused on entities, scenarios, or searches. The explicit list of topics further clarifies 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?
The description provides an explicit when-to-use instruction: 'Use this when a user asks "how did you calculate X".' However, it does not mention when not to use it or name alternative tools, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch geopolitical compute risk scenarios. Available: 'taiwan-strait' (4 TSMC disruption scenarios), 'iran-threat' (IRGC missile range vs Gulf compute), 'tokyo-earthquake' (Japan memory-fab exposure), 'abqaiq-2' (Saudi grid). Returns the scenario's summary plus its substrate serialized from the interactive page's own data modules — assumption scenarios / threat systems / affected assets with per-item sources and authority tiers, capped lists shipping their true totals. The propagation SIMULATION itself remains interactive-only at the returned URL.
| Name | Required | Description | Default |
|---|---|---|---|
| scenario_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true; the description adds the substantive behavior an agent needs, namely what is returned (summary plus substrate serialized from the page's data modules), how it is structured (assumption scenarios / threat systems / affected assets, each with sources and authority tiers), and that capped lists carry true totals. The explicit disclosure that simulation is unavailable here is a genuinely useful limitation. It loses a point only because the serialized shape is described in prose rather than mapping cleanly to a predictable response contract.
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 one-line purpose, then the enumeration, then return semantics and the interactive-only caveat in priority order. It is dense but every clause carries information; phrases like "capped lists shipping their true totals" are terse to the point of mild opacity.
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 must explain return values and does: summary, substrate contents, per-item sourcing, authority tiers, and list truncation. Combined with the interactive-only caveat, an agent has everything needed to call this and interpret the result.
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 0%, so the description carries the full burden, and it does so by glossing every enum value: TSMC disruption scenarios, IRGC missile range vs Gulf compute, Japan memory-fab exposure, Saudi grid. An agent can pick the right scenario_id without guessing.
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?
"Fetch geopolitical compute risk scenarios" is a specific verb plus resource, and the four enumerated scenario IDs immediately show the scope. Nothing here overlaps with siblings like scrutica_get_company or scrutica_get_facility, so an agent can route on the first sentence alone.
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 enumeration of the four available scenario IDs functions as a de facto selection guide, and the closing note that the propagation simulation is interactive-only at the returned URL marks a clear capability boundary. It stops short of naming when to prefer a sibling tool (e.g. search vs. this fetch), so it is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, NVIDIA/US dependency, source_count, and published_spending (a government's own spending figures, each in its currency against its budget, with the document). 'list_all' returns a summary table of all tracked programs.
announced_usd can include private commitments; announced_govt_only_usd records the government-funded portion. Compare the programme sources for scope, dates and currency conversions. A government-only figure can still span a different budget period or initiative from another programme's figure. reality_ratio divides disbursed_usd by announced_govt_only_usd, using announced_usd when the government-only field is null. The ratio is null when disbursement or the denominator is missing, or the denominator is zero. Each row includes reality_ratio_denominator_usd and reality_ratio_denominator_field so the division is reproducible from the payload. Where disbursed_usd converts a government's published spending figure, reality_ratio_basis is native_currency and the ratio divides that figure by its own budget in the source currency (reality_ratio_numerator_native / reality_ratio_denominator_native, in reality_ratio_currency): the two dollar amounts were converted on different dates and do not reproduce it. disbursed_usd derives only from a government's published expenditure or payments; a transfer to an administering body is listed in published_spending as released and is not counted. Missing fields and differing reporting scopes limit comparisons; reality_ratio_unavailable_reason explains an absent ratio.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description extensively explains returned fields, data provenance, ratio calculation, denominator basis, currency-conversion caveats, and missing-data limitations. This is unusually strong behavioral disclosure for a read-only retrieval 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?
The description is front-loaded with purpose and return fields, then organized into explanatory paragraphs about ratio semantics and caveats. It is long but dense with relevant data-interpretation context, with little obvious filler.
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 explaining return values and does so comprehensively, including field meanings, ratio derivation, and data-quality limitations. It is complete enough for an agent to interpret and use the result correctly.
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 the input schema already documents country, list_all, and program_id thoroughly. The description reinforces the list_all behavior but adds little parameter meaning beyond what the schema provides.
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: fetching detailed data on a national sovereign AI compute program. It also clarifies the internal list_all mode, but it does not explicitly distinguish this tool from siblings such as scrutica_search or 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Fetch detailed data' and by the note that list_all returns a summary table instead. However, the description does not explicitly say when to use this tool versus scrutica_search or other retrieval tools, nor does it name exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return supply-chain relationships for one or more organizations. direction = 'upstream' traces suppliers (who feeds this entity); 'downstream' traces customers (who depends on this entity); 'both' returns both. Each edge carries supplier_org_id, customer_org_id and data_source; product_service, category, sole-source status, share and criticality appear only where the edge's cited source states them for that pair, and attribute_withholding gives the reason for every withheld value. Collection size: 20,684 supply-chain records across all sources (snapshot 2026-10-29). Of these records, 1,924 come from a licensed layer limited to relationships between organizations already in Scrutica's records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| org_id | No | Alias for org_ids; a single id may be passed as a bare string. | |
| org_ids | No | REQUIRED. Scrutica org IDs in 'org-<slug>' format (e.g. ['org-nvidia', 'org-tsmc']), 1-5 of them. Optional in the schema only so the single-id aliases below can stand in. | |
| direction | No | both | |
| company_id | No | Alias for org_ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond readOnlyHint by disclosing data-coverage reality: which edge fields always appear, which appear only when the cited source states them, that attribute_withholding explains every gap, and that 1,924 of 20,684 records come from a licensed layer restricted to already-known organizations. Those are exactly the caveats an agent needs before treating a sparse edge as a negative finding.
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?
Four sentences, front-loaded with the core purpose and direction semantics before the coverage caveats. Every sentence carries information, though the final snapshot-count sentence is dense enough that it could be tightened without losing the caveat.
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 correctly does the work of explaining returned edge fields and their conditional population, plus a snapshot date for staleness. Missing only pagination/limit behavior and whether limit applies per organization, which matters for a tool accepting up to five org IDs.
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 real meaning for direction (the highest-value parameter) that the schema's bare enum lacks. The org identifier aliasing and the limit/default behavior are left to the schema, which documents org_ids and the ids well but says nothing about limit.
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 opens with a specific verb and resource ("Return supply-chain relationships for one or more organizations") and immediately explains what each direction value traces. That is enough to distinguish it from entity-oriented siblings at a glance, though no sibling is named explicitly.
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 direction values are defined in operational terms — upstream = who supplies this entity, downstream = who depends on it, both = union — which tells an agent exactly which mode to pick. There is no guidance on when to prefer this tool over siblings or on how the results differ in cost or scope, 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.
Look up BIS Entity List designations for companies or countries. The queried dataset is the US Commerce Department Entity List, Federal-Register-anchored; it does NOT cover OFAC SDN or Wassenaar CCL (for an organization's Section 1260H, NS-CMIC or FASCSA listing, use scrutica_get_company — its us_restrictive_listings rows and the on_1260h / on_ns_cmic flags derived from them; OFAC's SDN list is not ingested, and on_ofac_sdn is null). entity_name is a case-insensitive substring match against the designated entity's published name (no alias expansion). Returns entity_name, entity_type, country, list_type, designation_date, removal_date, grounds, federal_register_citation, source_url (Federal Register notice URL), data_quality_flags. Provide entity_name or country. entity_id filtering is not implemented: an entity_id-only call is rejected; alongside a supported filter, entity_id is ignored and the response sets entity_id_ignored: true. VEU authorization removals are returned separately in regulatory_events (maximum 50, with count and truncation); they do not contribute to designation membership or counts. Event effective_date and publication_date are distinct. Authority tier: Federal-Register-anchored designations are Tier 1 (primary source). bis_coverage_class discriminates how a row is covered: explicitly_named (FR notice cites the entity by name) vs affiliate_50pct_rule (inferred via BIS's 50% Affiliates Rule). coverage_note is populated only on affiliate_50pct_rule rows and states whether that rule is currently suspended. data_quality_flags is an array of provenance/caveat notes, empty for most rows; where present (derived-country provenance, removal-date sourcing, or the affiliate rows' suspension and substrate-reproducibility caveats) treat it as load-bearing context for the row.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| country | No | ISO 3166-1 alpha-2 | |
| entity_id | No | Retained for compatibility; filtering by this ID is not implemented. An ID-only call is rejected; with entity_name or country, the ID is ignored and entity_id_ignored is true. | |
| entity_name | No | Case-insensitive substring of the designated entity's published name; no alias expansion. Supply entity_name or country. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply readOnlyHint, so the description carries most of the burden and does so well: no alias expansion, 50-event cap with count and truncation on regulatory_events, entity_id_ignored signaling, the explicitly_named vs affiliate_50pct_rule coverage distinction, and the instruction that data_quality_flags is load-bearing. These are real behavioral traits an agent could not infer from 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?
Purpose and scope are front-loaded correctly, but the long parenthetical on OFAC/1260H is dense and the OFAC exclusion is stated twice ('it does NOT cover OFAC SDN' and 'OFAC's SDN list is not ingested, and on_ofac_sdn is null'). The entity_id rules are also duplicated verbatim from the schema, adding bulk without new 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 read-only lookup with no output schema, the description enumerates the returned fields (entity_name through data_quality_flags), explains the provenance tier, and clarifies the semantics of the two non-obvious output attributes (bis_coverage_class, coverage_note). Nothing an agent needs to call or interpret the result 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 75%, so entity_name and entity_id are already documented, and the description largely restates the entity_id rejection semantics rather than adding new detail. It does add value on matching behavior (substring, no alias expansion) and the entity_name-or-country disjunction, but leaves the limit parameter (default 20, max 50) and country usage unelaborated.
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?
Opens with a specific verb and resource ('Look up BIS Entity List designations for companies or countries') and immediately bounds the scope by naming what it does NOT cover (OFAC SDN, Wassenaar CCL) and which sibling handles adjacent data ('use scrutica_get_company'). An agent can distinguish this from scrutica_get_company and scrutica_search 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 required filter ('Provide entity_name or country'), the failure mode for entity_id-only calls (rejected), the fallback behavior for mixed calls (ignored plus entity_id_ignored: true), and exactly which alternative tool to use for 1260H/NS-CMIC/FASCSA listings. Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search facilities, companies, or sovereign programs by free-text query. Returns ranked results with id, name, type, one-line summary, and Scrutica URL. Filter by entity_type to scope to a single class. Filter by ISO 3166-1 alpha-2 country code. Do NOT use this for BIS Entity List / export-control lookups — use scrutica_query_export_controls. Do NOT use this for supply-chain traversal — resolve an entity ID first via this tool, then call scrutica_get_supply_chain.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Free-text search query | |
| country | No | ISO 3166-1 alpha-2 country code (e.g. US, CN, TW) | |
| entity_type | No | Limit results to this entity class | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds context about search scope (facilities/companies/sovereign programs), return format (ranked results with id/name/type/summary/URL), and explicit exclusions, which go beyond the annotation but don't cover rate limits 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?
Four sentences, all substantive: purpose, return type, filters, and exclusions. Front-loaded with the main action, no filler.
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 search tool with no output schema, the description covers purpose, return fields, filters, and exclusions well. It lacks pagination/limit behavior details, but the schema covers limits, and the exclusions make it quite complete for selection.
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 covers 75% of parameters with descriptions (query, country, entity_type). The description reinforces the filtering semantics ('Filter by entity_type', 'Filter by ISO 3166-1 alpha-2 country code') but adds no new details beyond schema, and limit remains undocumented in both.
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 'Search facilities, companies, or sovereign programs by free-text query' with a specific verb and resource scope. It also lists return fields and explicitly distinguishes from sibling tools like scrutica_get_company and scrutica_query_export_controls.
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 when-to-use context ('by free-text query') and clear when-not-to-use with named alternatives: 'Do NOT use this for BIS Entity List / export-control lookups — use scrutica_query_export_controls' and 'Do NOT use this for supply-chain traversal — resolve an entity ID first via this tool, then call scrutica_get_supply_chain'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
scrutica_get_scenario1 field changedInput schema / properties / scenario_id / enumPrevious value: -[
- "taiwan-strait",
- "iran-threat",
- "tokyo-earthquake",
- "south-china-sea",
- "abqaiq-2"
-]New value: +[
+ "taiwan-strait",
+ "iran-threat",
+ "tokyo-earthquake",
+ "abqaiq-2"
+]Coordination Intelligence: AI infrastructure coordination dynamics across geopolitical blocs
AI infrastructure tracker: data center campuses, power projects, MW and the companies behind them
US-government semiconductor & quantum supply-chain intelligence: controls, entities, funding.
Geopolitical grounding for AI agents: country risk, forecasts, chokepoints, sanctions. Free tier.
Add one secure layer between your agents and this server.
