AI compute infrastructure intelligence: facilities, supply chains, sovereign AI, export controls.
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, entity / addition / removal counts, 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 entity_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). 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?
Beyond the readOnlyHint annotation, the description discloses bounded results, the 24-event cap, truncation in metadata, separate date-keyed removal events, zero-count week semantics, and the derivation of event dates with authority tier. These are exactly the non-obvious behaviors an agent needs to interpret results correctly.
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 long but proportionally so for a complex tool; it front-loads purpose and routing, organizes return semantics into labeled paragraphs, and every sentence carries operational meaning. No filler is present.
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 it does: event composition, counts, samples, rollup, truncation, and removal handling. It also clarifies zero-count weeks and authority sourcing, so an agent has enough context to call and interpret the tool 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 still adds value by explaining that 'count field always reports the full total in scope,' that truncation appears in metadata, and that company_id only matches entities in the cross-reference id space — avoiding false scoping assumptions.
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 defines a specific operation and resource: 'What CHANGED in the BIS Entity List, as bounded change-log summaries.' It also names the sibling it competes with (scrutica_query_export_controls) and the freshness scenario, so an agent can tell them apart without opening schemas.
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 routing: 'PREFER this over scrutica_query_export_controls for freshness questions' and 'Do NOT use this to look up one entity's designation rows — use scrutica_query_export_controls.' It also scopes company_id to an already-resolved organization, clarifying when the parameter is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute peak BF16 FLOP estimates for a hardware configuration. Returns point estimate + bounds. Methodology matches the Interactive Methodology Explorer at /methodology#flop-estimation. Do NOT present outputs as exact measurements — always relay the bounds and the is_estimated flag.
| Name | Required | Description | Default |
|---|---|---|---|
| sparsity | No | Structured-sparsity mode. NOTE: both values currently apply a 1.0x multiplier — the theoretical 2x speedup of 2:4 sparsity rarely materializes in wall-clock training throughput, so this estimator deliberately does not credit it (see the response note and /methodology#flop-estimation). The parameter is accepted and echoed for forward compatibility only. | dense |
| precision | No | bf16 | |
| unit_count | Yes | Number of accelerators | |
| utilization | No | Sustained utilization (MFU) fraction (default 0.40; documented range 0.20–0.50, calibrated to PaLM 540B 0.462 and LLaMA 3 405B 0.384) | |
| hardware_type | Yes | GPU / accelerator model |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that the result is an estimate with bounds and an is_estimated flag, and that it matches the Interactive Methodology Explorer. This adds meaningful behavioral context about uncertainty and output interpretation. It does not over-explain side effects, but for a read-only estimation 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?
The description is three concise, front-loaded sentences. The first sentence states the primary action, the second names the return structure and methodology link, and the third gives a critical usage caution. Every sentence earns its place with no redundancy or 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 compensates by stating the return format (point estimate + bounds) and the is_estimated flag. It also references the methodology URL for deeper context. It could mention units or clarify how the precision parameter interacts with 'BF16,' but overall it provides enough context for an agent to invoke the tool and interpret results.
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 already documents 4 of 5 parameters with descriptions (80% coverage), so the baseline is 3. The tool description itself does not add detailed parameter-level semantics beyond noting 'BF16' and 'hardware configuration,' which maps loosely to the precision and hardware_type/unit_count parameters. This is sufficient but not exceptional.
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: 'Compute peak BF16 FLOP estimates for a hardware configuration.' This clearly distinguishes the tool from its siblings, which all concern entity lookups or searches. It also immediately conveys the tool's core purpose and precision focus.
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 clear usage context by stating the tool returns a point estimate plus bounds and points to a methodology reference. It also gives an explicit 'do not' instruction: 'Do NOT present outputs as exact measurements — always relay the bounds and the is_estimated flag.' It does not name alternative tools, but the context is sufficient given the sibling set.
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. 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?
The readOnlyHint annotation already indicates a safe read operation. The description adds useful behavioral context by listing the concrete fields returned and warning that only summary edge counts are included, not full graphs, which prevents unrealistic expectations. It also explains the resolver prerequisite without contradicting any annotations.
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 first, then return fields, then explicit alternatives. Every sentence carries useful information with 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?
There is no output schema, but the description lists the key return fields, notes parent/subsidiary references and edge counts, and warns about using a different tool for full graphs. Together with the parameter schema, the agent has enough to call the tool and interpret its 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%, and the schema already documents the alias relationship and the required format 'org-<slug>'. The description reinforces "canonical Scrutica ID" and the need to resolve via search, but most parameter nuance is already present in the schema, so the description adds little beyond the baseline.
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 verb and resource — "Fetch complete details for a single organization" by canonical Scrutica ID — and explicitly distinguishes itself from siblings by naming what to use instead for BIS details and full edge graphs. This lets an agent immediately recognize the tool's niche.
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?
It gives explicit routing guidance: use scrutica_query_export_controls for BIS designation details, and scrutica_get_supply_chain for full edge graphs. The parameter docs also instruct agents to resolve the ID via scrutica_search first and not to guess slugs, which is essential when to use and how to prepare.
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: operator, owner, country, 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). For BIS Entity List designations tied to the facility's owner, look up the owner org 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 carry only readOnlyHint=true and a short title. The description adds meaningful behavior beyond that: the tool returns estimated and data-quality flags, only includes GPU inventory where disclosed, and explicitly does not compute BIS ownership-chain exposure. It conveys the tool's limitations and data caveats without contradicting the annotations.
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 well-structured and front-loaded: a one-sentence purpose, a concise returns list, then two clear routing statements. Every sentence contributes meaningful information, and there is no wordy filler or redundancy with the schema.
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?
There is no output schema, so the description carries the burden of explaining the return payload, and it does by enumerating operator, owner, capacity, GPU inventory, location, status, source, data-quality flags, and more. It also handles the ID-resolution prerequisite, alias options, and the division of labor with adjacent tools. Nothing needed for correct invocation or basic interpretation 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 description coverage is 100%, so the baseline is 3. The schema already fully explains facility_id, its alias relationships, the canonical ID format, and the 'supply exactly one' rule. The description largely repeats these details and adds no new parameter semantics beyond what the schema already 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 starts with a specific verb 'Fetch complete details for a single Scrutica facility by canonical ID', identifying both the resource and the access pattern. It then enumerates the return fields, and the final lines distinguish the tool from related sibling tools such as scrutica_query_export_controls and scrutica_search.
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 is provided: 'Resolve facility IDs first via scrutica_search' and for BIS Entity List designations, use scrutica_query_export_controls instead. The description also explicitly states what this tool does not compute (ownership-chain BIS exposure), giving concrete when-to-use and when-not-to-use guidance.
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), 'south-china-sea' (submarine cable severing), '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?
While annotations already declare readOnlyHint=true, the description adds substantial behavioral context: returns summary plus serialized substrate with per-item sources and authority tiers, notes capped lists shipping true totals, and explicitly states the propagation simulation is interactive-only. This goes well beyond the annotation.
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 three well-structured sentences: purpose, available values with inline explanations, and return behavior. Every sentence adds necessary information, and the critical limitations are front-loaded in the final sentence.
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 fully covers what the tool returns (summary + substrate), what it does not return (simulation), and the capping behavior. The single parameter is completely explained via the listed scenario IDs, making the tool self-contained.
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 provides only an enum of scenario_id values with zero descriptions. The description compensates by explaining each value (e.g., 'taiwan-strait (4 TSMC disruption scenarios)'), giving the agent full semantic understanding of the only 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 opens with a specific verb and resource: 'Fetch geopolitical compute risk scenarios.' It then lists the available scenarios with their unique contents, which clearly distinguishes this tool from sibling get_* tools for companies, facilities, supply chains, etc.
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 clear context that this tool is for risk scenarios, but it does not explicitly name alternative tools or state when not to use it. The sibling tool names imply the domain, yet the guidance is not fully explicit.
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, 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.
| 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?
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.
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.
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.
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.
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.
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.
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, product_service, data_source, and nullable numerical and sole-source attributes. Dataset: 18,980 edges from a licensed supply-chain database (held under subscription, not redistributed) plus SEC Exhibit 21 (substrate snapshot 2026-09-05).
| 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?
Beyond the readOnlyHint annotation, the description discloses return-edge fields (supplier_org_id, customer_org_id, product_service, data_source), nullability, dataset scale (18,980 edges), and data provenance/licensing constraints (subscription database plus SEC Exhibit 21 snapshot). This gives the agent a clear picture of what the call returns and what data coverage to expect.
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 tight sentences cover purpose, direction semantics, and output/data provenance with no filler. The most decision-critical information for choosing a direction is front-loaded, and 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?
With no output schema, the description supplies the missing return contract (edge attributes) and data-source context. Combined with schema descriptions for org_ids and direction, an agent has everything needed to form a correct request 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?
The description adds plain-language definitions for the direction enum that the schema does not explain, e.g., upstream 'traces suppliers (who feeds this entity)' and downstream 'traces customers (who depends on this entity)'. It also reinforces that multiple organizations are supported, while the org_ids/org_id/company_id alias relationships are already documented in 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 opens with a specific verb and resource: 'Return supply-chain relationships for one or more organizations.' It also explains direction semantics (upstream/downstream/both), which clearly distinguishes it from sibling tools like scrutica_search or scrutica_get_company by naming the exact domain and edge structure.
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 implies when the tool applies (any supply-chain relationship query) and explains how to choose direction, but it never explicitly says when not to use it or which sibling tool to prefer instead. This is adequate contextual inference, but it lacks explicit routing guidance such as 'use get_company for org profile details'.
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 OFAC SDN / NS-CMIC / Section-1260H status, use scrutica_get_company — the record has on_ofac_sdn / on_ns_cmic / on_1260h booleans). 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. 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 | Scrutica org ID (exact match) | |
| entity_name | No | Company name (fuzzy matched against aliases) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true, so the description carries the burden of behavioral disclosure. It goes far beyond by disclosing dataset anchoring (Federal Register), authority tier (Tier 1), coverage classes, the 50% affiliates rule, and the load-bearing nature of data_quality_flags. No contradiction with annotations.
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 dense but purposeful; each segment covers a distinct aspect: scope, exclusions, matching semantics, return fields, coverage classification, and data-quality caveats. It is front-loaded with the core purpose and main alternative. Slight redundancy around 'Federal-Register-anchored' and the lack of visual structure keep it from a perfect score.
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 enumerates returned fields and their semantics, including source_url and data_quality_flags. It also resolves practical questions an agent would have: what dataset, what exclusions, how entity_name matches, and what coverage_note/bis_coverage_class mean. This is complete for a read-only lookup tool.
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 important operational meaning for entity_name — case-insensitive substring match, no alias expansion — but this directly contradicts the input schema's entity_name description ('fuzzy matched against aliases'), creating ambiguity. It does not add parameter guidance for limit, country, or entity_id beyond what the schema already states. The contradiction makes the parameter semantics less reliable.
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 opening line names a specific verb ('Look up') and a specific resource ('BIS Entity List designations') for companies or countries, and the following sentence distinguishes it from adjacent OFAC/Wassenaar coverage by naming scrutica_get_company. It clearly identifies the US Commerce Department Entity List dataset.
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 when this tool is relevant, lists what it does NOT cover (OFAC SDN, Wassenaar CCL), and directs the agent to scrutica_get_company for OFAC/NS-CMIC/1260H status. It also defines the matching semantics, helping an agent decide whether this lookup is the appropriate one.
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. Dates show when Glama detected each change.
scrutica_entity_list_changes1 field changedInput schema / properties / company_id / descriptionPrevious value: -"Scope to change events touching one organization. Canonical Scrutica org ID ('org-<slug>'); the id space is the matched_org_id values the BIS cross-reference carries, so designated entities without a compute-substrate cross-reference never appear under a scope. Kept events retain their full entity context."New value: +"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."scrutica_get_sovereign_program1 field changedInput schema / properties / program_id / descriptionPrevious value: -"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 carry 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."New value: +"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."scrutica_get_company6 fields changedInput schema / properties / company_id / descriptionPrevious value: -"Canonical Scrutica organization ID. Format: 'org-<slug>' (e.g. 'org-nvidia', 'org-tsmc', 'org-huawei'). Resolve via scrutica_search first — do NOT guess slugs."New value: +"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."Input schema / properties / entity_idAdded value: +{
+ "description": "Alias for company_id.",
+ "type": "string"
+}Input schema / properties / idAdded value: +{
+ "description": "Alias for company_id.",
+ "type": "string"
+}Input schema / properties / org_idAdded value: +{
+ "description": "Alias for company_id.",
+ "type": "string"
+}Input schema / properties / organization_idAdded value: +{
+ "description": "Alias for company_id.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "company_id"
-]scrutica_get_facility4 fields changedInput schema / properties / entity_idAdded value: +{
+ "description": "Alias for facility_id.",
+ "type": "string"
+}Input schema / properties / facility_id / descriptionPrevious value: -"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."New value: +"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."Input schema / properties / idAdded value: +{
+ "description": "Alias for facility_id.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "facility_id"
-]scrutica_get_supply_chain4 fields changedInput schema / properties / company_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ ],
+ "description": "Alias for org_ids."
+}Input schema / properties / org_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ ],
+ "description": "Alias for org_ids; a single id may be passed as a bare string."
+}Input schema / properties / org_ids / descriptionPrevious value: -"Scrutica org IDs in 'org-<slug>' format (e.g. ['org-nvidia', 'org-tsmc'])"New value: +"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."Input schema / requiredRemoved value: -[
- "org_ids"
-]Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Coordination Intelligence: AI infrastructure coordination dynamics across geopolitical blocs
US-government semiconductor & quantum supply-chain intelligence: controls, entities, funding.
Geopolitical grounding for AI agents: country risk, forecasts, chokepoints, sanctions. Free tier.
Dated, sourced semiconductor data: chip costs, HBM/wafer pricing, fab capacity, policy, forecasts.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
