Skip to main content
Glama
ferinator

Bullrun

by ferinator
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get company relationship network

get_company_relationships
Read-only

Maps a stock's competitors, suppliers, customers and partners with tickers, verified status, confidence, dependence and evidence to support supply-chain and second-order risk analysis.

Instructions

Bullrun's company relationship graph for one stock: named competitors, suppliers, customers and partners, each with its Bullrun ticker when the counterparty is listed, verification status (VERIFIED against a primary filing/source vs search-SUGGESTED), confidence, sole-source flag, quantified dependence where disclosed (e.g. "Cirrus Logic gets 91% of revenue from Apple") and the evidence behind it. Use for supply-chain and second-order risk questions ("who supplies X", "who depends on X", "who competes with X", "which listed companies are exposed if X stumbles"), then call get_company_risk or get_stock_metrics on the counterparties' tickers. Returns only the cached graph and never starts a paid discovery run; a company with no graph yet reports status "none". A missing edge is not proof of no relationship. Read-only.

Input Schema

NameRequiredDescriptionDefault
rolesNoWhich relationships to return, from this company's point of view. Default: all four.
tickerYesBullrun ticker, e.g. "AAPL", "SAP", "ASML". Use the listing ticker returned by search_stocks. US/European examples: AAPL, BMW, NESN. Most Asian listings keep their exchange suffix (6324.T, 0700.HK); some use bare codes (005930). Native or suffixed forms resolve only when one listing matches; search by company name or ISIN if unsure.
evidenceNonone = omit evidence sources, keeping counterparties, measurements and evidence counts; sources = source title/URL/type per edge; excerpts = also quoted evidence text.sources
limitPerRoleNoMax counterparties per role, verified and highest-confidence first.
verifiedOnlyNotrue = only edges confirmed against a primary source (filing, company release). false also returns search-suggested edges, each labelled with its status and confidence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.9.0
    • changedInput schema / properties / evidence / description
      Previous value: -"none = counts only; sources = source title/URL/type per edge; excerpts = also the quoted evidence text."New value: +"none = omit evidence sources, keeping counterparties, measurements and evidence counts; sources = source title/URL/type per edge; excerpts = also quoted evidence text."
    • changedInput schema / properties / ticker / description
      Previous value: -"Bullrun ticker, e.g. \"AAPL\", \"SAP\", \"ASML\". Bullrun tickers: US and most European listings use the plain local symbol (AAPL, BMW, NESN, ABBN); most Asian and Indian listings keep their exchange suffix (Tokyo 6324.T, Hong Kong 0700.HK, Shanghai 600519.SS, Shenzhen 000001.SZ, Taiwan 2330.TW, Korea 000100.KS, Singapore D05.SI, India RELIANCE.NS), but some Japanese and Korean large caps are plain codes (Toyota 7203, Samsung 005930). Either form is resolved automatically when exactly one listing matches; use search_stocks to find a ticker by company name or ISIN."New value: +"Bullrun ticker, e.g. \"AAPL\", \"SAP\", \"ASML\". Use the listing ticker returned by search_stocks. US/European examples: AAPL, BMW, NESN. Most Asian listings keep their exchange suffix (6324.T, 0700.HK); some use bare codes (005930). Native or suffixed forms resolve only when one listing matches; search by company name or ISIN if unsure."
  2. Addedv0.7.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the read-only annotation, the description discloses that the tool returns only the cached graph and never starts a paid discovery run, that a company with no graph reports status 'none', and that a missing edge is not proof of no relationship. It also explains verification statuses, confidence, sole-source flags, and quantified dependence evidence, giving the agent important behavioral context.

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

Conciseness5/5

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

The description is front-loaded with the resource and returned fields, then moves to use cases, follow-on calls, caching behavior, and caveats. Despite its length, every sentence adds useful context and there is no obvious filler.

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?

With no output schema, the description sufficiently explains what the graph contains, including relationship roles, tickers, verification status, confidence, dependence metrics, and evidence. It also covers caching behavior, missing-data caveats, and safety context, so an agent has enough information to call and interpret the tool.

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 description coverage is 100%, so the schema already documents all five parameters in detail, including the roles enum, evidence modes, limitPerRole, and verifiedOnly. The description reinforces the role categories and verification/evidence concepts but does not add parameter-level 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the resource: Bullrun's company relationship graph for one stock, enumerating competitors, suppliers, customers and partners and the fields returned. It is specific, but it does not explicitly contrast this tool with close siblings such as find_stock_peers or compare_company_exposures; it only names follow-on tools like get_company_risk and get_stock_metrics.

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?

It provides explicit use cases ('who supplies X', 'who depends on X', 'who competes with X', second-order risk) and names follow-on tools to call on counterparties. It also discloses the cached-only limitation and the 'missing edge is not proof' caveat, but it does not explicitly say when not to use this versus a sibling like find_stock_peers.

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

Deploy Server

Other Tools