Bullrun

Compare shared company exposures

compare_company_exposures

Read-only

Compare relationship graphs for two to five stock tickers to find shared suppliers, customers, competitors, and partners with confidence levels, evidence status, and source links.

Instructions

Compare the cached company relationship graphs of two to five stock tickers. Finds shared suppliers, customers, competitors and partners, including cross-role overlaps, using stable company entity IDs or exact tickers only. Returns directed direct relationships with VERIFIED vs SUGGESTED/NEEDS_REVIEW status, confidence, sole-source flags, disclosed metrics with meaning/unit/period, and primary-source URLs/dates. Shared groups reference the evidence-bearing relationship rows by ID. Missing graphs or edges mean unknown coverage. One cached graph read per company (plus a ticker lookup when the typed ticker has no graph); never starts paid discovery, infers exposure weights or estimates portfolio losses. Read-only.

Input Schema

Name	Required	Description
`roles`	No	Counterparty roles from EACH subject company's point of view; default all four. Suppliers and customers preserve the direction of SUPPLIES_TO.
`tickers`	Yes	Two to five distinct Bullrun listing tickers, e.g. AAPL, BMW or 6324.T. 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. Company names are not accepted here.
`verifiedOnly`	No	Only VERIFIED edges when true. The default also includes SUGGESTED/NEEDS_REVIEW edges, explicitly labelled with their individual confidence and evidence.
`limitPerCompany`	No	Maximum direct relationships returned per input company. Shared counterparties are prioritized; totals and any truncation are reported.

Output Schema

Name	Required	Description	Default
`totals`	Yes
`tickers`	Yes
`webPage`	No
`warnings`	Yes
`companies`	Yes
`methodology`	Yes
`retrievedAt`	Yes
`platformLink`	No
`relationships`	Yes
`requestedRoles`	Yes
`sharedCounterparties`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.9.0Oct 30, 2026

changedInput schema / properties / tickers / description

Previous value: -"Two to five distinct Bullrun listing tickers, e.g. AAPL, BMW or 6324.T. 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. Company names are not accepted here."New value: +"Two to five distinct Bullrun listing tickers, e.g. AAPL, BMW or 6324.T. 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. Company names are not accepted here."

Changed1 schema field changedv0.8.1Oct 22, 2026

changedInput schema / properties / tickers / description

Previous value: -"Two to five distinct exact Bullrun listing tickers. Names and inferred exchange suffixes are not accepted."New value: +"Two to five distinct Bullrun listing tickers, e.g. AAPL, BMW or 6324.T. 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. Company names are not accepted here."

Addedv0.7.0Oct 19, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial context beyond the read-only annotations: cost profile (one cached graph read per company plus a possible ticker lookup, no paid discovery), evidence statuses (VERIFIED vs SUGGESTED/NEEDS_REVIEW with confidence and sole-source flags), and the critical caveat that missing graphs or edges mean unknown coverage rather than no relationship. That last point is a behavioral trap an agent would otherwise fall into.

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 the core action, then layered with cost and evidence caveats; nearly every sentence carries operational weight. It runs long and includes return-format detail that the output schema already provides, which slightly dilutes focus.

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?

Given a read-only tool with a full output schema and complete parameter descriptions, the definition is essentially complete: it covers cost, coverage gaps, evidence labeling and truncation. The return-shape sentence duplicates the output schema rather than adding new information, leaving only minor room for improvement.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds the constraint that only stable entity IDs or exact tickers are accepted and that results are per-input-company, reinforcing the truncation semantics of limitPerCompany. Minor tension: it mentions entity IDs while the schema accepts only tickers, but overall it adds value over the schema.

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 and resource: compare the cached relationship graphs of two to five tickers, finding shared suppliers/customers/competitors/partners. This clearly separates it from single-company siblings like get_company_relationships and from compare_stocks/compare_etfs.

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?

Gives clear context for use (cross-ticker shared counterparty analysis, including cross-role overlaps) and important exclusions: it never starts paid discovery, never infers exposure weights or portfolio losses. It does not explicitly name which sibling to use instead for single-company relationship lookups, so routing against alternatives is left partly implicit.

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

Deploy Server