Skip to main content
Glama

scrutica_get_facility

Read-only

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.

Input Schema

NameRequiredDescriptionDefault
idNoAlias for facility_id.
entity_idNoAlias for facility_id.
facility_idNoREQUIRED. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / entity_id
      Added value: +{
      +  "description": "Alias for facility_id.",
      +  "type": "string"
      +}
    • changedInput schema / properties / facility_id / description
      Previous 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."
    • addedInput schema / properties / id
      Added value: +{
      +  "description": "Alias for facility_id.",
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "facility_id"
      -]
  2. Changed1 schema field changed
    • changedInput schema / properties / facility_id / description
      Previous value: -"Canonical Scrutica facility ID (e.g. 'epoch-dc-001')"New 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."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources