Skip to main content
Glama
Sign In

Scrutica

by io.github.davidgringras
OverviewDiscussionsAdmin

scrutica_get_company

Read-only

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.

Input Schema

NameRequiredDescriptionDefault
idNoAlias for company_id.
org_idNoAlias for company_id.
entity_idNoAlias for company_id.
company_idNoREQUIRED. 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_idNoAlias for company_id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / company_id / description
      Previous 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."
    • addedInput schema / properties / entity_id
      Added value: +{
+  "description": "Alias for company_id.",
+  "type": "string"
+}
    • addedInput schema / properties / id
      Added value: +{
+  "description": "Alias for company_id.",
+  "type": "string"
+}
    • addedInput schema / properties / org_id
      Added value: +{
+  "description": "Alias for company_id.",
+  "type": "string"
+}
    • addedInput schema / properties / organization_id
      Added value: +{
+  "description": "Alias for company_id.",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "company_id"
-]
  2. Changed1 schema field changed
    • changedInput schema / properties / company_id / description
      Previous value: -"Canonical Scrutica organization ID (e.g. 'nvidia', 'tsmc', 'huawei')"New 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."
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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

With no output schema, the description 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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Scrutica toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources