Skip to main content
Glama

Silicon Floor

by com.siliconfloor
OverviewDiscussionsAdmin

Relationships between companies, investors and people

get_relationships
Read-only

Returns the relationship graph around a company, an investment house or a person — every relationship a filed fact with the filings that prove it: who holds the company (13F, Schedule 13D/G, Form 4: share of capital), which companies hold shares of other companies (invests_in: NVIDIA in CoreWeave, Alphabet in SpaceX), its officers and directors and their roles, who holds warrants, convertibles or preferred shares in it (holds_rights_in: AMD's warrant to Meta, Akamai's to Anthropic), and who buys from whom: the customers a company names in its own filings, with their share of its revenue (customer_of, from the customer to the company that names it: NVIDIA is 16% of Fabrinet's revenue, Apple 91% of Cirrus Logic's, Samsung a customer of Applied Materials, Qorvo and FormFactor) — and the contracts named in 8-K, 6-K, 10-Q, 10-K and prospectuses: customer_of when the filing says who buys from whom (Microsoft and NVIDIA from IREN, OpenAI from CoreWeave, Anthropic and Fluidstack leasing from TeraWulf), agreement_with when it does not (Intel and NVIDIA), each contract with its title, value as stated, term, megawatts, signing date and document — and who acquired whom: acquired, from the buyer to what it acquired, whichever side filed it (Skyworks and Qorvo; AMD and ZT Systems; Sanmina buying ZT Systems' manufacturing business from AMD), each deal with what changed hands (the company, a business, a stake), agreed or completed, its date, the full price when stated and its document — then, as sources are added, suppliers named in annual reports, competitors named by the company and lenders. Private companies are nodes too (Anthropic, OpenAI, Nscale): named by a filing, with no price or financials. depth: 2 adds the neighbours' relationships (who else Vanguard holds, where else a director sits). Use it when the user asks how companies are connected, who is behind a company, or what links two of them. For the full list of a company's shareholders with bounds and moves, use get_ownership; for one investor's portfolio, get_holders.

Input Schema

NameRequiredDescriptionDefault
viewNoWhich relationships (default 'all').
depthNo1 (default): the center's relationships; 2: its neighbours' too.
limitNoHow many relationships at most (default 40, max 200).
sinceNoOnly relationships whose proving filing is dated on or after this day (YYYY-MM-DD).
centerYesThe company, house or person at the center: a ticker, a company name (listed or not: 'Anthropic'), a holder's key or name ('vanguard', 'Elon Musk'), or a typed id from a previous answer (company:nvda, holder:vanguard, person:<id>, gov:us).
statusNo'active' (default): relationships the filings still state — a customer the supplier's latest report still names, a contract not past its stated term; 'all': past ones too, each with its relationshipStatus (not_restated, expired).
naturesNoComma-separated natures within the view: owns, invests_in, holds_rights_in, insider_of, customer_of, supplier_of, agreement_with, acquired, competes_with, lends_to.
minShareNoMinimum share of capital, as a fraction (0.01 = 1%), for ownership relationships.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / status / description
      Previous value: -"'active' (default): relationships the filings still state — a customer the supplier's latest report still names, a contract still restated and not past its stated term; 'all': past ones too, each with its relationshipStatus (not_restated, expired)."New value: +"'active' (default): relationships the filings still state — a customer the supplier's latest report still names, a contract not past its stated term; 'all': past ones too, each with its relationshipStatus (not_restated, expired)."
  2. Changed1 schema field changed
    • addedInput schema / properties / status
      Added value: +{
+  "description": "'active' (default): relationships the filings still state — a customer the supplier's latest report still names, a contract still restated and not past its stated term; 'all': past ones too, each with its relationshipStatus (not_restated, expired).",
+  "enum": [
+    "active",
+    "all"
+  ],
+  "type": "string"
+}
  3. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: every edge is a filed fact tied to a proving document, private companies appear as nodes with no price or financials, and depth=2 fans out to neighbours' relationships. It stops short of describing result ordering, pagination shape, or behavior when the center is ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but it is then delivered as a single sprawling em-dash sentence stuffed with dozens of illustrative examples (Fabrinet, Cirrus Logic, TeraWulf, ZT Systems, and more) that repeat what the enumerated nature list already conveys. The length is far beyond what an agent needs to select and call the tool, and the run-on structure hurts parseability.

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?

For a complex multi-parameter graph tool with no output schema, the description does substantial work: it explains what each relationship carries (title, stated value, term, megawatts, signing date, document) and what changed hands for acquisitions. Missing is any indication of ordering, truncation behavior with limit, or how empty results present, which the absent output schema would otherwise have to cover.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter including center's accepted id forms, natures, status, minShare and since is already documented in the schema. The description's depth:2 explanation largely restates the schema's own wording ("its neighbours' too"). With the schema doing the heavy lifting, 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 description opens with a specific verb+resource ("Returns the relationship graph around a company, an investment house or a person") and enumerates the exact edge types it yields (owns, invests_in, holds_rights_in, customer_of, agreement_with, acquired) with concrete examples. It explicitly differentiates itself from siblings get_ownership and get_holders, so an agent can route correctly without opening any 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?

It states the trigger conditions directly: "Use it when the user asks how companies are connected, who is behind a company, or what links two of them." It also names the two alternatives and the conditions that select them — get_ownership for a full shareholder list with bounds and moves, get_holders for one investor's portfolio.

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

All Silicon Floor 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